Well - the Python interpreter/compiler HAS a complete codewalker, and
parser trees are available from python:
>>> from parser import parsefile
>>> ptree = parsefile( python_source_file )
Admittedly, the tree is not a very readable object, but I've got some
alpha code to map token numbers back to grammar descritpion strings
and pretty-print the annotated trees. ( I'm experimenting with some
static code checkers: right now, a cross reference generator that
checks for used but unassigned variables, etc. Hopefully, it will
eventually become a more general static type/signature checker. )
>The "code is data" model is a *very* powerful one. Don't try and force
>something on me that forces me to violate it. Fine me a better compromise
>than Tcl... I don't think you can: Tcl is such a very nice balance between
>the ideal I would prefer (lisp or scheme) and the ideal that just about
>every end user prefers (basic).
However, I still agree with your general points.
I also agree with many of the points Bill Janssen made, contra tcl.
[ But not with his conclusion that there is No reason to use tcl. ]
Before I started to heavily use Python, I evaluated tcl, Perl, Icon,
and various lisp and scheme implementations. All of them had particular
strong points and for any one particular project, tcl or another
language might have made a better fit, but I didn't want to have to
support all of those languages, and Python seemed to be the best
overall compromise for my set of applications. I can certainly see
how someone else would come up with a different estimate based on a
different set of applications, or even based on a different view of
MY applications. Theoretically, scheme should have been the best
choice - but for other practical and implementation-centric reasons,
it didn't look ( at the time ) like the best practical choice.
[ And, having made that decision to avoid having to learn and support
all of: Python, Perl, tcl, scheme, xlisp, etc., it now looks like that
may be futile and I *will*, in fact, end up having to learn and support
Perl, tcl, ..., etc. Some folk in this thread have argued that you
*OUGHT* to use the "right language for the job" -- but at some point
this can divert too many resources into "treading water". And the
point where I move closer to Bill Janssen's conclusion is in
considering whether tcl adds enough value over a stripped down scheme
to make it worth the effort of being different. ]
>Using two languages for this would simply make for the worst of both worlds:
>forcing end users to parse lisp, in config files, and forcing all the chaos
>and complexity of algol-style languages on the implementor (and again I say
>unto you, for something like this where you have lots of programs digging
>into config files parsing the code gets reinvented again and again).
I think two syntaxes for the same language make a lot of sense.
However, there are practical problems dealing with standardizing two
syntaxes. It's always been pretty trivial to write an algebraic front
end to scheme. People have done it many times - never the same way
twice! Dylan initially started out with a dual-syntax plan. They are
now deprecating the lispish syntax. There is little effort required
to support the lisp syntax - I believe this is a practical political
decision and that their worry is choosing to have syntax > 1, it will
be hard to limit it to only two standard syntaxes. Standards > 1 is
an unstable condition - look at graphics file "standards", for
example!
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]