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: Type ambiguity - Int vs. Integer (Andres Loeh)
2. Re: Type ambiguity - Int vs. Integer (Daniel Fischer)
3. Re: diagrams installation trouble (Daniel Fischer)
4. Re: Type ambiguity - Int vs. Integer (Thomas)
5. Haskell described as a "rigid" language (aditya siram)
6. Re: Haskell described as a "rigid" language (Amy de Buitl?ir)
7. Implementing a Local Propagation Network (Patrick LeBoutillier)
8. Re: Haskell described as a "rigid" language (Amy de Buitl?ir)
9. Re: Haskell described as a "rigid" language
(Stephen Blackheath [to Haskell-Beginners])
----------------------------------------------------------------------
Message: 1
Date: Mon, 17 May 2010 19:43:32 +0200
From: Andres Loeh <[email protected]>
Subject: Re: [Haskell-beginners] Type ambiguity - Int vs. Integer
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi.
So this fragment works:
> data AW = AI Integer deriving (Show, Eq, Ord)
>
> class AWC a where
> toAW :: a -> AW
> fromAW :: AW -> a
>
> instance AWC Integer where
> toAW = AI
> fromAW (AI v) = v
>
> > toAW 5
> 5
But replacing Integer by Int everywhere above
yields
> > toAW 5
> Ambiguous type variable 't' in the constraints:
> 'Num t' arising from the literal '5'
> 'AWC t' arising from the use of 'toAW'
The reason for this behaviour is a dark(er) corner of Haskell called
"defaulting", described in Section 4.3.4 of the Haskell Report. Look at
what ghci says about 5:
> :t 5
5 :: (Num t) => t
So, the literal 5 can be interpreted as any numeric type. This is
nice, because it allows us to use 5 as an integer, as in
> :t length [] + 5
length [] + 5 :: Int
or as a floating point number
> :t sin pi + 5
sin pi + 5 :: (Floating a) => a
(Note that the latter type is still overloaded, as Floating can
be instantiated to either Float or Double.)
Now, your method toAW has the type
(AWC a) => a -> AW
You apply this method not to a value of a specific type, but to
a value of another overloaded type, namely your literal 5. This
means that Haskell has to figure out which concrete type to choose
for "a" in this case.
Haskell's type classes are open, and it usually does not randomly
pick one if multiple *might* match. In this case, there is an instance
for Integer (in your first example) or Int (in your second), but there
might as well be another one for Float or Double. Which one would be
the right one? Well, as I said, usually Haskell is conservative here
and just complains, hence the "Ambiguous type variable" error you get
in the second case.
However, there is a mechanism in Haskell to give heuristics, and
that's what "defaulting" is all about. Under normal circumstances,
Haskell will, for numeric types, pick "Integer" in cases of ambiguity,
and if that doesn't work, it will try "Double". It does not try "Int"
though. This explains why your first example (by accident) works.
If you ask GHCi for the type, defaulting isn't applied, but you
can observe it to happen in many places. For example,
> show 5
"5"
> show (5 :: Double)
"5.0"
So, apparently, Haskell decides to show an unconstrained numeral
like an Integer, not like a Double.
A more conclusive example is
> Data.Typeable.typeOf 5
Integer
Defaulting to Double if Integer is ruled out can be observed by
> Data.Typeable.typeOf (sin pi)
Double
Cheers,
Andres
--
Andres Loeh, Universiteit Utrecht
mailto:[email protected] mailto:[email protected]
http://www.andres-loeh.de
------------------------------
Message: 2
Date: Mon, 17 May 2010 19:45:00 +0200
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] Type ambiguity - Int vs. Integer
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On Monday 17 May 2010 18:44:11, Thomas wrote:
> Hello!
>
> I was very surprised to see that Int and Integer seem to differ with
> respect to ambiguity. And I have no idea what is going on.
>
> This works as intended:
> data AW = AI Integer deriving (Show, Eq, Ord)
>
> class AWC a where
> toAW :: a -> AW
> fromAW :: AW -> a
>
> instance AWC Integer where
> toAW = AI
> fromAW (AI v) = v
>
> > toAW 5
>
> 5
>
> However, the following gives an error:
> data AW = AI Int deriving (Show, Eq, Ord)
>
> class AWC a where
> toAW :: a -> AW
> fromAW :: AW -> a
>
> instance AWC Int where
> toAW = AI
> fromAW (AI v) = v
>
> > toAW 5
>
> Ambiguous type variable 't' in the constraints:
> 'Num t' arising from the literal '5'
> 'AWC t' arising from the use of 'toAW'
>
> Ok, I can fix this easily with
>
> > toAW (5::Int)
>
> But I still don't understand what's going on?
The literal 5 (which is implicitly 'fromInteger 5'), can have any type
which is a member of Num, so in
toAW 5
, the type of 5 is ambiguous. For convenience, in some cases, a Haskell
implementation tries to resolve such ambiguities by defaulting
(http://haskell.org/onlinereport/decls.html#sect4.3.4).
The default-default is (Integer, Double), that means, if an ambiguity can
be resolved by choosing the type Integer, that is chosen, otherwise Double
is tried. You can give different defaults in a module, so e.g. a default
declaration
default (Int, Integer, Rational, Double)
would try Int first.
However, according to the defaulting rules in the report, no defaulting
would take place here, since there's a class (AWC) involved which isn't
defined in the standard libraries.
But ghci uses relaxed defaulting rules (to resolve more cases, otherwise
'ambiguous type' errors would be much more frequent), so it tries to
resolve the ambiguity although AWC isn't defined in the standard libraries.
In the first case, choosing Integer for the type works, so it takes Integer
for the type of 5 and all's well. In the second case, Integer doesn't work,
nor does Double, so it can't resolve the ambiguity.
Unfortunately, when ghci loads a module, it ignores default declarations,
so you couldn't get it to work by adding default declaration including Int.
> Why does one type work and the other does not?
> Is there a way around this without type annotations?
No, not at the ghci prompt. In normal code, usually the type of such a
value could be determined from other things (when you use it in a function,
there's much more contextual information than when you enter such an
expression at the prompt).
For uses inside the module, you can have some success with
{-# LANGUAGE ExtendedDefaultRules #-}
module AWC where
default (Int, Integer, Double)
data AW = AI Int deriving (...)
...
if not all uses allow the type to be determined from the context.
>
> Any hint would be greatly appreciated!
> Thanks in advance,
> Thomas
------------------------------
Message: 3
Date: Mon, 17 May 2010 20:18:02 +0200
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] diagrams installation trouble
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Monday 17 May 2010 19:40:06, Scott N. Walck wrote:
> Â I'd like to try to get gtk2hs
> to compile with GHC 6.12. Â Below I show the trouble that I run into.
> Maybe there's an easy fix?
>
> Thanks,
>
> Scott
<snip wall of text from gtk2hs>
I don't know what that means, maybe it's
"January 18th, 2010
Duncan posted a patch that allows compilation of Gtk2Hs with ghc 6.12.
However, you need to specify âdisable-split-objs option when running
configure as ghc 6.12 puts object files in directories where our Makefile
does not expect them."
So you could try configuring with --disable-split-objs.
But perhaps better try
http://haskell.org/gtk2hs/archives/2010/04/21/cabalized-version-of-gtk2hs-
now-up-for-testing/ ?
------------------------------
Message: 4
Date: Mon, 17 May 2010 21:21:22 +0200
From: Thomas <[email protected]>
Subject: Re: [Haskell-beginners] Type ambiguity - Int vs. Integer
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thanks Andres, thanks Daniel.
It's crystal clear now...
:)
------------------------------
Message: 5
Date: Mon, 17 May 2010 20:22:18 -0400
From: aditya siram <[email protected]>
Subject: [Haskell-beginners] Haskell described as a "rigid" language
To: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Haskell is considered by many as an inflexible language [1] . I
describe a flexible language as one that supports any design you want
(even a bad one) - if you can think it, you can code it and run it
(bugs and all).
I share this opinion about Haskell but pursue it because I feel that
one day it will open up and let me think more about the problem and
less about how to get GHC to approve it.
So I guess the question to you practitioners is: Would you agree that
it is a rigid language as describe in the link below, or is that just
an illusion that goes away with experience?
-deech
[1]
http://therighttool.hammerprinciple.com/statements/this-language-has-a-very-rigid-idea-of-how-things-
------------------------------
Message: 6
Date: Tue, 18 May 2010 01:42:58 +0100
From: Amy de Buitl?ir <[email protected]>
Subject: Re: [Haskell-beginners] Haskell described as a "rigid"
language
To: aditya siram <[email protected]>
Cc: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I'm still sort of a beginner with Haskell, but ere are my thoughts. In the
sense you mean it, yes Haskell could be considered inflexible because it
makes it easier to implement a functional design and harder to implement an
imperative design. But if I were to go back to Java now, I would find it
very inflexible because it makes it very difficult to functional design, and
very easy to do imperative design. I would miss features like functors,
monads, and lazy evaluation.
On 18 May 2010 01:22, aditya siram <[email protected]> wrote:
> Haskell is considered by many as an inflexible language [1] . I
> describe a flexible language as one that supports any design you want
> (even a bad one) - if you can think it, you can code it and run it
> (bugs and all).
>
> I share this opinion about Haskell but pursue it because I feel that
> one day it will open up and let me think more about the problem and
> less about how to get GHC to approve it.
>
> So I guess the question to you practitioners is: Would you agree that
> it is a rigid language as describe in the link below, or is that just
> an illusion that goes away with experience?
>
> -deech
>
> [1]
> http://therighttool.hammerprinciple.com/statements/this-language-has-a-very-rigid-idea-of-how-things-
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20100517/07dcaaf3/attachment-0001.html
------------------------------
Message: 7
Date: Mon, 17 May 2010 20:59:11 -0400
From: Patrick LeBoutillier <[email protected]>
Subject: [Haskell-beginners] Implementing a Local Propagation Network
To: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
After learning some Haskell recently, I decided to revisit a book
about functional programming techniques for Perl: Higher Order Perl. I
didn't fully understand the book at the time but now my Haskell
experience has proved to be very insightful.
Towards the end of the book the author implements a local propagation network.
Here is the Perl source code:
http://hop.perl.plover.com/Examples/Chap9/Local-Propagation/
The PDF of the specific chapter is here:
http://hop.perl.plover.com/book/pdf/09DeclarativeProgramming.pdf
I would like to experiment with something similar in Haskell, but the
way this network is designed is all about state and references:
- Wires have a values that can change over time;
- Wires have references to nodes;
- Nodes have references to wires;
I'm a bit stuck as to how to approach the "object has a list
references to other objects" situation from Haskell. I tried this:
type Name = String
data Node = Node Name [Wire]
data Wire = Wire Name Node Double [Node]
But that doesn't seem like it would work since when I change a Wire I
must find all "copies" of it (in the Node objects) and update them
also. Perhaps I should just refer to Wires/Nodes by name and use an
association list to lookup them up, but that seems cumbersome.
Anybody have any suggestions?
Thanks a lot,
Patrick
--
=====================
Patrick LeBoutillier
Rosemère, Québec, Canada
------------------------------
Message: 8
Date: Tue, 18 May 2010 02:24:50 +0100
From: Amy de Buitl?ir <[email protected]>
Subject: Re: [Haskell-beginners] Haskell described as a "rigid"
language
To: aditya siram <[email protected]>
Cc: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
To put it another way...
If you try to use an object-oriented approach in Haskell, you're going to
find the experience a little frustrating, and you'll feel the language is
rigid.
If you try to use a functional approach in Java, C++, etc., you're going to
find the experience a little frustrating, and you'll feel the language is
rigid.
A few weeks ago I did a bit of PHP programming for a client, and discovered
that PHP won't warn you if you use a variable without declaring it. Now
that's what I call flexible! But instead of rejoicing in that flexibility, I
was annoyed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20100517/55e050c2/attachment-0001.html
------------------------------
Message: 9
Date: Tue, 18 May 2010 14:26:45 +1200
From: "Stephen Blackheath [to Haskell-Beginners]"
<[email protected]>
Subject: Re: [Haskell-beginners] Haskell described as a "rigid"
language
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Aditya,
I have been programming in imperative languages for 20+ years and
Haskell for about 2 years, and I've written a lot of it. I've never
found Haskell restricting. Twice I have decided that a dynamic type was
needed, and in many cases I've used object-oriented approaches in
Haskell where it makes sense. This is actually fairy often. One
example is a web widgets library where each widget had different
'render', 'parse', etc methods.
Doing OO in Haskell isn't hard at all, in my opinion. You just use a
data structure of functions. If you want it to have mutable state, you
use an IORef (but it really isn't necessary). It's more typing than
usual Haskell, but it still beats Java. Python would be more succinct
than both.
I've also written things very imperatively in IO, and found I could do
anything I liked.
I can think of some very small parts of programs where it might have
been a little easier in Java or Python, but not by much, and Haskell's
other advantages generally offset it.
On occasions I've realized that the design wasn't going to work, and I
needed to get some data from A to B. In other languages, you can use a
global variable or singleton (same thing). In Haskell it means a bit of
re-design. But the thing is, it's so easy to refactor in Haskell, that
the extra work doesn't matter much. Your code is already modular at
every level, so it's easy to move things around. When your code never
gets a chance to get messy, and the type system doesn't let you break
anything that previously worked, refactoring becomes a pleasure instead
of a chore.
So Haskell's inflexibility actually gives you the ability to rearrange
your program effortlessly. That is, you get a lot in return. I could
probably add that Haskell's inflexibility is determined by the types you
give things. You can restrict yourself as much or as little as you
like, but Haskell allows you to restrict yourself a lot more than other
languages do.
Steve
On 18/05/10 12:22, aditya siram wrote:
> Haskell is considered by many as an inflexible language [1] . I
> describe a flexible language as one that supports any design you want
> (even a bad one) - if you can think it, you can code it and run it
> (bugs and all).
>
> I share this opinion about Haskell but pursue it because I feel that
> one day it will open up and let me think more about the problem and
> less about how to get GHC to approve it.
>
> So I guess the question to you practitioners is: Would you agree that
> it is a rigid language as describe in the link below, or is that just
> an illusion that goes away with experience?
>
> -deech
>
> [1]
> http://therighttool.hammerprinciple.com/statements/this-language-has-a-very-rigid-idea-of-how-things-
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 23, Issue 25
*****************************************
