On 4/1/06, Talin <[EMAIL PROTECTED]> wrote: > This is about the print / writeln debate.
No, it isn't. :-) Let me focus on the part that you skirt, to explain that that's what makes anything like this pretty much impossible. > We would start by defining a simple metalanguage for giving instructions to > the parser. I won't even try to suggest a syntax, but in essence this would > be something that has the same role as a macro language or preprocessor, in > that it is not part of the programming language itself, but instead describes > how the subsequent text is to be interpreted. (There's already some precedent > for this with the __future__ syntax.) So here's the rub. Assume we have nice simple meta-syntax for making "print" a special form. For the sake of having a concrete (if silly) example, let's say you do this by writing (-:print:-) The problem is, where do you put this so that the parser knows that 'print' is a special form? You'd like to be able to define a whole library of these, and import it; you don't want to have to write (-:print:-) at the top of each file where you want to use this (this would pretty much destroy the newbie-friendliness of the feature). But the Python parser doesn't read the modules it imports! When it sees "import foo" it just generates a few bytecodes that cause foo to be imported at run time, and notes that foo is now a local variable (yes, local!). If there are any (-:print:-) declarations in foo.py, the parser won't know about them. This is different from import in Java and #include in C/C++, where the contents of what is imported/included can inform the parser. Based on my experience with past wild proposals, you're probably going to counter by proposing that the Python interpreter somehow follows imports at compile time; I could then object that it's totally reasonable that the module to be imported is unavailable to the parser (either due to import hooks to be installed later, or simple separate compilation as done by compileall.py). You could then counter by proposing an alternative syntax for compile-time imports (-:import foo:-) that must be followed and interpreted by the parser. And I could call that ugly, hard to implement, etc. But please save your breath. Programmable syntax is not in Python's future -- or at least it's not for Python 3000. The problem IMO is that everybody will abuse it to define their own language. And the problem with that is that it will fracture the Python community because nobody can read each other's code any more. It's one thing to read code that calls an external function whose meaning you have to guess from its name. It's quite another thing to realize that you can't even know for sure where the function calls are. Let's not go there. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
