[Haskell-cafe] Language extensions

[Andrew Coppin]

>> 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...