Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Red-black tree performance (Adrien Haxaire)
2. GHC: missing "No instance for ..." errors without the
monomorphism restriction (M?t? Kov?cs)
3. With Best Wishes (Alia)
4. Re: GHC: missing "No instance for ..." errors without the
monomorphism restriction (Daniel Fischer)
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Mar 2012 15:16:32 +0200
From: Adrien Haxaire <[email protected]>
Subject: Re: [Haskell-beginners] Red-black tree performance
To: [email protected]
Message-ID: <20120325131631.GA1939@arch>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 21, 2012 at 10:08:06AM +0000, Lorenzo Bolla wrote:
> toInsert :: [Int]
> -- toInsert = [1..1000000]
> toInsert = map (`mod` 100) [1..10000000]
Hello,
Sorry for replying so late.
Using mod 100 will just give me entries from 0 to 99, right? so this can
explain the performance improvement :)
Concerning the GC. Foldl' gives me a better productivity but takes more time,
when foldr' uses more GC but results in faster code. In general, what are the
best practices here: tolerate a use of the GC up to 20% but with good
performance, or strive for the minimum GC use? Apart from the RBTree case, in
the Haskell code I am writing, performance is not the primary goal, so I would
go for latter. But maybe there are some common rules to measure the right
tradeoff?
I chose to use this worst cas scenario of inserting a sorted ascending list to
require many rebalancing; it is the same list I use to compare with the C++
implementation. I ask for the maximum to see if it yields the right result.
Thanks for the reminder about the pattern used in the program, and the pattern
order in functions. Reorganizing them led to some improvement. I'll keep that
in mind.
Best regards,
Adrien
--
Adrien Haxaire
www.adrienhaxaire.org | @adrienhaxaire
------------------------------
Message: 2
Date: Sun, 25 Mar 2012 17:34:45 +0200
From: M?t? Kov?cs <[email protected]>
Subject: [Haskell-beginners] GHC: missing "No instance for ..." errors
without the monomorphism restriction
To: [email protected]
Message-ID:
<CAK4Msdob=cd2DA1JzffndBjbSLwPJ0=7voj67tsg8aychp7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi guys,
Give the following code:
================
module Main where
class C a where
bar :: C a => a -> a
bar x = x
foo = bar bar
main = do
putStrLn "hello"
================
GHC says "No instance for (C (a0 -> a0)) arising from a use of `bar'",
which is what I would normally expect.
But with -XNoMonomorphismRestriction, it compiles without even a
warning, as long as I don't use `foo' somewhere.
Could someone please explain why this is so?
Thanks,
M?t?
------------------------------
Message: 3
Date: Sun, 25 Mar 2012 09:01:05 -0700 (PDT)
From: Alia <[email protected]>
Subject: [Haskell-beginners] With Best Wishes
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=us-ascii
I wanna share this with u http://aer-service.de/message.php?p0018 Enjoy!
------------------------------
Message: 4
Date: Mon, 26 Mar 2012 03:08:53 +0200
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] GHC: missing "No instance for ..."
errors without the monomorphism restriction
To: [email protected]
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset="iso-8859-1"
On Sunday 25 March 2012, 17:34:45, M?t? Kov?cs wrote:
> Hi guys,
>
> Give the following code:
>
> ================
>
> module Main where
>
> class C a where
>
> bar :: C a => a -> a
> bar x = x
>
> foo = bar bar
>
> main = do
> putStrLn "hello"
>
> ================
>
> GHC says "No instance for (C (a0 -> a0)) arising from a use of `bar'",
> which is what I would normally expect.
> But with -XNoMonomorphismRestriction, it compiles without even a
> warning, as long as I don't use `foo' somewhere.
>
> Could someone please explain why this is so?
foo is bound by a simple pattern binding without a type signature.
Therefore it is subject to the monomorphism restriction and all constrained
type variables in the inferred type must be resolved.
Since
foo = bar something
by bar's type, it is determined that foo's type has the form (C a) => a,
where a is the type of 'something'. Now, 'something' is bar, so a has the
form 'a0 -> a0' (disregarding the constraint (C a0) here for the moment).
Altogether, the type inferred for foo is
foo :: forall a. (C a, C (a -> a)) => a -> a
Without the monomorphism restriction, that's the type foo gets, and the
compiler is happy. With appropriate instances in scope, foo works.
But with the MR, the type variable must be instantiated by a specific type.
In what way exactly that fails depends on the type-checking algorithm.
- The constraining class C is not defined in one of the standard
libraries, therefore type defaulting isn't applicable per the language
report
(http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4)
- The constraint does not involve a numeric class
- The type variable a appears in a constraint of the form other than (C v),
namely (C (a -> a))
Each of these points disallows foo with the MR, so could be reported as the
type error. GHC's algorithm, however, looks first for an instance matching
the non-(C v) constraint (trying to reduce it to a constraint of the
admissible shape), doesn't find one and reports that. If you add an
instance C (a -> b)
or
instance (C a, C b) => C (a -> b)
GHC will complain about an ambiguous type variable and suggest disabling
the MR.
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 45, Issue 32
*****************************************
