Thursday, July 21, 2011
There are some extensions, or we may call them "dialect", that greatly rely on functional programming, up to the level of writing entire modules of several hundred lines in functional sequences. Of course, it is necessary to have full compiler support into those long sequences, so that an error in the sequence body gets pinpointed and the compilation can proceed in search for further errors.
This is pretty common in compilers aiming to support purely functional languages as LISP or Haskell, but outside the specific domain in which expressions are considered all you have, declarations involving list are generally treated as one single expression that might be either malformed or well-formed. The best that you can get, usually, is the point of the expression where the error is detected; for instance, this is a rather uncommon (and appreciated) feature i C++ compilers.
The flat-parsing nature of Bison on which the previous parser was based didn't allow the fine control we wanted to give to our parser to treat sequence initializations as expressions are treated in functional languages.
It took me one workday, (actually, half of which was dedicated to the empowering the error control and resume in other common structures), but now we have it working. Thanks to a construct we introduced in our parser, the grammar "state", it's now pretty easy to do special parsing in some code areas without breaking the consistency of the surrounding code. As the array declaration token is met, the state is pushed, and when it's popped it leaves a coherent, atomic token in the stack where the parsing of the surrounding context can continue.
The exact same thing is done in classes; in fact, now we can create nested classes and class-expressions (that is, anonymous classes); and the same mechanism is already employed in the new Prototype item definition.
Next step: compile-to-module and serialization-deserialization of modules.