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