"class []" proposal Re: [Haskell-cafe] One thought: Num to 0 as ? to list?

Arie Peterson ariep at xs4all.nl
Tue Aug 22 11:24:34 EDT 2006

Hello Bryan,

On 2006-08-22, Bryan Burgers <bryan.burgers at gmail.com> wrote:
>> so, while this proposal is rather minor, i think that it is Good thing
> I disagree. As a new learner to Haskell, I already have a hard time
> keeping Constructors, Types, and Classes straight. I know what they
> all are and what they all do, but sometimes I really have to think
> hard to remember which is which in a piece of code. What helps my
> understanding is that each has a specific place in the type signature
> (which I guess includes 'nowhere' regarding constructors). Being able
> to put Classes where Types go would just serve to muddle that
> understanding.

This is an instance of a general conflict: should we sacrifice nice
notation for ease of learning? You could make a similar case for list
comprehensions, for example: they complicate matters for newcomers (yet
another meaning of brackets and pipe), but once you get used to them, they
may actually simplify code.

However, this need not be a conflict at all. Introductory material can
simply ignore syntactic sugar like list comprehensions and this new
proposal (*). If there are independent tutorials of these "extra
features", explaining their meaning in terms of basic haskell, someone
learning haskell can learn to use them one at a time, as s/he encounters
them in the wild.

I agree that it may be complicating to have more than one way to write the
same code. There is a balance between the gained ease of writing (and
reading!) and the burden of having to do a mental translation when
combining code using the different ways, but this should be kept distinct
from the problem of learning Haskell.

(*) In this specific instance one might (ab?)use the additional notation
to create a gentle introduction to type classes in a course/tutorial: one
of the first lessons/chapters could state that the type of '(+)' is 'Num
-> Num -> Num', where 'Num' means "some numeric type" (stressing that it
is *the same* type in all three places), only later confessing that this
is actually shorthand for something more elaborate, and that the vague
notion of "some numeric type" can be made explicit using type classes.




Mr. Pelican Shit may be Willy.


More information about the Haskell-Cafe mailing list