On Jun 28, 2007, at 9:49 PM, Stefan Holdermans wrote:
That way you would have to use monads everywhere.
As you already hinted at in a later message, this has to do with
let-bindings being potentially polymorphic and monadic bindings
being necessarily monomorphic:
Are there papers that prove this need be the case in any language, or
are we simply now trapped into this for the moment by some design
choices?
If monads weren't late to the party, with clumsy notation left over
from the core language, would we really mind a language where one has
"to use monads everywhere" ? The trick would be to design them in so
seamlessly that a Perl/Python/Ruby scale mainstream _thought_ they
were just using another imperative language, that happened to scale
_very_ gracefully to eight core machines and such because of the
underlying semantics.
Compare a Haskell do statement to a Lisp expression. In the Lisp
expression the first element is special, a convention of the eval
loop. In the Haskell do expression, every line is equally special,
and type information is used to combine the lines, inserting implied
combinators. This is a fascinating variation on Lisp rules, alas
restricted to a couple of situations, akin to the special syntax for
tuples and lists. I see potential for a whole language that worked
this way, opened up to let the programmers control this process
without waiting for an implementation to take their suggestions
(think history of arrows) piecemeal.
Here's a different analogy: People like Haskell parsing because it
looks so much like the definition of the grammar itself. So step down
a rung, to regular expressions, and imagine a toy language where a
regular expression _IS_ by itself, with no further ado, a fully
working program. One is immediately led back to the same idea as
Haskell do expressions: Two pieces of program, juxtaposed next to
each other, silently "multiply" to combine into a larger program,
with type rules guiding the multiplication process.
That sure reads to me like a description of how do statements work in
Haskell, so unleash them?
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
