From a previous email in the beginners list I more or less understood that
the monomorphism restriction will not exist anymore in Haskell Prime.
Is this correct?
On Fri, Mar 27, 2009 at 10:32 PM, Jonathan Cast
jonathancc...@fastmail.fmwrote:
On Fri, 2009-03-27 at 14:26 -0700, Kirk Martinez
, 2009 at 12:51 AM, Peter Verswyvelen bugf...@gmail.com
wrote:
From a previous email in the beginners list I more or less understood that
the monomorphism restriction will not exist anymore in Haskell Prime.
Is this correct?
On Fri, Mar 27, 2009 at 10:32 PM, Jonathan Cast jonathancc...@fastmail.fm
- Integer) )
The alpha conversion, necessary before doing scope extension, is the
step that might not have been apparent. Because @f@ is polymorphic in
its argument, the different instances of @f@ can be polymorphic in
different ways. This in turn is what leads to the ambiguity in @g@,
monomorphism
On Sun, Dec 21, 2008 at 9:21 AM, Maurício briqueabra...@yahoo.com
wrote:
Why isn't the last line of this code allowed?
f :: (TestClass a) = a - Integer
f = const 1
a = (f,f)
g = fst a
The only thing I can think about is monomorphism
restriction, but it's allowed (...)
(...) The reason
Why isn't the last line of this code allowed?
f :: (TestClass a) = a - Integer
f = const 1
a = (f,f)
g = fst a
The only thing I can think about is monomorphism
restriction, but it's allowed (...)
(...) The reason is that a has type
a :: (TestClass a, TestClass b) = (a,b)
and then when we take
You have a few options.
In Haskell98 (no extensions):
a () = (f,f)
g () = fst (a ())
-- alternatively
g x = fst (a ()) x
Here you make it explicit that a and g are functions; the
monomorphism restriction is there to stop things that look like values
(and therefore you expect to only get
Hello,
You can work around the monomorphism restriction with extensions but
to fix the ambiguity in your program that Reiner pointed out you'll
have to change the program to specify how you'd like to instantiate
a.
here are all the types once again:
f :: (TestClass a) = a - Integer
f = const 1
:: (TestClass a) = a - Integer
f = const 1
a = (f,f)
g = fst a
The only thing I can think about is monomorphism
restriction, but it's allowed (...)
(...) The reason is that a has type
a :: (TestClass a, TestClass b) = (a,b)
and then when we take 'fst' of this value (as in g) we get
g
Hi,
Why isn't the last line of this code allowed?
f :: (TestClass a) = a - Integer
f = const 1
a = (f,f)
g = fst a
The only thing I can think about is monomorphism
restriction, but it's allowed (or even the third
line would not be accepted). Is there something
I could read to understand
On Sat, Dec 20, 2008 at 4:28 PM, Maurício briqueabra...@yahoo.com wrote:
Hi,
Why isn't the last line of this code allowed?
f :: (TestClass a) = a - Integer
f = const 1
a = (f,f)
g = fst a
Yep, monomorphism restriction. a, because it is syntactically not a
function, must
On Sun, Dec 21, 2008 at 10:28 AM, Maurício briqueabra...@yahoo.com wrote:
Hi,
Why isn't the last line of this code allowed?
f :: (TestClass a) = a - Integer
f = const 1
a = (f,f)
g = fst a
The only thing I can think about is monomorphism
restriction, but it's allowed (or even the third
questionable to me.
Not necessarily, contrast these two definitions:
f = foldr (+) 0
f_expensive = let n = head $ drop 10 $ fibs 1 1 in foldr (+) n
With the monomorphism restriction in place, f_expensive only
calculates n once. Without, it gets calculated each time f is
instantiated.
-- ryan
Ryan Ingram wrote:
sumns 0 = 0
sumns x = sumns (x-1) + n
Without the monomorphism restriction, computing n is a function call;
it is evaluated each time it is asked for.
I'm relatively new to Haskell, and since this topic already came up, I
was wondering if anyone could explain to me how
On Sat, 2008-06-14 at 17:19 +1000, Rafal Kolanski wrote:
Ryan Ingram wrote:
sumns 0 = 0
sumns x = sumns (x-1) + n
Without the monomorphism restriction, computing n is a function call;
it is evaluated each time it is asked for.
I'm relatively new to Haskell, and since this topic
On 6/11/08, Rex Page [EMAIL PROTECTED] wrote:
Please remind me, again, of the advantages of f being something different
from the formula defining it.
fibs !a !b = a : fibs b (a+b)
-- fibs :: Num a = a - a - [a]
n = head $ drop 100 $ fibs 1 1
-- n :: Integer (due to monomorphism restriction
On Wed, 2008-06-11 at 20:24 -0700, Don Stewart wrote:
page:
Definition of f:
f = foldr (+) 0
Types:
0 :: (Num t) = t
foldr (+) 0 :: Num a = [a] - a
f :: [Integer] - Integer
Please remind me, again, of the advantages of f being something different
from the formula
Definition of f:
f = foldr (+) 0
Types:
0 :: (Num t) = t
foldr (+) 0 :: Num a = [a] - a
f :: [Integer] - Integer
Please remind me, again, of the advantages of f being something different from
the formula defining it.
- Rex Page
___
page:
Definition of f:
f = foldr (+) 0
Types:
0 :: (Num t) = t
foldr (+) 0 :: Num a = [a] - a
f :: [Integer] - Integer
Please remind me, again, of the advantages of f being something different
from the formula defining it.
Overloaded 'constants' take a dictionary as an
Wed May 14 08:12:34 PDT 2008 Simon Marlow [EMAIL PROTECTED]
* Accepted: remove the monomorphism restriction
M ./status.hs -1 +1
View patch online:
http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514151234-12142-8883dd9b436af3208701e5dcd9b926e38391765c.gz
Wed May 14 08:12:12 PDT 2008 Simon Marlow [EMAIL PROTECTED]
* separate the various monomorphism restriction proposals
M ./status.hs -1 +17
View patch online:
http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514151212-12142-28aa86fa87208d58913b72b0fdb6be38e61e9a62.gz
| Ok. So I counter-propose that we deal with pattern bindings like this:
|
|The static semantics of a pattern binding are given by the following
|translation. A binding 'p = e' has the same meaning as the set of
|bindings
|
| z = e
| x1 = case z of { p - x1 }
| ...
|
On Wed, Apr 30, 2008 at 12:18:47PM +0100, Ross Paterson wrote:
On Wed, Apr 23, 2008 at 10:32:24AM -0700, Simon Marlow wrote:
The current proposal on the table for what to do about the monomorphism
restriction (henceforth MR) is
* remove the MR entirely
Just to be clear, are we
Hi,
On Mon, Apr 28, 2008 at 9:42 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Ok. So I counter-propose that we deal with pattern bindings like this:
The static semantics of a pattern binding are given by the following
translation. A binding 'p = e' has the same meaning as the set of
On Mon, Apr 28, 2008 at 09:42:10AM -0700, Simon Marlow wrote:
Ok. So I counter-propose that we deal with pattern bindings like this:
The static semantics of a pattern binding are given by the following
translation. A binding 'p = e' has the same meaning as the set of
bindings
| The report doesn't actually mention this translation although it is
| widely used to implement pattern bindings, and in some compilers (not
| GHC) the translation is done before type checking.
|
| What's interesting to me is that perhaps this gives us a way to
| understand what the static
Hi Simon,
Those additional reasons given are much more compelling, and should
definately go on the wiki. I think the essential point is that it
makes reasoning about the code simpler - regardless of the effect on
implementation.
My main remaining reservation is that:
(x) /= x
[EMAIL PROTECTED]
| Iavor:
| the change is valid. I do believe that you can probably work around
| the problem in many situations but the question in my mind is why
| should we have to work around stuff when we have a system that already
| works? In other words, what problem do MBPs solve?
...
| Neil:
| Haskell
,
The current proposal on the table for what to do about the monomorphism
restriction (henceforth MR) is
* remove the MR entirely
* adopt Monomorphic Pattern Bindings (MPB)
Right now, the committee is almost uniformly in favour of dropping the MR,
and most of us are coming round to the idea
of (_,v) - v
It seems that under MBP the second program is not equivalent to the
first because it is more polymorphic.
-Iavor
On Wed, Apr 23, 2008 at 10:32 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Folks,
The current proposal on the table for what to do about the monomorphism
restriction
Hi
* remove the MR entirely
Finally!
* adopt Monomorphic Pattern Bindings (MPB)
There are 6 reasons on that page why we shouldn't adopt MPB - of those
number 5 I think is particularly compelling. There seems to be 1 main
reason to remove it, which is that it has a complex translation to
Hi, all!
It may be a side-effect of being a newbie, but many times I find the
-fno-monomorphism-restriction quite handy. Is it intrinsically evil? I
mean, has anyone had a bad time using it or does it imply some runtime
performance overhead? I guess it is not portable, is it?
Thanks in advance
On Tue, Oct 09, 2007 at 03:29:55PM -0300, Jorge Marques Pelizzoni wrote:
It may be a side-effect of being a newbie, but many times I find the
-fno-monomorphism-restriction quite handy. Is it intrinsically evil? I
mean, has anyone had a bad time using it or does it imply some runtime
Haskell98's monomorphism restriction is too confusing! See my mistaken
GHC bug report http://hackage.haskell.org/trac/ghc/ticket/1503.
Whether a binding is monomorphic depends not just on syntax, but on the
amount of type constraints on the right-hand side of a binding - and I
didn't realize
#1485: -fno-monomorphism-restriction -fallow-undecidable-instances do not play
nicely together
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug| Status: reopened
#1485: -fno-monomorphism-restriction -fallow-undecidable-instances do not play
nicely together
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug| Status: closed
#1485: -fno-monomorphism-restriction -fallow-undecidable-instances do not play
nicely together
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug| Status: closed
#1485: -fno-monomorphism-restriction -fallow-undecidable-instances do not play
nicely together
+---
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug| Status: new
#1398: -fno-monomorphism-restriction suggested when not appropriate
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: feature request| Status: closed
Priority: normal
#1398: -fno-monomorphism-restriction suggested when not appropriate
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: feature request| Status: closed
Priority: normal
#1398: -fno-monomorphism-restriction suggested when not appropriate
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: feature request| Status: closed
Priority: normal
#1398: -fno-monomorphism-restriction suggested when not appropriate
+---
Reporter: [EMAIL PROTECTED] | Owner:
Type: feature request| Status: new
Priority: normal
#1292: -fwarn-monomorphism-restriction should be -Wmonomorphism-restriction
-+--
Reporter: guest |Owner:
Type: bug | Status: closed
Priority: normal|Milestone
#1292: -fwarn-monomorphism-restriction should be -Wmonomorphism-restriction
-+--
Reporter: guest |Owner:
Type: bug | Status: closed
Priority: normal|Milestone
#1296: -fwarn-monomorphism-restriction breaks package compilation
-+--
Reporter: guest |Owner:
Type: bug | Status: closed
Priority: normal|Milestone
#1292: -fwarn-monomorphism-restriction should be -Wmonomorphism-restriction
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone
#1292: -fwarn-monomorphism-restriction should be -Wmonomorphism-restriction
-+--
Reporter: guest |Owner:
Type: bug | Status: closed
Priority: normal|Milestone
#1296: -fwarn-monomorphism-restriction breaks package compilation
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone
Neil Mitchell wrote:
http://haskell.org/hawiki/MonomorphismRestriction
Note to others (esp Cale): does this page not appear on the new wiki?
I did a very rough quick conversion:
http://www.haskell.org/haskellwiki/MonomorphismRestriction
The old wiki is locked, for obvious reasons. But
Neil Mitchell wrote:
http://haskell.org/hawiki/MonomorphismRestriction
Note to others (esp Cale): does this page not appear on the
new wiki?
I did a very rough quick conversion:
http://www.haskell.org/haskellwiki/MonomorphismRestriction
The old wiki is locked, for obvious reasons.
I wrote:
I did a very rough quick conversion:
http://haskell.org/hawiki/MonomorphismRestriction
http://www.haskell.org/haskellwiki/MonomorphismRestriction
Oops. Moved to:
http://www.haskell.org/haskellwiki/Monomorphism_Restriction
Alistair Bayley wrote:
You can see the source for the page
I wrote:
I did a very rough quick conversion:
http://haskell.org/hawiki/MonomorphismRestriction
http://www.haskell.org/haskellwiki/MonomorphismRestriction
Oops. Moved to:
http://www.haskell.org/haskellwiki/Monomorphism_Restriction
Alistair Bayley wrote:
You can see the source for
Hello,
I talked for a while with bd_ about this on #haskell, and I think maybe
I'm just being silly. But I can't get why:
lambda = \x - length (show x)
or
dot = length . show
is different from
pre x = length $ show x
I read about monomorphism restriction on the haskell 98 report, but I
#1090: Bad monomorphism-restriction-related type error message
-+--
Reporter: kirsten | Owner:
Type: bug | Status: closed
Priority: lowest
#1090: Bad monomorphism-restriction-related type error message
+---
Reporter: kirsten | Owner:
Type: bug | Status: new
Priority: lowest
Hello,
On 10/14/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello haskell-prime,
first is the monomorphism restriction. why isn't it possible to check
_kind_ of parameter-less equation and apply monomorphism restrictions
only to values of kind '*'? so, this:
sum = foldr1 (*)
will become
Brian Hulley wrote:
I'm wondering if the monomorphism restriction is now just an anachronism
from Haskell 98 or if it is still needed for efficiency ie should I just
now use -fno-monomorphism-restriction when compiling all my code to
consign it to the dustbin of history? :-)
A related
Simon Marlow wrote:
Brian Hulley wrote:
I'm wondering if the monomorphism restriction is now just an
anachronism from Haskell 98 or if it is still needed for efficiency
ie should I just now use -fno-monomorphism-restriction when
compiling all my code to consign it to the dustbin of history
Hi -
I'm wondering if the monomorphism restriction is now just an anachronism
from Haskell 98 or if it is still needed for efficiency ie should I just now
use -fno-monomorphism-restriction when compiling all my code to consign it
to the dustbin of history? :-)
A related question
Hi,
thanks for the last help and hints. I have encountered an other problem,
and again I don't quite understand the reason why I get the results I
get. ghci seems to infer different types for the same expression.
Consider that I have disabled the monomorphism restriction
in module AGC.lhs
Implicit parameters are *evil*. They seem to simplify programs
but they make reasoning about them much harder.
To an extent, they can be simulated with type classes,
because dictionaries are also implicit (you don't see them in the code
but you see them in the type declaration - same as for
On Mon, Feb 27, 2006 at 04:42:32PM +0100, Johannes Waldmann wrote:
Implicit parameters are *evil*. They seem to simplify programs
but they make reasoning about them much harder.
Indeed. We really need some big caveats in the manual. I find a lot of
new users think they are what they need and
expression.
Consider that I have disabled the monomorphism restriction
in module AGC.lhs (which is attached).
and I have a toplevel definition of:
mylength = synAttr listLength
loding the module in ghci (6.4) gives (beside some correct warnings):
$ Ok, modules loaded: Main.
$ *Main :type
Eike Scholz wrote:
mylength = synAttr listLength
$ *Main :type synAttr
$ synAttr :: (Data b) = ((?stack::[Dyn]) = b - a) - Attr a
$ *Main :type listLength
$ listLength :: (?stack::[Dyn]) = List - Float
$ *Main :type (synAttr listLength)
$ (synAttr listLength) :: Attr Float
$ *Main :type
| 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
-
| 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 example (without imports
OPTIONS line, will make it go through)
Cheers Christian
{-# OPTIONS -fno-monomorphism-restriction #-}
module NoMonoRestr where
data ShATerm = ShAAppl String [Int] [Int]
data ATermTable = ATermTable
getATerm :: ATermTable - ShATerm
getATerm = undefined
data Annotation = Annotation
data Annoted
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
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
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
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
Hi,
I've a file ATC/Sml_cats.hs that does not compile (see below) with the
flag -fno-monomorphism-restriction (ghc 6.2.2), whereas it compiles fine
without that option. Since I want to use -fno-monomorphism-restriction
for other files (from programatica) I've a problem, because
of the 1s were changed to
something else. Cases like this would be rare, though, and it's not
clear that programs of this type should really be accepted anyway,
since the safety is rather fragile.
None of these complications threatens the overall validity of the
monomorphism restriction
Question 3: monomorphism
There's a nasty corner case when the monomorphism restriction bites:
z = (x::Int) + ?y
The argument above suggests that we *must* generalise
over the ?y parameter, to get
z :: (?y::Int) = Int,
No, it's not necessary that z
I wrote:
Exactly the same rule should apply to implicit parameters. In the case of
implicit parameters, safety is ensured if in every use of the bound
variable, its implicit parameter refers to the same explicit binding of
that parameter. For example, the expression
let g = ?x in
I wrote:
My solution *is* the Right Thing. :-)
What I meant is: it always preserves the validity of inlining, it always
preserves sharing, and it rejects otherwise-correct programs only in
situations which are (I expect) uncommon in practice.
-- Ben
I just figured out why the monomorphism restriction interacts so weirdly
with implicit parameters, and how to fix it.
We all know that when the monomorphism restriction is turned on, the
following doesn't work:
let f = () in (f 1 2, f 'a' 'b')
On the other hand, the following does work
| I just figured out why the monomorphism restriction interacts so
weirdly
| with implicit parameters, and how to fix it.
I'm afraid that I have not read all of the recent exciting flood of
messages carefully, but I do remember that the interaction of the
monomorphism restriction with implicit
Ashley Yakeley, Seattle WA, writes:
Is there a point to the monomorphism restriction in GHC and Hugs? In
practice, all it seems to mean is occasionally require unnecessary
explicit type signatures.
I think the point is made clearly enough in section 4.5.5 of the Haskell 98
language report
Is there a point to the monomorphism restriction in GHC and Hugs? In
practice, all it seems to mean is occasionally require unnecessary
explicit type signatures.
--
Ashley Yakeley, Seattle WA
___
Haskell mailing list
[EMAIL PROTECTED]
http
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
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
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
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
-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
On 15-Jul-1998, Alex Ferguson [EMAIL PROTECTED] wrote:
Fergus Henderson writes of:
the monomorphism restriction (which exists for a similar reason,
to ensure termination of type inference).
Is this true? The rationale normally given for it by its advocates
(boo, hiss) seems invariably
92 matches
Mail list logo
