On Wed, Dec 3, 2008 at 3:55 PM, Michal Kwiatkowski <[EMAIL PROTECTED]> wrote: > > On 3 Gru, 20:27, "Edward K. Ream" <[EMAIL PROTECTED]> wrote: >> However, I prefer to approach the subject from other directions. I >> remember the first time I heard about xml. I thought, how can xml >> encode meaning? The answer, clear in retrospect, is that it doesn't. >> Meaning resides in programs such as Leo, that supports .leo files. >> These .leo (xml) files have a meaning *to Leo*. > > So you can say Leo is an interpreter for .leo files.
You could say that. My point was that Leo, and only Leo (not any part of xml), gives meaning to .leo files. >> Similarly, Python's parser doesn't understand the meaning of the >> programs it is compiling. Neither does the Python interpreter, for >> that matter! >> >> So "meaning" happens implicitly, as least at present. > > Well, it depends on what level you consider "meaning". Python > interpreter does "understand" bytecode enough to execute it. Agreed. > Python > compiler may "notice" certain patterns in an application and optimize > them. So, from this point of view, it *does* extract meaning from the > program, and not only the explicit one (instructions to execute), but > also the implicit one (expected end result of those instructions, as > in case of the optimizing compiler). This is what the pypy project is doing. I don't want to quibble here. You can say that any python interpreter does (or does not) understand a program, depending on your viewpoint and your purposes. For *my* purpose, I would prefer to say that the python interpreter does *not* understand python programs. This opens the door to tools that *do* understand, or understand in a different way. In this sense, pythoscope "understands" python programs in a quite different way than the python interpreter. Clear? > This is a long way of saying that you could implement a compiler that > would understand more, but only when you would allow it to be wrong > from time to time. Interesting. For now, I think of my new, unnamed, project as extending what lib2to3 can do. But first, I must learn more about lib2to3. >> So lib2to3 is just the first baby step towards treating Python >> programs as data in interesting ways. We won't run out of ideas in >> this area in my lifetime. > > Since you mention XML in the context of code generation I have a link > for you: > > http://www.defmacro.org/ramblings/lisp.html Thanks for this. > In Python, you have to operate on the AST level, different than the > source code level, while in Lisp, for the most part, AST *is* the > source code. That simplifies meta-programming quite a bit and makes it > much more accessible. I just hate lisp, and nothing is going to change my mind. Parentheses do not carry enough meaning or clarity for my taste. > Below some more links that may be of interest: > > http://time-loop.tumblr.com/post/47664644/python-ast-preserving-whitespace-and-comments > (the reason why I've chosen lib2to3) > http://nedbatchelder.com/blog/200804/the_structure_of_pyc_files.html > http://nedbatchelder.com/blog/200804/wicked_hack_python_bytecode_tracing.html > http://thermalnoise.wordpress.com/2007/12/30/exploring-python-bytecode/ Thanks again. Links are great now. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
