Kay Schluehr <[EMAIL PROTECTED]> wrote: ... > work. Or maybe it works and I just have no clue how completely opaque > call graphs as they appear in functions like this > > def f(x): > h = g(x) > h() > > can be tracked sufficiently in "register-time" in order to capture > dependencies. It is not clear what h can be unless g is called and it > might be as hard as type-inference or completely impossible to figure > this out without executing g. If otherwise the checker can guarantee > detection of a few obvious cycles where dependencies can be tracked > also syntactically, at least in principle like in your example, what > exactly is ensured by the checker and how can the definition of a > typeclass be adapted accordingly?
My preference would be to have the dependency tracker mark explicit dependencies only; here, if this was in a typeclass with the appropriate additions of self., I'd mark f as dependent on g only. No real purpose is served by allowing dependencies to be specified in a "cloaked" form, anyway -- nor in going out of one's way to impede vigorous attempts by a programmer to shoot himself or herself in the foot. Alex -- http://mail.python.org/mailman/listinfo/python-list
