Anton Vredegoor wrote:
> 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 :-)
no comment...
(snip various transformations examples)
>
> So if we can transform documents, images and XML, why not sourcecode?
>
(snip preliminary precautions)
> it would be easy to convert all datatypes
> into the datatypes of another language, thereby making it possible to
> exchange code between languages.
You mean like 'converting' javascript to python or python to ruby (or
converting any home-grown DSL to Python, etc) ?
> 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.
Lol !-)
Well, given this quote from another of your posts:
"""
The idea is to have a way to transform a Python (.py) module into XML
and then do source code manipulations in XML-space using ElementTree.
"""
I effectively understood something like a python to python
transformation, which of course led me to something very very like macros.
> 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,
count me in then :(
> 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!
No way you will escape from your responsabilities so easily !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
