On Thu, Nov 11, 2010 at 8:16 PM, John Lask 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... ....ie 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.