Am Samstag, 19. November 2005 14:57 schrieb David Roundy:

[...]

2. Multi-constructor getters, ideally as a function:

An accessor ought to be able to access an identically-named field from

multiple constructors of a given data type:

...

data FooBar = Foo { name :: String } | Bar { name :: String }

However we access "name", we should be able to access it from either constructor easily (as Haskell 98 does, and we'd like to keep this).

Let's take a concrete example. Say, I have a type Address which is declared as follows: data Address = OrdinaryAddr { name :: String, street :: String, number :: Int, city :: String, postalCode :: Int } | POBoxAddr { name :: String, poBox :: Int, city :: String, postalCode :: Int } In this example, it would be really good if there was a getter function for extracting the name out of an ordinary address as well as an PO box address. But in my opinion, the above declaration is not very nice and one should write the following instead: data Address = Address { name :: String, destination :: Destination, city :: String, postalCode :: Int } data Destination = OrdinaryDest { street :: String, number :: Int } | POBoxDest { poBox :: Int } And with this declaration we wouldn't need getter functions which are able to access identically-named fields from different data constructors of the same type. So I wonder if this feature is really sensible.

[...]

Best wishes, Wolfgang

On Saturday 19 November 2005 17:35, Bulat Ziganshin wrote:

Hello David,

Saturday, November 19, 2005, 4:57:09 PM, you wrote:

DR> I'd benefit from just a list of problems that the record proposals want to DR> solve.

DR> 1. The field namespace issue. DR> 2. Multi-constructor getters, ideally as a function. DR> 3. "Safe" getters for multi-constructor data types. DR> 4. Getters for multiple data types with a common field. DR> 5. Setters as functions. DR> 6. Anonymous records. DR> 7. Unordered records.

DR> Argh. When I think about records too long I get dizzy.

really you are wrote solutions for all these problems (except 6), and it's just an additional syntax sugar (like the fields itself). for beginning, we must split this list to two parts: belonging to static (like H98) and dynamic (anonymous) records. items in your list (except 6) belongs to static ones. dynamic records is whole different beast and it's really hard to master, so the first question will be:

"are we wanna to have in Haskell only static records, only dynamic records or both?"

as i see, GHC team want to implement such proposal, which will resolve both issues. and wainting (waiting+wanting:) for such solution, they are don't implement suggestions which address only static records problems

but the dynamic records is too complex thing: it may be syntactically incompatible with H98, it may require changes to GHC internals and so on, so they are delayed until better times

besides this all, i want to add one more item to your list:

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

Please take a look at the recent paper by Daan Leijen (http://www.cs.uu.nl/~daan/pubs.html#scopedlabels). I think this would solve the mentioned problems and has the additional advantage of supporting anonymous records. The author claims his proposal to be integrable with most known type systems. Ben

Hello Wolfgang, Sunday, November 20, 2005, 6:21:05 PM, you wrote:

...

data Coord = { x,y :: Double } data Point : Coord = { c :: Color }

WJ> A point is not a special coordinate pair. Instead it has a coordinate paar as WJ> one of its properties. So the above-mentioned problem would be better WJ> handled this way: WJ> data Coord { x, y :: Double } WJ> data Point = Point {coord :: Coord, c :: Color } because this allows a large number of procedures written to work with Coord, to automatically work with Point. iy just a matter of usability. currently, my program is full of double-dereferncing, like this: if (fiTime (cfFileInfo arcfile) >= fiTime (cfFileInfo diskfile)) maximum (last_time' : map (fiTime.cfFileInfo) dir) let size = fiSize (cfFileInfo cfile') bytes = sum$ map (fiSize.cfFileInfo) directory let keyFunc = fiStoredName . cfFileInfo -- Best regards, Bulat mailto:bulatz@HotPOP.com

Hello Wolfgang, Monday, November 21, 2005, 1:30:10 PM, you wrote:

...

...

data Coord { x, y :: Double } data Point = Point {coord :: Coord, c :: Color }

because this allows a large number of procedures written to work with Coord, to automatically work with Point. iy just a matter of usability. currently, my program is full of double-dereferncing, like this:

[...]

WJ> You should never use bad design to increase usability, I'd say. to be exact now i have the following definitions: data FileInfo = FileInfo { fiFilteredName :: !PackedFilePath , fiDiskName :: !PackedFilePath , fiStoredName :: !PackedFilePath , fiSize :: !FileSize , fiTime :: !FileTime , fiIsDir :: !Bool } -- |File to compress: either file on disk or compressed file in existing archive data FileToCompress = DiskFile { cfFileInfo :: FileInfo } | CompressedFile { cfFileInfo :: FileInfo , cfArcBlock :: ArchiveBlock -- Archive datablock which contains file data , cfPos :: FileSize -- Starting byte of file data in datablock , cfCRC :: CRC -- File's CRC } i prefer to replace second definition with the -- |File to compress: either file on disk or compressed file in existing archive data CompressedFile : FileInfo = CompressedFile { cfArcBlock :: ArchiveBlock -- Archive datablock which contains file data , cfPos :: FileSize -- Starting byte of file data in datablock , cfCRC :: CRC -- File's CRC } and then use procedures, written to work with FileInfo, to directly work with CompressedFile also. now my program is full of constructs like: uiStartProcessing (map cfFileInfo (arcDirectory arcinfo)) let fileinfo = cfFileInfo compressed_file and double-dereferencing about i wrote in previous letter. such change will allow me to omit all these superfluous code. imho, new design will be more natural and allow me to think about my algorithms instead of implementation complications -- Best regards, Bulat mailto:bulatz@HotPOP.com

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 Coord might not be the best example, but I'd certainly like to be able to automatically derive this sort of class functionality without writing lots of boiler-plate instances. -- David Roundy http://www.darcs.net

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

On 11/21/05, David Roundy wrote:

class Coord a where get_x :: a -> Double get_y :: a -> Double set_x :: Double -> a -> a set_y :: Double -> a -> a

I'd say this is a typical OO solution to the problem that doesn't exist Why do you need setters and getters for coordinate in purely functional language? Doesn't data Coord = Coord Double Double, functional composition and monads solve problems in way better than inheritance? The most impressive feature of haskell for me, as a former "OO-design patterns-UML is great" programmer was that I don't have to and in fact must not use OO and inheritance and can write code that doesn't leave you guessing what exactly it is doing and what is not. And that the language forces you make good design decisions and doesn't let you make wrong ones. Inheritance is no doubt one of the most sensless solutions for code reuse i have ever seen.

David Roundy wrote:

4. Getters for multiple data types with a common field.

[skip]

4. Getters for multiple data types with a common field.

This basically comes down to deriving a class for each named field, or something equivalent to it, as far as I can tell. This also works with the namespace issue, since if we are going to define getters and setters as functions, we either need unique field labels or we need one class per field label--or something equivalent to a class for each field label.

This is a problem similar to one I had to solve for HSFFIG to design a syntax to access fields of C structures (where different structures may have fields of same name but of different types). I ended up with a multiparameter class parameterized by a C structure name, field name, field type, and for each occurrence of these in C header file I autogenerated an instance of this class. See http://hsffig.sourceforge.net/repos/hsffig-1.0/_darcs/current/HSFFIG/FieldAc... for the class itself, and a typical instance (autogenerated of course) looked like instance HSFFIG.FieldAccess.FieldAccess S_362 ((CUChar)) V_byteOrder where z --> V_byteOrder = ((\hsc_ptr -> peekByteOff hsc_ptr 0)) z {-# LINE 5700 "XPROTO_H.hsc" #-} (z, V_byteOrder) <-- v = ((\hsc_ptr -> pokeByteOff hsc_ptr 0)) z v {-# LINE 5701 "XPROTO_H.hsc" #-} for a field `byteOrder' of type `unsigned char'. This might work in general for what is proposed in the item 4 quoted above. A class with 3 parameters will be needed, and perhaps some syntactic sugar to autogenerate it and its instances. The only downside is GHC needs too much memory to compile all this: I had to add a splitter utility to HSFFIG otherwise GHC failed short of memory on even several tens of C structures. Dimitry Golubovsky Middletown, CT

Hello,

Personally, I would quite like to have "first-class labels". By this I mean the ability to pass record labels as arguments, and to return them as results.

To me, this seems as the most elegant and reasonable solution. First class thingies are a good idea imho. --Andy ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

My mistake, what you want is: ( mything .=. "something" .*. value .=. (27::Int) .*. logic .=. True .*. HNil ) Admittedly the label creation would benefit from some syntactic sugar to reduce typing... Keean. Bulat Ziganshin wrote:

Hello Keean,

Monday, November 21, 2005, 6:56:06 PM, you wrote:

KS> So you can do this now... with reasonable syntax, for example to KS> create an extensible record

KS> ("some thing" .*. (27 :: Int) .*. True .*. HNil)

KS> is a statically typed anonymous record.

it is not record, but heterogenous list, in my feel. record must be indexed by field name, not by type name or position