generic preprocessor for haskell
I have recently made a small detour into ocaml programming and I'm rather impressed with the generic preprocessor 'camlp4' for ocaml. Camlp4 allows the programmer to (i) interact with the ocaml parser and lexer to extend the concrete grammar with new syntax and (ii) to directly define the translation of such new syntax forms in terms of ocaml abstract syntax. Haskell programmers (at least in GHC) can also manipulate abstract syntax with the Template Haskell extension and the Language.Haskell.THSyntax library, but to my knowing there is no haskell compiler which supports the inclusion of new syntax forms. Wouldn't such a tool be cool? In the haskell community there are a number of handmade preprocesserors (DrIFT, Generic Haskell, HaRP, ...) which are both cumbersome to write, because the authors must write a (partial) haskell parser for every small extension, but also cumbersome to use because of increasing complexity to your makefiles and different standards for error reporting. Also, experimental extensions could quickly be written and evaluated by the haskell users, decreasing the dependency on the compiler maintainers. Per Larsson
We have all the machinery available. See: http://www.cs.uu.nl/groups/ST/Center/SyntaxMacros It will be part of the UtrechtHaskellCompiler (UHC), that is being constructed with our toolset, and which recently strated to produce running code. You get the syntax macros "almost" for free if you build your parser with the UtrechtParserCombinators (UPC). You can experiment with it yourself for your own language. The probem we are still working on is to handle left-recursive extensions being made by the user. We are well on our way with that. In principle we also know how to provide feedback to the user in terms of the extended input language, but unfortuantely the implementation is rather cumbersome. Doaitse On 2004 mei 15, at 17:49, Per Larsson wrote:
I have recently made a small detour into ocaml programming and I'm rather impressed with the generic preprocessor 'camlp4' for ocaml. Camlp4 allows the programmer to (i) interact with the ocaml parser and lexer to extend the concrete grammar with new syntax and (ii) to directly define the translation of such new syntax forms in terms of ocaml abstract syntax. Haskell programmers (at least in GHC) can also manipulate abstract syntax with the Template Haskell extension and the Language.Haskell.THSyntax library, but to my knowing there is no haskell compiler which supports the inclusion of new syntax forms. Wouldn't such a tool be cool? In the haskell community there are a number of handmade preprocesserors (DrIFT, Generic Haskell, HaRP, ...) which are both cumbersome to write, because the authors must write a (partial) haskell parser for every small extension, but also cumbersome to use because of increasing complexity to your makefiles and different standards for error reporting. Also, experimental extensions could quickly be written and evaluated by the haskell users, decreasing the dependency on the compiler maintainers.
Per Larsson
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I guess that extensible syntax is great for language experiments, but I'd be concerned about it becoming a common feature of production programming. I have found that even the simple facility of user-defined operators (not including the `name` form) leads to code that is far harder to pick up and understand. I hypothesize (based on my own experience) that when picking up some new code, a programmer relies to a considerable extent on the mnemonic significance of the names used in the code. Non-mnemonic elements of the code must be learned and committed to memory before they can be read with any facility. This suggests that user-defined syntax (and operators) run the risk of making the task of understanding a new program more akin to learning a new programing language. #g -- At 17:49 15/05/04 +0200, Per Larsson wrote:
I have recently made a small detour into ocaml programming and I'm rather impressed with the generic preprocessor 'camlp4' for ocaml. Camlp4 allows the programmer to (i) interact with the ocaml parser and lexer to extend the concrete grammar with new syntax and (ii) to directly define the translation of such new syntax forms in terms of ocaml abstract syntax. Haskell programmers (at least in GHC) can also manipulate abstract syntax with the Template Haskell extension and the Language.Haskell.THSyntax library, but to my knowing there is no haskell compiler which supports the inclusion of new syntax forms. Wouldn't such a tool be cool? In the haskell community there are a number of handmade preprocesserors (DrIFT, Generic Haskell, HaRP, ...) which are both cumbersome to write, because the authors must write a (partial) haskell parser for every small extension, but also cumbersome to use because of increasing complexity to your makefiles and different standards for error reporting. Also, experimental extensions could quickly be written and evaluated by the haskell users, decreasing the dependency on the compiler maintainers.
Per Larsson
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
On 2004-05-17 at 09:43BST Graham Klyne wrote:
I guess that extensible syntax is great for language experiments, but I'd be concerned about it becoming a common feature of production programming.
I (the design of Ponder notwithstanding) think that too.
I have found that even the simple facility of user-defined operators (not including the `name` form) leads to code that is far harder to pick up and understand.
That's probably true. I've often wondered if there was a way of restricting parts of the language to use within widely available libraries (as opposed to user-defined modules). For a user to add an instance of a class, and so change the meaning of '+' is not unreasonable, but more than slight use of weird combinations of symbols surely increases the overhead when reading code.
I hypothesize (based on my own experience) that when picking up some new code, a programmer relies to a considerable extent on the mnemonic significance of the names used in the code. Non-mnemonic elements of the code must be learned and committed to memory before they can be read with any facility. This suggests that user-defined syntax (and operators) run the risk of making the task of understanding a new program more akin to learning a new programing language.
I concur. My desire to have a language with extensible syntax derives from a desire to impose some sort of consistency on additions to the language, which makes them easier to absorb when they do arrive, but it's tempered with a wish to limit the use of such facilities to places where it's really necessary. The addition of regular expressions might well be a suitable case for treatment and an argument that the current extension facilities aren't quite enough, but I wouldn't want to see too general a mechanism for the reasons you give. Jón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
At 14:02 17/05/04 +0100, Jon Fairbairn wrote:
On 2004-05-17 at 09:43BST Graham Klyne wrote:
I guess that extensible syntax is great for language experiments, but I'd be concerned about it becoming a common feature of production programming.
I (the design of Ponder notwithstanding) think that too.
Is that Ponder as in access and authorization description (based on Morris Sloman's work)?
I have found that even the simple facility of user-defined operators (not including the `name` form) leads to code that is far harder to pick up and understand.
That's probably true. I've often wondered if there was a way of restricting parts of the language to use within widely available libraries (as opposed to user-defined modules). For a user to add an instance of a class, and so change the meaning of '+' is not unreasonable, but more than slight use of weird combinations of symbols surely increases the overhead when reading code.
I hypothesize (based on my own experience) that when picking up some new code, a programmer relies to a considerable extent on the mnemonic significance of the names used in the code. Non-mnemonic elements of the code must be learned and committed to memory before they can be read with any facility. This suggests that user-defined syntax (and operators) run the risk of making the task of understanding a new program more akin to learning a new programing language.
I concur. My desire to have a language with extensible syntax derives from a desire to impose some sort of consistency on additions to the language, which makes them easier to absorb when they do arrive, but it's tempered with a wish to limit the use of such facilities to places where it's really necessary. The addition of regular expressions might well be a suitable case for treatment and an argument that the current extension facilities aren't quite enough, but I wouldn't want to see too general a mechanism for the reasons you give.
I can see the utility of regexp support for a wide range of apps. And it's probably the kind of thing that really does benefit from a special syntactic form, being widely enough used to be easily recognized. Maybe where this leads is that it's fine to have means for experimental support of new syntax, but for production use there should be some broadly held consensus that the syntax is meaningful and useful. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
On 2004-05-18 at 00:04BST Graham Klyne wrote:
At 14:02 17/05/04 +0100, Jon Fairbairn wrote:
On 2004-05-17 at 09:43BST Graham Klyne wrote:
I guess that extensible syntax is great for language experiments, but I'd be concerned about it becoming a common feature of production programming.
I (the design of Ponder notwithstanding) think that too.
Is that Ponder as in access and authorization description (based on Morris Sloman's work)?
No, the FL I designed in my PhD back in the days before Haskell! -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
participants (5)
-
Doaitse Swierstra -
Graham Klyne -
Graham Klyne
-
Jon Fairbairn -
Per Larsson