At 05:52 PM 3/28/2006, Dino Viehland wrote (in part) >[snip]There's actually a lot of interesting problems [with] runtime vs. >compile time. For example if we were to do a from __experimental__ import ... >for optional static typing [snip]
At least one interpreter for a different dynamic language (APL) has the notion of "compiling" each line of code to a stack-based list of (internal) method invocations that smells (to me) a tad like what Forth is -- there's no "interpreted language" overhead left (tho there is "dynamic typing" overhead). It "compiles" a line when it's first encountered for execution. It also records the assumptions that are implicit in the decisions about what internal methods should be invoked, and re-processes the line if those assumptions turn out to be incorrect. Whether the initial "compile" activity takes place during a compile step or at runtime, it should be possible to keep track of the decisions that were made and potentially replace the code if it turns out that the decision is wrong. (Or, rather than replace the code, have both versions of the code in memory and invoke the one that matches the current situation in the future.) I had suggested something similar when dealing with the "what's the right CLR method overload to call" issue. In Python-think, there'd be a dictionary with the key being a tuple formed from the identity of the CLR method to be invoked (assembly, class, method). The associated value would be a dictionary; in that, the key is a tuple of the Python types of the parameters presented in this attempt to call the method, and the value is (normally) the identity of the CLR method to be invoked -- and if any of the Python values need to be "diddled" to match the chosen CLR overload, the referenced CLR method would be one dynamically constructed that (e.g.) converts a Python float to a CLR int64 and calls ToString on a Python class before calling the CLR method named in the source. (If the programmer discovers a wrong overload guess by IP, it should be possible to mark the guess as incorrect so the overload-guesswork will be done again -- but the info about the bad guess has to stay in the dictionary so that the same guess won't be made again. That's why I said "normally" above; details left to the reader <g>.) The same kind of thing could be done for calling Python methods, or evaluating any Python expression, so you get different code generated when (e.g.) the method is called with (string, int) than when it's called with (int, string). In other words, record what happened before that resulted in a particular "static" code block getting generated, and be prepared to do it again if things are different at the next call. But if you want Python with static typing, you can just use Boo <g>. J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
