On 24-Feb-1999, John Hughes <[EMAIL PROTECTED]> wrote:
> 
> Everybody agrees the monomorphism restriction is a pain: [...]
> On the other hand, interpreting such definitions using call-by-name when the
> programmer expects call-by-need would REALLY introduce a trap for the unwary.
> 
> Some suggest that it is enough for compilers to issue a warning when using
> call-by-name. I disagree strongly. [...] The distinction between call-by-need
> and call-by-name is vital for understanding programs operationally, and it
> should be visible in the source.
> 
> So, let's make it visible, in the simplest possible way. Let there be TWO
> forms of binding: x = e, and x := e (say). A binding of the form `x = e' is
> interpreted using call-by-name, and may of course be overloaded: it makes `x'
> and `e' exactly equivalent. A binding of the form `x := e' is interpreted
> using call-by-need, and is monomorphic; `x' behaves as though it were
> lambda-bound.

The explicit distinction between call-by-name and call-by-need is good.

But does call-by-need have to require monomorphism?
You can implement call-by-need even for polymorphic values, using memoing!
Perhaps `:=' could even be extended as a generic memoing operator... ;-)

Seriously, I like John Hughes' proposal.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger [EMAIL PROTECTED]        |     -- leaked Microsoft memo.


Reply via email to