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. > 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. 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 probably more visible in a purely functional language like Haskell, where your program doesn't state actions to take, but certain facts about your application domain. Execution strategy is left entirely up to the compiler. So, in some way, it has to extract meaning from your program to deliver the end result. It's up to the compiler to "decide" which calculations should be run. At some level, it looks kind of what we do as programmers - we get the requirements and are expected to deliver an application that, when executed, fulfill those requirements. The compiler does the similar thing, the difference being its requirements are written in a pretty rigid and unambiguous language. There is a limit on what compilers can do, and the reason for that doesn't lie in an inherent "stupidity" of computers, but in our expectations for programming languages. We expect them to be predictable. We expect to be no ambiguity in any possible program. print "Hello world" should do the same thing every day. We don't give our compilers a free hand to interpret our programs as they like. Any incoherence is considered a bug. This is actually a real problem in Haskell - it's sometimes hard to reason about programs, their execution time and memory footprint, that is. All because compiler was given a lot of power. 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. > OTOH, people explicitly understand meaning, so maybe automating what > people do will lead to richer kinds of meaning for computers. At least for a given meaning of the word "meaning". ;-) > 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 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. Anyway, back to Python... There are more user-friendly libraries for code generation than lib2to3, starting from the new _ast module (http://docs.python.org/dev/3.0/library/ast.html) and ending at some interesting third-party libraries like bytecode assembler (http:// peak.telecommunity.com/DevCenter/BytecodeAssembler) or byteplay (http://code.google.com/p/byteplay/). 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/ Hope that helps. Cheers, mk --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
