
In "Monadic Parser Combinators" (1996) by Graham Hutton and Erik Meijer, the authors state that "Some prior exposure to functional programming would be helpful in reading this article, but special features of Gofer (Jones, 1995b) --- our implementation language --- are explained as they are used. Any other lazy functional language that supports (multi-parameter) constructor classes and the use of monad comprehension notation would do equally well. ...." I am curious: was there any other language at the time supporting all of these features, or was this a joke? Also, why were monad comprehensions removed from Haskell? Was it for efficiency? -- /Times-Bold 40 selectfont/n{moveto}def/m{gsave true charpath clip 72 400 n 300 -4 1{dup 160 300 3 -1 roll 0 360 arc 300 div 1 1 sethsbcolor fill}for grestore 0 -60 rmoveto}def 72 500 n(This message has been)m (brought to you by the)m(letter alpha and the number pi.)m(David Feuer) m(David_Feuer@brown.edu)m showpage

David Feuer asks:
implementation language --- are explained as they are used. Any other lazy functional language that supports (multi-parameter) constructor classes and the use of monad comprehension notation would do equally well. ...."
I am curious: was there any other language at the time supporting all of these features, or was this a joke?
I'm fairly sure there wasn't; but of course they had hopes that Haskell soon would. As it turns out, Haskell still doesn't have MPTC in the standard, but it did for a while have monadic comprehensions, and most Haskell implementations now support MPTC.
Also, why were monad comprehensions removed from Haskell? Was it for efficiency?
No, it was because they led to extremely confusing error messages. This was a particular concern because list comprehensions tend to be used a lot by beginners, in assignments designed to demonstrate the power and compactness of the language. If simple typos lead to error messages about functors and monads and other arcane and unknown concepts, these beginners are liable to be put off; if instead the error messages talk about lists then they will be much more useful. --KW 8-)

On Wed, 23 Jan 2002, Keith Wansbrough wrote:
No, it was because they led to extremely confusing error messages. This was a particular concern because list comprehensions tend to be used a lot by beginners, in assignments designed to demonstrate the power and compactness of the language. If simple typos lead to error messages about functors and monads and other arcane and unknown concepts, these beginners are liable to be put off; if instead the error messages talk about lists then they will be much more useful.
Was it not possible to specialize the error message rather than the comprehensions? Alternatively, if the underlying type information really isn't available, why not give errors in terms of lists and have language sophisticates deal with the error message wierdness (they have to know that "list" in error messages really means monad). Or the implementation could simply have a beginner/advanced error message setting. I realize this is all water under the bridge, but personally, I would trade off more simple code for less readable error messages. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
participants (3)
-
David Feuer
-
Keith Wansbrough
-
S. Alexander Jacobson