John Launchbury wrote:
> Koen,
>
> > If a language has the property that in one place, one can
> > use a "let" block to define polymorphic bindings, and in
> > another place one can only use it for monomorphic bindings,
> > then I think that is bad language design.
>
> I don't think that's a very accurate description. The "let" in "do"
> is a bit of a different beast from the usual "let..in" construct.
> For a start, it doesn't have an "in" keyword. This is not a trivial
> point: "let"s are guaranteed to introduce polymorphism only
> within the block introduced by "in".
Isn't that a bit of a dodgy argument? I don't know of any papers on `in'
polymorphism, but many about `let' polymorphism. If I see `let', I expect
polymorphism, and I'm not going to go searching for an `in'. (and yes, I
don't like the DMR, but that's another story).
It's been proposed before that we have a separate notation for monomorphic
bindings. I'd like to see you adopt this approach, rather than having `let'
in `do' behave fundamentally differently. This example also provides nice
example and motivation for introducing a monomorphic let notation.
> Uses of variables (functions)
> bound by a "let" block are a priori monomorphic within the rest of that
> block. In pactice, of course, the strongly-connected-components pass
> will reconfigure big let-blocks into many separate blocks, and so
> increase the amount of polymorphism. In a "do" block, however, it's
> a lot harder to do the reconfiguration, so we would be stuck with
> the by-default monomorphic behavior. (The current use of "let" in
> "do" does some simplistic reconfiguration -- introducing an "in"
> keyword to obtain polymorphism -- which does not work in the recursive
> case).
The ability to bind multiple things at once (and have the corresponding
increase in polymorphism) is a nice feature of a modern `let' - but it's not
the primary characteristic. The let in do could easily bind multiple things
as well (by allowing `in'). The currently syntax is just an aesthetic choice
isn't it?
--Jeff
