Hello, I may be wrong but can't we keep old records and add new ones (as proposed in the First Class Modules paper) with a different syntax? Ussual records and extensible records are both usefull, in different cases. Best regards, Nicolas Oury Le mardi, 9 sep 2003, à 14:52 Europe/Paris, Johannes Waldmann a écrit :

On Tue, 9 Sep 2003, Adrian Hey wrote:

...

I rarely use named fields in my Haskell progs with Haskell as it is ...

but you sure agree records are useful for collecting heterogenous data? for example, see data DynFlags here:

http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/ CmdLineOpts.lhs

...

IMHO preserving the status quo wrt records should be low priority. It really doesn't bother me much if new (useful) language features break existing code.

but this might be an issue for others, who have to maintain "legacy" code.

best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/209 --

.. .. Viertes Leipziger Jongliertreffen, 17. - 19. Oktober 2003 .. .. .. .. http://www.informatik.uni-leipzig.de/~joe/juggling/vier/ .. ..

_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

G'day all. On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote:

but this might be an issue for others, who have to maintain "legacy" code.

You know a language has made it when we're talking about "legacy" code. On the other hand, you have to worry about a pure declarative language where support for anything "legacy" is a priority. Just a little bit. Cheers, Andrew Bromage

hello, i think records are very useful, and we don't use them much in haskell, becuase the current record system is not very good. Adrian Hey wrote:

IMHO preserving the status quo wrt records should be low priority. It really doesn't bother me much if new (useful) language features break existing code. I think this is a better option than permanently impoverishing the language and/or forcing users to migrate their entire code to some other less impoverished language which may appear in the future. i also think that having backwards compatability is not much of an issue. after all, ghc has introduces a number of not backward compatable changes to haskell, and i never heard any complaints. i am referring to the hirarchical modules, and more recently template haskell, which has introduced a number of syntactic differences, and we had to actually go through our code and fix it to work with ghc 6.

What I don't particularly want to see is some "half baked" record system, the usefulness of which has been compromised by the need to retain backwards compatibility. I quite liked what I saw of the "First Class Modules" paper. Is there some reason why we can't have (shouldn't have?) that. (Apart from the additional workload it places on Haskell implementors :-) there has been a lot of work on record systems, so there really is no excuse for having a half-baked recrod system. the trex implementation in hugs tried to retain backward compatability with haskell, which resulted in a rather ugly syntax (this of course is just my opinion :-)

my preference would be to have something simillar to trex but with a nicer syntax, i.e. extensible records that do not need to be declared. incidently i gathered that people wanted reocrds that support record concatenation, does anyone have any examples of what that might be used for? bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

Iavor Diatchki <diatchki@cse.ogi.edu> writes:

Adrian Hey wrote:

...

IMHO preserving the status quo wrt records should be low priority. It really doesn't bother me much if new (useful) language features break existing code. I think this is a better option than permanently impoverishing the language and/or forcing users to migrate their entire code to some other less impoverished language which may appear in the future.

I also think that having backwards compatability is not much of an issue. After all, ghc has introduces a number of not backward compatable changes to haskell, and I never heard any complaints.

Oh no? Implicit parameters: I'm sure it is a great thing, but I'd already used the (?) operator, and need -fglasgow-exts. Now my program depends on a bunch of well places spaces to compile. Template Haskell: really cool new feature, which just happens to use a syntax that overlaps with the list comprehension syntax. And now, let's just screw any backwards compatibility, and re-engineer the records system¹. I don't need any of this, and it makes my life harder. Are you guys going to keep at it, until I regret ever using Haskell? There was recently a thread about using Haskell for something else than Haskell compilers; well, if you actually want people to do this, then you can't constantly keep changing the language. -kzm PS: For the record, I think the compiler developers are in general doing a great job of augmenting the language *without sacrificing backwards compatibility*. But compatibility is important. Branch GHC and develop a new language instead! -- If I haven't seen further, it is by standing in the footprints of giants

Johannes Waldmann <joe@informatik.uni-leipzig.de> writes:

What about "ad-hoc overloading" (allowing visible entities to share names, as long as they can be distinugished by their typing).

This is orthogonal to the "proper records" issue (?) but it might improve the current situtation (?) and it seems backward-compatible (?)

Yes. Don't get me wrong; please go and define "proper records", improve the record system accordingly, adapt and implement. I just wanted to correct the impression that there were no complaints about broken backwards compatibility. Because it is - or at least, it can be - a real problem. Sometimes it has to be done in order to set things right, but it shouldn't be done lightly. There is also the issue of weighing down the language with features and extensions. It may give you more expressive power, but it also makes the language harder to master, and programs more difficult to maintain.

Of course this would need an extension of the type checker

Doesn't worry me overly, it is Somebody Else's Problem :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Hi!

...

So in summary, here is my proposal:

No specific "extensible records" system.

Define record update to be a function just like record selection is.

Allow these functions to be in type classes.

I do not understand the second and third point: As I understand your idea, record selectors and updaters should still be defined by the datatype declaration. What does it then mean that they be "allowed" to be defined in type classes? Would that happen automatically?

I was thinking of something along the following lines: class Wibble a where wibble :: a -> Int wobble :: a -> String set_wibble :: Int -> a -> a set_wobble :: String -> a -> a data Foo = Foo {wibble :: Int, wobble :: String} deriving Wibble The Wibble class defines selector and updater functions for fields called wibble and wobble. When I define the datatype Foo, I give it fields called wibble and wobble, which will define the functions in Wibble. If I say "deriving Wibble" then the type system acknowledges that these functions are implementing the class Wibble. If I had not derived Wibble then there would have been a name clash. We could imagine the definition of Foo being automatically desugared to the following: data Foo = Foo Int String instance Wibble Foo where wibble (x,_) = x wobbble (_,y) = y set_wibble x (_,y) = (x,y) set_wobble y (x,_) = (x,y) Note that Wibble is a normal class. I could thus implement Wibble in a class that was not a record. For example, the following, rather dull, implementation: instance Wibble () where wibble () = 3 wobble () = "hello" set_wibble _ _ = () set_wobble _ _ = () Does that make things clearer? -Rob

Yes, things are clearer and I rather like the idea. The only thorny issue is that the update function for field 'wibble' is formed from but not equal to the field name itself.

In short, the magic thing would be in the 'deriving' clause:

If the data type declares fields with names x_1, ..., x_n and the class mentioned declares operators y_1, ..., y_k and set_y_1, ..., set_y_k where {y_1, ..., y_k} is a subset of {x_1, ..., x_k}, of the appropriate types, then the corresponding instance declarations are generated.

Yep. It would also be possible for a class to declare only the selector or only the updater for a field. E.g.: class FooGet a where foo :: a -> Int class FooSet a where set_foo :: Int -> a -> a data Bar = Bar {foo :: Int} deriving (FooGet, FooSet) -Rob

Karl-Filip Faxen wrote:

| Yes, things are clearer and I rather like the idea. | The only thorny issue is that the update function for | field 'wibble' is formed from but not equal to the | field name itself.

This could be solved by having an abstract type Field thusly (*):

[snip] All very cute :-)) The downside is of course that it would no longer be a compatible extension to the existing Haskell language. Current Haskell programs consider the field name to be a function from types to field values. If we are to retain compatibility then we need to preserve this. Still very cute though :-) [snip] -Rob

On Wed, 10 Sep 2003 10:26:04 +0100, Robert Ennals <Robert.Ennals@cl.cam.ac.uk> wrote:

...

class Wibble a where wibble :: a -> Int wobble :: a -> String set_wibble :: Int -> a -> a set_wobble :: String -> a -> a

data Foo = Foo {wibble :: Int, wobble :: String} deriving Wibble

The Wibble class defines selector and updater functions for fields called wibble and wobble.

When I define the datatype Foo, I give it fields called wibble and wobble, which will define the functions in Wibble. If I say "deriving Wibble" then the type system acknowledges that these functions are implementing the class Wibble. If I had not derived Wibble then there would have been a name clash.

What would you do if Wibble had more functions than just those 4? You'd need somewhere to put the implementations of the other functions for Foo.

I guess there are three options. A: Don't allow records to be instances of such classes. B: Add extra syntax to allow this. E.g something like this: data Foo = Foo {wibble :: Int} deriving Wibble where wobble x = "hello" set_wobble w x = x C: Declare instances using normal instance declarations: e.g. data Foo = Foo {wibble :: Int} instance Wibble Foo where wobble = x "hello" set_wobble w x = x -- wibble and set_wibble done automatically. This has the weakness that the compiler has to see the instance declaration when compiling the type declaration for Foo in order to know that the names are not clashing. It is however possibly the best option. -Rob

On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:

Shouldn't that rather be:

class HasWibble a where wibble :: a -> Int set_wibble :: a -> Int -> a

class HasWobble a where ...

Or even: class HasWibble a b | a -> b where wibble :: a -> b set_wibble :: a -> b -> a class HasWobble a b | a -> b where ... Best regards, Tom -- .signature: Too many levels of symbolic links

ketil@ii.uib.no (Ketil Z. Malde) writes:

Robert Ennals <Robert.Ennals@cl.cam.ac.uk> writes:

BTW, isn't this more or less exactly what Simon suggested (at the very top of this thread)? -kzm -- If I haven't seen further, it is by standing in the footprints of giants