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
Joe English:
I was thinking of the example from the Haskell Report:
let { len = genericLength xs } in (len, len)
which, without the MR, computes 'len' twice.
Operationally I expect that in "let x = f y in ... x ... x",
'f y' is only evaluated once, no matter what type it is.
If
On 24-Feb-1999, Thomas Hallgren [EMAIL PROTECTED] wrote:
I agree with Johns objection to the compiler warning solution, so here is
another suggestion:
The monomorphism restriction makes sure that certain values are computed
at most once by restricting them to be used at only one type.
John Hughes wrote:
Everybody agrees the monomorphism restriction is a pain:
Hmm well, it's really not a nice thing.
Some suggest that it is enough for compilers to issue a warning when using
call-by-name. I disagree strongly. Such a warning may alert the programmer
at the time the
I just wanted to mention that John's idea
of two different forms of binding, a polymorphic one
with repeated evaluation and a monomorphic one with single evaluation, is not new.
It is also in Xavier Leroy's PhD thesis "Polymorphic Typing of an Algorithmic
Language",
where he suggests two
John Hughes [EMAIL PROTECTED] wrote:
Everybody agrees the monomorphism restriction is a pain:
[...]
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
Joe English:
(Am I the only one who's never been bitten by the MR restriction?)
If one always uses type sigs, or never/rarely uses compositional/
combinator style function definitions, it's much less likely to
crop up.
How about leaving the 'a = b' binding form as it is,
(monomorphism
John Hughes wrote:
Some suggest that it is enough for compilers to issue a warning when using
call-by-name. I disagree strongly.
I agree with Johns objection to the compiler warning solution, so here is another
suggestion:
The monomorphism restriction makes sure that certain values are
Thomas Hallgren:
The monomorphism restriction makes sure that certain values are computed at
most
once by restricting them to be used at only one type. Couldn't the same be
achieved by
* getting rid the monomorphism restriction, i.e., let all definitions to be
overloaded by
-Original Message-
From: Joe English [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 24, 1999 2:36 PM
To: [EMAIL PROTECTED]
Subject: Re: Modifying the monomorphism restriction
This is a good idea, except for the use of ':='.
I'd hate to lose that symbol from the programmers
I wrote:
Operationally I expect that in "let x = f y in ... x ... x",
'f y' is only evaluated once, no matter what type it is.
Which, of course, is not how Haskell actually works,
if x :: (SomeClass a) = SomeType a. DOH!
Please disregard my earlier remarks...
--Joe English
[EMAIL
Alex Ferguson [EMAIL PROTECTED] wrote:
Joe English:
How about leaving the 'a = b' binding form as it is,
(monomorphism restriction and all) and using 'a = ~ b'
to indicate call-by-name. [...]
I like that much less [...] because I consider it
(still) to be the wrong 'default'.
For
12 matches
Mail list logo