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.
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 sugges
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.
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
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 comp
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 re
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 overl
Christian Sievers replies to John Hughes:
> > 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 overloaded definition is compiled. But programmers need to
> > understand pro
Why not allow the code-bloat and treat type information as a hint by
which compilers/interpreters _may_ optimize?
i.e. when an expresion like
> foo=goo
violates the monomorphism restriction allow overloading (and perhaps code
bloat), but if foo is explicitly typed,
> foo::Num a=> a->b
then
> -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&#
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 PR
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'
Everybody agrees the monomorphism restriction is a pain:
* Often we WANT to make overloaded definitions of the form variable = expr
* The eta-expansion fix is ugly, and only works if the variable has a
function type
* Adding a type signature instead is tedious during prototyping, and moreov
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 differen
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, a
15 matches
Mail list logo
