Re: [Haskell] Compositional Compiler Construction, Oberon0 examples available
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! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Compositional Compiler Construction, Oberon0 examples available
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 Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] [Haskell] Compositional Compiler Construction, Oberon0 examples available
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
[Haskell] Compositional Compiler Construction, Oberon0 examples available
On Aug 19, 2012, at 10:40 , Heinrich Apfelmus apfel...@quantentunnel.de wrote: Doaitse Swierstra wrote: Over the years we have been constructing a collection of Embedded Domain Specific Languages for describing compilers which are assembled from fragments which can be compiled individually. In this way one can gradually ``grow a language'' in a large number of small steps. The technique replaces things like macro extensions or Template Haskell; it has become feasible to just extend the language at hand by providing extra modules. The nice thing is that existing code does not have to be adapted, nor has to be available nor has to be recompiled. Recently we have been using (and adapting) the frameworks such that we could create an entry in the ldta11 (http://ldta.info/tool.html) tool challenge, where one has to show how one's tools can be used to create a compiler for the Oberon0 language, which is used a a running example in Wirth's compiler construction book. We have uploaded our implementation to hackage at: http://hackage.haskell.org/package/oberon0. More information can be found at the wiki: http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo You may take a look at the various Gram modules to see how syntax is being defined, and at the various Sem modules to see how we use our first class attribute grammars to implement the static semantics associated with the various tasks of the challenge. We hope you like it, and comments are welcome, Awesome! 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? Best regards, Heinrich Apfelmus 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. Doaitse -- http://apfelmus.nfshost.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Compositional Compiler Construction, Oberon0 examples available
On Aug 19, 2012, at 10:40 , Heinrich Apfelmus apfel...@quantentunnel.de wrote: Doaitse Swierstra wrote: Over the years we have been constructing a collection of Embedded Domain Specific Languages for describing compilers which are assembled from fragments which can be compiled individually. In this way one can gradually ``grow a language'' in a large number of small steps. The technique replaces things like macro extensions or Template Haskell; it has become feasible to just extend the language at hand by providing extra modules. The nice thing is that existing code does not have to be adapted, nor has to be available nor has to be recompiled. Recently we have been using (and adapting) the frameworks such that we could create an entry in the ldta11 (http://ldta.info/tool.html) tool challenge, where one has to show how one's tools can be used to create a compiler for the Oberon0 language, which is used a a running example in Wirth's compiler construction book. We have uploaded our implementation to hackage at: http://hackage.haskell.org/package/oberon0. More information can be found at the wiki: http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo You may take a look at the various Gram modules to see how syntax is being defined, and at the various Sem modules to see how we use our first class attribute grammars to implement the static semantics associated with the various tasks of the challenge. We hope you like it, and comments are welcome, Awesome! 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? Best regards, Heinrich Apfelmus 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. Doaitse -- http://apfelmus.nfshost.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
