| > b) this is a feature request: you want a flag
-fmonomorphism-restriction
| > to restore the monomorphism restriction even if it's been turned
| > off by an earlier flag?
I've implemented this flag in the HEAD, as you requested. It'll be in
6.4
Simon
__
Simon Peyton-Jones wrote:
This isn't a bug. See Section 4.5.5 of the Haskell Report,
http://haskell.org/onlinereport/decls.html
in the second bullet under the sub-heading "Motivation". Your (bi, las)
binding is essentially the same as the (n,s) binding in that bullet.
Thanks for your anal
riginal Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Christian Maeder
| Sent: 29 November 2004 16:31
| To: Simon Peyton-Jones
| Cc: GHC Users Mailing List
| Subject: Re: -fno-monomorphism-restriction
|
| I've found a much shorter exam
Christian Maeder wrote:
I've found a much shorter example (without imports) that does not
compile.
and shorter:
{-# OPTIONS -fno-monomorphism-restriction #-}
module NoMonoRestr where
data ATermTable = ATermTable
data Annotation = Annotation
data Annoted a = Annoted a [Annotation]
toPair ::
AT
I've found a much shorter example (without imports) that does not
compile. The error displayed is:
Ambiguous type variable `a' in the top-level constraint:
`ATermConvertibleSML a'
arising from use of `las' at
/home/maeder/haskell/examples/NoMonoRestr.hs:29
(comenting out the initial
I wrote
| If someone wants to reproduce the error, do the following:
| 1) check out HetCATS repository with:
| cvs -d pserver:[EMAIL PROTECTED]:/repository
co
| HetCATS
| 2) comment out variable HC_PACKAGE in the Makefile (to avoid
dependency
| from uni)
| 3) add the flag -fno-monomorphism-restrict
Simon Peyton-Jones wrote:
I'm not sure whether you are saying (a) or (b):
a) This is a compiler bug; even with -fno-monomorphism-restriction
the module should compile. Are you sure?
b) this is a feature request: you want a flag -fmonomorphism-restriction
to restore the monomorphism
I'm not sure whether you are saying (a) or (b):
a) This is a compiler bug; even with -fno-monomorphism-restriction
the module should compile. Are you sure?
b) this is a feature request: you want a flag -fmonomorphism-restriction
to restore the monomorphism restriction even if it'