Records (was Re: [Haskell] Improvements to GHC)
Hi folks, rather than discussing about which operator symbol to use for record access, which is really a question of personal taste we should try to seriously discuss the proposals and get to a solutions! We all seem to agree that records are broken in Haskell. In order to fix that we need a new and most probably incompatible solution. However, I think the new solution should go in a new version of the Haskell standard (among other things :-) ). I would strongly disadvice to try to stick with the old system and improve it. Just because there are lots of different opinions we should still try to find a reasonable solution soon. Desite the minor problem of '.' that dominated the discussion so far, what are the REAL offences against Simons proposal [1] (denoted as SR in the following)? To me it sounds like a very reasonable starting point. Which other proposals exist? I quote David Roundy's list of problems [2] with a short annotation whether SR solves them: 1. The field namespace issue. solved by not sharing the same namespace with functions 2. Multi-constructor getters, ideally as a function. not solved. only possible by hand - As stated by Wolfgang Jeltsch [3] another datatype design might be better - I can image a solution is within SR example:
data Decl = DeclType { name :: String, ... } | DeclData { name :: String, ... } | ... d :: Decl in addition to d.DeclType.name d.DeclData.name we provide (only if save, see 3.) d.name
3. "Safe" getters for multi-constructor data types. not supported as it is - with the above suggestion it could be possible (don't know if desireable) 4. Getters for multiple data types with a common field. - solved with contrains > getx :: (r <: { x :: a }) => r -> a 5. Setters as functions. doesn't seem to be supported, or I don't see it right now. 6. Anonymous records. Supported 7. Unordered records. I don' t understand it. points added from me: 8. Subtyping Supported, quite nicely 9. higher order versions for selecting, updateing ... [4] not supported seems important to me, any solutions? Regards Georg [1] http://research.microsoft.com/~simonpj/Haskell/records.html [2] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012226.html [3] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012227.html [4] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012162.html Am Donnerstag, 17. November 2005 19:08 schrieb Dimitry Golubovsky:
Sebastian Sylvan wrote:
Personally I think that the dot is way to good of a symbol to be "wasted" on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I
I found it useful to use (mainly for debugging purposes)
mapM (putStrLn . show) <some list>
if I want to print its elements each on a new line.
-- Dimitry Golubovsky
Anywhere on the Web
-- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------
On Sun, Nov 20, 2005 at 01:40:01PM +0100, Georg Martius wrote:
7. Unordered records. I don' t understand it.
It's just that I'd like to be able to write: data FooBar = FooBar { foo, bar :: String } such that you can't write let f = FooBar "a" "b" but instead are forced to write let f = FooBar { foo = "a", bar = "b" } More importantly when you pattern match, you couldn't write case f of FooBar _ b -> b but instead would have to write case f of FooBar { bar = b } -> b The reason being that I'd like to be able to export constructors from a module in such a way that I can later reorder or add or remove field from that record without breaking any pattern-matching code, and if I'm only reordering the fields, I shouldn't break any constructor code either. As an aside, what's responsible for the insanity of pattern matching record fields being backwards? I'd bar = b to bind b to bar, not the other way around... why should record pattern matching use '=' in a manner opposite from the rest of Haskell? -- David Roundy http://www.darcs.net
On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
As an aside, what's responsible for the insanity of pattern matching record fields being backwards? I'd bar = b to bind b to bar, not the other way around... why should record pattern matching use '=' in a manner opposite from the rest of Haskell?
It just mimics the way (record) values are constructed, as in all pattern matching in Haskell. You can put a pattern variable everywhere you could put a value in a corresponding constructing expression. For example, all these "terms" can be used both as an expression and a pattern. In the first case x, y, z are expressions, in the second they are patterns. [x,y,z] (x:y:z) (x,(y,z)) (C x y, D z) R { field1 = x, field2 = y, field3 = z } I think this is very consistent. Best regards Tomasz
On Sun, Nov 20, 2005 at 03:43:08PM +0100, Tomasz Zielonka wrote:
On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
As an aside, what's responsible for the insanity of pattern matching record fields being backwards? I'd bar = b to bind b to bar, not the other way around... why should record pattern matching use '=' in a manner opposite from the rest of Haskell?
It just mimics the way (record) values are constructed, as in all pattern matching in Haskell. You can put a pattern variable everywhere you could put a value in a corresponding constructing expression. For example, all these "terms" can be used both as an expression and a pattern. In the first case x, y, z are expressions, in the second they are patterns.
[x,y,z] [...] R { field1 = x, field2 = y, field3 = z }
I think this is very consistent.
I see, you're right that it's consistent, but I still don't like the use of '=' in this scenario. I don't really have a better idea, but something like R { field1 -:- x, field2 -:- y, field3 -:- z } (where I don't like the -:- but can't think of anything better off the top of my head) might be more intuitive, since '=' means bind the value on the right to the name on the left everywhere else in haskell, but in record syntax it's part of a constructor. It'd be nice to reuse an existing haskell syntax ("->" ?), but I can't think of one that would fit. One could perhaps use :=, which at least looks like a constructor rather than a binding... -- David Roundy http://www.darcs.net
On Sun, Nov 20, 2005 at 02:09:04PM -0500, David Roundy wrote:
[x,y,z]
[...]
R { field1 = x, field2 = y, field3 = z }
I think this is very consistent.
I see, you're right that it's consistent, but I still don't like the use of '=' in this scenario.
I understand you. I had the same feelings some time ago, I even have them today to some degree. At least consistency helps to get used to it. Best regards Tomasz
On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
As an aside, what's responsible for the insanity of pattern matching record fields being backwards? I'd bar = b to bind b to bar, not the other way around... why should record pattern matching use '=' in a manner opposite from the rest of Haskell?
Perhaps it's better to think of '=' as asserting equality, than as binding? Andrew
Am Sonntag, 20. November 2005 13:40 schrieb Georg Martius:
[...]
4. Getters for multiple data types with a common field.
Do we need this? Couldn't this have ugly consequences? Say, I have a datatype with a field of a certain name and another datatype with a field of the same name. Having a single getter for both fields might be bad if the fields mean different things. For example, a "name" and a "name" can be quite different things.
[...]
Best wishes, Wolfgang
2005/11/20, Georg Martius <mai99dgf@studserv.uni-leipzig.de>:
7. Unordered records. I don' t understand it.
Consider this example: data DataT = DataT (Int,String) (String,String) if we treat records as tuples with labels, then we could write: data DataR = DataR {tel::Int,addr::String} {zip::String,state::String} so we could have more records per sum-type case. It is also good because constructor arity stays the same, in this case both DataT and DataR have arity 2. What do you think? -- Gracjan
On records in Haskell - can we start by formulating requirements (design goals). What do we want from a record system, and what are non-goals. Some of the proposals here sound like records should be more like objects (with some kind of inheritance). Do we really want this? We already have inheritance (for interfaces). Isn't that enough? My main objection is that concrete data types (e. g. records) should not be exposed by a module anyway, and should definitely not be a base for derivations (Compare the OO design pattern literature). Still if they are exposed (or while we're inside a module), what makes the current records quite impractical is the namespace issue (for component names). Sure, one thing would be to invent some ad-hoc solution (automatic qualification by type name or something) but another possibility is to allow ad-hoc polymorphisms generally in the language. Just my 2 cent (and none of them new, I'm afraid) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Hi guys, Since discussion has returned to records, it might be useful for me to post a link to a proposal that I knocked up a while back when this topic came up a few years ago: http://www.cambridge.intel-research.net/~rennals/records.pdf The basic idea is to keep records largely as they are, but add two extensions: - field getter functions are placed in type classes - fields desugar to setter functions as well as getters Useful features of this approach are: - backward compatibility with existing code - the existing type-class mechanism is used for shared field names - setters can be redefined if a type is changed, just as getters can now To go through Dave's issues: 1. Field namespaces: solved by using type classes 2. Multi-constructor getters: solved by desugaring to functions 3. "Safe" getters for multi-constructor data types: ditto 4. Getters for multiple data types with a common field: solved by type-classes (no special "constains" feature required) 5. Setters as functions: yep 6. Anonymous records: not supported 7. Unordered records: yep (if I understand the problem correctly) And Georg's points: 8. Subtyping: yep -using type classes 9. higher order versions for selecting, updateing ... : not sure what is meant here Of course, my proposal might very well not do what you want, but I thought it was worth posting it again. Hope people find this useful. -Rob On 11/22/05, Johannes Waldmann <waldmann@imn.htwk-leipzig.de> wrote:
On records in Haskell - can we start by formulating requirements (design goals). What do we want from a record system, and what are non-goals.
Some of the proposals here sound like records should be more like objects (with some kind of inheritance). Do we really want this? We already have inheritance (for interfaces). Isn't that enough?
My main objection is that concrete data types (e. g. records) should not be exposed by a module anyway, and should definitely not be a base for derivations (Compare the OO design pattern literature).
Still if they are exposed (or while we're inside a module), what makes the current records quite impractical is the namespace issue (for component names).
Sure, one thing would be to invent some ad-hoc solution (automatic qualification by type name or something) but another possibility is to allow ad-hoc polymorphisms generally in the language.
Just my 2 cent (and none of them new, I'm afraid) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Tue, Nov 22, 2005 at 02:32:47PM +0000, Rob Ennals wrote:
Since discussion has returned to records, it might be useful for me to post a link to a proposal that I knocked up a while back when this topic came up a few years ago:
http://www.cambridge.intel-research.net/~rennals/records.pdf
Looks pretty nice.
To go through Dave's issues:
1. Field namespaces: solved by using type classes
But these classes are required to be manually specified, right? This avoids the problem of proliferation of typeclasses if one had one class per field, but does mean that coordination is necesary in order to avoid namespace clashes. As far as I can tell, this means that we'd have issues with data StupidDouble = StupidDouble { value :: Double } data StupidInt = StupidInt { value :: Int } unless we use multiparameter typeclasses or something. This is a stupid example (thus the type names), but I think there are real cases where you'd like to create constructors like this.
2. Multi-constructor getters: solved by desugaring to functions 3. "Safe" getters for multi-constructor data types: ditto
I think either you misunderstood my meaning by "safe", or I misunderstood your paper. I meant that if I write data FooBar = Foo { foo :: String } | Bar { bar :: String } there shouldn't be accessors of type foo :: FooBar -> String bar :: FooBar -> String which die when given bad input (e.g. calling (foo $ Bar "bar")). I'd rather in this case either not have these functions generated (and require that I use pattern matching) or have them have type foo :: FooBar -> Maybe String bar :: FooBar -> Maybe String I just don't like bottom. Perhaps it wouldn't be so bad if we got decent error messages, but when you call (foo $ Bar "bar") you get no hint as to where the bug actually is.
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly. What I'd like (and this is another one of those David-specific issues--I've never heard anyone else complain about this) is to be able to create a data type that has no order. If I write data FooBar = FooBar { foo, bar :: String } I can construct this (either with Haskell 98 or with your proposal, as I understand it) with either fb = FooBar { foo = "a", bar = "b" } or with fb = FooBar "a" "b" I'd prefer to at least optionally be able to make the second syntax fail to compile--which is what I mean by an unordered record. The same goes for pattern matching. This feature is orthogonal to almost all the other record issues, and really a compiler warning would probably be enough to satisfy me, although I'd prefer to have this in the language. The point (in case I've been unclear again) is that I'd like to be able to later change the definition to data FooBar = FooBar { foo, bar :: String } without the possibility of breaking the code. This is a silly example, and noone would actually make this change, simply because it would be too hard to go through the code and verify that all the patterns have been swapped (and didn't get swapped twice). It's something that one could implement with code policy, but on the other hand, you could in principle say the same thing about static typing. -- David Roundy http://www.darcs.net
David Roundy <droundy@abridgegame.org> writes:
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly. What I'd like (and this is another one of those David-specific issues--I've never heard anyone else complain about this) is to be able to create a data type that has no order.
FWIW, there are certainly other people out there who think the same way. In the Blobs diagram editor for instance, there are lots of instances of exported datatypes with exported field accessors/updaters, but the constructors are not exported. e.g. module M (FooBar(), emptyFooBar, getFoo, getBar, setFoo, setBar) where data FooBar = FooBar { foo :: String, bar :: Bool } emptyFooBar = FooBar {} getFoo = foo getBar = bar setFoo f fb = fb {foo=f} setBar b fb = fb {bar=b} This gives you three-quarters of your desire, i.e. unordered construction is possible, positional construction is not, and positional de-construction (pattern-matching) is also unavailable. The only thing lacking is the ability to do unordered pattern-matching, which is impossible here because the accessors are pure functions, not true field names. Just as for you, the intent of the design pattern here is total data encapsulation - to be able to change the internals of the FooBar type without any of the importing modules needing to change as a result. Regards, Malcolm
Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
On Tue, Nov 22, 2005 at 02:32:47PM +0000, Rob Ennals wrote: [...]
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly. What I'd like (and this is another one of those David-specific issues--I've never heard anyone else complain about this) is to be able to create a data type that has no order. If I write
data FooBar = FooBar { foo, bar :: String }
I can construct this (either with Haskell 98 or with your proposal, as I understand it) with either
fb = FooBar { foo = "a", bar = "b" }
or with
fb = FooBar "a" "b"
I'd prefer to at least optionally be able to make the second syntax fail to compile--which is what I mean by an unordered record. The same goes for pattern matching.
You can just omit the data constructors from the module's export list.
[...]
Best wishes, Wolfgang
On Wed, Nov 23, 2005 at 02:58:43PM +0100, Wolfgang Jeltsch wrote:
Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
On Tue, Nov 22, 2005 at 02:32:47PM +0000, Rob Ennals wrote: [...]
7. Unordered records: yep (if I understand the problem correctly) ... You can just omit the data constructors from the module's export list.
Yes, you can do that if you don't want to allow pattern matching. That's an acceptable solution for truly "exported" (i.e. opaque) data, but for internal data structures I would like to allow pattern matching without allowing positional matching (or constructing). Too many times I've had to go through the entire code adding an extra "_" to each pattern match, and each time there's a possibility you'll add it in the wrong spot. I could do this with coding guidelines, but I'd prefer to have the compiler enforce this. -- David Roundy http://www.darcs.net
you can always do: case (field1 record,field2 record, field3 record ...) of (pat1,pat2,pat3) -> _ -> Which lets you pattern match on fields independantly of their position in the record. Keean. David Roundy wrote:
On Wed, Nov 23, 2005 at 02:58:43PM +0100, Wolfgang Jeltsch wrote:
Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
On Tue, Nov 22, 2005 at 02:32:47PM +0000, Rob Ennals wrote: [...]
7. Unordered records: yep (if I understand the problem correctly)
...
You can just omit the data constructors from the module's export list.
Yes, you can do that if you don't want to allow pattern matching. That's an acceptable solution for truly "exported" (i.e. opaque) data, but for internal data structures I would like to allow pattern matching without allowing positional matching (or constructing). Too many times I've had to go through the entire code adding an extra "_" to each pattern match, and each time there's a possibility you'll add it in the wrong spot. I could do this with coding guidelines, but I'd prefer to have the compiler enforce this.
Hello David, Wednesday, November 23, 2005, 4:22:47 PM, you wrote:
7. Unordered records: yep (if I understand the problem correctly)
DR> I don't think you understood correctly. What I'd like (and this is another DR> one of those David-specific issues--I've never heard anyone else complain DR> about this) is to be able to create a data type that has no order. i think that this is very good thing, especially for library writers. it's just a Good Programming Style, not for bad guys like me ;) -- Best regards, Bulat mailto:bulatz@HotPOP.com
On 11/23/05, David Roundy <droundy@abridgegame.org> wrote:
On Tue, Nov 22, 2005 at 02:32:47PM +0000, Rob Ennals wrote:
[snip]
1. Field namespaces: solved by using type classes
But these classes are required to be manually specified, right? This avoids the problem of proliferation of typeclasses if one had one class per field, but does mean that coordination is necesary in order to avoid namespace clashes.
As far as I can tell, this means that we'd have issues with
data StupidDouble = StupidDouble { value :: Double } data StupidInt = StupidInt { value :: Int }
unless we use multiparameter typeclasses or something.
You are indeed right. My thinking was that fields should be thought of in much the same way as functions. If two same-named fields are supposed to be used the same way, then one should declare a type class, and if they are supposed to be distinct, then one should use module namespaces. As regards multiparameter typeclasses - I think that they should work quite well with this proposal. e.g. class HasVal a b where value :: a -> b instance HasVal StupidDouble Double instance HasVal StupidDouble Int [snip]
3. "Safe" getters for multi-constructor data types: ditto
I think either you misunderstood my meaning by "safe", or I misunderstood your paper. I meant that if I write
data FooBar = Foo { foo :: String } | Bar { bar :: String }
there shouldn't be accessors of type
foo :: FooBar -> String bar :: FooBar -> String
I did indeed misunderstand what you meant by "safe". Bottom is indeed a nasty thing. Perhaps such definitions should generate a warning? (banning them outright would cause compatability issues)
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly.
I was thinking along the same lines as Wolfgang : don't export the internal representation of the type, but do expose the field manipulator functions. This needn't prevent the use of pattern matching, provided the desugaring of patterns is consistent with the rest of the system. E.g. I was assuming that case e of { x = 3, y = 4} -> ... would desugar to case e of _ | x z = 3 && y z = 4 -> ... Note that this pattern matching syntax will continue to work, even if 'x' and 'y' are reimplemented as normal functions, rather than fields. Hope this all makes sense. -Rob
On Sun, Nov 27, 2005 at 08:47:54PM +0000, Rob Ennals wrote:
On 11/23/05, David Roundy <droundy@abridgegame.org> wrote:
3. "Safe" getters for multi-constructor data types: ditto
I think either you misunderstood my meaning by "safe", or I misunderstood your paper. I meant that if I write
data FooBar = Foo { foo :: String } | Bar { bar :: String }
there shouldn't be accessors of type
foo :: FooBar -> String bar :: FooBar -> String
I did indeed misunderstand what you meant by "safe". Bottom is indeed a nasty thing.
Perhaps such definitions should generate a warning? (banning them outright would cause compatability issues)
Yeah, issuing a warning (which can become an error with -Werr) is a nice option. The other option would be some sort of syntax to declare that a particular record is unordered. Or I suppose to just give up on backward compatibility. Any of these three alternatives would be fine with me.
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly.
I was thinking along the same lines as Wolfgang : don't export the internal representation of the type, but do expose the field manipulator functions.
This needn't prevent the use of pattern matching, provided the desugaring of patterns is consistent with the rest of the system.
E.g. I was assuming that
case e of { x = 3, y = 4} -> ...
would desugar to
case e of _ | x z = 3 && y z = 4 -> ...
Note that this pattern matching syntax will continue to work, even if 'x' and 'y' are reimplemented as normal functions, rather than fields.
Indeed, it hadn't occurred to me to make pattern matching work this way. It actually sounds a lot like pattern guards, since you're suggesting this sugar could be applied to any sort of object? So your desugarer would allow a function like islong :: [a] -> Bool islong {length = l} = l > 10 -- David Roundy http://www.darcs.net
It actually sounds a lot like pattern guards, since you're suggesting this sugar could be applied to any sort of object? So your desugarer would allow a function like
islong :: [a] -> Bool islong {length = l} = l > 10
this looks like a hack that only works for one-argument functions, and its only purpose seems to hide the argument. I don't like the (local) looks of "length = 1" anyway. Compare to "length [] = 0". You'd think the first one is a typing error until you spot the surrounding "{ .. }" While we're at it, I'd like to mention a feature that I'd love to have in a record system (for a long time): defaults, resp. initializer functions. E. g. data Foo = Foo { foo :: Int, bar :: Int ; bar x = 2 * foo x } Something like that (imagine that (*) is some expensive computation). Note that default declarations in classes are vaguely similar. Again, the concrete syntax problem is whether to hide the argument. Perhaps data Foo = Foo { foo :: Int, bar :: Int ; bar = 2 * foo self } with a reserved word "self" is better. - Are there semantic problems? It might even be desirable to hide the "computed" component, i. e. Foo { foo = 5, bar = 7 } could be forbidden. And still better: if we could say later (i. e. outside the definition of Foo) that the values of bar should be "memorized" in the Foo records. Of course this might be hard for separate compilation (if type definition and memorized functions are in different modules. Again, this is vaguely similar to orphan instances.) Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Johannes Waldmann <waldmann@imn.htwk-leipzig.de> writes:
Again, the concrete syntax problem is whether to hide the argument. Perhaps data Foo = Foo { foo :: Int, bar :: Int ; bar = 2 * foo self } with a reserved word "self" is better. - Are there semantic problems?
Can't you solve this by writing a fiunction to construct Foo with the desired properties? I.e. something like mkStdFoo f = Foo f (2*f) Or is there other functionality you would get by using records in this way? -k -- If I haven't seen further, it is by standing in the footprints of giants
Ketil Malde wrote:
Perhaps data Foo = Foo { foo :: Int, bar :: Int ; bar = 2 * foo self } with a reserved word "self" is better. - Are there semantic problems?
Can't you solve this by writing a fiunction to construct Foo with the desired properties?
Sure but by the same argument I wouldn't need records at all because I could use tuples :-) I'd say it makes the intention of the programmer more explicit, and this is what pragmatics of programming languages is all about, isn't it ... Also, for updates ( like x { foo = 3 } ) I'd expect that a new record is built and the initializer is called again - this would be inconvenient to write with functions because of the unwrapping and wrapping (you would need to name all components even if they don't change so you don't want to mention them). I think it would be even more convenient if it were possible to have initializers in separate modules (a la orphan instances) because often I have one module that just defines the data type, and then several modules that define operations. I would need to know all the default-initialized fields already when writing the type definition, which is wrong design (it forces me to make decisions too early and write them down in the wrong place). I realize that my above idea looks something like introducing objects through the back door. Because one might say that I want something like a "Foo" with an additional component (bar) that is ignored by those who don't know them. This is indeed a severe criticism - normally I tend to avoid implementation inheritance and now it looks like I'm advocating it... best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
correct me if I am wrong but ... 1. Field namespaces: solved by using type classes This would imply that the type of the field is the same between all instances of this common field. Under this proposal two fields with same label and different type would not be possible eg { name :: String }, { name :: Int } John ----- Original Message ----- From: "Rob Ennals" <rob.ennals@gmail.com> To: "Johannes Waldmann" <waldmann@imn.htwk-leipzig.de> Cc: <haskell@haskell.org> Sent: Wednesday, November 23, 2005 1:32 AM Subject: Re: Records (was Re: [Haskell] Improvements to GHC) Hi guys, Since discussion has returned to records, it might be useful for me to post a link to a proposal that I knocked up a while back when this topic came up a few years ago: http://www.cambridge.intel-research.net/~rennals/records.pdf The basic idea is to keep records largely as they are, but add two extensions: - field getter functions are placed in type classes - fields desugar to setter functions as well as getters Useful features of this approach are: - backward compatibility with existing code - the existing type-class mechanism is used for shared field names - setters can be redefined if a type is changed, just as getters can now To go through Dave's issues: 1. Field namespaces: solved by using type classes 2. Multi-constructor getters: solved by desugaring to functions 3. "Safe" getters for multi-constructor data types: ditto 4. Getters for multiple data types with a common field: solved by type-classes (no special "constains" feature required) 5. Setters as functions: yep 6. Anonymous records: not supported 7. Unordered records: yep (if I understand the problem correctly) And Georg's points: 8. Subtyping: yep -using type classes 9. higher order versions for selecting, updateing ... : not sure what is meant here Of course, my proposal might very well not do what you want, but I thought it was worth posting it again. Hope people find this useful. -Rob On 11/22/05, Johannes Waldmann <waldmann@imn.htwk-leipzig.de> wrote:
On records in Haskell - can we start by formulating requirements (design goals). What do we want from a record system, and what are non-goals.
Some of the proposals here sound like records should be more like objects (with some kind of inheritance). Do we really want this? We already have inheritance (for interfaces). Isn't that enough?
My main objection is that concrete data types (e. g. records) should not be exposed by a module anyway, and should definitely not be a base for derivations (Compare the OO design pattern literature).
Still if they are exposed (or while we're inside a module), what makes the current records quite impractical is the namespace issue (for component names).
Sure, one thing would be to invent some ad-hoc solution (automatic qualification by type name or something) but another possibility is to allow ad-hoc polymorphisms generally in the language.
Just my 2 cent (and none of them new, I'm afraid) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Am Sonntag, 27. November 2005 22:34 schrieb John Lask:
correct me if I am wrong but ...
1. Field namespaces: solved by using type classes
This would imply that the type of the field is the same between all instances of this common field.
Under this proposal two fields with same label and different type would not be possible eg { name :: String }, { name :: Int }
As I already said, this approach may lead to mixing different concepts. Example: data Person = Person { name :: String } data File = File { name :: String } A field identifier has to be seen in context of the datatype it belongs to. When used in conjunction with Person, name means a person's name while it means a filename (a notably different thing) when used in conjunction with File. With the typeclass approach, we would have a single function called "name" which deals with different things. Important details would just be camouflaged. This is not good. In fact, it is really bad in my opinion. Maybe it would really be better to have functions like Person.name and File.name?
John
Best wishes, Wolfgang
On 11/28/05, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
As I already said, this approach may lead to mixing different concepts. Example:
data Person = Person { name :: String } data File = File { name :: String }
A field identifier has to be seen in context of the datatype it belongs to. When used in conjunction with Person, name means a person's name while it means a filename (a notably different thing) when used in conjunction with File. With the typeclass approach, we would have a single function called "name" which deals with different things. Important details would just be camouflaged. This is not good. In fact, it is really bad in my opinion.
Hi Wolfgang, I think you are right in that two similarly named fields should not be automatically considered to be equivilent. Indeed that is why the typeclass approach I proposed requires that one explicitly declare any typeclasses, and explicitly declare when two similarly named fields are part of the same typeclass -- one thus cannot have two fields been considered equivalent without the programmer making a conscious descision that this is correct behaviour.
Maybe it would really be better to have functions like Person.name and File.name?
In the case you give, I think you are right. In this case, using namespaces to distinguish fields is preferable to treating the same. However I think there are also other cases in which it *is* desirable to allow several datatypes to have the same field -- with the programmer making a contious descision to do things this way. [snip] -Rob
participants (13)
-
Andrew Pimlott -
Bulat Ziganshin -
David Roundy -
Georg Martius -
Gracjan Polak -
Johannes Waldmann -
John Lask -
Keean Schupke -
Ketil Malde -
Malcolm Wallace -
Rob Ennals -
Tomasz Zielonka -
Wolfgang Jeltsch