On Aug 21, 2012, at 13:46 , Heinrich Apfelmus
Doaitse Swierstra wrote:
I have a small question: Last I remember, you've mainly been using your UUAGC preprocessor to write attribute grammars in Haskell, especially for UHC. Now that you have first-class attribute grammars in Haskell ("achievement unlocked"), what do you intend to do with the preprocessor? How do these two approaches compare at the moment and where would you like to take them? On the page http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo there is a link (http://www.fing.edu.uy/~mviera/papers/VSM12.pdf) to a paper we presented at LDTA (one of the ETAPS events) this spring. It explains how UUAGC can be used to generate first class compiler modules. We have also a facility for grouping attributes, so one can trade flexibility for speed. The first class approach stores list of attributes as nested cartesian products, access to which a clever compiler might be able to optimize. This however would correspond a
Heinrich Apfelmus wrote: form of specialisation, so you can hardly say that we have really independent modules; as always global optimisation is never compositional). From the point of view of the first class approach such grouped non-termionals are seen as a single composite non-terminal.
Ah, I see. So the custom syntax offered by UUAGC is still appreciated, but you now intend to compile it to first-class attribute grammars instead of "bare metal Haskell". Makes sense. Thanks!
It is not much that it is our intention, but it is an easy way to make an existing compiler extensible. The main (fixed) part of the compiler is constructed in the "old" way from an UUAGC description, and those attributes are grouped (and quite a bit more efficient). On top of this you can define extra attributes and computations, which plug in to the old system. Notice that there is a main difference between the two approaches is that the uuagc route gives you fast compilers, because we can analyse the grammar, and generate efficient tree walking evaluators, whereas the first-class approach gives you great flexibility and the possibility to abstract from common patterns for which others prefer to get lost in stacks of monads, or find out that monads do not work at all since they cannot feed back information into a computation easily. Doaitse
Best regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell