Records in Haskell

[Ingo Wechsung]

2012/1/8 Gábor Lehel <illissius at gmail.com>

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

Yes, I can see your point here. OTOH, with the x.y.z notation the number of
parentheses needed can be reduced drastically at times.
In the end it's maybe a matter of taste. Frege started as a pure hobby
project (inspired by Simon Peyton-Jones' paper "Practical type inference
for higher ranked types"), but later I thought it may be interesting for OO
programmers (especially Java) because of the low entry cost (just download
a JAR, stay on JVM, etc.), and hence some aspects are designed so as to
make them feel at home. Ironically, it turned out that the most interest is
in the FP  camp, while feedback from the Java camp is almost 0. Never mind!

-- 
Mit freundlichen Grüßen
Ingo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120108/db0f9cdf/attachment.htm>