Type classes are very easy to explain, and quite obviously useful. This,
presumably, is why they're in the language.
You'd be surprised, I've seen people twist their brains in knots before
finally getting it.
Given the long debate I've just had about why "(/) 7 4" is a valid
expression but "/ 7 4" isn't, nothing would surprise me... *sigh*
Almost all language extensions seem to be of the form "hey, let's see what
happens if we randomly change the type checking rules so that *this* is
permitted. What would that be like?" Usually it's an extreme struggle to even
wrap my brain around what the extension *is*, never mind why this would be a
useful thing...
The proposer almost invariably has a use case - often a pretty big one.
But usually one that's vastly too mind-bending to comprehend, it must be
said...
I suppose it's like when mathematitions say that the Gamma function is
of fundamental importance - and yet they can't explain what it's
actually important for.
(OOC, what's a constructor class?)
It's a type class that's really a class of type constructors rather than
one of types - if you like, a class whose parameter isn't of kind *. The
canonical example is Monad. These days they're just type classes, there's
no distinction made.
Oh, right. I thought that was called "higher-kinded classes"?
Indeed, I'm still figuring out why you would want to do something like this.
(Beyond "because you can".)
It's much easier to understand than the 'traditional' style of
implementation (which fuses the constructors with the interpreter). It's
even more useful if you work with structures like arrows where there are
useful things you can do with a computation without actually running it,
as you don't have to bake the various analyses into the arrow type. I
wouldn't chose it as the ideal release version, but I'd mechanically build
the release code by doing everything with the GADT and then fusing once
I'm done - and if compilers ever get good enough at deforesting, I'd
happily elide that step!
If you're fond of the Knuth quote, then the 'traditional' implementation
may smell a lot like premature optimisation enforced by an inflexible type
system.
Well, sure enough I've run across useful things the type checker won't let me
do. (For example, you can't make Data.Set into a monad, since it demands that
all elements be in Ord, but a monad is required to accept *all* possible
element types.) It's pretty rare though.
For me, working in Haskell 98, it tends to happen as my apps grow above a
certain size (and it's less than a thousand lines). That, and I find the
ST monad pretty invaluable so if I'm doing something where it fits I
won't blink before using it.
Perhaps it depends on the kind of code you write or something... I've
found very few occasions where the type system defeats me. (Heterogenous
lists, the Set monad I mentioned, a few bits like that.) Mostly I can't
make my programs work properly because I can't come up with a working
algorithm.
Looks like a pretty simple language to me...
It can be stripped significantly further.
True. But I mean, useful little bits of syntax aside, the semantics are
pretty simple. (Indeed, that's what I love about the language. Figure
out function definition, function application, currying, parametric
polymorphism, and type classes and you've basically learned almost all
of it.)
you can
retain pretty much everything with variables, applications, lambdas and
simple let and case statements.
I wish I had a parser that would parse Haskell this way... heh.
Things like do blocks and list
comprehensions aren't strictly speaking necessary at all, and an awful lot
of complexity's added to parsing Haskell 98 by everything that can be done
with infix operators.
Yeah, parsing Haskell is pretty simple until you add comments, and
do-blocks, and list comprehensions, and infix operators, and where
bindings, and guards, and...
Personally, I try to avoid ever using list comprehensions. But every now
and then I discover an expression which is apparently not expressible
without them - which is odd, considering they're only "sugar"...
You're missing a lot of the conceptual background
Possibly. I find that most of what is written about Haskell tends to be
aimed at absolute beginners, or at people with multiple PhDs. (As in,
people to whom arcane terms like "denotational semantics" actually
*means* something.) I remember seeing somebody wrote a game (!!) in
Haskell - despite the fact that this is obviously impossible. So I went
to read the paper about how they did it... and rapidly become completely
lost. I get that they used something called "funtional reactive
programming", but I am still mystified as to what on earth that actually
is, or how it functions.
But an awful lot
of the more popular extensions are primarily about relaxing constraints
and picking the most natural way to follow through.
"Hey, let's make it so that classes can have several parameters!" Um...
OK, that more or less makes sense. I can see uses for that.
"Hey, let's make it so a class instance can have one or more types
associated with it!" Er... well, that seems straight forward enough.
Alright.
"Hey, let's make it so that class methods can have completely arbitrary
types!" Wait, what the hell? How does *that* make sense?! o_O
"Hey, let's make it so you can use a type variable on the RHS that
doesn't even appear on the LHS!" Um... that's going to be tricky, but
sure, OK.
"Hey, let's make it so you can implement Prolog programs inside the type
system!" Right, I'm getting my coat now... :-P
In short, some of these relax restrictions in fairly obvious directions,
and others just seem downright bizzare.
It helps if you can picture a matching explicitly-typed language.
I don't really understand that statement.
An idea you might find helps: what you're finding with algorithms, I find
with architecture when I have the extensions that let me type it.
...or that one...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
