Fwd: Re: [Haskell-cafe] Type Directed Name Resolution

John Lask jvlask at hotmail.com
Thu Nov 11 22:00:51 EST 2010

> On Thu, Nov 11, 2010 at 8:16 PM, John Lask<jvlask at hotmail.com>  wrote:
>> consider "length" ...
>> I have records with the attribute length, length can be given as an Int,
>> Double, Float or maybe as a constructed type "Length", length's use as a
>> record selector would also clash with List.length. All these have the same
>> denotation.
>> should I then seporate into int_length, float_length, or use rec1_length,
>> rec2_length etc etc...
> class Lengthy a where
>    type LengthType a
>    length :: a ->  LengthType a
> This extends easily to lenses if you want setters.

to make use of the class Lengthy I still need to define record selectors
with different names, which is exactly the point I am making...


data Record = RecLen { rec_length :: ... }

instance Lengthy Record where
   length = rec_length

>> This is easily handled in C, Pascal, PL/1, Cobol why not in Haskell ?
> By this argument, Haskell should provide global mutable state and
> allow side-effects universally.

no, but these languages have their strengths as well, for example Cobol
PIC strings format currency values very nicely and it would be great if
there were a Haskell library that could do the same. Not to mention
currency values!

The point is that languages are often constructed with a purpose in
mind, at which they tend to be particularly good. Haskell has
traditionally been a test bed for type system innovation, which is why
we all like it so much.

As and if, the usage of Haskell broadens, then domains of application
stray into areas of application for which it is not ideally suited, in
those circumstances why not consider features of other languages which
handle those use cases well. (for some definition of "well")

By the way I am not arguing for TDNR, merely that all is not well with
haskell records.

More information about the Haskell-Cafe mailing list