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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe