 Macros and Preprocessing in Haskell
started 1/11/2002; 6:51:06 PM - last post 8/5/2002; 2:42:32 PM
|
|
Bryn Keller - Macros and Preprocessing in Haskell 
1/11/2002; 6:51:06 PM (reads: 1498, responses: 8)
|
|
| Macros and Preprocessing in Haskell |
|
Existing large Haskell systems make extensive use of the C preprocessor, CPP. Such use is problematic, as CPP is not designed for use with Haskell code. Certain features of the Haskell report also indicate a possible deficiency in the Haskell language. This paper investigates these deficiencies, and proposes two extensions to Haskell: the inclusion of distfix operators, and the incorporation of a Haskell preprocessor, HSPP, into the Haskell standard. Related issues are discussed, including the provision of a general macro facility for Haskell.
This is an unpublished paper by Keith Wansbrough. It seems interesting, though Keith says the idea wasn't exactly warmly received:
...most people seemed to believe that a lazy language shouldn't need macros or a preprocessor (despite the liberal use of both in GHC, for example).
What do you think?
Posted to functional by Bryn Keller on 1/11/02; 6:51:34 PM
|
|
|
|
Brent Fulgham - Re: Macros and Preprocessing in Haskell
1/14/2002; 1:48:34 PM (reads: 1004, responses: 2)
|
|
|
It's dissapointing to hear that this proposal has not received more enthusiastic response. One of the real benefits of the Lisp-family of languages is the ability to define new syntax constructs. Lots of Haskellers tell me that Haskell is excellent for creating DSL's, but without the ability to extend the syntax I am not quite convinced.
Still, I think Haskell is a great language. It's certainly very easy to read -- almost like reading a proof in mathematics. And although I can admit the power of Scheme and Lisp, I still sometimes get lost in the parethesis.
So, were Haskell to extend itself with a stronger Module system and perhaps a Macro system I would be extremely pleased.
|
|
Ehud Lamm - Re: Macros and Preprocessing in Haskell
1/14/2002; 2:40:14 PM (reads: 976, responses: 0)
|
|
|
most people seemed to believe that a lazy language shouldn't need macros or a preprocessor
Well, macros are indeed sometimes used when you need call-by-name instead of call-by-value/reference, so it makes sense that in these cases call-by-need in a lazy language would be enough. But macros are obviously used for other purposes as well, like syntactic abstraction.
So I wonder, is anyone aware of some survey about the different uses of macros? We have plenty of texts about how to use inheritance etc. but it seems that macros were always something of a black art.
|
|
David B. Wildgoose - Re: Macros and Preprocessing in Haskell
1/14/2002; 2:43:08 PM (reads: 996, responses: 0)
|
|
|
I have to agree. If Haskell could extend its own syntax it would be perfect. After a quick skim of the paper, (it's late, I'll read it properly tomorrow morning), my initial impression is to approve the use of distfix operators. However I still have reservations about the addition of a pre-processor.
|
|
Bryn Keller - Re: Macros and Preprocessing in Haskell
1/14/2002; 2:48:28 PM (reads: 1065, responses: 1)
|
|
|
I have much the same feelings about Haskell (and Scheme, for that matter) as Brent. You might find this interesting:
First-class Modules for Haskell
It's a proposal for a much stronger module system (a la Ocaml) for Haskell. Looks quite promising to me.
|
|
Ehud Lamm - Re: Macros and Preprocessing in Haskell
1/14/2002; 11:28:43 PM (reads: 1108, responses: 0)
|
|
|
I think we linked to this paper some time ago. I don't remember if we had a discussion about it.
Keep in mind that first-classness is the enemy of static analysis and reasoning about programs.
|
|
Chris Rathman - Re: Macros and Preprocessing in Haskell
1/16/2002; 6:27:29 AM (reads: 968, responses: 0)
|
|
|
Guess I'll have to go against the grain. :-) In the long run, I don't have a problem with extending Haskell to support eagerness at compile time (or even some run time eagerness for that matter). But at this juncture, I do think it important for Haskell to remain true to it's goal of being lazy language.
Macros might help programmers to build special syntaxes to the language, but the bottom line for the designers of the language is to complete their mission of a formal language. In the meantime, if someone really wants macros, then they can write a preprocessor that interprets the embedded macros and converts them to straight up Haskell code.
|
|
Brent Fulgham - Re: Macros and Preprocessing in Haskell
1/16/2002; 1:45:51 PM (reads: 960, responses: 0)
|
|
|
I'll be the first to admit that Slashdot is a poor source for hard factual data, but there is an interesting link to how ITA Software used Common Lisp for their airline routing software (used by Orbitz among others.)
The inimitable Paul Graham has a copy of some e-mail describing why ITA selected Common Lisp, their design challenges, etc.
What I found most interesting is that they did not choose CL for its garbage collection, recursive programming techniques, or ability to evaluate arbitrary code fragments, but rather for its MACRO facilities.
That's right -- they use an imperitive, destructive (set!), and altogether un-functional approach to this project, but found that CL was still a big win because the MACRO facilities allowed them to create useful syntax that facilitated short, readable programs.
So -- I'd say that MACROS are quite useful. And the reasons ITA cites hold true even in the case of a lazy language.
|
|
Bryn Keller - Re: Macros and Preprocessing in Haskell
8/5/2002; 2:42:32 PM (reads: 699, responses: 0)
|
|
|
Just to tie things together, Haskell (or rather, Template Haskell) should now meet David B. Wildgoose's standards of perfection as described above. :-)
|
|
|
|