Question

I’m working on a macro system for Python (as discussed here) and one of the things I’ve been considering are units of measure. Although units of measure could be implemented without macros or via static macros (e.g. defining all your units ahead of time), I’m toying around with the idea of allowing syntax to be extended dynamically at runtime.

To do this, I’m considering using a sort of partial evaluation on the code at compile-time. If parsing fails for a given expression, due to a macro for its syntax not being available, the compiler halts evaluation of the function/block and generates the code it already has with a stub where the unknown expression is. When this stub is hit at runtime, the function is recompiled against the current macro set. If this compilation fails, a parse error would be thrown because execution can’t continue. If the compilation succeeds, the new function replaces the old one and execution continues.

The biggest issue I see is that you can’t find parse errors until the affected code is run. However, this wouldn’t affect many cases, e.g. group operators like [], {}, (), and “ still need to be paired (requirement of my tokenizer/list parser), and top-level syntax like classes and functions wouldn’t be affected since their ‘runtime’ is really load time, where the syntax is evaluated and their objects are generated.

Aside from the implementation difficulty and the problem I described above, what problems are there with this idea?

Answer 1

Here are a few possible problems:

• You may find it difficult to provide the user with helpful error messages in case of a problem. This seems likely, as any compilation-time syntax error could be just a syntax extension.
• Performance hit.

I was trying to find some discussion of the pluses, minuses, and/or implementation of dynamic parsing in Perl 6, but I couldn’t find anything appropriate. However, you may find this quote from Nicklaus Wirth (designer of Pascal and other languages) interesting:

The phantasies of computer scientists in the 1960s knew no bounds. Spurned by the success of automatic syntax analysis and parser generation, some proposed the idea of the flexible, or at least extensible language. The notion was that a program would be preceded by syntactic rules which would then guide the general parser while parsing the subsequent program. A step further: The syntax rules would not only precede the program, but they could be interspersed anywhere throughout the text. For example, if someone wished to use a particularly fancy private form of for statement, he could do so elegantly, even specifying different variants for the same concept in different sections of the same program. The concept that languages serve to communicate between humans had been completely blended out, as apparently everyone could now define his own language on the fly. The high hopes, however, were soon damped by the difficulties encountered when trying to specify, what these private constructions should mean. As a consequence, the intreaguing idea of extensible languages faded away rather quickly.

Edit: Here’s Perl 6’s Synopsis 6: Subroutines, unfortunately in markup form because I couldn’t find an updated, formatted version; search within for ‘macro’. Unfortunately, it’s not too interesting, but you may find some things relevant, like Perl 6’s one-pass parsing rule, or its syntax for abstract syntax trees. The approach Perl 6 takes is that a macro is a function that executes immediately after its arguments are parsed and returns either an AST or a string; Perl 6 continues parsing as if the source actually contained the return value. There is mention of generation of error messages, but they make it seem like if macros return ASTs, you can do alright.