On Sun, 7 Aug 2005 18:37:42 -0400, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> >"John Roth" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> http://martinfowler.com/articles/languageWorkbench.html > >This clarified your proposal for Python considerably. So I note that now >and especially once the AST compiler is completed, you are quite free to >start a Python AST Extension (PASTE) project quite independently of Guido >and the PSF developers. Build an AST-based editor like Fowler described, >with transient text presentations. (And pick your preferred GUI for doing >so.) Or design a system for translating domain-specific languages into >PyASTs, from whence they can be compiled to bytecode and run. > (Not implying that you need this for your edification ;-) I think the relationship of abstract entities and their concrete representations is very interesting. And it is useful to note that the representation of an AST in computer memory with a python interpreter looking at the AST node representations involves another layer of concrete representation. And the interpreter is an abstraction with a concrete representation, etc. down to the CPU as interpreter of of instructions etc., and the CPU being an abstraction made concrete my aggregating concrete elements chosen for their physical nature as representations of abstractions and behaving so as to transform concrete states in ways that reflect the transformations of the corresponding abstractions. And so forth ;-) IOW, a compiled python program AST in the abstract, would be the same abstraction even if both compiler and tree represention were done in lisp and you had lispython instead of cpython etc. Or whether we kept track of everything scribbling in beach sand with our toes. BTW, maybe this is a place to mention the concept of an AST decorator, that works like a function decorator except that it is prefixed with @@ instead of @ and it operates at compile time when the AST becomes available, but before it gets translated to code, and what gets passed to the decorator is the AST and the node of its own call (which it would typically eliminate from the AST as it does whatever else it is programmed to do). Which means that the decorator must already be compiled and avaiable at that point, so it can be looked up somewhere by the name. The idea is that this form of decoration could transform the AST arbitrarily before code generation, and be a very flexible tool for mischief of course, but also useful tricky things IWT. Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
