records proposals list

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

records proposals list

Bulat Ziganshin
Hello Haskell,

  can anyone write at least the list of record proposals for Haskell?
or, even better, comment about pros and contras for each proposal?

--
Best regards,
 Bulat                          mailto:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

David Roundy
On Fri, Nov 18, 2005 at 05:42:41PM +0300, Bulat Ziganshin wrote:
>   can anyone write at least the list of record proposals for Haskell?
> or, even better, comment about pros and contras for each proposal?

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

I can list the issues that seem important to me, but I am sure my list
isn't complete.  Also note that some of these goals may be mutually
contradictory, but agreeing on the problems might help in agreeing on the
solutions.

A getter is a way to get a field out of a record, a setter is a way to
update a field in a record.  These may be either pattern-matching syntaxes,
functions or some other odd syntax.

Here's the quick summary, expanded below:

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

2. Multi-constructor getters.

1. Field namespace issue:

Field names should not need to be globally unique.  In Haskell 98, they
share the function namespace, and must be unique.  We either need to make
them *not* share the function namespace (which means no getters as
functions), or somehow stick the field labels into classes.

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

3. "Safe" getters for multi-constructor data types.

Getters ought to be either "safe" or explicitly unsafe when only certain
constructors of a data type have a given field (this is my pet peeve):

> data FooBar = Foo { foo :: String } | Bar { bar :: String }

This shouldn't automatically generate a function of type

> foo :: FooBar -> String

which will fail when given a FooBar of the Bar constructor.  We can always
write this function ourselves if we so desire.

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.

5. Setters as functions.

It would be nice to have a setter function such as (but with perhaps a
better name)

> set_foo :: String -> Foo -> Foo

be automatically derived from

> data Foo = Foo { foo :: String }

in the same way that in Haskell 98 "foo :: Foo -> String" is implicitely
derived.

Note that this opens up issues of safety when you've got multiple
constructors, and questions of how to handle setting of a field that isn't
in a particular datum.

6. Anonymous records.

This idea is from Simon PJ's proposal, which is that we could have
anonymous records which are basically tuples on steroids.  Strikes me as a
good idea, but requires that we address the namespace question, that is,
whether field labels share a namespace with functions.  In Simon's
proposal, they don't.

This is almost a proposal rather than an issue, but I think that it's a
worthwhile idea in its own right.

7. Unordered records.

I would like to have support for unordered records, which couldn't be
matched or constructed by field order, so I could (safely) reorder the
fields in a record.  This is really an orthogonal issue to pretty much
everything else.


Argh.  When I think about records too long I get dizzy.
--
David Roundy
http://www.darcs.net
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Wolfgang Jeltsch
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: records proposals list

Bulat Ziganshin
In reply to this post by David Roundy
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


--
Best regards,
 Bulat                            mailto:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Dimitry Golubovsky-2
In reply to this post by David Roundy
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/FieldAccess.hs

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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: records proposals list

Ben Franksen-2
In reply to this post by Bulat Ziganshin
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Wolfgang Jeltsch
In reply to this post by Bulat Ziganshin
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?

A point is not a special coordinate pair.  Instead it has a coordinate paar as
one of its properties.  So the above-mentioned problem would be better
handled this way:

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

> [...]

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: records proposals list

Bulat Ziganshin
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:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Wolfgang Jeltsch
Am Montag, 21. November 2005 08:31 schrieb Bulat Ziganshin:

> Hello Wolfgang,
>
> Sunday, November 20, 2005, 6:21:05 PM, you wrote:
> >> data Coord = { x,y :: Double }
> >> data Point : Coord = { c :: Color }
>
> > A point is not a special coordinate pair.  Instead it has a coordinate
> > paar as one of its properties.  So the above-mentioned problem would be
> > better handled this way:
> >
> >         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:
>
> [...]

You should never use bad design to increase usability, I'd say.

> [...]

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: records proposals list

Bulat Ziganshin
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:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

David Roundy
In reply to this post by Wolfgang Jeltsch
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Wolfgang Jeltsch
In reply to this post by Bulat Ziganshin
Am Montag, 21. November 2005 13:37 schrieb Bulat Ziganshin:
> [...]

> > You should never use bad design to increase usability, I'd say.
>
> to be exact now i have the following definitions:

> [...]

> i prefer to replace second definition with the
>
> [...]
>     data CompressedFile : FileInfo = CompressedFile {
>         cfArcBlock :: ArchiveBlock [...],
>         cfPos :: FileSize [...],
>         cfCRC :: 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

I would say, it's more natural because naturally we don't think as exactly as
we should when programming.  A general file info and an info about compressed
files are two different things, although related.  Allowing to silently use
an info about compressed files where a general file info is expected, hides
this difference and may, for example, result in the compiler not detecting
certain errors which it otherwise would detect.

Another problem is that your inheritance approach only solves a rather
restricted class of problems.  This is, in my opinion, a general problem with
object-orientation.  OO just seems to not being well thought-out to me.  It
seems that the inventors of OO just had a specific class of problems to solve
in mind and then invented a system which is rather specific.  On the other
hand, Haskell's type system, including several common extensions, is rather
general and therefore more flexible.

What, for example, if you have two specific kinds of file infos A and B and
also a kind of file info C which covers both A and B?  You need multiple
inheritance.  But if you would declare a type C which inherits from A and B,
you would also be allowed to add new fields.  But this is something you don't
want since you just want to create the union of A's and B's fields.

In addition, with multiple inheritance you always have the question of whether
you should inherit a common ancestor class of the superclasses more than once
or not.  If you do "inheritance by hand" by writing something along the lines
of

        data CompressedFileInfo = CompressedFileInfo {
                cfiFileInfo :: FileInfo,
                cfiArcBlock :: ArchiveBlock,
                cfiPos :: FileSize,
                cfiCRC :: CRC
        },

you already have all opportunities to decide how often you want to include a
certain common superclass.

I have to admit that I didn't work with OO for quite some time so my thinkings
about OO and similar things may be wrong.  But I could imagine that the whole
inheritance concept is flawed, and I don't want to see flawed things in
Haskell.  I always liked the fact that Haskell doesn't go the road of
object-oriented programming where, as it seems to me, you have sometimes
rather complicated rules which give you little flexibility.

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Wolfgang Jeltsch
In reply to this post by David Roundy
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.

> [...]

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Philippa Cowderoy
On Mon, 21 Nov 2005, David Roundy wrote:

> (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

I'm not sure it's all that bad if we can avoid namespace pollution?

--
[hidden email]

Performance anxiety leads to premature optimisation
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Keean Schupke
In reply to this post by Bulat Ziganshin
Hi,

    Haskell already has static records (in H98)

    Dynamic records are addressed by the HList library, which uses
extensions already present in GHC and Hugs (namely Multi-parameter
type-classes and function-dependancies).

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

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

    is a statically typed anonymous record.
   

    In other words there is no need for any more extensions to GHC or
Hugs to implement Records (although  having a type-level type-equality
constaint would simplify the internal implementation of the library)...

    For details see the HList paper: http://homepages.cwi.nl/~ralf/HList/

    Regards,  
    Keean.

Bulat Ziganshin wrote:

>Hello Haskell,
>
>  can anyone write at least the list of record proposals for Haskell?
>or, even better, comment about pros and contras for each proposal?
>
>  
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: records proposals list

Bulat Ziganshin
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


--
Best regards,
 Bulat                            mailto:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: records proposals list

Ralf Lammel-2
In reply to this post by Bulat Ziganshin
I certainly agree with Keean. It's just that the given example is a bit
misleading. As Bulat observed, the example is about a heterogeneous
list, as opposed to a record. But there are of course tons of record
examples to be found, if you follow the HList link.

Ralf

P.S.: The HList paper also has a reasonable related work section, which
might hold more information of the kind that Bulat asked for.


> -----Original Message-----
> From: [hidden email] [mailto:haskell-cafe-
> [hidden email]] On Behalf Of Keean Schupke
> Sent: Monday, November 21, 2005 7:56 AM
> To: Bulat Ziganshin
> Cc: Haskell Cafe
> Subject: Re: [Haskell-cafe] records proposals list
>
> Hi,
>
>     Haskell already has static records (in H98)
>
>     Dynamic records are addressed by the HList library, which uses
> extensions already present in GHC and Hugs (namely Multi-parameter
> type-classes and function-dependancies).
>
>     So you can do this now... with reasonable syntax, for example to
> create an extensible record
>
>     ("some thing" .*. (27 :: Int) .*. True .*. HNil)
>
>     is a statically typed anonymous record.
>
>
>     In other words there is no need for any more extensions to GHC or
> Hugs to implement Records (although  having a type-level type-equality
> constaint would simplify the internal implementation of the
library)...
>
>     For details see the HList paper:
http://homepages.cwi.nl/~ralf/HList/

>
>     Regards,
>     Keean.
>
> Bulat Ziganshin wrote:
>
> >Hello Haskell,
> >
> >  can anyone write at least the list of record proposals for Haskell?
> >or, even better, comment about pros and contras for each proposal?
> >
> >
> >
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Malcolm Wallace
In reply to this post by David Roundy
David Roundy <[hidden email]> writes:

> I'd benefit from just a list of problems that the record proposals want to
> solve.
>
> 1. The field namespace issue.
> 2. Multi-constructor getters, ideally as a function.
> 3. "Safe" getters for multi-constructor data types.
> 4. Getters for multiple data types with a common field.
> 5. Setters as functions.
> 6. Anonymous records.
> 7. Unordered records.

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.

With this one generalisation, it would be possible to cover most of
the wishlist above.  A generic getter and setter could be defined
simply as polymorphic functions e.g.

    get :: Label n -> Record (n::a | r) -> a
    set :: Label n -> a -> Record r -> Record (n::a | r)
    upd :: Label n -> (a->a) -> Record (n::a | r) -> Record (n::a | r)

You could even define your own preferred syntactic sugar for these
operations e.g.

    r . l = get l r

.. and the higher-order uses fall out for free

    map (get foo) listOfRecords

There are several proposals incorporating this idea.

    Oleg Kiselyov and Ralf Lämmel, "Haskell's overlooked object system"
        http://homepages.cwi.nl/~ralf/OOHaskell/

    Daan Leijen, "First-class labels for extensible rows"
        http://www.cs.uu.nl/~daan/pubs.html

    Benedict Gaster and Mark Jones, "A Polymorphic Type System for
    Extensible Records and Variants"
        http://www.cse.ogi.edu/~mpj/pubs/polyrec.html

Regards,
    Malcolm
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: records proposals list

Andy Georges
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.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12