[OT] code is data

[Anton Vredegoor]

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