On 06/03/06, John Meacham
I have similar concerns. All of the record proposals I have seen don't really seem to subsume the current haskell record system, the task is different, anonymous records feel like they fill a similar niche to anonymous tuples, and just like we don't declare everything as
newtype Foo = Foo (Int,Char,Either Bar Baz)
it would seem odd that the only way to get named fields is to do the same thing but with records.
not to say that the record proposals won't be useful in their own right, but I wouldn't want too see them necessarily replace labeled fields.
it would also be unfortunate if the choice to use the (often cleaner) labeled fields implied a run-time and change in representation, one shouldn't have to make decisions like that.
It feels to me that anonymous records should look more like the other anonymous(ish) type haskell provides, tuples. so the following syntax feels more natural
(x = 3,y = 4) (x=3 | r)
where (perhaps) (x,y,z) is shorthand for (t1 = x,t2 = y,t3 = z)
this would also have the nice advantage that it is syntaxwise more backwards compatable, since labeled fields require a constructor argument to appear before the {}'s but tuples already don't. (and presumably a new record system wouldn't)
I think an issue is that we call the current system records, so we expect them to work like other languages records, when in actuality, they are just labeled fields on standard haskell datatypes, but since that is true, we get all the power of standard haskell datatypes such as strict fields, summation types, the ability to declare instances and lots of typesafety. Haskell currenty just doesn't have a record system, adding one shouldn't get rid of the unrelated and very useful labeled fields feature :)
John
I agree, and I'd also say that the concrete syntax of Daan's proposal ought to still be up in the air, as the version in the paper uses TeX symbols which we don't have :) From my viewpoint, there's nothing particularly wrong with the labelled fields in datatypes feature as it stands. Leaving them in without change would be fine. Haskell just seems to be missing a flexible way to deal with large product types, and a record system would fix that problem. Normally, I'd say that one should more often design one's program so that large products aren't needed at any point, but there are cases where one is dealing with interfaces from applications written in languages where large products are common. (A lot of network applications spring to mind. Joel Reymont had this issue, definitely.) - Cale