[Haskell-cafe] records proposals list

[David Roundy]

On Mon, Nov 21, 2005 at 02:48:48PM +0100, Wolfgang Jeltsch wrote:
> Am Montag, 21. November 2005 14:27 schrieb David Roundy:
> > On Sun, Nov 20, 2005 at 04:21:05PM +0100, Wolfgang Jeltsch wrote:
> > > Am Samstag, 19. November 2005 17:35 schrieb Bulat Ziganshin:
> > > > 7. OOP-like fields inheritance:
> > > >
> > > > data Coord = { x,y :: Double }
> > > > data Point : Coord = { c :: Color }
> > > >
> > > > of course this is just another sort of syntax sugar once we start
> > > > using classes to define getter/setter functions
> > >
> > > I thought that even many OO people say that inheritance of fields is not
> > > good practice.  So why should we want to support it?
> >
> > Think of it instead as being syntactic sugar for a class declaration:
> >
> > class Coord a where
> >   get_x :: a -> Double
> >   get_y :: a -> Double
> >   set_x :: Double -> a -> a
> >   set_y :: Double -> a -> a
> 
> As I pointed out in another e-mail just sent, this kind of special syntax
> only solves a very specific problem so that it's questionable whether
> this syntax should be included into Haskell.  However, if we manage to
> create a more generalized approach, inclusion of it into the language
> might be quite fine.
> 
> In addition, having a line which begins with "data" declaring a class is
> *very* misleading, in my opinion.

Data lines declare instances all the time via deriving.  If something like
this were implemented--and really this applies to any scheme that creates
functions to access record fields--there would need to be a set of implicit
classes for field access.  To fix the namespace issue with field names, the
only two solutions (as far as I can tell) are

(a) Don't create getter or setter functions for field access.  This is what
    the SM proposal does.

(b) Create some sort of class that allows getter and/or setter functions
    for field access.

(a) involves the creation of a non-function syntax for something that is
essentially a function--and means you'll need boiler-plate code if you want
to create accessor functions.  (b) means a proliferation of classes, which
is perhaps more problematic, but you gain more from it--you avoid the
requirement of a special syntax for accessing fields of a record.  So if
some variant of (b) is practical, I'd vote for it.  I'm not attached to the
inheritance idea, but it's basically a limited form of (b).
-- 
David Roundy
http://www.darcs.net