"Mike Meyer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> http://martinfowler.com/articles/languageWorkbench.html > > Um - I see no mention of "AST" in that article at all. He's mostly > talking about "Language Oriented Programming" (seems to be another > term to describe DSLs) and "Language Workbenches".
AST means Abstract Syntax Tree and there are lots of mentions of ASTs and 'abstract syntax' in the collection of pages. Moreover, elevating abstract representations is the key idea of Fowler's essay. Near the beginning he says "This is a good moment to introduce a common distinction that you run into in programming language circles - the distinction between abstract and concrete syntax. The concrete syntax of a language is its syntax in its representation that we see. The XML and custom language files have different concrete syntaxes. However both share the same basic structure: you have multiple mappings, each with a code, a target class name, and a set of fields. This basic structure is the abstract syntax. When most developers think about programming language syntax they don't make this separation, but it's an important one when you use DSLs. You can think of this in two ways. You can either say we have one language with two concrete syntaxes, or two languages that share the same abstract syntax." Roth (following Fowler) talked about taking the first view of seeing the abstract syntax as the language with multiple possible concrete syntaxes. Fowler later introduces a section with the summary sentence "One of the strongest qualities of language workbenches is that they alter the relationship between editing and compiling the program. Essentially they shift from editing text files to editing the abstract representation of the program." Again, this is what John proposed for Python (if defined by its abstract syntax (high-level, I presume)). The multiple-paragraph explanation of the above includes "For the purposes of this discussion we can break the [traditional]compilation process into two steps. The first step takes the text from the file foo.cs and parses it into an abstract syntax tree (AST). The second step walks this tree generating CLR byte codes that it puts into an assembly (an exe file)." His companion article Generating Code for DSLs http://martinfowler.com/articles/codeGenDsl.html expands the sentence above and includes this: "What's the advantage of separating the two stages? It does cost us a bit of complexity - we have to add the AST classes. If we were only reading and writing to a single format it's arguable whether the AST is worth the effort - at least for this simple case. The real advantage in the AST lies when we want to read or write multiple formats." That is three "AST"s in three sentences, albeit on a different page of his multipage essay. Anyway, back where we were, Fowler continues that in a Language Workbench (by contrast to the traditional system) "The key difference here is that the 'source' is no longer the editable textual files. The key source that you manipulate is the abstract representation itself. In order to edit it, the language workbench projects the abstract representation into some form of editable representation. But this editable representation is purely transient - it's only there to help the human. The true source is the persistent abstract representation. " So it seems that John Roth proposes that Python become at least in part a 'Language Workbench' language. as Fowler defines his new term. It also seems that ASTs or some sort of abstract representation are central to such a system. Terry J.Reedy -- http://mail.python.org/mailman/listinfo/python-list
