hello
i'm getting inconsistent monomorphism behavior with the same code only
depending on whether or not -XTypeFamilies is enabled:
{-# LANGUAGE TypeFamilies #-}
snda :: a - b - b
snda ba = id
main = do
let ma = (return () :: IO ())
mBox bb = snda ma bb
mBox $ return (4 :: Int
On Thu, Jan 5, 2012 at 3:32 PM, Rian Hunter r...@thelig.ht wrote:
hello
i'm getting inconsistent monomorphism behavior with the same code only
depending on whether or not -XTypeFamilies is enabled:
Which version of GHC are you using?
Starting with GHC 7.0, the TypeFamilies extension implies
#307: Implicit Parameters and monomorphism
-+--
Reporter: nobody|Owner:
Type: feature request | Status: new
Priority: low
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
#1503: GHC doesn't respect monomorphism restrictions for
non-type-class-restricted
values that are bound
---+
Reporter: Isaac Dupree | Owner:
Type: bug | Status: new
#1503: GHC doesn't respect monomorphism restrictions for
non-type-class-restricted
values that are bound
-+--
Reporter: Isaac Dupree |Owner:
Type: bug | Status: new
#1503: GHC doesn't respect monomorphism restrictions for
non-type-class-restricted
values that are bound
-+--
Reporter: Isaac Dupree |Owner:
Type: bug | Status: new
#1503: GHC doesn't respect monomorphism restrictions for
non-type-class-restricted
values that are bound
-+--
Reporter: Isaac Dupree |Owner:
Type: bug | Status: new
#1503: GHC doesn't respect monomorphism restrictions for
non-type-class-restricted
values that are bound
-+--
Reporter: Isaac Dupree |Owner:
Type: bug | Status: new
#1503: GHC doesn't respect monomorphism restrictions for
non-type-class-restricted
values that are bound
-+--
Reporter: Isaac Dupree |Owner:
Type: bug | Status: closed
#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
#307: Implicit Parameters and monomorphism
-+--
Reporter: nobody | Owner: nobody
Type: feature request | Status: assigned
Priority: low | 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
be used with different types.
The interesting thing is that k behaves as a Float in both cases. This
is monomorphism isn't it? i.e. the compiler may have a variety of types
to choose from, but it picks one and sticks to it for every usage. In
summary, k didn't give the same outputs as kN
polymorphism, doesn't it? i.e. Not only
has the compiler got a variety of types to choose from, but a variety of
types can be used at runtime?
The output for kI and kF is obvious.
The interesting thing is that k behaves as a Float in both cases. This
is monomorphism isn't it? i.e. the compiler
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
By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implicit Parameters and monomorphism
Initial Comment:
http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html
Notes some oddness with recursive binding of implicit
parameters. Roughly, giving a 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
However, in ghc-5.02.3 for Haskell 98 (without glasgow extensions) it
seems that is not the case. I _guessed_ that I need to use the flag
-fno-monomorphism-restriction
but I don't know whether I've failed to turn it on or if the
problem is to be found somewhere else. A related problem
Thanks a lot for the solution! And of course the ghci behaviour is much
more sensible than the hugs one.
And for pointing me to the mail archive. It encourages me to submit my next
problem: stack overflow with simple Show instances...more later
I wonder if there is a list of Hugs to GHCI
It encourages me to submit my next problem: stack overflow with
simple Show instances...more later
Let me guess that this involves a data declaration of the form:
data Foo = ... | Foo op ... | ...
That is an infix data constructor whose first argument is a recursive
reference to the
Hmm. It might be related but I somehow doubt it. The buggy program is
--
module Bug2 where
data Bug2 = Bug2
instance Show Bug2 where
showsPrec _ Bug2 str = showChar '?' str
--
(stack overflow on Bug2 Bug2)
and
: monomorphism/hugs98/ghc-5.02.3
It encourages me to submit my next problem: stack overflow with
simple Show instances...more later
Let me guess that this involves a data declaration of the form:
data Foo = ... | Foo op ... | ...
That is an infix data constructor whose first argument
not be monomorphic
in where clauses in that case (is this a departure from the standard?).
However, in ghc-5.02.3 for Haskell 98 (without glasgow extensions) it
seems that is not the case. I _guessed_ that I need to use the flag
-fno-monomorphism-restriction
but I don't know whether I've failed to turn
glasgow extensions) it
seems that is not the case. I _guessed_ that I need to use the flag
-fno-monomorphism-restriction
but I don't know whether I've failed to turn it on or if the
problem is to be found somewhere else. A related problem I've found
is that if I try to specify that flag in a pragma
--- Matt Fairtlough [EMAIL PROTECTED]
wrote:
instance (Eq a, Testit a) = Super (Test a) where
sup1 (Test{f1=x, f2=y}) = Just Test{f1=x, f2=y}
where
y' = top y
x' = top x
top :: [a] - a
top (s:st) = s
is it possible to compile this program in
ghc-5.02.3?
Maybe
Hello!
On Mon, Oct 08, 2001 at 07:38:09PM +, Marcin 'Qrczak' Kowalczyk wrote:
Mon, 8 Oct 2001 11:35:48 +0200, Hannah Schroeter [EMAIL PROTECTED] pisze:
Now, with the typical dictionary implementation of type classes,
this wouldn't really be too difficult.
Dictionaries would have to
Hannah Schroeter wrote:
I don't think so. Why not create a dictionary record while compiling
the associated instance (which may, by the H'98 definition, occur
only once in the program)?
One problem is that certain Haskell programs need an unbounded
number of instances.
-- Lennart
1 - 100 of 173 matches
Mail list logo
