On Aug 21, 2012, at 13:46 , Heinrich Apfelmus <apfel...@quantentunnel.de> wrote:
> Doaitse Swierstra wrote:
>> Heinrich Apfelmus 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
>> 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
> hask...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
