So when I read the "Syntactic Sugar for Arrows" proposal, my initial reaction is "Wow, that's a little complicated. It doesn't look like syntactic sugar to me." (Err, no offense, I hope.) This contrasts with the do-notation, which does look like syntactic sugar: you can rewrite any do expression in terms of the basic combinators with a bounded amount of pain.[1] Somehow with Arrows the point-free syntax you are forced into is extraordinarily unwieldy, and the arrows "syntactic sugar" is much handier. I presume people have tried and failed to come up with a more efficient set of combinators? Any thoughts as to why the arrow combinators need to be so unwieldy? A possibly related question: are there any general results on the verboseness of lambda calculus versus combinators? Incidentally, it seems to me that this is one case where a Lisp-like macro facility might be useful. With Haskell, it is impossible to play with bindings, while presumably you can do this with good Lisp macro systems. Best, Dylan Thurston Footnotes: [1] A quick look at the Haskell report reveals that named fields, pattern matching, and deriving declarations are not "syntactic sugar" in this sense. Of these, pattern matching is fundamental, named fields have clear semantics, and deriving declarations are more iffy [though very handy]. Did I miss any?
Dylan writes:
Incidentally, it seems to me that this is one case where a Lisp-like macro facility might be useful. With Haskell, it is impossible to play with bindings, while presumably you can do this with good Lisp macro systems.
Yes, this is one thing you can do with good macro systems as are found in Lisp and Dylan (the language, not the person!). See the references in my http://www.cl.cam.ac.uk/~kw217/research/paper-abstracts.html#Wansbrough99:Ma... Wansbrough, 1999. Macros and Preprocessing in Haskell especially section 8. Hygiene is a key concept here; that variables bound in a macro should not clash with other variables in the program (unless this is explicitly required). --KW 8-) -- Keith Wansbrough <kw217@cl.cam.ac.uk> http://www.cl.cam.ac.uk/users/kw217/ Cambridge University Computer Laboratory.
On Fri, Oct 12, 2001 at 12:39:09PM +0100, Keith Wansbrough wrote:
Dylan writes:
Incidentally, it seems to me that this is one case where a Lisp-like macro facility might be useful. With Haskell, it is impossible to play with bindings, while presumably you can do this with good Lisp macro systems.
Yes, this is one thing you can do with good macro systems as are found in Lisp and Dylan (the language, not the person!). See the references in my
http://www.cl.cam.ac.uk/~kw217/research/paper-abstracts.html#Wansbrough99:Ma...
Wansbrough, 1999. Macros and Preprocessing in Haskell
especially section 8.
Very good. Is there a concrete proposal for such macros? I think the arrow notation would be a harder test case than any of the existing syntactic sugar; I'd be curious to see what it looked like. (And is there support for adding these macros to Haskell?)
Hygiene is a key concept here; that variables bound in a macro should not clash with other variables in the program (unless this is explicitly required).
Off to read some Dylan manuals, Dylan
Very good. Is there a concrete proposal for such macros? I think the arrow notation would be a harder test case than any of the existing syntactic sugar; I'd be curious to see what it looked like. (And is there support for adding these macros to Haskell?)
Sadly, there's not a concrete proposal - it seems that no one sees a need for macros in a lazy language. Most of what they do can be achieved through laziness - you can write "if" in Haskell already, for example, whereas you need a macro for it in Lisp. Your arrow notation example may provide some motivation, though.
Hygiene is a key concept here; that variables bound in a macro should not clash with other variables in the program (unless this is explicitly required).
Off to read some Dylan manuals,
Do that, but the details of hygienic macros were first worked out in Scheme (a kind of Lisp), and then Dylan's was based on Scheme's. The key difference is that Dylan has a rich syntax, whereas Scheme just has S-expressions.
Dylan
On Fri, Oct 12, 2001 at 01:02:07PM +0100, Keith Wansbrough wrote:
Sadly, there's not a concrete proposal - it seems that no one sees a need for macros in a lazy language. Most of what they do can be achieved through laziness - you can write "if" in Haskell already, for example, whereas you need a macro for it in Lisp. Your arrow notation example may provide some motivation, though.
I wonder if macros could also be used to implement views. I think there were other times I wanted to play similar tricks with scoping, but I don't remember right now. Best, Dylan Thurston
Dylan Thurston:
On Fri, Oct 12, 2001 at 01:02:07PM +0100, Keith Wansbrough wrote:
Sadly, there's not a concrete proposal - it seems that no one sees a need for macros in a lazy language. Most of what they do can be achieved through laziness - you can write "if" in Haskell already, for example, whereas you need a macro for it in Lisp. Your arrow notation example may provide some motivation, though.
I wonder if macros could also be used to implement views.
They are heavily used in Clean, so, there *are* people who see a need for them in a lazy language. Jerzy Karczmarczuk Caen, France
On 12-Oct-2001, Jerzy Karczmarczuk <karczma@info.unicaen.fr> wrote:
They [macros] are heavily used in Clean, so, there *are* people who see a need for them in a lazy language.
Well, that depends on what you mean by "macros". Clean's "macros" have essentially the same semantics as inline functions, don't they? If I understand correctly, the denotation semantics of Clean's macros is exactly the same as ordinary functions, the only difference is that operationally they are guaranteed to be inlined. So, unless I'm missing something, they are just an efficiency hack, and one which is already looking somewhat dated -- a bit like the "register" keyword in C. This is quite different to the kind of macros that would allow you to extend the language syntax to support things like arrow notation or views. -- Fergus Henderson <fjh@cs.mu.oz.au> | "... it seems to me that 15 years of The University of Melbourne | email is plenty for one lifetime." WWW: <http://www.cs.mu.oz.au/~fjh> | -- Prof. Donald E. Knuth
On Fri, Oct 12, 2001 at 08:33:15PM +0900, Dylan Thurston wrote:
So when I read the "Syntactic Sugar for Arrows" proposal, my initial reaction is "Wow, that's a little complicated. It doesn't look like syntactic sugar to me."
Why, thank you!
This contrasts with the do-notation, which does look like syntactic sugar: you can rewrite any do expression in terms of the basic combinators with a bounded amount of pain.[1] Somehow with Arrows the point-free syntax you are forced into is extraordinarily unwieldy, and the arrows "syntactic sugar" is much handier.
I guess it's the generality of the arrows interface that makes it so awkward to use. There are some examples of this awkwardness in sections 7 and (especially) 9 of the draft version of John Hughes's arrows paper (http://www.cs.chalmers.se/~rjmh/arrows.ps or .pdf).
Incidentally, it seems to me that this is one case where a Lisp-like macro facility might be useful. With Haskell, it is impossible to play with bindings, while presumably you can do this with good Lisp macro systems.
If you extend the syntax using macros, it's essential for pain-limitation that errors are presented in terms of derived type rules for the macros. There's a paper on type-safe macros (not Haskell, but could be) in ICFP 2001 by Ganz, Sabry and Taha. The arrows stuff seems like it would require a second-order variant though (macros with macro arguments).
participants (5)
-
Dylan Thurston -
Fergus Henderson -
Jerzy Karczmarczuk -
Keith Wansbrough -
Ross Paterson