Diez B. Roggisch wrote: <...>
>> The whole point of a code transformation mechanism like the one Anton is >> talking about is to be dynamic. Else one just needs a preprocessor... > > No, it is not the whole point. The point is > > "" > The idea is that we now have a fast parser (ElementTree) with a > reasonable 'API' and a data type (XML or JSON) that can be used as an > intermediate form to store parsing trees. Especially statically typed > little languages seem to be very swallow-able. Maybe I will be able to > reimplement GFABasic (my first love computer language, although not my > first relationship) someday, just for fun. > """ > > No on-the-fly code generation here. He essentially wants lisp-style-macros > with better parsing. Still a programming language. Not a data-monger. The 'problem' is that a lot of incredibly smart people are reading and replying here who are seeing a lot more into my post than I was prepared for :-) Anyway, the last few weeks I have been busy transforming MsWord documents into XML using Open Office, and next parsing this XML and transforming it into a special subset of HTML using ElementTree's XMLWriter class. Then the output of the XMLWriter was put into a Zope/Plone page but I added special markup for footnotes, making them plone objects that could be separately edited, and I added image tags for images that were retrieved from a separate server using an XSLT script. To accomplish that a special zope parser was written to recognize my nonstandard footnote and image tags, and to create the necessary objects, and to insert them into the page. After that I came across some turbogears code (which is stacking code at different levels like it were those things you put under your beer glass) and still later I saw some JSON equivalents of XML. JSON looks a lot like Python dicts which makes it seem likely that javascript will be able to interface with Python more efficiently. Remember that ElementTree comes from the same place that brought us PIL which is a package that can transform images into different types. So if we can transform documents, images and XML, why not sourcecode? Especially if it's not a conversion into a 'lossy' file format, (I consider dynamically typed code versus statically typed code the analog thing to JPEG versus bitmaps) it would be easy to convert all datatypes into the datatypes of another language, thereby making it possible to exchange code between languages. Algorithms just being things that convert sets of data-objects into other sets of data-objects. Now if one would equate standardized code exchange between languages and within a language with macros then I guess there is nothing left for me to do but wait till a certain google bot comes knocking at my ip-address port 80 and transfers me to the google equivalent of Guantanamo. But the whole point of distinguishing macros from official language structures *is* standardization, as some other clever poster already pointed out, so it would be extremely unfair to equate trans-language standardized code exchange with the guerrilla type macro activities that are plaguing the Lisp community. Then there are some people who keep insisting they don't understand what I'm talking about until I simplify things enough to get them on-board, but then simply dismiss my ideas with 'you can already do that easily with this standard python construct'. This strategy was also eloquently refuted by some other poster, so I don't need to repeat it :-) I've gotten a lot of things to think about, so thanks all for your thoughts, but since this is getting way above my head I'll just wimp out and leave the rest of the thread to the experts! Regards, Anton -- http://mail.python.org/mailman/listinfo/python-list