Records in Haskell

[Gábor Lehel]

2012/1/8 Ingo Wechsung <ingo.wechsung at googlemail.com>:
>
>
> 2012/1/8 Gábor Lehel <illissius at gmail.com>
>
>>
>> The second is that only the author of the datatype could put functions
>> into its namespace; the 'data.foo' notation would only be available
>> for functions written by the datatype's author, while for every other
>> function you would have to use 'foo data'. I dislike this special
>> treatment in OO languages and I dislike it here.
>
>
> Please allow me to clarify as far as Frege is concerned.
> In Frege, this is not so, because implementations of class functions in an
> instance will be linked back to the  instantiated types name space. Hence
> one could do the following:
>
> module RExtension where
>
> import original.M(R)    -- access the R record defined in module original.M
>
> class Rextension1 r where
>       firstNewFunction :: .....
>       secondNewFunction :: .....
>
> instance Rextension1 R where
>      -- implementation for new functions
>
> And now, in another module one could
>
> import RExtension()      -- equivalent to qualified import in Haskell
>
> and, voilá, the new functions are accessible (only) through R

Ah, I see. And that answers my other question as well about why you
would special case class methods like this. Thanks. I think I prefer
Disciple's approach of introducing a new keyword alongside 'class' to
distinguish 'virtual record fields' (which get put in the namespace)
from any old class methods (which don't). Otherwise the two ideas seem
very similar. (While at the same time I still dislike the
wrong-direction aspect of both.)

It strikes me that this kind of 'virtual record fields' (or
'projectors') thing is trying to tackle a very similar problem space
as views and view patterns do. Namely, a kind of implementation
hiding, eliding the difference between information which happens to
represented by actual physical data and information which is merely
calculated from that data. So you could in theory later change the
representation (which fields are stored and which are calculated)
without the client code noticing. There also seems to be an analogy
between view patterns and simple function-based virtual-record-fields
on the one hand, which are read-only, and full views and a theoretical
lens-based virtual-record-fields on the other hand, which you can also
use for update. (I don't see any way around having to write both the
access and update function manually though, unless someone figures out
how to invert functions in the general case). I don't have any
follow-on thoughts from this at the moment but it seemed interesting
to note.

>
>
> --
> Mit freundlichen Grüßen
> Ingo



-- 
Work is punishment for failing to procrastinate effectively.