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. How to think in Haskell (Jun HU)
2. Re: How to think in Haskell (Luca Ciciriello)
3. Re: How to think in Haskell (Tommy M. McGuire)
4. Re: How to think in Haskell (Brent Yorgey)
5. polymorphism vs. overloading (Dennis Raddle)
6. polymorphism vs. overloading (Eugene Perederey)
----------------------------------------------------------------------
Message: 1
Date: Thu, 16 Dec 2010 15:46:57 +0100
From: Jun HU <[email protected]>
Subject: [Haskell-beginners] How to think in Haskell
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear everyone,
My first language is C, and I've strong intention in learning a pure
functional programming language. My very first question is how to
think in the functional programming way, anyone has some ideas.
Really appreciate....
Regards,
Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20101216/dd2afc62/attachment-0001.htm>
------------------------------
Message: 2
Date: Thu, 16 Dec 2010 16:41:24 +0100
From: Luca Ciciriello <[email protected]>
Subject: Re: [Haskell-beginners] How to think in Haskell
To: Jun HU <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi, here my path (in correct order) I followed to learn to think functionally:
1) Curry-Howard Isomorphism
2) Type Theory & Functional Programming
3) The Hindley-Milner Type inference algorithm
4) Basic Category Theory
5) Notions of computation and monads
6) Denotational semantics
7) Monads for functional programming
8) Theorems for free.
9) A History of Haskell: Being Lazy With Class
These are all papers you can find on Google.
Then you can start to read some Haskell tutorial.
It is not easy, but these readings are necessary to open your mind to the
fantastic world of Functional Programming (I come from 15 Years of C++).
Luca.
On Dec 16, 2010, at 3:46 PM, Jun HU wrote:
> Dear everyone,
>
> My first language is C, and I've strong intention in learning a pure
> functional programming language. My very first question is how to
> think in the functional programming way, anyone has some ideas.
> Really appreciate....
>
> Regards,
>
> Jun
> _______________________________________________
> 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/20101216/e6180b75/attachment-0001.htm>
------------------------------
Message: 3
Date: Thu, 16 Dec 2010 11:32:22 -0600
From: "Tommy M. McGuire" <[email protected]>
Subject: Re: [Haskell-beginners] How to think in Haskell
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/16/2010 08:46 AM, Jun HU wrote:
> My first language is C, and I've strong intention in learning a pure
> functional programming language. My very first question is how to
> think in the functional programming way, anyone has some ideas.
> Really appreciate....
I cannot claim C as my first language, but I do say it is my "natural"
language; I have written more code in it than I have in any other, and
I've been using it for nigh on 20 years.
I also cannot claim to think in the functional programming way, but it
definitely has changed my thinking. (Thinking about it now, I believe
functional programming has had a bigger effect than I had considered.
But I am definitely not a Haskell guru.)
I believe the biggest difference between functional programming and
procedural is thinking equationally rather than operationally. With
procedural programming as in C (and object oriented languages, which in
my experience are more procedural than not), the tendency is to think
operationally: "First this happens, then it does this, then that,...."
Now, back at UT Austin (I grew up in the land of Dijkstra), at the time
anyway, they were fond of axiomatic thinking: "At this point in the
program text, the state is this; at that point in the text, the state is
that...." That is definitely a significant improvement, and I attribute
what decent code I have written to that approach, but it definitely is
not as natural as either operational or equational thinking.
In Haskell especially, but in other functional languages to a lesser
extent (and also when doing functional approaches in a non-functional
language), it is very important to think equationally: "This means that;
this other thing is that...." Now, equational thinking is easy for stuff
like
add_one n = n + 1
But it is not immediately apparent how that extends to something that
needs recursion, say. The big "Ah-ha!" moment for me is the realization
that recursion and mathematical induction are the same thing (ok, it's
not a surprise; the big deal was when I internalized it). With that, you
can deal with anything equational and recursive as equational and
inductive. The change in thinking is as big as the difference between
operational and axiomatic.
Equational thinking extends beyond basic function definitions; I think
it is the key to the type system, classes, and most of the other neat
language features.
At this point, I am still struggling with category theory, although I
have been able to make use of monads reasonably elegantly (in my
(humble) opinion, of course). I think there is another step there,
although I haven't made it. (I am willing to change my traditional
definition, "Programming is applied formal logic," to include at least
abstract algebra and category theory at this point, though.)
--
Tommy M. McGuire
[email protected]
------------------------------
Message: 4
Date: Thu, 16 Dec 2010 13:28:59 -0500
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] How to think in Haskell
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Thu, Dec 16, 2010 at 04:41:24PM +0100, Luca Ciciriello wrote:
> Hi, here my path (in correct order) I followed to learn to think functionally:
>
> 1) Curry-Howard Isomorphism
> 2) Type Theory & Functional Programming
> 3) The Hindley-Milner Type inference algorithm
> 4) Basic Category Theory
> 5) Notions of computation and monads
> 6) Denotational semantics
> 7) Monads for functional programming
> 8) Theorems for free.
> 9) A History of Haskell: Being Lazy With Class
These are all wonderful topics. But I strongly disagree with the
notion that one must understand all of these before even starting a
Haskell tutorial (!), or even that one must understand all of these to
be able to "think functionally" in some sense.
-Brent
------------------------------
Message: 5
Date: Thu, 16 Dec 2010 19:34:52 -0800
From: Dennis Raddle <[email protected]>
Subject: [Haskell-beginners] polymorphism vs. overloading
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I looked up the difference between polymorphism and overloading (speaking of
all languages in general), and apparently polymorphism is a general term for
an operation that can accept arguments of different types. Overloading is a
form of "ad-hoc polymorphism" in which the compiler chooses specific code to
be executed by inspecting the arguments at compile time. Apparently "true
polymorphism" means exactly the same code is executed no matter what the
argument types, such as implemented by inheritance in C++ (*) Now my
understanding of Haskell's classes is that the compiler chooses the right
instance of the class at compile time. Does that mean that Haskell
implements only ad-hoc polymorphism?
(*) Another question: if someone says "What feature of C++ makes
polymorphism possible?" What is the correct answer? Inheritance? Virtual
methods? Some combination?
-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20101216/984adde9/attachment-0001.htm>
------------------------------
Message: 6
Date: Thu, 16 Dec 2010 20:02:54 -0800
From: Eugene Perederey <[email protected]>
Subject: [Haskell-beginners] polymorphism vs. overloading
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Haskell supports parametric polymorphism in the sense as, for example,
operations on lists. Thus function ?List.length::[a]->Int is
polymorphic.
The difference between polymorphism and overloading is that
polymorphism basically means that there is one algorithm for different
types of operands whereas overloading means that for one symbol there
are different implementations.
Haskell compiler converts an overloaded function in such way that the
function is passed an additional argument -- a dictionary that
contains implementation of operations defined in the class.
Consider function square:
square :: Num n => n -> n
square x = x*x
class Num a where
(+) ?:: a -> a -> a
(-) ?:: a -> a -> a
negate :: a->a
...etc...
instance Num Int where
(+) = intPlus a b
(*) = intMult a b
negate a = intNeg a
...etc...
where functions intPlus, intMult, intNeg are defined somewhere else.
So at compile time the type of square :: Num n => n -> n is replaced with
square :: numDict n -> n -> n
where numDict a is a parametric data type with defined accessor
functions that return implementation of operations defined in the
class.
On 16 December 2010 19:34, Dennis Raddle <[email protected]> wrote:
> I looked up the difference between polymorphism and overloading (speaking of
> all languages in general), and apparently polymorphism is a general term for
> an operation that can accept arguments of different types. Overloading is a
> form of "ad-hoc polymorphism" in which the compiler chooses specific code to
> be executed by inspecting the arguments at compile time. Apparently "true
> polymorphism" means exactly the same code is executed no matter what the
> argument types, such as implemented by inheritance in C++ (*) Now my
> understanding of Haskell's classes is that the compiler chooses the right
> instance of the class at compile time. Does that mean that Haskell
> implements only ad-hoc polymorphism?
>
>
> (*) Another question: if someone says "What feature of C++ makes
> polymorphism possible?" What is the correct answer? Inheritance? Virtual
> methods? Some combination?
>
> -D
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
--
Best,
Eugene Perederey
--
Best,
Eugene Perederey
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 30, Issue 34
*****************************************
