OK, maybe I should give some idea of what to expect from the new
parser, when it comes on line.
1) It will be a lot easier to maintain (admittedly, not something
users will see directly).
2) It will check the syntax of hansl commands much more rigorously.
This is a benefit which might hurt a little at first ;-) Here are
some examples:
* The old parser sloppily accepted some quoted strings where the
quotation was never actually closed, as in
print "This is a string
Not any more!
* While the old parser mostly checked for _absence_ of required
elements on the command line, it wasn't properly equipped to check
for the _presence_ of syntactical "junk". E.g.
print "This is a string")
The extraneous ')' here will now cause an error. For another
example, consider
end mle @foo
at the end of an mle block. The idea is clear enough, "@foo" is
being used for string substitution, perhaps to add the --verbose
option or not depending on how the string named foo is defined. But
suppose there is in fact no string named foo in scope. The old
parser would happily ignore the undigested "@foo" at the end of the
line; the new one will not.
(The above examples are based on real-world cases from contributed
function packages.)
3) The main benefit that should eventually be visible to users is
the potential for substantial speed-up of big scripts. I say
"potential" here: in the first instance I don't expect much impact
on speed -- some scripts may go faster, some may go a little slower.
But the way the new parser works, it will create the possibility for
pre-parsing an entire hansl script, including both loops and any
functions called, and I expect a major speed-up for complex scripts
from that, when we get to it.
Allin