Chris, Thank you for the real word experience report. I had assumed (because everyone else told me) that importing qualified would be much, much better than prefixing. I had thought that in your case since you are big on model separation that you would have liked having a separate file for each model to separate out all your model related code with. As a counter point, in all of my (MVC) web application projects, we do have a separate file for each model, and we like this approach. Each file usually contains a lot of "business logic" related to the model- the only relatively empty model files are ones that really represent embedded data. When I use MongoDB (which actually supports embedded data instead of forcing you to create a separate table), I will actually place the embedded models in the same file as the model which includes them. After my blog post complaining about records, I had a few people telling me that I can just use existing polymorphism to avoid the name-spacing issue. I collected the approaches here: http://www.yesodweb.com/wiki/record-hacks I didn't think any of those telling me what i should do had actually tried to do this themselves, particularly at any kind of larger scale. I am interested to see if anyone has experience trying this approach, or if you have considered it. On Thu, Sep 15, 2011 at 3:00 AM, Christopher Done wrote:

I added my evaluation of the module-based approach to existing records, but on second thoughts it's maybe inappropriate, so I'll post it here. I saw that some people commented on the reddit discussion that the solution is to put your types in separate modules but it doesn't seem that anyone has tried to do this on a large scale. I tried it (and some other record paradigms including Has), but I don't think it scales. Here's why…

Suppose I have 112 hand-crafted data types in my project (e.g. see attachment 51369.txt[1]), this creates a lot of conflicts in field names and constructor names. For example:

{{{ data Comment = Comment { commentId :: CommentId , commentContent :: Content , commentReviewId :: ReviewId , commentSubmissionId :: SubmissionId , commentConferenceId :: ConferenceId , commentDate :: ISODate , commentReviewerNumber :: Int } deriving (Show) }}}

This is a real type in my project. It has fields like “id”, “content”, “reviewId”, “submissionId”, “date”. There are seven other data types that have a field name “submissionId”. There are 15 with “conferenceId”. There are 7 with “content”. And so on. This is just to demonstrate that field clashes ''do'' occur ''a lot'' in a nontrivial project.

It also demonstrates that if you propose to put each of these 112 types into a separate module, you are having a laugh. I tried this around the 20 type mark and it was, apart from being very slow at compiling, ''very'' tedious to work with. Creating and editing these modules was a distracting and pointless chore.

It ''also'' demonstrated, to me, that qualified imports are horrible when used on a large scale. It happened all the time, that'd I'd import, say, 10 different data types all qualified. Typing map (Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious and distracting, especially having to add every type module when I want to use a type. And when records use other types in other modules, you have ''a lot'' of redundancy. With the prefixing paradigm I'd write fooId and barMuThisField, which is about as tedious but there is at least less . confusion and no need to make a load of modules and import lines. Perhaps local modules would solve half of this problem. Still have to write “Bar.mu bar” rather than “mu bar”, but it'd be an improvement.

I also have 21 Enum types which often conflict. I end up having to include the name of the type in the constructor, or rewording it awkwardly. I guess I should put these all in separate modules and import qualified, too. Tedious, though. At least in this case languages like C# and Java also require that you type EnumName.EnumValue, so c‘est la vie.

[1]: http://hackage.haskell.org/trac/ghc/attachment/wiki/Records/51369.txt

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

I should be clear that in my counter point I am using Ruby, not Haskell on those projects. In Ruby one can use a string for the name of a class (which will be evaluated later) and other general dynamic typing tricks to avoid cyclical dependencies. I have worked on one large Yesod project. I felt they were creating artificially shortened field names in some cases (that I found difficult to understand/remember) to try and ease the pain of large prefixed record selectors. However, Yesod does create all the records with prefixes in one module/file- so all the types are in there. They create a new model file for each model (conceptually, but not for a model representing simple embedded data). The model file can import all the record types. Personally I would prefer to define my type in the model file so I can quickly see my type with the related code if it were possible, but it seems that it isn't. On Thu, Sep 15, 2011 at 8:15 AM, Christopher Done wrote:

2011/9/15 Greg Weber :

...

Chris, Thank you for the real word experience report. I had assumed (because everyone else told me) that importing qualified would be much, much better than prefixing. I had thought that in your case since you are big on model separation that you would have liked having a separate file for each model to separate out all your model related code with. As a counter point, in all of my (MVC) web application projects, we do have a separate file for each model, and we like this approach. Each file usually contains a lot of "business logic" related to the model- the only relatively empty model files are ones that really represent embedded data. When I use MongoDB (which actually supports embedded data instead of forcing you to create a separate table), I will actually place the embedded models in the same file as the model which includes them.

Ah, this is because my approach to types is to put them in a ProjectName.Types.X module. I /do/ have separate modules for all my models, e.g.

$ ls Confy/Model/*.hs Confy/Model/Actions.hs Confy/Model/Driver.hs Confy/Model/Manuscript.hs Confy/Model/Proceedings.hs Confy/Model/SubmissionAuthor.hs Confy/Model/Token.hs Confy/Model/Activity.hs Confy/Model/Fields.hs Confy/Model/Message.hs Confy/Model/ReviewComment.hs Confy/Model/Submission.hs Confy/Model/Track.hs Confy/Model/Author.hs Confy/Model/FormField.hs Confy/Model/Papertype.hs Confy/Model/ReviewerPreference.hs Confy/Model/Tables.hs Confy/Model/User.hs Confy/Model/Conference.hs Confy/Model/Form.hs Confy/Model/Participant.hs Confy/Model/Review.hs Confy/Model/Template.hs Confy/Model/UserMeta.hs Confy/Model/Deadline.hs Confy/Model/LogEntry.hs Confy/Model/Period.hs Confy/Model/Role.hs Confy/Model/TH.hs Confy/Model/Utils.hs

I have my HaskellDB types and then I have my normal Haskell types which contain different fields to the database model.

But to put the /type/ in the model file itself causes cyclic import problems when I have to start caring about what imports what and then having modules that just contain types, etc. I find this to be quite laborious, I did it at first but it became a hindrance to development practice for me. Have you not found that you have this problem if you put types in the same modules as code in a large project? Examples welcome, too.

...

After my blog post complaining about records, I had a few people telling me that I can just use existing polymorphism to avoid the name-spacing issue. I collected the approaches here: http://www.yesodweb.com/wiki/record-hacks I didn't think any of those telling me what i should do had actually tried to do this themselves, particularly at any kind of larger scale. I am interested to see if anyone has experience trying this approach, or if you have considered it.

I considered that approach but never tried it, one would probably enlist the help of TemplateHaskell to do that approach properly. Maybe it's not so bad? I suppose I could try making a few branches in my project and try out this approach.

It ''also'' demonstrated, to me, that qualified imports are horrible when used on a large scale. It happened all the time, that'd I'd import, say, 10 different data types all qualified.  Typing map (Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious and distracting, especially having to add every type module when I want to use a type. And when records use other types in other modules, you have ''a lot'' of redundancy. With the prefixing paradigm I'd write fooId and barMuThisField, which is about as tedious but there is at least less . confusion and no need to make a load of modules and import lines. Perhaps local modules would solve half of this problem. Still have to write “Bar.mu bar” rather than “mu bar”, but it'd be an improvement.

I disagree about qualified imports, in my experience they're even more useful as the scale increases, because there are many more modules each symbol could come from, and many more name conflicts, and of course there starts to be module name conflicts. I don't find it much of an imposition because I have an automatic tool to add and remove imports when needed, and once the import is already there keyword completion works on it. Grepping for '^data .. =', I have 199 types, of which 97 are probably records, spread over 296 modules. The 97 records are spread over 50 modules, but in practice there are a number with 5-10 and then a long tail with just 1 or 2 each. However I entirely agree a better syntax for records would make programming clearer, more concise, and more fun. I also agree that one module per record is annoying, so I wind up with many records per module, so I have record prefixes anyway. Access is annoying, but not so bad, I think. It's true '(ModuleB.recField2 . ModuleA.recField1) val' is inferior to val.field1.field2, but at least the functions compose and if you make a habit of reducing the dots by defining a few precomposed functions you can cut out a lot of the work of moving a field, or more likely, grouping several fields into a nested record. But the really annoying thing is that modification doesn't compose. Record updates also don't mix well with other update functions. So, just to put give another data point, here's an extreme case: set_track_width view_id tracknum width = do views <- gets views view <- maybe (throw "...") return $ Map.lookup view views track_views <- modify_at "set_track_width" (Block.view_tracks view) tracknum $ \tview -> tview { Block.track_view_width = width } let view' = view { Block.view_tracks = track_views } modify $ \st -> st { state_views = Map.insert view_id view' (state_views st) } I inlined the 'modify_view' function, so this looks even nastier than the real code, but it would be nice to not have to define those helper functions! In an imperative language, this would look something like state.views[view_id].tracks[tracknum].width = width Of course, there's also monadic vs. non-monadic getting its claws in there (and the lack of stack traces, note the explicit passing of the function name). So if I hypothesize a .x syntax that is a modification function, some handwavy two arg forward composition, and remove the monadic part (could get it back in with some fancy combinator footwork), theoretically haskell could get pretty close to the imperative version: let Map.modify k m f = Data.Map.adjust f k m (.views .> Map.modify view_id .> .tracks .> modify_at tracknum .> .width) state width -- or, let set = (...) in state `set` width It's also nice if the field names can be in their own namespace, since it's common to say 'x.y = y'. I'm not saying I think the above would be a good record syntax, just that I think composing with other modify functions is important. Passing to State.modify is another obvious thing to want to do. The above is an extreme case, but I've lost count of the number of times I've typed 'modify $ \st -> st { field = f (field st) }'. I don't even have to think about it anymore. I know that these are the problems that lenses / first class labels libraries aim to solve, so if we're talking only about non-extensible records, I'm curious about what a language extension could provide that a library can't. Simply not being standard and built-in is a big one, but presumably the platform is an answer to that. It would be nice if record updates and access to come with no performance penalty over the existing system, since updating records forms a large part of the runtime of some programs, I'm not sure if the libraries can provide that?

On Thu, Sep 15, 2011 at 6:03 AM, Barney Hilken wrote:

The right way to deal with records is first to agree a mechanism for writing a context which means

       "a is a datatype with a field named n of type b"

then give the selector n the type

       "a is a datatype with a field named n of type b" => n :: a -> b

There is no reason why this shouldn't be used with the current syntax (although it might clash with more advanced features like first-class labels).

Trex is one existing approach in the Haskell design space http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html http://web.cecs.pdx.edu/~mpj/pubs/lightrec.html /g -- "I’m surprised you haven’t got a little purple space dog, just to ram home what an intergalactic wag you are."

On 15/09/2011 14:03, Barney Hilken wrote:

As formulated on the wiki page, the "narrow issue" is a problem without a good solution. The reason the community rejected TDNR is because it's basically polymorphism done wrong. Since we already have polymorphism done right, why would we want it?

I think you mean "overloading", not "polymorphism", right? Cheers, Simon

On 15/09/2011 15:43, Ian Lynagh wrote:

On Thu, Sep 15, 2011 at 08:47:30AM +0000, Simon Peyton-Jones wrote:

...

Provoked the (very constructive) Yesod blog post on "Limitations of Haskell", and the follow up discussion, I've started a wiki page to collect whatever ideas we have about the name spacing issue for record fields.

http://hackage.haskell.org/trac/ghc/wiki/Records

As Simon M said on Reddit, this is something we'd like to fix; but we need a consensus on how to fix it.

Re TypeDirectedNameResolution, I would actually prefer it if it were less general. i.e. if you were to write x.f then f would be required to be a record selector.

Then there's no need for the "If there is exactly one f whose type matches that of x" unpleasantness. Instead, the type of x must be inferred first (without any knowledge about the type of f), and then we know immediately which f is being referred to.

One benefit of TDNR is to replicate the discoverability of APIs that OO programming has - if x :: Foo then typing "x." in an IDE gives you a list of things you can do with a Foo. (Obviously it's not a complete lis for various reasons, but it does allow the author of Foo and others to design discoverable APIs.) So I think we'd be losing quite a bit to force f to be a record selector. Ganesh

On Fri, Sep 16, 2011 at 06:46:35AM +0100, Ganesh Sittampalam wrote:

On 15/09/2011 15:43, Ian Lynagh wrote:

...

On Thu, Sep 15, 2011 at 08:47:30AM +0000, Simon Peyton-Jones wrote:

...

Re TypeDirectedNameResolution, I would actually prefer it if it were less general. i.e. if you were to write x.f then f would be required to be a record selector.

Then there's no need for the "If there is exactly one f whose type matches that of x" unpleasantness.

One benefit of TDNR is to replicate the discoverability of APIs that OO programming has - if x :: Foo then typing "x." in an IDE gives you a list of things you can do with a Foo. (Obviously it's not a complete lis for various reasons, but it does allow the author of Foo and others to design discoverable APIs.)

But add another import, and some of those APIs disappear! And of course, the language doesn't need to support TDNR in order for an IDE to use it (although the juxtaposition application syntax doesn't make the UI easy). Thanks Ian

On 16 September 2011 16:31, Ryan Newton wrote:

I started playing around with Leksah and scion/emacs (searching for "what's the type of this expr" support) and was a little disappointed that this functionality doesn't seem to exist yet.  Or am I wrong and it exists somewhere?

The problem is when you have incomplete programs. Scion does allow you to ask for the type of a subexpression(1), but it can only do so if the program type checks. In many cases you can get an incomplete program to type check by adding "undefine"s, but that doesn't work in the general case. You may get issues with ambiguous types with no defaulting rules. Ambiguity checking is a separate stage in the type checker (at least it was before 7.0.*) so it's possible in principle to add an option to the GHC API to allow such programs to pass the type checker. I'm not a fan of TDNR because it would make programs even more sensitive to imports than they are now (the current issue is due to type classes and the lack of control about importing them). I also fear that it would interact badly with things an IDE has to do. I may be wrong, though, as some people seem to claim the opposite. I haven't had the chance to think about that fully. Personally, I like the type class + special label type solution best, so far. (1) It's disabled in the current master branch, but it's available in the fork used by EclipseFP and it does indeed work there. -- Push the envelope. Watch it bend.

I really like Simon PJ's "proposal for records in Haskell". Some reasons for this are: - Anonymous record types. For example, an anonymous record type can easily hold ad-hoc keyword arguments. (Oh, just noticed that said in the document.) - To quote the document, "We can express polymorphic update (a standard awkward case) quite nicely". (If I'm not mistaken (please tell me if so), OverloadedRecordFields proposal fails here.) - Nice syntax (in my opinion). Possible record member set syntax: let x.k = value in x Pros: - No new syntax - Least Surprise Cons: - Verbosity (especially such: (\ x -> let x.k = value in x)) On 20/10/2011, Simon Peyton-Jones wrote:

| Subject: Re: Records in Haskell | | I have added my proposal to the wiki.The only downsides to it that I can see are:

Thanks to Barney for articulating a proposal for records in Haskell. Over various plane rides and ICFP chats I've worked out some more details. It's not as simple as I'd hoped.

I'm underwater with stuff at the moment but I did find the time to capture a summary here http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

Please do correct errors, suggest solutions, or explore variants.

Simon

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Matthew Farkas-Dyck

| would inclusion of such a record system into GHC mean that plans for | first-class labels (http://tinyurl.com/7fppj32) are abandoned? That | would be a pity, since first-class labels are very useful to implement | record systems that go beyond what the abovementioned record system | provides. See, for example, my work on records: | http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf | http://hackage.haskell.org/package/records The story is summarised at http://hackage.haskell.org/trac/ghc/wiki/Records First-class labels are one point in the vast swamp of competing and overlapping proposals for records. I think they are summarise here: http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords I am unsure which of this list of proposals you are referring to. The URL you quote is this http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels but it doesn't seem to actually contain a design, merely some options for a design that is implicit. If you do have a design you advocate, it would be good to add it to the list at http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords perhaps explaining which of the other members of the list it subsumes. Because there are so many proposals I have not gone ahead with any of them. The most recent thread, articulated at http://hackage.haskell.org/trac/ghc/wiki/Records is to ask what is the *smallest change* that would solve the *most pressing problem*, namely the inability to use the same field name in different records. First class labels is (I assume) much more ambitious. But maybe not. Anything you can do to bring clarity to the swamp, by editing the above two pages, would be a great service to the community. At the moment, we are stuck in an infinite loop. Simon

Am Montag, den 07.11.2011, 18:16 +0100 schrieb Claus Reinke:

...

I am unsure which of this list of proposals you are referring to. The URL you quote is this http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels

That sounds familiar, I think I wrote that when I was younger;-)

...

but it doesn't seem to actually contain a design, merely some options for a design that is implicit.

Please note that this particular instance of FirstClassLabels was *not* about record systems themselves (already a hopeless mess of proposals and preferences back then), but about a feature that would help defining record systems *in the language*.

Indeed. And I think it is important to make implementing new record systems in the language easier. Each record system built into the language might lack some features that someone wants. So it would be good if one could come up with one’s own record system easily. Best wishes, Wolfgang

Are Records stalled out again? I am perfectly willing to leave the fate of records up to a willing and capable implementer. That seems much better than waiting another 5 years for perfection :) As an intermediate step, is it possible to put a warning in 7.4 when the dot operator is used without a space so that it can be reserved for usage with a records solution? Or will the new records solution be turned on by an extension anyways? On Mon, Nov 7, 2011 at 10:21 AM, Simon Peyton-Jones wrote:

| would inclusion of such a record system into GHC mean that plans for | first-class labels (http://tinyurl.com/7fppj32) are abandoned? That | would be a pity, since first-class labels are very useful to implement | record systems that go beyond what the abovementioned record system | provides. See, for example, my work on records: | < http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf> | http://hackage.haskell.org/package/records

The story is summarised at http://hackage.haskell.org/trac/ghc/wiki/Records

First-class labels are one point in the vast swamp of competing and overlapping proposals for records. I think they are summarise here: http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords I am unsure which of this list of proposals you are referring to. The URL you quote is this http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels but it doesn't seem to actually contain a design, merely some options for a design that is implicit. If you do have a design you advocate, it would be good to add it to the list at http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords perhaps explaining which of the other members of the list it subsumes.

Because there are so many proposals I have not gone ahead with any of them. The most recent thread, articulated at http://hackage.haskell.org/trac/ghc/wiki/Records is to ask what is the *smallest change* that would solve the *most pressing problem*, namely the inability to use the same field name in different records. First class labels is (I assume) much more ambitious. But maybe not.

Anything you can do to bring clarity to the swamp, by editing the above two pages, would be a great service to the community. At the moment, we are stuck in an infinite loop.

Simon

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Tue, Dec 20, 2011 at 5:57 PM, Matthew Farkas-Dyck wrote:

Another thought: Perhaps bang as record selection operator. It would avoid further corner cases of dot, and it's not unprecedented in Haskell (e.g. Data.Map.!).

We already have weird syntax rules for dot, and the proposed change (i.e., dot is an identifier when surrounded with spaces, else it's reserved syntax) actually makes the rules *simpler* in some ways rather than more complex... so why wouldn't we do it that way? The more difficult bit isn't about quirks of syntax, but rather about some significant semantic issues and differing design goals.... should we have a built-in notion of lenses... if so, which formulation... what kinds of punning do we want to preserve, and how deeply should punning go in the semantics, versus be a shallow kind of sugar... how does that interact with the type system... and so on. These are the significant problems.

Yet another idea: Consider using '\' as record access operator. No conflicts with anything at all, and, moreover, it really looks like hierarchical access. Reminds of filesystems though. Matthew Farkas-Dyck wrote

Another thought: Perhaps bang as record selection operator. It would avoid further corner cases of dot, and it's not unprecedented in Haskell (e.g. Data.Map.!).

-- View this message in context: http://haskell.1045720.n5.nabble.com/Records-in-Haskell-tp4806095p5109437.ht... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

Are Records stalled out again? I am perfectly willing to leave the fate of records up to a willing and capable implementer. That seems much better than waiting another 5 years for perfection :) Yes, they are stalled again. The "simple solution" turned out to be not simple. I wrote it up at length in http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields There are various unsatisfactory aspects of the proposal, particularly concerning record update. I am not sure how to resolve them. There was essentially no reaction. As it's quite a lot of work to implement, and no one seemed to care very much, I put it back on the back burner. So that's where it stands. Meanwhile, AntC has put forth another proposal that I have not had time to look at in detail. http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.... What this needs is someone (not me) to lead the discussion and try to make sure it makes progress. For example, does AntC's proposal work? Is it better than the one I articulated? Are any other variants worth considering? Is the gain from overloading record fields worth the pain or design and implementation? Volunteers, stand forth! Simon From: Greg Weber [mailto:greg@gregweber.info] Sent: 09 December 2011 19:38 To: Simon Peyton-Jones Cc: Wolfgang Jeltsch; glasgow-haskell-users@haskell.org Subject: Re: Records in Haskell Are Records stalled out again? I am perfectly willing to leave the fate of records up to a willing and capable implementer. That seems much better than waiting another 5 years for perfection :) As an intermediate step, is it possible to put a warning in 7.4 when the dot operator is used without a space so that it can be reserved for usage with a records solution? Or will the new records solution be turned on by an extension anyways? On Mon, Nov 7, 2011 at 10:21 AM, Simon Peyton-Jones mailto:simonpj@microsoft.com> wrote: | would inclusion of such a record system into GHC mean that plans for | first-class labels (http://tinyurl.com/7fppj32) are abandoned? That | would be a pity, since first-class labels are very useful to implement | record systems that go beyond what the abovementioned record system | provides. See, for example, my work on records: | http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf | http://hackage.haskell.org/package/records The story is summarised at http://hackage.haskell.org/trac/ghc/wiki/Records First-class labels are one point in the vast swamp of competing and overlapping proposals for records. I think they are summarise here: http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords I am unsure which of this list of proposals you are referring to. The URL you quote is this http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels but it doesn't seem to actually contain a design, merely some options for a design that is implicit. If you do have a design you advocate, it would be good to add it to the list at http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords perhaps explaining which of the other members of the list it subsumes. Because there are so many proposals I have not gone ahead with any of them. The most recent thread, articulated at http://hackage.haskell.org/trac/ghc/wiki/Records is to ask what is the *smallest change* that would solve the *most pressing problem*, namely the inability to use the same field name in different records. First class labels is (I assume) much more ambitious. But maybe not. Anything you can do to bring clarity to the swamp, by editing the above two pages, would be a great service to the community. At the moment, we are stuck in an infinite loop. Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.orgmailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

The original goal was to come up with a simple solution. Perhaps that goal is unattainable, or at least attaining it has much higher cost than we had hoped. If that is the case we must take a step back and look at changing how things are done currently. Perhaps the approach that a record label becomes a global module function is just not feasible. In the Frege http://code.google.com/p/frege (a Haskell with some differences implementation on the JVM) language every data type is at the same time a namespace. * the function that accesses field x of data type T is T.x * If a::T then a.x = T.x a * the function that updates field x of data type T is T.{x=} * the function that sets field x in a T to 42 is T.{x=42} * If a::T then a.{x=} and a.{x=42} are valid * the function that changes field x of a T by applying some function to it is T.{x <-} * T.{x?} is a function that returns true iff the argument was constructed with a data constructor that has field x. In the Opa language a Module is in fact a Record specially marked as a module. What do you think of the Frege system? On Fri, Dec 23, 2011 at 2:40 PM, Greg Weber wrote:

I am willing to help on this as much as I can. Unfortunately I don't think you want me to lead the discussion or make decisions on this - many of these discussions seem over my head. I will continue to study them though and see if the sink in more.

I do think almost all of these proposals want a dot selector, so it is a good idea for Haskell to require the normal function (composition) dot to have spaces around it - should this be brought to the Haskell Prime committee?

Greg Weber

On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones

...

wrote:

...

Are Records stalled out again? I am perfectly willing to leave the fate of records up to a willing and capable implementer. That seems much better than waiting another 5 years for perfection :)****

** **

Yes, they are stalled again. The “simple solution” turned out to be not simple. I wrote it up at length in ****

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields** **

There are various unsatisfactory aspects of the proposal, particularly concerning record update. I am not sure how to resolve them. ****

** **

There was essentially no reaction. As it’s quite a lot of work to implement, and no one seemed to care very much, I put it back on the back burner. So that’s where it stands.****

** **

Meanwhile, AntC has put forth another proposal that I have not had time to look at in detail.****

http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.... ****

** **

*What this needs is someone (not me) to lead the discussion and try to make sure it makes progress*. For example, does AntC’s proposal work? Is it better than the one I articulated? Are any other variants worth considering? Is the gain from overloading record fields worth the pain or design and implementation? Volunteers, stand forth!****

** **

Simon****

** **

** **

*From:* Greg Weber [mailto:greg@gregweber.info] *Sent:* 09 December 2011 19:38 *To:* Simon Peyton-Jones *Cc:* Wolfgang Jeltsch; glasgow-haskell-users@haskell.org

*Subject:* Re: Records in Haskell****

** **

Are Records stalled out again? I am perfectly willing to leave the fate of records up to a willing and capable implementer. That seems much better than waiting another 5 years for perfection :)****

** **

As an intermediate step, is it possible to put a warning in 7.4 when the dot operator is used without a space so that it can be reserved for usage with a records solution? Or will the new records solution be turned on by an extension anyways?****

** **

On Mon, Nov 7, 2011 at 10:21 AM, Simon Peyton-Jones < simonpj@microsoft.com> wrote:****

| would inclusion of such a record system into GHC mean that plans for | first-class labels (http://tinyurl.com/7fppj32) are abandoned? That | would be a pity, since first-class labels are very useful to implement | record systems that go beyond what the abovementioned record system | provides. See, for example, my work on records: | < http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf

...

| http://hackage.haskell.org/package/records****

The story is summarised at http://hackage.haskell.org/trac/ghc/wiki/Records

First-class labels are one point in the vast swamp of competing and overlapping proposals for records. I think they are summarise here: http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords I am unsure which of this list of proposals you are referring to. The URL you quote is this

http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels but it doesn't seem to actually contain a design, merely some options for a design that is implicit. If you do have a design you advocate, it would be good to add it to the list at http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords perhaps explaining which of the other members of the list it subsumes.

Because there are so many proposals I have not gone ahead with any of them. The most recent thread, articulated at http://hackage.haskell.org/trac/ghc/wiki/Records is to ask what is the *smallest change* that would solve the *most pressing problem*, namely the inability to use the same field name in different records. First class labels is (I assume) much more ambitious. But maybe not.

Anything you can do to bring clarity to the swamp, by editing the above two pages, would be a great service to the community. At the moment, we are stuck in an infinite loop.

Simon****

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users****

** **

Quoth Greg Weber , ...

Many of the built-in record proposals seem more ambitious (create a new record from an existing one, generalize in some other direction). More power or generalization could be very useful, but it can wait for later - Haskell's records are glaringly bad because they lack name-spacing.

I think one of the problems being faced with improving records is a false choice between a quick but hacky library desugaring or a major "Extensible" records built into the compiler. What I am proposing is that (unless someone proposes a great desugaring solution) we make it the immediate goal to have records built into the compiler, but done in the simplest (perhaps least "Extensible") way that just accomplishes name-spacing.

It's sure easy to imagine something like that happening, in principle, but ... are you saying that extensibility specifically has been a major issue? Could be, I haven't been paying so much attention. Wouldn't extensibility more or less come along with row polymorphism? I mean, my understanding of the term is that an expression that instantiates a particular record field, can incorporate a record lacking that field, which seems to me to be implicit in row polymorphism anyway. I would think row polymorphism is a must-have. If you're interested in looking at old, Haskell-related record systems, also see O'Haskell. Donn

Quoth Greg Weber ,

On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave wrote: ...

...

I would think row polymorphism is a must-have.

Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing.

No, to be clear on that, I haven't given much thought to extensibility per se, I was thinking row polymorphism is a valuable feature on its own, and extensibility just seemed to me to be an implicit side benefit. In principle, a "less is more" approach to language features appeals to me a lot, but not to the point where we just preemptively give up on "any higher form of abstraction". Given the potential for backwards incompatibility, you'd want to have something pretty good to show for it. Donn

On 12/28/11 1:34 PM, Donn Cave wrote:

Quoth Greg Weber,

...

On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave wrote: ...

...

I would think row polymorphism is a must-have.

Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing.

No, to be clear on that, I haven't given much thought to extensibility per se, I was thinking row polymorphism is a valuable feature on its own, and extensibility just seemed to me to be an implicit side benefit.

Yes, row polymorphism would still be helpful in lack of extensible records. In particular it allows for easily determining principle (structural) types of records; this is desirable from a generic programming perspective even if records on the whole are not structurally typed. That is, we can distinguish the following types data Foo = MkFoo { x :: T } data Bar = MkBar { x :: T } By considering them to desugar into type Foo = { __type :: Foo , x :: T } constructor MkFoo :: T -> Foo pattern MkFoo :: T -> Pattern type Bar = { __type :: Bar , x :: T } constructor MkBar :: T -> Bar pattern MkBar :: T -> Pattern accessor x :: { x :: T , ... } -> x Of course, an actual implementation needn't come up with a phantom argument like __type in order to nominally distinguish structurally identical types. Rather, the existence of the hack shows that it's doable. -- Live well, ~wren

| The lack of response, I believe, is just a lack of anyone who | can cut through all the noise and come up with some | practical way to move forward in one of the many possible | directions. You're right. But it is very telling that the vast majority of responses on http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leaders... were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem. My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed. The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone. That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either. Usually I feel I know how to move forward, but here I don't. Simon

Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start by using Frege's document as the proposal. We can start a new wiki page as discussions are needed. If it's a serious proposal, it needs a page to specify the design. Currently all we have is a paragraph on http://hackage.haskell.org/trac/ghc/wiki/Records, under "Better name spacing". As previously stated on this thread, the Frege user manual is available here: http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields) To all those concerned about Records: look at the Frege implementation and poke holes in it. Well the most obvious issue is this. 3.2 says e.m = (T.m e) if the expression e has type t and the type constructor of t is T and there exists a function T.m But that innocent-looking statement begs the *entire* question! How do we know if "e has type t? This is the route ML takes for arithmetic operators: + means integer plus if the argument is of type Int, float plus if the argument is of type Float, and so on. Haskell type classes were specifically designed to address this situation. And if you apply type classes to the record situation, I think you end up with http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields Well, so maybe we can give up on that. Imagine Frege without the above abbreviation. The basic idea is that field names are rendered unique by pre-pending the module name. As I understand it, to record selection one would then be forced to write (T.m e), to select the 'm' field. That is the, qualification with T is compulsory. The trouble with this is that it's *already* possible; simply define suitably named fields data T = MkE { t_m :: Int, t_n :: Bool } Here I have prefixed with a (lower case version of) the type name. So we don't seem to be much further ahead. Maybe one could make it optional if there is no ambiguity, much like Haskell's existing qualified names. But there is considerable ambiguity about whether T.m means m imported from module T or the m record selector of data type T Perhaps one could make it work out. But before we can talk about it we need to see a design. Which takes us back to the question of leadership. Simon We only want critiques about * achieving name-spacing right now * implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation now, just possibly modify things slightly. Greg Weber On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones mailto:simonpj@microsoft.com> wrote: | The lack of response, I believe, is just a lack of anyone who | can cut through all the noise and come up with some | practical way to move forward in one of the many possible | directions. You're right. But it is very telling that the vast majority of responses on http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leaders... were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem. My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed. The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone. That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either. Usually I feel I know how to move forward, but here I don't. Simon

Gershom Bazerman wrote:

Beyond that, it would really help namespacing in general to appropriately extend the module system to allow multiple modules to be declared within a single file -- or, better yet, "submodules". I know that this introduces a few corner cases that need to be thought through -- what happens with overlapping declarations, for example. But I tend to think the path here is relatively straightforward and obvious, and the added expressive power should make namespacing issues much more tractable.

I agree, this would be a great first step forward. Nested modules would be the most helpful. But even just multiple modules per file would be an improvement, and that is Haskell 98 compliant. For past discussion about this idea, see the thread that begins here: http://www.haskell.org/pipermail/haskell-cafe/2008-August/046494.html There is also the issue of how GHC decides which files to open when searching for modules. One easy way to begin would be just to have the caveat that GHC will not find such modules unless it would otherwise look in the file based on the traditional GHC naming conventions. For various reasons including this one, I still think it is a good idea to allow the user to specify a manifest file to GHC instead of relying on GHC to walk the file system itself. See this GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2550 Thanks, Yitz

On Sun, Jan 01, 2012 at 01:22:31AM -0500, Matthew Farkas-Dyck wrote:

...

It seems to me that there's only one essential missing language feature, which is appropriately-kinded type-level strings

Isn't this possible now with type → kind promotion?

Unfortunately, I believe promotion of built-in types other than lists and tuples has not yet been implemented. In particular, Char cannot yet be promoted. However, there are no theoretical impediments to implementing it that I know of and it should be possible in the future. -Brent

I'm interested in type-level strings myself. I'm using an approximation in order to enrich the instant-generics-style reflection of data type declarations with a sensitivity to constructor names. For example, this lets me automatically convert between many the similarly-named constructors of related data types (e.g. pipeline of ASTs in a compiler). Is there any existing developments regarding type-level strings? I have (arbitrarily) taken the approach of promoting the cereal library to the type-level, encoding strings that way, and working from there (ultimately inspired by Kiselyov and Chan's implicit configurations paper). It's certainly not perfect, but it's all I need for the functionality I've been chasing so far. In regard to Labels versus Atom, etc., in my use case of converting between similar datatypes, it would be very reasonable to eventually add/remove prefixes/suffixes from these type-level reifications of constructor names. If type-level strings are not implemented as lists of characters, I would still like access to a comparable API. Perhaps an isomorphism? Thanks for your time,Nick PS — I suspect the "reflect to value-level" idea was something along the lines of automatically providing a function @stringVal :: forall (a :: Label). a -> String@. On Mon, Jan 2, 2012 at 6:38 AM, Simon Peyton-Jones wrote:

It seems to me that there's only one essential missing language feature, which is appropriately-kinded type-level strings (and, ideally, the ability to reflect these strings back down to the value level). Given that, template haskell, and the HList bag of tricks, I'm confident that  a fair number of elegant records packages can be crafted. Based on that experience, we can then decide what syntactic sugar would be useful to elide the TH layer altogether.

I think we can do this part without much trouble, once the dust has settled on -XPolyKinds.  It certainly fits with all the work we’ve been doing recently on the kind system. I agree that it’s a fairly basic requirement; for example, it’s also assumed by http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

Specifically

·        Allow String as a new kind

·        Now you can define classes or types with kinds like

MyCls :: String -> a -> Constraint

T :: String -> *

·        Provide type-level string literals, so that “foo” :: String

Open questions:

·        Is String (at the kind level) a synonym for [Char]?  I’m inclined *not* to do this initially, because it would require us to have promoted character literals too -- and the implementation of record labels as strings of type-level cons-cells is not going to be efficient.

·        If String is not a kind level synonym for [Char], maybe it should have a different name.  For example,   “foo” :: Label?  Or Atom?   After all, if it doesn’t behave like a Haskell string it probably should not have the same name.

·        Are there any operations over Labels?

·        I don’t know exactly what you have in mean by “the ability to reflect the type-level string at the value level”.

Simon

From: Gershom Bazerman [mailto:gershomb@gmail.com] Sent: 31 December 2011 19:12 To: Simon Peyton-Jones Cc: Greg Weber; glasgow-haskell-users@haskell.org

Subject: Re: Records in Haskell

On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:

The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone.  That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either.

Usually I feel I know how to move forward, but here I don't.

Simon

It seems to me that there's only one essential missing language feature, which is appropriately-kinded type-level strings (and, ideally, the ability to reflect these strings back down to the value level). Given that, template haskell, and the HList bag of tricks, I'm confident that  a fair number of elegant records packages can be crafted. Based on that experience, we can then decide what syntactic sugar would be useful to elide the TH layer altogether.

Beyond that, it would really help namespacing in general to appropriately extend the module system to allow multiple modules to be declared within a single file -- or, better yet, "submodules". I know that this introduces a few corner cases that need to be thought through -- what happens with overlapping declarations, for example. But I tend to think the path here is relatively straightforward and obvious, and the added expressive power should make namespacing issues much more tractable. Like the type-level strings proposal, this isn't about implementing records as such -- rather, it's about generally extending the expressive power of the language so that record systems--among other things--are easier to write.

Cheers,

Gershom

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Disclaimer: this use case for type-level string ops is still hypothetical, so these are predictions. Shooting for the moon, I foresee writing a type-level string similarity metric. In my experience, that would involve nested traversals, sliding of sequence windows, etc. In that case, I would very much like to write the similarity measure algorithm as if the labels were a sequence of characters. The kind in the following signature assumes promoted lists and — though I know it's still up in the air — some sort of promotion of characters as Char.

type LabelToLetters :: Label -> [Char]

Alternatively, the Char kind could simply be Label with an extralingual invariant that it has one "character" in it — though that doesn't smell like Haskell. The resulting kind of LabelToLetters in this case would be (Label -> [Label]). A class of "dumber" algorithms for "comparing" type-level promotions of constructor names might simply attach some prefix or suffix and then test for equality. In that case, I'd just need append.

type LabelAppend :: Label -> Label -> Label

I personally lean towards LabelToLetters, since I predict that any direct interface for labels-as-sequences is going to perpetually be a subset of whatever becomes established as the interface for type-level lists. The symmetric LettersToLabel would be nice for balance, but I don't foresee needing it in this use case, since comparing Labels is more so a consumer of Labels as opposed to a producer. Whatever the interface to Labels, I would need to be able to test type-level characters for equality. While built-in decidable type equality family that returns a type of kind Bool would be fantastic (or preferably GHC ticket 1894), I'm not anticipating that anytime soon. In order to continue using my own library for such a type-level type equality predicate, I need to be able to provide type family instances for the type-level characters.

I need type-level characters to be valid as indices in type family instances.

That's all I foresee. Thanks. On Tue, Jan 3, 2012 at 3:32 AM, Simon Peyton-Jones wrote:

| In regard to Labels versus Atom, etc., in my use case of converting | between similar datatypes, it would be very reasonable to eventually | add/remove prefixes/suffixes from these type-level reifications of | constructor names. If type-level strings are not implemented as lists | of characters, I would still like access to a comparable API.

Can you be specific?  What operations, exactly, do you want?

Simon

On Mon, Jan 2, 2012 at 1:38 PM, Simon Peyton-Jones wrote:

· **If String is not a kind level synonym for [Char], maybe it should have a different name. For example, “foo” :: Label? Or Atom?

Or Symbol? The name is inspired by Ruby's :symbol notation. We could even use the same notation (seems unambiguous on the type level, no?). Even if we don't use the notation we could use the name. Sebastian

On Jan 2, 2012, at 8:05 PM, Iavor Diatchki wrote:

Hello,

On Mon, Jan 2, 2012 at 4:38 AM, Simon Peyton-Jones wrote:

...

· I don’t know exactly what you have in mean by “the ability to reflect the type-level string at the value level”.

This can be done using singleton types in exactly the same way that it is done on the type-nats branch. It is useful if we want to allow users to define interesting polymorphic functions for values of types with type-level string literals (e.g., in the context of records, this would allow a user to define a custom showing function that can display the record labels). Here is what the type-nat singletons approach might look like for string literals:

newtype StringS (s :: String) = StringS String -- Abstract type for singletons (constructor not exported)

fromStringS :: StringS s -> String fromStringS (StringS s) = s

class StringI s where stringS :: StringS s -- "smart" constructor for StringS values.

Thanks for the clear exposition! This is nearly exactly what I had in mind, and describes precisely one of the use cases I'd imagine. The other tool I could imagine using, although for less common purposes, would be: newtype StringC a = StringC (forall (s :: String). StringS s -> a) runStringC :: String -> StringC a -> a runStringC = compiler magic With type level nats and the like, it's easy enough to write this by hand, and not terribly inefficient. But with type level strings, I'd imagine that it would be nicer to push the work to the compiler. Cheers, Gershom

Beyond that, it would really help namespacing in general to appropriately extend the module system to allow multiple modules to be declared within a single file -- or, better yet, "submodules". I know that this introduces a few corner cases that need to be thought through -- what happens with overlapping declarations, for example. But I tend to think the path here is relatively straightforward and obvious, and the added expressive power should make namespacing issues much more tractable. Like the type-level strings proposal, this isn't about implementing records as such -- rather, it's about generally extending the expressive power of the language so that record systems--among other things--are easier to write. I'm agnostic about nested modules. In principle they would be a good thing. However, for the application to records in particular, I'm not sure people would relish saying this module M where module T where data T = MkT { x,y :: Int } module S where data S = MkS { x,y : Int } The trouble is that, as ever, it is easier to say "add nested modules" than it is to say what that means. For example, if I say import qualified M (where M is defined as above), are the data types called M.T, M.S, or M.T.T and M.T.T? What if I import unqualified? Without a design it's hard to debate the pros and cons of different approaches to the record question. If anyone is seriously advocating nested modules, the first step is to work out a concrete design, in detail. Simon From: Gershom Bazerman [mailto:gershomb@gmail.com] Sent: 31 December 2011 19:12 To: Simon Peyton-Jones Cc: Greg Weber; glasgow-haskell-users@haskell.org Subject: Re: Records in Haskell On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote: The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone. That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either. Usually I feel I know how to move forward, but here I don't. Simon It seems to me that there's only one essential missing language feature, which is appropriately-kinded type-level strings (and, ideally, the ability to reflect these strings back down to the value level). Given that, template haskell, and the HList bag of tricks, I'm confident that a fair number of elegant records packages can be crafted. Based on that experience, we can then decide what syntactic sugar would be useful to elide the TH layer altogether. Beyond that, it would really help namespacing in general to appropriately extend the module system to allow multiple modules to be declared within a single file -- or, better yet, "submodules". I know that this introduces a few corner cases that need to be thought through -- what happens with overlapping declarations, for example. But I tend to think the path here is relatively straightforward and obvious, and the added expressive power should make namespacing issues much more tractable. Like the type-level strings proposal, this isn't about implementing records as such -- rather, it's about generally extending the expressive power of the language so that record systems--among other things--are easier to write. Cheers, Gershom

On 1/02/2012 12:26 AM, AntC wrote:

Simon Peyton-Jones writes:

...

Beyond that, it would really help namespacing in general to appropriately

...

much more tractable. [snip] this isn't about implementing records as such -- rather, it's about generally extending the expressive power of the language so that record systems--among other things--are easier to write.

I’m agnostic about nested modules. In principle they would be a good

extend the module system to allow multiple modules to be declared within a single file -- or, better yet, "submodules". [snip] the added expressive power should make namespacing issues thing. However, for the application to records in particular, ...

No! no! no! For records _don't_ put records in nested/sub-modules, and _don't_ require them in separate modules (as currently). Here's how ...

namespace management and record systems are intimately related, but as you assert distinct issues. taking your example of Customer_id, I expressly want to be able to define in the same syntactic module (file). Two records with a field with exactly the same name at two different types, say Customer_id :: Int and Customer_id :: String. As I understand it, your proposal would not enable this. In reality these two different uses of the name Customer_id are unrelated and distinct. Some would argue that therefore they should rightly have distinct names, however that is moot, for the purpose of this discussion lets take this as the objective. There are two roads to travel: Customer_id is one semantic entity (in the sense of an overloaded field, disambiguated by the type system) or Customer_id represents two distinct semantic entities disambiguated syntactically. I for one favor the second approach as it matches my intent, can I say, more faithfully.

[There may be other reasons for nested/sub-modules, but records ain't it.]

as above, however, I believe the best approach is to explore both paths and perhaps extend Haskell in both directions. As in your example the particular construction of which suits, the approach offered in your email better because it matches your intent "more faithfully". It is this ability to match construction with intent that is critical, which alludes to the notion of "the expressivity" of a language.

The reason was hinted at way back in Chris Done's attachment to the original Records wiki http://hackage.haskell.org/trac/ghc/wiki/Records "types in a non- trivial project".

Let's say I have a database application with a field (meaning type) customer_id. Then it appears in records for name and address, pricing, order entry, etc. This is not a name 'clash', it's 'intended sharing'. (It really galls me to even put it that way for explanatory purposes. Really it's the **same** customer_id.)

In data model design you'd typically go about identifying all the fields (types aka attributes) and putting them in a data dictionary. Then you'd construct your records from them.

You might (possibly) put the data dictionary in a distinct module, for easy maintenance. But you'd certainly want all the customer-related records in the same module.

So a data decl: data Customer_NameAddress = Cust_NA { customer_id :: Int, ... }

is _not_ declaring customer_id, it's _using_ an already-declared field. (Actually, if you've got any sense, you'll declare: newtype Customer_id = Customer_id Int data ... = { customer_id :: Customer_id, ... } and that takes us to Type-indexed records and then a short hop to anonymous tuples and polymorphic records and tuple extension/concat/merge and ... one day!)

The other purpose of the data dictionary is to declare what DBMS's call the 'domain' of the field (Int in the case of customer_id). The terminology's going to get a bit confusing here: Haskell's field name (selector functions) apply to the record as the function's domain, and Int as the result (range).

For Haskell's field selectors we might also want to constrain the records they can be used in. (For example they must be 'Persist'able so that we can write them to an external database.)

So, to the proposal (I'm assuming http://www.haskell.org/pipermail/glasgow- haskell-users/2011-December/021298.html can be made workable. SPJ has been kind enough to give it a once-over http://www.haskell.org/pipermail/glasgow- haskell-users/2012-January/021744.html, but of course all faults are the author's alone.) Specifically, there's to be a class Has with methods get and set. This is grossly simplified, see the posts):

0. class Has r fld t where -- record r has field fld at type t get :: r -> fld -> t set :: fld -> t -> r -> r' -- update t into r -- the r' is to cater for type-changing updates -- it's actually a type function over r fld t

And then: 1. We need -XDisambiguateRecordFields, so that we can talk about specific record types unambiguously(!) 2. We must avoid auto-generating the field selector function from data decls. So that we can free up the namespace and share the field name with other records. (IMHO this should always have been part of -XDisambiguate... I'm not the first to say that.) 3. We need a 'peg' at the type/kind level to drive instance resolution. (This is the `fld' of the Has instance. SPJ's SORF uses a String Kind. I'll use phantom type Proxy_field.) 4. There's to be a new form of declaration: field customer_id -- think data dictionary This is syntactic sugar for: type Proxy_customer_id -- phantom 'peg' customer_id :: (Has r Proxy_customer_id t) => r -> t customer_id r = get r (undefined :: Proxy_customer_id) So we now have a field selector function, similar to H98's but polymorphic.

5. Here's a data decl and its generated Has instance: data Customer_NameAddress = Cust_NA { customer_id :: Int, ... } instance (t ~ Int) => Has Customer_NameAddress Proxy_customer_id t ... in which get/set are defined using the data constructor unambiguously. The (t ~ ...) constraint is to force instance match, followed by type) refinement as a "functional-dependency-like mechanism" [SPJ]. 6. Another data decl using field customer_id generates another Has instance. So customer_id is polymorphic and 'just a function'. So at use sites, we use regular instance resolution, no dodgy semantics.

7. In other modules/namespaces, we can hide the existence and/or representation of fields, using standard export/import controls. We don't have to try to hide the instances (which Haskell don't do).

4b. At step 4. I wasn't telling the whole story. For this application, we want customer_id to be always an Int. We also (let's say) want the record to be Persistable. So the full syntax for the new declaration is: field customer_id :: (Persist r) => r -> Int (The :: type spec is optional.) The decl generates customer_id :: (Persist r, Has r Proxy_customer_id t, t ~ Int ) => r -> t [I'm not sure on that r -> t, perhaps r -> Int is better to help type inference??]

Back to modules and namespaces ... Some other module on a distant planet declares a field customer_id. It's using String as the domain (type). (Or perhaps it's using H98-style field naming.) Someone in the asteroid belt builds an application which imports both modules.

**Now** we have a name clash: these are different customer_id's. But this is just regular, familiar name clash. We're sweet: the field selector is 'just a function' we can use it qualified. (Also the phantom Proxy_customer_id must be qualified -- not that the end user/programmer needs to know that, not that it matters because it's only a phantom.)

Leftovers/problems for the implementer (thanks, Simons ;-):

Keyword `field' is probably used all over the place in extant code. (Also `label', and anything else we'd probably like to use.) Somebody please choose another keyword. Let's not put disproportionate effort into lexical syntax.

Somewhat off-topic for namespaces, an allowable (optional) syntax for field access is to be dot notation: show r.customer_id -- desugars to: show (customer_id r) How do we disambiguate this when there's differing fields in scope? -- easy: r.My.customer_id -- vs. r.Their.customer_id The syntax rule is that an upper-case to the left of the dot means qualified name, and binds rightwards more tightly. You can use parentheses to override binding.

Perhaps the asteroid-dweller wants to create their own record including a customer_id: data Customer_Planet = Cust_Planet { customer_id :: Int, ... } Now we're in trouble: the current syntax for data decl's doesn't contemplate qualified field names. Help!! Perhaps we only allow record decls using field names imported unqualified?

A possible refinement: it's daft in the data decl having to spec :: Int all the time, when the field declaration has already said that. Can we default it? Tricky: { customer_id, name, address :: String } looks like it's declaring three fields type String.

Syntax for field update: f1 Cust_NA{ customer_id, .. } = Cust_NA{ customer_id = 27, ..} (that is, with explicit data constructors) is regular DisambiguateRecordFields with wildcards and punning. Works as currently (GHC 7.2.). (And in fact the instance definition for set uses this syntax.)

Contrast f2 r = r{ customer_id = 27 } (that is, no data constructor prefixing the record update, `r' could be an expression) desugars to a polymorphic call to `set', with normal type inference and instance resolution: f2 r = set (undefined :: Proxy_customer_id) 27 r infer f2 :: r { customer_id :: Num a => a } => r -> r' (The Num a should get refined to Int.)

Should get/set have a proxy argument? Like SPJ, I've no strong preference: whatever works. My definition uses proxies (phantoms), because I was working in GHC 7.2.1 without 7.4.1's new PolyKinds. I quickly experimented with avoiding a proxy, but type inference wouldn't play. The end-programmer won't be defining instances, so this could be 'implementation dependent'.

Syntactic sugar for `Has', and eliding multiple constraints for the same record. SPJ is absolutely spot-on. Looks very intuitive. I slipped in an example just above.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

...

Simon Peyton-Jones writes:

...

No! no! no! For records _don't_ put records in nested/sub-modules, and

_don't_ require them in separate modules (as currently). Here's how ...

I've put up my proposal for namespacein Records/fields in Haskell, as an extra page linked from the Wiki. http://hackage.haskell.org/trac/ghc/wiki/Records Apologies for the rough-as-guts editting. AntC

[There may be other reasons for nested/sub-modules, but records ain't it.]

The reason was hinted at way back in Chris Done's attachment to the original Records wiki http://hackage.haskell.org/trac/ghc/wiki/Records "types in a non- trivial project".

Let's say I have a database application with a field (meaning type) customer_id. Then it appears in records for name and address, pricing, order entry, etc. This is not a name 'clash', it's 'intended sharing'. (It really galls me to even put it that way for explanatory purposes. Really it's the **same** customer_id.)

The Frege author does not have a ghc mail list account but gave a more detailed explanation of how he goes about TDNR for records and how often it type checks without annotation in practice. A more general explanation is here: http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leaders... He sent a specific response to Simon's mail list message, quoted below: Simon Peyton-Jones is absolutely correct when he notes: Well the most obvious issue is this. 3.2 says e.m = (T.m e) if the expression e has type t and the type constructor of t is T and there exists a function T.m But that innocent-looking statement begs the *entire* question! How do we know if "e has type t? The way it is done in Frege is such that, if you have a function that uses or updates (nondestructively, of course) a "record" then at least the type constructor of that record has to be known. This is no different than doing it explicitly with case constructs, etc., just here you learn the types from the constructors you write in the patterns. Hence, it is not so that one can write a function that updates field f to 42 for any record that contains a field f: foo x = x.{f=42} -- type annotation required for foo or x In practice this means you'll have to write a type annotation here and there. Often, the field access is not the only one that happens to some variable of record type, or the record is the result of another function application. In such cases, the type is known. I estimate that in 2/3 of all cases one does not need to write (T.e x) in sparsely type annotated code, despite the fact that the frege type checker has a left to right bias and does not yet attempt to find the type of x in the code that "follows" the x.e construct (after let unrolling etc.) I think one could do better and guarantee that, if the type of x is inferrable at all, then so will be x.e (Still, it must be more than just a type variable.) On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber wrote:

On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones

...

wrote:

...

Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start by using Frege's document as the proposal. We can start a new wiki page as discussions are needed.****

** **

If it’s a serious proposal, it needs a page to specify the design. Currently all we have is a paragraph on http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name spacing”.****

** **

As previously stated on this thread, the Frege user manual is available here:****

http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf****

see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields)****

** **

To all those concerned about Records: look at the Frege implementation and poke holes in it. ****

** **

Well the most obvious issue is this. 3.2 says ****

*e*.*m *= (*T*.*m e*) if the expression *e *has type *t *and the type constructor****

of *t *is *T *and there exists a function *T*.*m*

But that innocent-looking statement begs the **entire** question! How do we know if “e has type t? This is the route ML takes for arithmetic operators: + means integer plus if the argument is of type Int, float plus if the argument is of type Float, and so on.

****

...

** **

Haskell type classes were specifically designed to address this situation. And if you apply type classes to the record situation, I think you end up with****

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

More specifically I think of this as TDNR, which instead of the focus of the wiki page of maintaining backwards compatibility and de-surgaring to polymorphic constraints. I had hoped that there were different ideas or at least more flexibility possible for the TDNR implementation.

...

****

** **

Well, so maybe we can give up on that. Imagine Frege without the above abbreviation. The basic idea is that field names are rendered unique by pre-pending the module name. As I understand it, to record selection one would then be forced to write (T.m e), to select the ‘m’ field. That is the, qualification with T is compulsory. The trouble with this is that it’s **already** possible; simply define suitably named fields****

data T = MkE { t_m :: Int, t_n :: Bool }****

Here I have prefixed with a (lower case version of) the type name. So we don’t seem to be much further ahead.****

** **

Maybe one could make it optional if there is no ambiguity, much like Haskell’s existing qualified names. But there is considerable ambiguity about whether T.m means ****

m imported from module T****

or****

the m record selector of data type T

If there is ambiguity, we expect the T to be a module. So you would need to refer to Record T's module: OtherModule.T.n or T.T.n Alternatively these conflicts could be compilation errors. Either way programmers are expected to structure their programs to avoid conflicting names, no different then they do now.

****

...

** **

Perhaps one could make it work out. But before we can talk about it we need to see a design. Which takes us back to the question of leadership.* ***

I am trying to provide as much leadership on this issue as I am capable of. Your critique is very useful in that effort.

At this point the Frege proposal without TDNR seems to be a small step forward. We can now define records with clashing fields in the same module. However, without TDNR we don't have convenient access to those fields. I am contacting the Frege author to see if we can get any more insights on implementation details.

...

Simon****

** **

** **

We only want critiques about****

* achieving name-spacing right now****

* implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation now, just possibly modify things slightly.****

** **

Greg Weber****

** **

On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones < simonpj@microsoft.com> wrote:****

| The lack of response, I believe, is just a lack of anyone who | can cut through all the noise and come up with some | practical way to move forward in one of the many possible | directions.****

You're right. But it is very telling that the vast majority of responses on

http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leaders... were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem. My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed.

The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone. That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either.

Usually I feel I know how to move forward, but here I don't.

Simon

****

** **

Thank you. I have a few questions/comments. "The module/record ambiguity is dealt with in Frege by preferring modules and requiring a module prefix for the record if there is ambiguity." I think I see why they do it this way (otherwise you can't refer to a module if a record by the same name is in scope), but on the other hand it would seem intuitive to me to choose the more specific thing, and a record feels more specific than a module. Maybe you could go that way and just not give your qualified imports the same name as a record? (Unqualified imports are in practice going to be hierarchical, and no one's in the habit of typing those out to disambiguate things, so I don't think it really matters if qualified records shadow them.) "Expressions of the form x.n: first infer the type of x. If this is just an unbound type variable (i.e. the type is unknown yet), then check if n is an overloaded name (i.e. a class operation). [...] Under no circumstances, however, will the notation x.n contribute in any way in inferring the type of x, except for the case when n is a class operation, where an appropriate class constraint is generated." Is this just a simple translation from x.n to n x? What's the rationale for allowing the x.n syntax for, in addition to record fields, class methods specifically, but no other functions? Later on you write that the names of record fields are only accessible from the record's namespace and via record syntax, but not from the global scope. For Haskell I think it would make sense to reverse this decision. On the one hand, it would keep backwards compatibility; on the other hand, Haskell code is already written to avoid name clashes between record fields, so it wouldn't introduce new problems. Large gain, little pain. You could use the global-namespace function as you do now, at the risk of ambiguity, or you could use the new record syntax and avoid it. (If you were to also allow x.n syntax for arbitrary functions, this could lead to ambiguity again... you could solve it by preferring a record field belonging to the inferred type over a function if both are available, but (at least in my current state of ignorance) I would prefer to just not allow x.n for anything other than record fields.) Later on: "- the function that updates field x of data type T is T.{x=} - the function that sets field x in a T to 42 is T.{x=42} - If a::T then a.{x=} and a.{x=42} are valid" I think this looks considerably ugly. Aren't there better alternatives? { T.x = }, { T.x = 42 }, { a.x = }, { a.x = 42 } maybe? (Does this conflict in some unfinesseable way with explicit layout contexts?) "the function that changes field x of a T by applying some function to it is T.{x <-}" Same comment on syntax applies. I believe this is a new feature? It would be welcome, albeit the overloading of <- is a bit worrisome (don't have better ideas at the moment, but I think there was a thread). I assume T.{x <- f}, a.{x <-}, and a.{x <- f} (whatever the syntax is) would also be valid, by analogy to the above? Re: Compatibility with existing records: based on (very) cursory inspection I don't see an obstacle to making it (near-)fully compatible - you would just be adding some new syntax, most significantly x.n. Backwards compatibility is a great advantage, so why not? Generalizing the syntax to arbitrary TDNR: I think I'm opposed to this. The problem is that in existing Haskell the vast majority of expressions (with the notable (and imho unfortunate) exception of (>>=)) flow from right to left. Going the other way with record fields isn't a big problem because it's simple and doesn't even feel like function application so much as member-selection (like modules), but if you were to allow any function you would soon end up with lengthy chains of them which would clash nastily with the surrounding code. Having to jump back and forth and switch directions while reading is unpleasant. OO languages have this problem and I don't envy them for it. And in particular having "a . b" mean "first do b, then do a", but "a.b" mean "do b to a" would be confusing. (You'd already have this problem with global namespace record field selectors, but at least it's localized.) All of that said, maybe having TDNR with bad syntax is preferable to not having TDNR at all. Can't it be extended to the existing syntax (of function application)? Or least some better one, which is ideally right-to-left? I don't really know the technical details... Generalized data-namespaces: Also think I'm opposed. This would import the problem from OO languages where functions written by the module (class) author get to have a distinguished syntax (be inside the namespace) over functions by anyone else (which don't). Another thing that would be nice is lenses to solve the nested-record-update problem - at least the room to add them later. Most of the proposed syntax would be unaffected, but you'd need some syntax for the lens itself... I'm not sure what it might be. Would it be terrible to have T.x refer to a lens rather than a getter? (I don't know how you'd refer to the getter then, so probably yeah.) Or maybe { T.x }, building backwards from { T.x = }? Another existing language very similar to Haskell whose record system might be worth evaluating is Disciple: http://disciple.ouroborus.net/. Unfortunately I couldn't find any specific page it seemed best to link to. On Sun, Jan 8, 2012 at 2:40 AM, Greg Weber wrote:

I have updated the wiki - the entry level page [1] compares the different proposals and points to a more fleshed out explanation of the Frege proposal [2].

I think I now understand the differences between the existing proposals and am able to provide leadership to move this forward. Let me summarize the state of things: There is a debate over extensible records that we are putting off into the future. Instead we have 2 proposals to make things better right now: * an overloaded record fields proposal that still has implementation concerns * a name-spacing & simple type resolution proposal that is awaiting your critique

The Frege language originally had overloaded record fields but then moved to the latter system. The existing experience of the Frege language is very fortunate for us as we now have some experience to help inform our own decision.

Greg Weber

[1] http://hackage.haskell.org/trac/ghc/wiki/Records [2] http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing

On Wed, Jan 4, 2012 at 7:54 AM, Greg Weber wrote:

...

The Frege author does not have a ghc mail list account but gave a more detailed explanation of how he goes about TDNR for records and how often it type checks without annotation in practice.

A more general explanation is here:

http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leaders...

He sent a specific response to Simon's mail list message, quoted below:

Simon Peyton-Jones is absolutely correct when he notes:

Well the most obvious issue is this. 3.2 says e.m = (T.m e) if the expression e has type t and the type constructor of t is T and there exists a function T.m But that innocent-looking statement begs the *entire* question! How do we know if "e has type t?

The way it is done in Frege is such that, if you have a function that uses or updates (nondestructively, of course) a "record" then at least the type constructor of that record has to be known. This is no different than doing it explicitly with case constructs, etc., just here you learn the types from the constructors you write in the patterns.

Hence, it is not so that one can write a function that updates field f to 42 for any record that contains a field f:

foo x = x.{f=42}    -- type annotation required for foo or x

In practice this means you'll have to write a type annotation here and there. Often, the field access is not the only one that happens to some variable of record type, or the record is the result of another function application. In such cases, the type is known. I estimate that in 2/3 of all cases one does not need to write (T.e x) in sparsely type annotated code, despite the fact that the frege type checker has a left to right bias and does not yet attempt to find the type of x in the code that "follows" the x.e construct (after let unrolling etc.) I think one could do better and guarantee that, if the type of x is inferrable at all, then so will be x.e (Still, it must be more than just a type variable.)

On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber wrote:

...

On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones wrote:

...

Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start by using Frege's document as the proposal. We can start a new wiki page as discussions are needed.

If it’s a serious proposal, it needs a page to specify the design. Currently all we have is a paragraph on http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name spacing”.

As previously stated on this thread, the Frege user manual is available here:

http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf

see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields)

To all those concerned about Records: look at the Frege implementation and poke holes in it.

Well the most obvious issue is this.  3.2 says

e.m = (T.m e) if the expression e has type t and the type constructor

of t is T and there exists a function T.m

But that innocent-looking statement begs the *entire* question!  How do we know if “e has type t?   This is the route ML takes for arithmetic operators: + means integer plus if the argument is of type Int, float plus if the argument is of type Float, and so on.

Haskell type classes were specifically designed to address this situation. And if you apply type classes to the record situation, I think you end up with

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

More specifically I think of this as TDNR, which instead of the focus of the wiki page of maintaining backwards compatibility and de-surgaring to polymorphic constraints. I had hoped that there were different ideas or at least more flexibility possible for the TDNR implementation.

...

Well, so maybe we can give up on that.  Imagine Frege without the above abbreviation.  The basic idea is that field names are rendered unique by pre-pending the module name.  As I understand it, to record selection one would then be forced to write (T.m e), to select the ‘m’ field.  That is the, qualification with T is compulsory.   The trouble with this is that it’s *already* possible; simply define suitably named fields

  data T = MkE { t_m :: Int, t_n :: Bool }

Here I have prefixed with a (lower case version of) the type name.  So we don’t seem to be much further ahead.

Maybe one could make it optional if there is no ambiguity, much like Haskell’s existing qualified names.  But there is considerable ambiguity about whether T.m means

  m imported from module T

or

  the m record selector of data type T

If there is ambiguity, we expect the T to be a module. So you would need to refer to Record T's module: OtherModule.T.n or T.T.n Alternatively these conflicts could be compilation errors. Either way programmers are expected to structure their programs to avoid conflicting names, no different then they do now.

...

Perhaps one could make it work out.  But before we can talk about it we need to see a design. Which takes us back to the question of leadership.

I am trying to provide as much leadership on this issue as I am capable of. Your critique is very useful in that effort.

At this point the Frege proposal without TDNR seems to be a small step forward. We can now define records with clashing fields in the same module. However, without TDNR we don't have convenient access to those fields. I am contacting the Frege author to see if we can get any more insights on implementation details.

...

Simon

We only want critiques about

* achieving name-spacing right now

* implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation now, just possibly modify things slightly.

Greg Weber

On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones wrote:

| The lack of response, I believe, is just a lack of anyone who | can cut through all the noise and come up with some | practical way to move forward in one of the many possible | directions.

You're right.  But it is very telling that the vast majority of responses on

 http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leaders... were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem.  My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed.

The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone.  That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either.

Usually I feel I know how to move forward, but here I don't.

Simon

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Work is punishment for failing to procrastinate effectively.

Thanks to Greg for leading the records debate. I apologise that I don't have enough bandwidth to make more than an occasional contribution. Greg's new wiki page, and the discussion so far has clarified my thinking, and this message tries to express that new clarity. I put a conclusion at the end. Simon Overview ~~~~~~~~ It has become clear that there are two elements to pretty much all the proposals we have on the table. Suppose we have two types, 'S' and 'T', both with a field 'f', and you want to select field 'f' from a record 'r'. Somehow you have to disambiguate which 'f' you mean. (Plan A) Disambiguate using qualified names. To select field f, say (S.f r) or (T.f r) respectively. (Plan B) Disambiguate using types. This approach usually implies dot-notation. If (r::S), then (r.f) uses the 'f' from 'S', and similarly if (r::T). Note that * The Frege-derived records proposal (FDR), uses both (A) and (B) http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing * The Simple Overloaded Record Fields (SORF) proposal uses only (B) http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields * The Type Directed Name Resolution proposal (TDNR) uses only (B) http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolutio... I know of no proposal that advocates only (A). It seems that we are agreed that we must make use of types to disambigute common cases. Complexities of (Plan B) ~~~~~~~~~~~~~~~~~~~~~~~~ Proposal (Plan B) sounds innocent enough. But I promise you, it isn't. There has ben some mention of the "left-to-right" bias of Frege type inference engine; indeed the wohle explanation of which programs are accepted and which are rejected, inherently involves an understanding of the type inference algorithm. This is a Very Bad Thing when the type inference algorithm gets complicated, and GHC's is certainly complicated. Here's an example: type family F a b data instance F Int [a] = Mk { f :: Int } g :: F Int b -> () h :: F a [Bool] -> () k x = (g x, x.f, h x) Consider type inference on k. Initially we know nothing about the type of x. * From the application (g x) we learn that x's type has shape (F Int <something>). * From the application (h x) we learn that x's type has shape (F <something else> [Bool]) * Hence x's type must be (F Int [Bool]) * And hence, using the data family we can see which field f is intended. Notice that a) Neither left to right nor right to left would suffice b) There is significant interaction with type/data families (and I can give you more examples with classes and GADTs) c) In passing we note that it is totally unclear how (Plan A) would deal with data families This looks like a swamp. In a simple Hindley-Milner typed language you might get away with some informal heuristics, but Haskell is far too complicated. Fortunately we know exactly what to do; it is described in some detail in our paper "Modular type inference with local assumptions" http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn The trick is to *defer* all these decisions by generating *type constraints* and solving them later. We express it like this: G, r:t1 |- r.f : t2, (Has t1 "f" t2) This says that if r is in scope with type t1, then (r.f) has type t2, plus the constraint (Has t1 "f" t2), which we read as saying Type t1 must have a field "f" of type t2 We gather up all the constraints and solve them. In solving them we may figure out t1 from some *other* constraint (to the left or right, it's immaterial. That allow us to solve *this* constraint. So it's all quite simple, uniform, and beautiful. It'll fit right into GHC's type-constraint solver. But note what has happened: we have simply re-invented SORF. So the conclusion is this: the only sensible way to implement FDR is using SORF. What about overloading? ~~~~~~~~~~~~~~~~~~~~~~~ A feature of SORF is that you can write functions like this k :: Has r "f" Int => r -> Int k r = r.f + 1 Function 'k' works on any record that has a field 'f'. This may be cool, but it wasn't part of our original goal. And indeed neither FDR nor TDNR offer it. But, the Has constraints MUST exist, in full glory, in the constraint solver. The only question is whether you can *abstract* over them. Imagine having a Num class that you could not abstract over. So you could write k1 x = x + x :: Float k2 x = x + x :: Integer k3 x = x + x :: Int using the same '+' every time, which generates a Num constraint. The type signature fixes the type to Float, Integer, Int respectively, and tells you which '+' to use. And that is exactly what ML does! But Haskell doesn't. The Coolest Thing about Haskell is that you get to *abstract* over those Num constraints, so you can write k :: Num a => a -> a k x = x + x and now it works over *any* Num type. On reflection, it would be absurd not to do ths same thing for Has constraints. If we are forced to have Has constraints internally, it woudl be criminal not to abstract over them. And that is precisely what SORF is. Is (Plan A) worth it? ~~~~~~~~~~~~~~~~ Once you have (Plan B), and SORF in full glory, plus of course the existing ability to name fields T_f, S_f, if you want, I think it is highly questionable whether we need the additional complexities of (Plan A)? And I do think (Plan A) has lots of additional complexities that we have not begun to explore yet. The data-family thing above is an example, and I can think of some others. But even if it was simple, we still have to ask: does *any* additional complexity give enough payoff, if you already have SORF? I suspect not. Extensions to SORF ~~~~~~~~~~~~~~~~~~ Frege lets you add "virtual fields" to a record type, using an extra RExtension mechanism that I do not yet understand. But SORF lets you do so with no additional mechanism. See "Virtual record selectors" on http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields The point is that the existing type-class instance mechanisms do just what we want. Syntax ~~~~~~ The debate on the mailing list has moved sharply towards discussing lexical syntax. I'm not going to engage in that discussion because while it is useful to air opinions, it's very hard to get agreement. But for the record: * I don't mind having Unicode alternatives, but there must be ASCII syntax too * I think we must use ordinary dot for field selection. * I think it's fine to insist on no spaces; we are already doing this for qualified names, as someone pointed out * I think we should not introduce new syntax unless we are absolutely forced into it. Haskell's record update syntax isn't great, but we have it. Conclusion ~~~~~~~~~~ I am driven to the conclusion that SORF is the way to go. - Every other proposal on the table requires SORF (either visibly or invisibly) - When you have SORF, you don't really need anything else The blocking issues are described on http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields a) "Representation hiding" (look for that heading) b) "Record update" (ditto), most especially for records whose fields have polymorphic types If we fix these we can move forward.

On Fri, Jan 13, 2012 at 6:52 PM, Simon Peyton-Jones wrote:

[... good summary of the issues...] But note what has happened: we have simply re-invented SORF.  So the conclusion is this:

  the only sensible way to implement FDR is using SORF.

An obvious question at this point: can records have unboxed fields? I'm worried a bit about the kinds that can appear in a has constraint:

A feature of SORF is that you can write functions like this

  k :: Has r "f" Int => r -> Int   k r = r.f + 1

I'm thinking out loud about the implementation implications here. -Jan-Willem Maessen

| > But note what has happened: we have simply re-invented SORF.  So the | > conclusion is this: | > | >   the only sensible way to implement FDR is using SORF. | | An obvious question at this point: can records have unboxed fields? | I'm worried a bit about the kinds that can appear in a has constraint: Oh yes! That is indeed an important question, and one I had neglected. All of GHC's abstraction mechanisms only work over *lifted* types (which are all boxed). They don't work for unlifted types (many of which are unboxed, and vary in width). So SORF won't work at all for records with unboxed fields, such as data T = MkT { f :: Int# } But it *will* work for records with boxed fields with an UNPACK pragma data T = MKT { f :: {-# UNPACK #-} Int } I think it's probably an acceptable restriction, but we'd better be aware of it. With FDR (where you can't *abstract* over these constraints) we might be able to allow unboxed field, via some unsavoury ad-hoc cases for Has constraints. But I don't like it. I'll add this to the SORF wiki page. Simon

On Sat, Jan 14, 2012 at 13:38, Johan Tibell wrote:

On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones wrote:

...

I know of no proposal that advocates only (A). It seems that we are agreed that we must make use of types to disambiguate common cases.

I will try to make the case for (A), just so it has been put on the table.

I think the point is more that, given (b), (a) is seen to be redundant. Which I don't understand; seems to me that, in the context of (b), it's a way to easily provide more information to the type inferencer (which, given that (b) adds more complexity to the inferencer, looks like a way to control that complexity in practice) without hardcoding a type. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

2012/1/14 Johan Tibell :

On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones wrote:

...

I know of no proposal that advocates only (A).  It seems that we are agreed that we must make use of types to disambiguate common cases.

I will try to make the case for (A), just so it has been put on the table.

Proposal =========

The proposal is to implement http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing without any of the type resolution parts. I think this approach is dismissed a bit to easily on the wiki page above:

   "We have name-spaces, but it is hard to see how this is better than the current practice of adding prefixes to record fields: data Record = Record { recordA :: String }"

There are (at least) three benefits of using namespaces (e.g. 'Record.a') rather than ad-hoc prefixes (e.g. 'recordA'):

 * You can use a type synonym to abbreviate the namespace part (as shown on the wiki page.)

 * If there's no ambiguity you don't need to use a namespace (e.g. you can use 'a' instead of 'Record.a').

 * The namespace name is predictable (e.g. <Typename>.<fieldname>) while ad-hoc prefixes tend to use different conventions e.g. the whole record name (e.g. 'recordA') or some abbreviation thereof (e.g. 'rcrdA'.)

The main argument for this approach is its simplicity; it's simple to understand for users and (hopefully) simple to implement.

At work we have extended the OCaml compiler with the same mechanism, to solve the same problem. I find it quite annoying to use, as you tend to try without a namespace name first, and if you get a compile error you add one. I'd prefer a system which just infers the right selector - less time spent fighting with the compiler! David

Simon Peyton-Jones wrote:

Johan, if you are serious, do add a new wiki page to describe the design. You say it's simple, but I don't think it really is.

I'll support Johan by presenting the proposal for A below. I believe that it really is very simple, both in concept and implementation, but correct me if I am wrong. Of course, do not blame any of my errors on Johan, and do not assume that he supports this unless he says so. I'll support the consensus (so far) that B is the nicest. But if we can't get to a design for B that will actually be implemented within a reasonably short period of time, then please, let's try not to get stuck again. If this or some other design for A is indeed deemed to be simple, let's just do that if we can't do B. Perhaps we should set some time limit for B. I propose the following time limit: if a design for A has been tentatively approved and SPJ does not contribute to the discussion about B for one full month, then A automatically gets final approval and will be implemented immediately. [This has the additional advantage of giving SPJ motivation to remain engaged, because he seems to prefer B. :)] Proposal for A: Allow nested modules. A nested module can occur in any position that a data declaration can occur. The syntax of a nested module is the same as the syntax of a conventional module. A nested module must have the same hierarchical name as the module in which it is nested, followed by a single additional component. A name with a single component can be specified in the declaration of a nested module; this is syntactic sugar for the fully qualified name of the enclosing module followed by that single additional component. When a module M.A is directly nested in module M, there is an implied import in the enclosing module M as follows: import qualified M.A as A and an implied import in the nested module M.A as follows: import M These implied imports may optionally be specified explicitly with no effect, or overridden with other explicit imports, similarly to the usual implied import of Prelude. When modules are nested to a depth greater than one, similar implied imports exist for all recursively enclosing and enclosed modules, with the same rules about overriding. If an enclosing module M has an export list, a nested module N at any depth recursively cannot be imported by modules not nested inside M unless N is included in the export list of M. If M does not have an export list, N can be imported by any other module as usual. In every other respect, a nested module declaration has exactly the same effect as any other module declaration. In particular, the behavior of nested modules in the presence of all corner cases such as data families, etc., is specified by this rule. The effect of a nested module on the behavior of ghc --make is left unspecified as of now, until there is feedback from the GHC team. This would probably involve GHC looking for A.B and then A in turn when it fails to find A.B.C. Or perhaps even when A.B.C is found, to identify erroneous duplication. Or GHC could stay pretty much as it is now, relying on the user to ensure that GHC finds the nested module; that would certainly be fine for an initial implementation. Usage example: module Library where import Data.Text (Text) ... type ISBN = Text module Book where import Data.Text (Text) data T = New { name :: Text, iSBN :: ISBN } module Checkout where import Data.Time import qualified Library.Book as Book import qualified Library.Borrower as Borrower data T = New { book :: Book.T, borrower :: Borrower.T, dueDate :: Day } module Borrower where import Data.Text (Text) data T = New { name :: Text, address :: Text } module History where import qualified Library.Borrower as Borrower import qualified Library.Checkout as Checkout data T = New { borrower :: Borrower.T, checkouts :: [Checkout.T] } This makes available in the module Library the record types: Book.T, Checkout.T, Borrower.T, History.T with constructors: Book.New, Checkout.New, Borrower.New, History.New and record accessors: Book.name, Book.iSBN, Checkout.book, Checkout.borrower, Checkout.dueDate, Borrower.name, Borrower.address, History.borrower, History.checkouts I believe this specification should be very simple to implement and describe. There are some obvious shortcomings. But it does provide basic namespacing of records with almost no change to Haskell and GHC. Note also that you need to be careful to avoid mutually recursive imports. That is really more of a limitation of GHC than a limitation of the specification itself. Other compilers might not require that. I'd be happy to hear ideas about how to develop this simple idea further and eliminate some of the shortcomings, on condition that it doesn't lead to further bikeshedding and significant delay. One obvious enhancement would be for the implied import of the enclosing module to include also all names imported into the enclosing module, unlike the usual convention for imports. I'm not sure if there are complications to that though. Thanks, Yitz

By the way, thanks to Greg for driving this discussion, please keep up the good work! Simon Peyton-Jones wrote:

Can you turn your proposal into a Wiki page?

OK I'll try to get to that later today.

 It's different to Johan's.

Oh? I didn't realize that. OK, I'll look at it more closely. I'm basically just using modules the way they are, changing almost nothing. I wrote:

...

[This has the additional advantage of giving SPJ motivation to remain engaged, because he seems to prefer B. :)]

True: but that's because I think that in the end A will be deemed too clumsy, so we'll end with B anyway. And I'd rather not do both.  But I'm quite open to persuasion!

I agree that B would be great! It just seems harder, and I'm worried that we'll get stuck again. As long as we are moving forward productively towards a solution to B, I'm happy with that. I'm trying to suggest a simple, workable approach to A as a backup.

OK, so consider this:        module M where          module T where            data T = MkT { x :: Int }          module S where            data S = MkS { x :: Int } So inside M I can refer to T.x and S.x. Fine!  What does M export?

As it stands, M exports nothing. In my scheme, nested modules have almost exactly the same meaning as they would have if they were written as separate modules. So far, the only differences are: "module T" is syntactic sugar for "module M.T", and there are implied import statements added to M, T, and S. So an module external to M that wants to use T or S would need to import them explicitly in addition to the import of M. The usual rules would then apply. Based on your comments, I see that another optional enhancement to my proposal could be as follows: Whenever any module E imports M unqualified without an import list, as in: import M then the following implied imports would be added to E: import qualified M.T as T import qualified M.S as S and whenever E imports M qualified without an import list, as in: import qualified M as Q then the following implied imports would be added to E: import qualified M.T as Q.T import qualified M.S as Q.S Similarly, if M also contains more deeply nested modules and E imports M either qualified or unqualified without an import list, the corresponding implied imports of the deeply nested modules would also be added to E. But in fact, this is nothing more than a recursive application of the previous rule. Note that an import statement with an import list will never generate any automatic import of a nested module. I will add this additional enhancement to the wiki page (when I write it). Thanks, Yitz

On 01/17/2012 03:59 AM, Yitzchak Gale wrote:

and whenever E imports M qualified without an import list, as in:

import qualified M as Q

then the following implied imports would be added to E:

import qualified M.T as Q.T import qualified M.S as Q.S

Rather, those should be added whether or not M is imported qualified. For example, this is valid Haskell98: import Numeric as Flumeric main = print (Flumeric.showFloat 3.2 "") I like the spirit of this proposal. Does it have the ability yet to make packages with large APIs easier to use? e.g. http://code.haskell.org/gtk2hs/gtk/demo/graphic/Drawing.hs The long lists of import statements can get much worse. The existing remedies (e.g. re-export all the library's identifiers from one module) lose some of the benefits (to readability of code that uses the library) of having a module system. What if export lists like module M (module M.X) where import M.X perhaps... module M (module [qualified] M.X [as X]) where import M.X could trigger similar behavior in importers as nested modules could. What if in module M(....) import .X the "import .X" was sugar for "import M.X as X" (or "as" something else if you wrote an "as" clause explicitly). I think module system improvements like you propose could be a good idea (in general, rather than as a particularly good way to do records, and it shouldn't hold up the type-based records proposal ^_^). ~Isaac

Thank you Nils for those excellent links. Yitz would like Agda's module/record setup which allows for multiple modules in a single file. Records are yet another local module. The neat thing is, that like any module you can "open" it, or put it into the scope of your current module for convenient use that avoids the needs for qualifiers (see "Record opening example"). Johan, I think Agda's use of records might also be what you are getting at. On Tue, Jan 17, 2012 at 7:10 AM, Nils Anders Danielsson wrote:

On 2012-01-16 19:16, Yitzchak Gale wrote:

...

Allow nested modules. [...]

Perhaps Agda's module/record system can provide some inspiration:

 http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Modules  http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Records

(I don't think the wiki pages above are entirely complete/up to date, but for the purposes of this discussion they should do.)

-- /NAD

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Wed, Jan 18, 2012 at 9:43 AM, Johan Tibell wrote:

On Mon, Jan 16, 2012 at 2:32 AM, Simon Peyton-Jones wrote:

...

Johan, if you are serious, do add a new wiki page to describe the design.

I haven't thought trough the issues enough to describe the design just yet. At the moment I prefer to discuss a little more to gain some more clarity/insight.

Btw, definitely don't stop the presses waiting for me to find some time to think this through. If you see a clear path to implement some proposal please go ahead. I just wanted to point out we shouldn't dismiss the namespace system as a way to solve a namespacing issue (i.e. which of those two x:es did you mean)! Cheers, Johan

On Sun, Jan 15, 2012 at 01:38:20PM +0100, Greg Weber wrote:

...

The blocking issues are described on http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

a) "Representation hiding" (look for that heading)

How about http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#Scop... for resolving this? Thanks Ian

On 13/01/2012, Simon Peyton-Jones wrote:

Thanks to Greg for leading the records debate. I apologise that I don't have enough bandwidth to make more than an occasional contribution. Greg's new wiki page, and the discussion so far has clarified my thinking, and this message tries to express that new clarity. I put a conclusion at the end.

Simon

Overview ~~~~~~~~ It has become clear that there are two elements to pretty much all the proposals we have on the table. Suppose we have two types, 'S' and 'T', both with a field 'f', and you want to select field 'f' from a record 'r'. Somehow you have to disambiguate which 'f' you mean.

(Plan A) Disambiguate using qualified names. To select field f, say (S.f r) or (T.f r) respectively.

(Plan B) Disambiguate using types. This approach usually implies dot-notation. If (r::S), then (r.f) uses the 'f' from 'S', and similarly if (r::T).

Note that

* The Frege-derived records proposal (FDR), uses both (A) and (B) http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing

* The Simple Overloaded Record Fields (SORF) proposal uses only (B) http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

* The Type Directed Name Resolution proposal (TDNR) uses only (B)

http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolutio...

I know of no proposal that advocates only (A). It seems that we are agreed that we must make use of types to disambigute common cases.

Complexities of (Plan B) ~~~~~~~~~~~~~~~~~~~~~~~~ Proposal (Plan B) sounds innocent enough. But I promise you, it isn't. There has ben some mention of the "left-to-right" bias of Frege type inference engine; indeed the wohle explanation of which programs are accepted and which are rejected, inherently involves an understanding of the type inference algorithm. This is a Very Bad Thing when the type inference algorithm gets complicated, and GHC's is certainly complicated.

Here's an example:

type family F a b data instance F Int [a] = Mk { f :: Int }

g :: F Int b -> () h :: F a [Bool] -> ()

k x = (g x, x.f, h x)

Consider type inference on k. Initially we know nothing about the type of x. * From the application (g x) we learn that x's type has shape (F Int <something>). * From the application (h x) we learn that x's type has shape (F <something else> [Bool]) * Hence x's type must be (F Int [Bool]) * And hence, using the data family we can see which field f is intended.

Notice that a) Neither left to right nor right to left would suffice b) There is significant interaction with type/data families (and I can give you more examples with classes and GADTs) c) In passing we note that it is totally unclear how (Plan A) would deal with data families

This looks like a swamp. In a simple Hindley-Milner typed language you might get away with some informal heuristics, but Haskell is far too complicated.

Fortunately we know exactly what to do; it is described in some detail in our paper "Modular type inference with local assumptions" http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn

The trick is to *defer* all these decisions by generating *type constraints* and solving them later. We express it like this:

G, r:t1 |- r.f : t2, (Has t1 "f" t2)

This says that if r is in scope with type t1, then (r.f) has type t2, plus the constraint (Has t1 "f" t2), which we read as saying

Type t1 must have a field "f" of type t2

We gather up all the constraints and solve them. In solving them we may figure out t1 from some *other* constraint (to the left or right, it's immaterial. That allow us to solve *this* constraint.

So it's all quite simple, uniform, and beautiful. It'll fit right into GHC's type-constraint solver.

But note what has happened: we have simply re-invented SORF. So the conclusion is this:

the only sensible way to implement FDR is using SORF.

What about overloading? ~~~~~~~~~~~~~~~~~~~~~~~ A feature of SORF is that you can write functions like this

k :: Has r "f" Int => r -> Int k r = r.f + 1

Function 'k' works on any record that has a field 'f'. This may be cool, but it wasn't part of our original goal. And indeed neither FDR nor TDNR offer it.

But, the Has constraints MUST exist, in full glory, in the constraint solver. The only question is whether you can *abstract* over them. Imagine having a Num class that you could not abstract over. So you could write

k1 x = x + x :: Float k2 x = x + x :: Integer k3 x = x + x :: Int

using the same '+' every time, which generates a Num constraint. The type signature fixes the type to Float, Integer, Int respectively, and tells you which '+' to use. And that is exactly what ML does!

But Haskell doesn't. The Coolest Thing about Haskell is that you get to *abstract* over those Num constraints, so you can write

k :: Num a => a -> a k x = x + x

and now it works over *any* Num type.

On reflection, it would be absurd not to do ths same thing for Has constraints. If we are forced to have Has constraints internally, it woudl be criminal not to abstract over them. And that is precisely what SORF is.

Is (Plan A) worth it? ~~~~~~~~~~~~~~~~

Once you have (Plan B), and SORF in full glory, plus of course the existing ability to name fields T_f, S_f, if you want, I think it is highly questionable whether we need the additional complexities of (Plan A)?

And I do think (Plan A) has lots of additional complexities that we have not begun to explore yet. The data-family thing above is an example, and I can think of some others.

But even if it was simple, we still have to ask: does *any* additional complexity give enough payoff, if you already have SORF? I suspect not.

Extensions to SORF ~~~~~~~~~~~~~~~~~~ Frege lets you add "virtual fields" to a record type, using an extra RExtension mechanism that I do not yet understand. But SORF lets you do so with no additional mechanism. See "Virtual record selectors" on http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields The point is that the existing type-class instance mechanisms do just what we want.

Syntax ~~~~~~ The debate on the mailing list has moved sharply towards discussing lexical syntax. I'm not going to engage in that discussion because while it is useful to air opinions, it's very hard to get agreement. But for the record:

* I don't mind having Unicode alternatives, but there must be ASCII syntax too

* I think we must use ordinary dot for field selection.

* I think it's fine to insist on no spaces; we are already doing this for qualified names, as someone pointed out

* I think we should not introduce new syntax unless we are absolutely forced into it. Haskell's record update syntax isn't great, but we have it.

Conclusion ~~~~~~~~~~ I am driven to the conclusion that SORF is the way to go. - Every other proposal on the table requires SORF (either visibly or invisibly) - When you have SORF, you don't really need anything else

The blocking issues are described on http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

a) "Representation hiding" (look for that heading)

b) "Record update" (ditto), most especially for records whose fields have polymorphic types

I posted to the wiki a possible solution to (b): http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#Alte...

If we fix these we can move forward.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hi, One could also argue that a good email client should automatically hide long quotes. In fact, I guess many people are not even aware of the problem because their client does this. Cheers, Pedro On Thu, Jan 19, 2012 at 11:14, Malcolm Wallace wrote:

Sorry to pick on your post in particular Matthew, but I have been seeing a lot of this on the Haskell lists lately.

I find it completely unreasonable for a reply to a very long post to quote the entire text, only to add a single line at the bottom (or worse, embedded in the middle somewhere). In this case, there are 7 pages of quotation before your one-sentence contribution. (That is on my laptop. I dread to think how many pages it represents on a smartphone screen...) Usually, if I need to scroll even to the second page-worth of quotation and have still not found any new text, I now just delete the post without reading it.

It is a failure to communicate well, on the part of the writer who values their own time more highly than that of their intended readers. Even the much-maligned top-posting style, as forced upon Outlook users (and as I am doing right here), is preferable to the failure to trim, or to get to the point quickly. My inbox has >1600 unread messages in it, and life is just too short. So I offer this plea as a constructive social suggestion - if you want your ideas to reach their intended audience, don't annoy them before they have even seen what you want to say.

Regards, Malcolm

On 15 Jan 2012, at 20:33, Matthew Farkas-Dyck wrote:

...

On 13/01/2012, Simon Peyton-Jones wrote:

...

Thanks to Greg for leading the records debate. I apologise that I don't have enough bandwidth to make more than an occasional contribution. Greg's new wiki page, and the discussion so far has clarified my thinking, and this message tries to express that new clarity. I put a conclusion at the end.

Simon

Overview ~~~~~~~~ It has become clear that there are two elements to pretty much all the proposals we have on the table. Suppose we have two types, 'S' and 'T', both with a field 'f', and you want to select field 'f' from a record 'r'. Somehow you have to disambiguate which 'f' you mean.

(Plan A) Disambiguate using qualified names. To select field f, say (S.f r) or (T.f r) respectively.

(Plan B) Disambiguate using types. This approach usually implies dot-notation. If (r::S), then (r.f) uses the 'f' from 'S', and similarly if (r::T).

Note that

* The Frege-derived records proposal (FDR), uses both (A) and (B) http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing

* The Simple Overloaded Record Fields (SORF) proposal uses only (B)

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

...

* The Type Directed Name Resolution proposal (TDNR) uses only (B)

http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolutio...

...

I know of no proposal that advocates only (A). It seems that we are

agreed

...

that we must make use of types to disambigute common cases.

Complexities of (Plan B) ~~~~~~~~~~~~~~~~~~~~~~~~ Proposal (Plan B) sounds innocent enough. But I promise you, it isn't. There has ben some mention of the "left-to-right" bias of Frege type inference engine; indeed the wohle explanation of which programs are accepted and which are rejected, inherently involves an understanding of the type inference algorithm. This is a Very Bad Thing when the type inference algorithm gets complicated, and GHC's is certainly complicated.

Here's an example:

type family F a b data instance F Int [a] = Mk { f :: Int }

g :: F Int b -> () h :: F a [Bool] -> ()

k x = (g x, x.f, h x)

Consider type inference on k. Initially we know nothing about the type of x. * From the application (g x) we learn that x's type has shape (F Int <something>). * From the application (h x) we learn that x's type has shape (F <something else> [Bool]) * Hence x's type must be (F Int [Bool]) * And hence, using the data family we can see which field f is intended.

Notice that a) Neither left to right nor right to left would suffice b) There is significant interaction with type/data families (and I can give you more examples with classes and GADTs) c) In passing we note that it is totally unclear how (Plan A) would deal with data families

This looks like a swamp. In a simple Hindley-Milner typed language you might get away with some informal heuristics, but Haskell is far too complicated.

Fortunately we know exactly what to do; it is described in some detail in our paper "Modular type inference with local assumptions" http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn

The trick is to *defer* all these decisions by generating *type constraints* and solving them later. We express it like this:

G, r:t1 |- r.f : t2, (Has t1 "f" t2)

This says that if r is in scope with type t1, then (r.f) has type t2, plus the constraint (Has t1 "f" t2), which we read as saying

Type t1 must have a field "f" of type t2

We gather up all the constraints and solve them. In solving them we may figure out t1 from some *other* constraint (to the left or right, it's immaterial. That allow us to solve *this* constraint.

So it's all quite simple, uniform, and beautiful. It'll fit right into GHC's type-constraint solver.

But note what has happened: we have simply re-invented SORF. So the conclusion is this:

the only sensible way to implement FDR is using SORF.

What about overloading? ~~~~~~~~~~~~~~~~~~~~~~~ A feature of SORF is that you can write functions like this

k :: Has r "f" Int => r -> Int k r = r.f + 1

Function 'k' works on any record that has a field 'f'. This may be cool, but it wasn't part of our original goal. And indeed neither FDR nor TDNR offer it.

But, the Has constraints MUST exist, in full glory, in the constraint solver. The only question is whether you can *abstract* over them. Imagine having a Num class that you could not abstract over. So you could write

k1 x = x + x :: Float k2 x = x + x :: Integer k3 x = x + x :: Int

using the same '+' every time, which generates a Num constraint. The type signature fixes the type to Float, Integer, Int respectively, and tells you which '+' to use. And that is exactly what ML does!

But Haskell doesn't. The Coolest Thing about Haskell is that you get to *abstract* over those Num constraints, so you can write

k :: Num a => a -> a k x = x + x

and now it works over *any* Num type.

On reflection, it would be absurd not to do ths same thing for Has constraints. If we are forced to have Has constraints internally, it woudl be criminal not to abstract over them. And that is precisely what SORF is.

Is (Plan A) worth it? ~~~~~~~~~~~~~~~~

Once you have (Plan B), and SORF in full glory, plus of course the existing ability to name fields T_f, S_f, if you want, I think it is highly questionable whether we need the additional complexities of (Plan A)?

And I do think (Plan A) has lots of additional complexities that we have not begun to explore yet. The data-family thing above is an example, and I can think of some others.

But even if it was simple, we still have to ask: does *any* additional complexity give enough payoff, if you already have SORF? I suspect not.

Extensions to SORF ~~~~~~~~~~~~~~~~~~ Frege lets you add "virtual fields" to a record type, using an extra RExtension mechanism that I do not yet understand. But SORF lets you do so with no additional mechanism. See "Virtual record selectors" on http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields The point is that the existing type-class instance mechanisms do just what we want.

Syntax ~~~~~~ The debate on the mailing list has moved sharply towards discussing lexical syntax. I'm not going to engage in that discussion because while it is useful to air opinions, it's very hard to get agreement. But for the record:

* I don't mind having Unicode alternatives, but there must be ASCII syntax too

* I think we must use ordinary dot for field selection.

* I think it's fine to insist on no spaces; we are already doing this for qualified names, as someone pointed out

* I think we should not introduce new syntax unless we are absolutely forced into it. Haskell's record update syntax isn't great, but we have it.

Conclusion ~~~~~~~~~~ I am driven to the conclusion that SORF is the way to go. - Every other proposal on the table requires SORF (either visibly or invisibly) - When you have SORF, you don't really need anything else

The blocking issues are described on

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

...

a) "Representation hiding" (look for that heading)

b) "Record update" (ditto), most especially for records whose fields have polymorphic types

I posted to the wiki a possible solution to (b):

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#Alte...

...

...

If we fix these we can move forward.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On 19/01/2012, Malcolm Wallace wrote:

I find it completely unreasonable for a reply to a very long post to quote the entire text, only to add a single line at the bottom (or worse, embedded in the middle somewhere). In this case, there are 7 pages of quotation before your one-sentence contribution. (That is on my laptop. I dread to think how many pages it represents on a smartphone screen...) Usually, if I need to scroll even to the second page-worth of quotation and have still not found any new text, I now just delete the post without reading it.

Regards, Malcolm

Sorry. The reason that I have done so is that my primary mail client (GMail web) automatically folds quoted text (marked by ">" at start of line). (I'm not sure whether my secondary client (mutt) can do so.) When I first saw this message, I thought I would be slammed for top-posts (I have been guilty a few times). Anyhow, I shall keep this in mind.

On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones wrote:

But, the Has constraints MUST exist, in full glory, in the constraint solver. The only question is whether you can *abstract* over them. Imagine having a Num class that you could not abstract over. So you could write

k1 x = x + x :: Float k2 x = x + x :: Integer k3 x = x + x :: Int

using the same '+' every time, which generates a Num constraint. The type signature fixes the type to Float, Integer, Int respectively, and tells you which '+' to use. And that is exactly what ML does!

But Haskell doesn't. The Coolest Thing about Haskell is that you get to *abstract* over those Num constraints, so you can write

k :: Num a => a -> a k x = x + x

and now it works over *any* Num type.

On reflection, it would be absurd not to do ths same thing for Has constraints. If we are forced to have Has constraints internally, it woudl be criminal not to abstract over them. And that is precisely what SORF is.

So I understand that internally a Has constraint is great for resolving the type. What is the use case for having the Has abstraction externally exposed? I think there is a great temptation for this because we would have a functionality we can point to that has some kind of extensible record capability. But I believe the Has abstraction to be a form of weak-typing more so than a form of extensibility. Just because 2 records have a field with the same name, even with the same type in no way signifies they are related. Instead we need a formal contract for such a relation. We already have that in type classes, and they can already be used for this very capability in a more type-safe way. Let me give an example use case that we would be tempted to use this for: database record projections. Given a record representing a row of a database table data Row = Row { smallName :: String, largeVideo :: ByteString } We may have occasions in which we just use a subset of the database/record fields. display :: Row -> String display r = smallName r We can gain efficiency by just selecting the fields we need from the database (smallName). But now I need to re-factor all my Haskell code to have a projection of the original record with just the needed fields. I could try to make a sum type with projections, but then I need to pattern match on them. This seems like a great use case for a generic Has abstraction, but that broadens the types allowed to outside of just Record. Instead what I really need is a more specific Has abstraction. I want to write just: display :: RowSmallName r => r -> String So instead I should use type classes, but not something generic for all possible records, something for all possible Row projections. I do have to name the different Row types, and deal with re-factoring when field usage changes, but at least I have type-safety. i would like to avoid re-factoring and have the compiler to generate this constraint automatically based on what fields are required in the function. display :: RowProjection "smallName" -> String Ideally this information is propogated back to the point where I create the records. Using the Persistent library: records <- selectList [RecordSmallName .== "Bob"] [] Persistent uses Template Haskell to automatically define serializing to and from records, including the full database query projection. We could generate instances for the different available record projections automatically ahead of time. With this kind of system, we would have an amazing feature of automatic database projection for queries. But maybe this kind of system would end up with horrible error messages or have details that are very difficult to work out. My point is that Has abstractions are weak types and that likely we should be searching for something stronger or using type classes. If I am wrong then we should have convincing use cases outlined before we make this a goal of a records implementation, and still I don't see why it needs to be a blocking requirement if we are just trying to solve the basic records issue. Greg Weber

On Wed, Jan 18, 2012 at 1:09 PM, Matthew Farkas-Dyck wrote:

On 18/01/2012, Greg Weber wrote:

...

On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones wrote:

...

But, the Has constraints MUST exist, in full glory, in the constraint solver.  The only question is whether you can *abstract* over them. Imagine having a Num class that you could not abstract over. So you could write

  k1 x = x + x :: Float   k2 x = x + x :: Integer   k3 x = x + x :: Int

using the same '+' every time, which generates a Num constraint. The type signature fixes the type to Float, Integer, Int respectively, and tells you which '+' to use.  And that is exactly what ML does!

But Haskell doesn't.  The Coolest Thing about Haskell is that you get to *abstract* over those Num constraints, so you can write

 k :: Num a => a -> a  k x = x + x

and now it works over *any* Num type.

On reflection, it would be absurd not to do ths same thing for Has constraints.  If we are forced to have Has constraints internally, it woudl be criminal not to abstract over them.  And that is precisely what SORF is.

So I understand that internally a Has constraint is great for resolving the type. What is the use case for having the Has abstraction externally exposed?

I think there is a great temptation for this because we would have a functionality we can point to that has some kind of extensible record capability.

But I believe the Has abstraction to be a form of weak-typing more so than a form of extensibility. Just because 2 records have a field with the same name, even with the same type in no way signifies they are related. Instead we need a formal contract for such a relation. We already have that in type classes, and they can already be used for this very capability in a more type-safe way.

My point is that Has abstractions are weak types and that likely we should be searching for something stronger or using type classes. If I am wrong then we should have convincing use cases outlined before we make this a goal of a records implementation, and still I don't see why it needs to be a blocking requirement if we are just trying to solve the basic records issue.

Greg Weber

Has *is* a type class. It can be used and abused like any other. Record members with the same key ought to have the same semantics; the programmer must ensure this, not just call them all "x" or the like.

Weak types these are not. The selector type is well-defined. The value type is well-defined. The record type is well-defined, but of course we define a type-class to let it be polymorphic.

I think the concern is -- similarly to "duck typing" -- that unrelated modules or libraries might unintentionally choose the same name for their record fields. This doesn't seem so theoretical. That they would also choose the same -type- is less likely, but the possibility is there. (Especially for things like, say, size :: Int, or name :: String, or that sort of thing.) The way type classes solve this for functions and methods, as compared to duck typing, is that you have to explicitly declare an interface (type class) - it's not merely implied by the name and type - and for types you have to explicitly declare that they support that interface (with an instance). Classes and their methods are distinguished not just by their name, but also by the module they were defined in. So the analogous thing for records, I think, if you want to be super-safe about it, would probably be to explicitly declare the existence of a record field/selector/projector (do we have an agreed upon terminology?) -- I'm not sure whether the type would be declared for the selector or in the record... module ModuleA where selector fieldA :: Int selector fieldB :: a ...and in a potentially different module... module ModuleB where import ModuleA data SomeRecord = SomeRecord { fieldA, fieldB :: String } -- again, I have no idea where or how the types should be handled ...and in a third module... foo :: Has r fieldA (Int?) => r -> Int foo r = r.fieldA If there were more than one 'selector fieldA' declaration in scope, you would have to disambiguate them with the module name in the same way as all other things: foo :: Has r ModuleA.fieldA (Int?) => r -> Int foo r = r.(ModuleA.fieldA) I haven't thought this through and am not in any way recommending it (especially not any of the specific details); I just saw a parallel. (I *am*, however, uncomfortable with using straight-up type level strings, without consideration for any particular alternative. If nothing else they should at least be opaque symbols which can be passed around and used in the supported contexts but not manipulated as strings. String-based hackery should be left to Template Haskell, and out of the type system. I can't really express at the moment why in particular I think it would be bad, but it feels like it would be bad.)

On 18/01/2012, Simon Peyton-Jones wrote:

| > Has *is* a type class. It can be used and abused like any other. | > Record members with the same key ought to have the same semantics; the | > programmer must ensure this, not just call them all "x" or the like. | > | > Weak types these are not. The selector type is well-defined. The value | > type is well-defined. The record type is well-defined, but of course | > we define a type-class to let it be polymorphic.

I want to mention that the issue Greg raises here is tackled under "Representation hiding".

The way we currently prevent random clients of a data type from selecting its "foo" field is by hiding the record selector "foo". Similarly for its data constructors. This is Haskell's way of doing data abstraction; it may not be the best way, but it's Haskell's way.

The trouble with instance declarations is that they are *always* exported. No hiding.

Yes. This is a fault. I found a document, "Controlling the scope of instances in Haskell", by Gontijo and Camarão, whose goal is to solve this very problem. http://www.dcc.ufmg.br/~camarao/controlling-the-scope-of-instances-in-Haskel... The link seems broken, but if so, and anyone should want a copy, feel free to tell me and I shall send it. The size is 244 KB.

Under "Representation hiding" I suggest that

* If the record selector "foo" is in scope (by any name), then the corresponding Has instance is in scope too and vice versa.

That would match up with Haskell's hiding mechanisms precisely, albeit at the cost of having an ad-hoc rule for "Has" instances.

Simon

2012/1/18 Simon Peyton-Jones :

| > Has *is* a type class. It can be used and abused like any other. | > Record members with the same key ought to have the same semantics; the | > programmer must ensure this, not just call them all "x" or the like. | > | > Weak types these are not. The selector type is well-defined. The value | > type is well-defined. The record type is well-defined, but of course | > we define a type-class to let it be polymorphic.

I want to mention that the issue Greg raises here is tackled under "Representation hiding".

The way we currently prevent random clients of a data type from selecting its "foo" field is by hiding the record selector "foo". Similarly for its data constructors. This is Haskell's way of doing data abstraction; it may not be the best way, but it's Haskell's way.

The trouble with instance declarations is that they are *always* exported.  No hiding.

Under "Representation hiding" I suggest that

* If the record selector "foo" is in scope (by any name),  then the corresponding Has instance is in scope too  and vice versa.

That would match up with Haskell's hiding mechanisms precisely, albeit at the cost of having an ad-hoc rule for "Has" instances.

Simon

I am not just concerned about Has instances from modules not under my control. I am concerned there is a new implicit rule that must be explained to me and that I have no control over: that every record field in the same module with a given label must have the exact same semantics as all others with the same label. Currently we don't have this rule. Currently we have records with the essentialy the same field labels, but with prefixes so they can coexist, and they need not have the same semantics. There is an extra problem with adding this rule: it is common practice to put types that arguably should be spread across multiple modules into one (module often named Types). Some form of this must be done out of necessity in the case of circular references between types that will otherwise not resolve. By default in Yesod, we do this out of necessity for records representing database tables. We call the module Models and users are free to write functions there. Now we have to explain to them that they should not. What use case for abstraction over record fields is too burdensome to use a type class for? Lacking such a compelling use case we are adding implicit complexity that can result in weak-typing for the unwary user with no compelling benefit. The wiki page for overloaded records suggests that users are expected to write code like this for virtual selectors: instance Has Shape "area" Float where get = area This is a leaky abstraction forcing me to quote function names at the type level. I would rather not be writing this code - explaining this code to someone means delving into implementation details that I don't understand. The overloaded records proposal is vying for "extensibility" by supporting abstraction over record fields with the same name. For this dubious use case that type classes already satisfies we lose user-friendly implementation of obviously useful functionality like virtual selectors, and also explainability. There is something to be said for the fact that I can quickly comprehend explanations of module-based record systems. I have read over the Overloaded Records proposal several times now and I have the gist of it, but I am still confused on details and need another couple reads to look at all the details instead of glossing over them. So far I have found some details on record implementations in four FP languages. Every single one implements a module-like namespace for records, one after abandoning the abstraction over fields approach. There are differing good approaches to convenient access - I think that is where it is appropriate for Haskell to attempt to take a different approach.

| The starting point a new records implementation was to be pragmatic | and get something done. Simon has identified that Has constraints are | required to implement records. I think it'd be overstating it to say "required". But Has constraints do seem to be a modest way to make progress that fits with the rest of the language. | So I propose we move forward with implementing Has constraints, but do | not expose it to the user (similar to TDNR). We don't add abstraction | over fields or virtual fields or any special capabilities that would | expose the implementation. Fair enough. I call this the "ML numeric solution" in the sense that ML lets you use "+" for floating point addition and integer addition, but insists that the choice be made statically; if you write f x = x+x it'll ask which "+" you mean, so you can have f :: Int -> Int or f :: Float -> Float but not both. Haskell generalises by allow you to abstract over the constraint f :: Num a => a -> a Choosing the ML way for records constraints has the advantage of addressing the immediate problem while making as few future commitments as possible. | With this in mind, what limitations are left? are updates still a | problem, and can we solve it (for now at least) by being more | demanding of type annotations? Yes I think updates (of polymorphic fields) are still a problem. It seems like the main difficulty in your current story. Thanks for working on this. I'll await the writeup that you and Anthony Clayden are doing. Simon

Hi, Greg Wever wrote:

What is the use case for changing the type of a record field on update?

Lots. For example, I often use in the context of abstract syntax parametrised on the type of some kind of "annotation". A transformation may then take an abstract syntax tree with one type of annotation onto an abstract syntax tree with a different type of annotation. And if I opted to use named fields for my abstract syntax tree nodes, as I tend to do, polymorphic record update is exactly what I need.

This seems to make things harder on the implementer and harder on users to reason about the types in their program.

Can't comment on the former, but I don't find the latter compelling. I find it completely natural and in a well-documented program there will be enough explicit type information around to make it pretty clear what is going on.

I think it would be easier on everyone to just remove this capability

I'd say that would be very unfortunate.

or have an explicit syntax for changing the type to make it easier for both implementer (to distinguish) and user (to declare intent).

Also sounds unfortunate, and might lead to very repetitive code? I have not followed this thread close enough to be able to say for sure, but if the upshot is that code like the one I am alluding to above would need an annotation wherever there is a polymorphic record update today, then that would not be very nice. For all its flaws, the present Haskell "record" system is far from as useless as it sometimes is made out to be, and it would be a pity if the price for fixing some of those flaws were to lose something as useful as update of polymorphic record fields. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk

Thanks to Anthony for his DORF proposal, and spending time to clearly explain it on the wiki. I have looked over the main page: http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie... I have a big issue with the approach as presented - it assumes that record fields with the same name should automatically be shared. As I have stated before, to avoid circular dependencies, one is forced to declare types in a single module in Haskell that would ideally be declared in a multiple modules. Continuing the database example, I will have multiple tables with a 'name' column, but they do not have the same meaning. If I have a function: helloName person = "Hello, " ++ person.name The compiler could infer that I want to say hello to inanimate objects! Note that I am not completely against abstraction over fields, I just don't think it is the best default behavior. And the section "Modules and qualified names for records" shows that the proposal doesn't fully solve the name-spacing issue. On Sat, Feb 11, 2012 at 9:43 PM, wren ng thornton wrote:

On 2/11/12 9:47 AM, Greg Weber wrote:

...

What is the use case for changing the type of a record field on update?

I use it all the time. One may just as well ask: What is the use case for changing the type of a Maybe on update? Or what is the use case for changing only one of the types for a tuple update? Records are no different from any other polymorphic data type. We don't require special syntax for changing Maybe A to Maybe B nor for changing (A,B) to (A,C), so why should we treat records any differently?

One particular use case is for records with phantom types. For example, say I have a large record which contains both "real" data and also some memoization caches for common queries. I don't want to have to recompute the caches every time I make a small change to the data, instead I'd like to just be able to flip a type-level bit that says "now the caches are dirty". This way I can make a bunch of small changes to the main data, and then only once that is completed I will recompute the caches (because all the querying functions require that the type-level bit says "the caches are clean/up-to-date").

There are, of course, non-phantom examples as well. For instance, consider a record type for dealing with both sound and unsound versions of some kind of yucky data. For example, dealing with commandline argument handling. For the first stage of handling we just want to store the raw Strings (or [String]s, Maybe Strings,...); but then we'll want to parse those strings into ADTs and also perform some sanity checks to make sure the whole configuration is sane. One option of doing this is to have our record parametrized by the types of the fields, so we're converting from (Yuck String String ...) into (Yuck Bool (Maybe (Int,Float)) ...).

For both of these examples it would be possible to monomorphize things to have DataDirty/DataClean or YuckRaw/YuckSane. For the latter example, that's probably a better choice; but for the former example it is demonstrably inferior. And of course it is easy to construct additional examples where monomorphization is not actually feasible.

The reason to do this sort of thing as polymorphic records is so that you can simultaneously have some functions which care about the type parameters, and other functions which do not. Without type-changing updates the only way to achieve this is with some convoluted hack like defining a type class over all the monomorphic records (and duplicating all the neigh-identical record definitions), or using data families which are non-portable. Neither of those hacks says what you mean, and both require much more sophisticated type analysis than just using type-changing update for records. Type-changing update should not be removed, and rendering it into something distinct from type-unchanging record update is only coherent for phantom type uses of type changes and so cannot apply to non-phantom uses.

-- Live well, ~wren

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Thu, Feb 23, 2012 at 4:25 PM, AntC wrote:

Greg Weber writes:

...

Thanks to Anthony for his DORF proposal, and spending time to clearly explain it on the wiki.

I have a big issue with the approach as presented - it assumes that record fields with the same name should automatically be shared. As I have stated before, to avoid circular dependencies, one is forced to declare types in a single module in Haskell that would ideally be declared in a multiple modules. ...

Thanks Greg, but I'm struggling to understand what the difficulty is with sharing the same name, or why your dependencies are circular. Would you be able to post some code snippets that illustrate what's going on (or what's failing to go on)?

Or perhaps this is an experience from some application where you weren't using Haskell? Could you at least describe what was in each record type?

You can get an idea of things in the section 'Problems with using the module namespace mechanism' here: http://hackage.haskell.org/trac/ghc/wiki/Records?version=4 The attachment that Chris Done left to demonstrate his types seems to be overwritten. I will bring back his text as it seems his point does need to be driven home. A lot of Haskell projects have a separate Types module to avoid issues with circular dependencies.

...

Continuing the database example, I will have multiple tables with a 'name' column, but they do not have the same meaning.

If I have a function:

  helloName person = "Hello, " ++ person.name

The compiler could infer that I want to say hello to inanimate objects!

So the first question is: * do your fields labelled `name` all have the same type? (Perhaps all String?) * what "meaning" does a name have beyond being a String?

Your code snippet doesn't give the types, but if I guess that you intend `person` to be of type `Person`. Then you can give a signature:     helloName :: Person -> String

If person can be 'anything' then the type inferred from the bare function equation would be:     helloName :: r{ name :: String } => r -> String

So you could say hello to your cat, and your pet rock. You couldn't say hello to a pile of bricks (unless it's been given a name as an art installation in the Tate Gallery ;-)

Of course we know that we can always add type annotations to clarify things. The question is whether we want to be opt-out and have to explain people that they can end up with weakly typed code when they don't want to share fields.

...

Note that I am not completely against abstraction over fields, I just don't think it is the best default behavior.

So what is the best default behaviour, and what is the range of other behaviours you want to support?

I believe the best default is to not share fields, but instead have the programmer indicate at or outside of the record definition that they want to share fields. Basically just use type-classes how they are used now - as opt-in. But I am OK with making an especially easy way to do this with records if the current techniques for defining typeclasses are seen as to verbose.

...

And the section "Modules and qualified names for records" shows that the proposal doesn't fully solve the name-spacing issue.

I think it shows only that record field labels can run into accidental name clash in exactly the same way as everything else in Haskell (or indeed in any programming language). And that Haskell has a perfectly good way for dealing with that; and that DORF fits in with it.

Greg, please give some specific examples! I'm trying to understand, but I'm only guessing from the fragments of info you're giving.

AntC

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Actually, I looked at the SORF page again: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields There is now an 'Alternative Proposal' section that claims to solve polymorphic update. If anyone has comments on this please let us know! So my proposal would be to somehow use the SORF Alternative Proposal to allow for name-spaced records. This should be used to generate internal constraints and not be exposed to the end user and not automatically abstract over fields. This leaves all of our future options open while satisfying the narrow issue at hand. On Fri, Feb 24, 2012 at 9:27 AM, Greg Weber wrote:

I looked at the DORF implementers view http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie...

It appears that we still have no solution for record updates that change the type of a polymorphic field. I think this means we need to look to ways to solve this update issue other than just de-sugaring to typeclasses.

On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:

...

This should be used to generate internal constraints and not be exposed to the end user and not automatically abstract over fields.

Every one of your messages about records stresses your dislike for polymorphic projections, and your insistence that the Has class should be hidden from the user. I've read all of your explanations, but I'm still totally unconvinced. All your arguments about the semantics of labels are based on the way you want to use them, not on what they are. They are projection functions! Semantically, the only difference between them is the types. Polymorphism makes perfect sense and is completely natural. There is nothing "untyped" about it.

I feel you are pushing a narrow personal agenda here. I think the Has class would be useful to programmers and no harder to understand than other Haskel classes. It should not be hidden.

Barney, these kinds of statements about "personal agenda" are counterproductive. I have put in a lot of work that nobody, including yourself has been willing to do for years to push Haskell's records forward. I would appreciate respectful disagreement - I think I have earned that much. Please just stick to logical arguments. Greg Weber

Sorry for getting offended! I agree with your sentiment, which is why I thought having to write an extra word in a Record declaration to get automatic abstraction over fields was a good solution to the problem. But now I am in the position of being the lone dissenter on automatic abstraction over fields. And I am in disagreement with SPJ, and I would gladly drop this entire process and just ask him to be a benevolent dictator on the subject. So I am ok with automatic abstraction over fields. Ideally we should have a way to disable it, just as I was proposing we have a way to enable it. But perhaps having this will help force a solution to the circular references issues that makes automatic field abstraction problematic in the first place. After all, Haskell did start with barely any way to do IO. On Fri, Feb 24, 2012 at 2:26 PM, Barney Hilken wrote:

I'm sorry Greg, I didn't mean to be offensive. I just feel that all your arguments in favour of this restriction are based on one particular application of records, rather than a general notion of what records are. Obviously this application is what motivates you to do all the valuable work you have done, and I appreciate that. But people are going to use records in many different ways, and I don't think that a restriction which makes perfect sense in your application should be allowed to restrict the ways other people want to write programs.

Barney.

I share Greg's concerns about polymorphic projections. For example, given a function

sort :: Ord a => ...

we don't allow any 'a' that happens to export a operator that's spelled <= to be passed to 'sort'. We have the user explicitly create an instance and thereby defining that their <= is e.g. a strict weak ordering and thus make sense when used with 'sort'. This explicitness is useful, it communicates the contract of the function to the reader and lets us catch mistakes in a way that automatically polymorphic projections don't.

But the difference is that <= is (potentially) an arbitrary function, so we need to be careful that the instances make sense. A formally correct system would insist that all instances are (at least) reflexive and transitive. But in the case of records, we know what the instances are: they are projection functions. Every single (automatically generated) instance does exactly the same thing: it projects out one component of a record. This isn't like OO polymorphism, where "messages" are actually arbitrary functions which could do anything, the polymorphism is exactly the same as that of fst and snd.

At the very least use two different LANGUAGE pragmas so users can have one without the other.

This I can agree with. It was the way that Greg mentioned it in every single email which was starting to worry me. Barney.

On Fri, Feb 24, 2012 at 4:15 PM, Johan Tibell wrote:

Aside: It is possible to have no scalar fields in records of course. data R = C { compare :: (a -> a -> Ordering) }

Has x f has no semantic content besides type x having an f field; Ord has (at least in the programmer's mind, even if the language can't check it) meaning beyond the simple presence of a compare function. /g -- "Would you be so kind as to remove the apricots from the mashed potatoes?"

On Fri, Feb 24, 2012 at 11:40 PM, Johan Tibell wrote:

Hi Barney,

On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:

...

Every one of your messages about records stresses your dislike for polymorphic projections, and your insistence that the Has class should be hidden from the user. I've read all of your explanations, but I'm still totally unconvinced. All your arguments about the semantics of labels are based on the way you want to use them, not on what they are. They are projection functions! Semantically, the only difference between them is the types. Polymorphism makes perfect sense and is completely natural. There is nothing "untyped" about it.

I share Greg's concerns about polymorphic projections. For example, given a function

   sort :: Ord a => ...

we don't allow any 'a' that happens to export a operator that's spelled <= to be passed to 'sort'. We have the user explicitly create an instance and thereby defining that their <= is e.g. a strict weak ordering and thus make sense when used with 'sort'. This explicitness is useful, it communicates the contract of the function to the reader and lets us catch mistakes in a way that automatically polymorphic projections don't.

Automatically polymorphic projections feels like Go's structural polymorphism, C++'s templates or C's automatic numeric coercions, and I'm worried it'll lead to problems when used at scale. They're not required to solve the problem we're trying to solve, so lets hurry slowly and don't bake them in together with the namespacing problem. At the very least use two different LANGUAGE pragmas so users can have one without the other.

I agree completely. This is what I like about DORF: the D stands for "Declared", which is referring to the fact that the contracts are explicit. Record fields aren't automatically polymorphic based on their name and type, as with SORF, rather they are scoped and disambiguated in the same way as classes. My only discontentments are that it requires top-level declarations for each record field, which feels excessive, and that the polymorphism is opt-out, in other words if you declare a record with a given field and a field with that name/type is already in scope, it is automatically considered to be an instance of the same field. (Not that this is not the same as SORF, because if more than one field with the same name/type is in scope you can (and have to) use the usual explicit module qualification to disambiguate them, and you can write a new top-level field declaration to make it explicit that you're not re-using the field which was in scope.) I think both of these problems could be solved at the same time if (a) instead of requiring explicit top-level declarations for fields, declaring a record would also automatically declare its fields, as distinct from any other fields which may have been in scope, and (b) there would be some lightweight syntax you could use within record declarations to specify that you do want to re-use the record field in scope instead of declaring a new one. This has the added benefit that record declarations as currently written would continue to have the same meaning as they currently have. (For the record, I don't see any harm in also allowing explicit top-level field declarations, outside of records, it's the requirement for them which seems onerous.) So in DORF, if you want to declare a Contact record with a name, a phone number, and an address, you would write: fieldLabel name :: Text fieldLabel phoneNumber :: PhoneNumber fieldLabel address :: Address data Contact = Contact { name :: Text, phoneNumber :: PhoneNumber, address :: Address } -- it's unclear whether the type annotations would be belong in the field declarations, in the record, or in both then if you also want to keep track of people as employees, you write fieldLabel position :: Position fieldLabel salary :: Word data Employee = Employee { name :: Text, position :: Position, salary :: Word } And the name field would automatically be shared between them, and could be used polymorphically with either record. but then if you later write... data City = City { name :: Text} that would also automatically re-use the name field, but that would clearly be wrong. It could be avoided by explicitly declaring a new name field beforehand. (I suppose this aspect of the complaint might be overblown, because as you can see when want a new field you always write a fieldLabel declaration, and if you don't you're implying that you're intending to use the existing one. But it's still very verbose.) In my variant of the proposal, declaring the Contact record would look like this: data Contact = Contact { name :: Text, position :: Position, salary :: Int } This would automatically declare the name, position, and salary fields with their associated types (equivalently to the fieldLabel declarations from the previous example). Then for Employee you would write: data Employee = Employee { %name, position :: Position, salary :: Int } where the just-invented-on-the-spot-don't-attach-any-importance-to-it %name syntax would indicate that you want to re-use the name field in scope, while position and salary would be newly declared. And when you write data City = City { name :: Text } you would be declaring a new field. Just like DORF, if you wanted to declare the Employee record in a situation where you already had the name fields from both City and Contact in scope, you would write: data Employee = Employee { %Data.Contact.name, ... } using normal module qualification to disambiguate it. One thing you couldn't do (with either proposal, I think) is declare multiple fields in the same module and with the same name, but which *aren't* meant to be shared. This is just like how you can't declare two classes with the same name in the same module, either. (Some kind of independently introduced submodules feature feels like it might be the appropriate remedy here.) Please correct me if I've misunderstood or mischaracterized any aspect of DORF.

Henrik Nilsson writes:

Hi,

Just checking my understanding here as I have not followed this thread in all its details.

So, with both DORF ''', am I correct in understanding that polymorphic fields, be it universally quantified as in

Good question Henrik! It's explicitly answered in the wiki, because it's a tricky area. Briefly: - both of those varieties of poly fields are possible - both can be declared in records - both can be extracted and applied in polymorphic contexts - DORF supports updating the universally quantified, including changing the type of the field and therefore of the record. (Also there's a Quasifunctor proposal for SORF to do that.) - Neither approach supports updating the existential/higher-ranked variety. (There are all the complexities you discuss in detail. They are solved (with quite a bit of complexity behind the scenes), except for updating h-r types.) You can still use explicit data constructurs to pattern match and update h-r fields. Question for you: (you've already given an example of wanting to update a universally quant'd field and change its type) Do you want to update a h-r field? If so, what's the use case? AntC

data ARecordType a = C1 { ..., fieldX :: a, ..., fieldY :: a -> a, ... }

or existentially quantified as in:

data AnotherRecordType = forall a . C2 { ..., fieldU :: a, ..., fieldV :: a -> Int, ... }

would no longer be possible?

Note that the type variable a in both cases scope just over the constructor(s) of the data type in question. So any attempt at declaring the types of the fields outside of this context, be it explicitly with the fieldLabel notation, or implicitly as per your proposal, would not be possible. E.g.

fieldLabel fieldY :: a -> a

would presumably mean

fieldLabel fieldY :: forall a . a -> a

resulting in ARecordType becoming second-order polymorphic where the value of fieldY would *have* to be a polymorphic function, which is very different from the original definition.

Similarly, the whole point with the existentially quantification is to allow a number of fields to share some specific but arbitrary type, which again means that any attempt to type these fields outside of the context of the datatype to which they belong would result in something different.

Note that fieldU and fieldV cannot be used as projection functions due to escaped type variables, but that field selection by pattern matching is perfectly fine.

Both constructions above are very useful and, I'd argue that a design that rules them out actually is a rather poor fit for a language like Haskell.

To be completely honest, I, at least, would be much happier keeping working around the present limitations of Haskell's named fields by picking my field names carefully, than losing the above.

Or am I missing something? E.g. is the idea that sharing of fields only applies to fields of monomorphic type, i.e. whose type can be declared globally?

Best,

/Henrik

Gábor Lehel writes:

2012/2/25 Gábor Lehel :

...

Please correct me if I've misunderstood or mischaracterized any aspect of

DORF.

Okay, I did end up misunderstanding and mischaracterizing at least two aspects of DORF.

Re-reading the wiki page:

http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie...

Sorry, Gábor, but you've still mis-understood. I tried so hard to explain it clearly!

it's clear that you would not have to write fieldLabel declarations for every single field of every single record,

But yes you do have to declare every fieldLabel that's going to appear in a record decl within a module compiled under DORF. (Even if the field only appears once in one record -- sorry!) You can, though, mix records/fields from modules compiled under H98 monomorphs (providing no clash of names!)

only for the ones you wish to be shared and usable polymorphically. By default, fields of individual records would be specific to that record (monomorphic in the type of the record),

No! the record decl would (try to) generate an instance for every field of every record, then the compile would fail because there was no fieldLabel declared.

So the difference between DORF and my variant would be: ...

(You've misunderstood DORF, so got the next bit wrong.)

It wasn't clear to me before that DORF retains record-monomorphic fields, ...

(It doesn't!)

In DORF you can presumably still use a record-monomorphic field selector to help infer the concrete type of the record

Kind-of: you can declare a fieldLabel with a monomorphic type (if you want it to only appear in a single record), then it helps type inference.

... One troubling consequence of DORF -- again, if I'm understanding things correctly -- is that due to implicit field instances a module import can change the meaning of your program:

No you aren't understanding correctly, so: no, a module import can't change the meaning. (It might mean the program fails to compile, due to name clash.) I've responded to same later posts to clarify this. AntC

On Sat, Feb 25, 2012 at 3:54 PM, Barney Hilken wrote:

After more pondering, I finally think I understand what the DORFistas want. Here is an example:

You want to define records which describe people, and include (among other things) a field called "name". There might be several different record types with a name field, depending on whether the record refers to a customer, an employee, a business contact etc., but in each case "name" is the name of the person to which the record refers. You then write various functions which assume this, such as

...

      spam :: Has r "name" String => r -> String       spam r = "Dear " ++ r.name ++ "\nHave you heard..."

Now I want to define records which describe products, and I also use a field "name" in the same way, except that it is the brand name of the product. I also define functions such as

...

      offer :: Has r "name" String => r -> String       offer r = "Reduced! " ++ r.name ++ " 50% off!"

It doesn't make any sense to apply your functions to my records or vice-versa, but because we both chose the same label, the compiler allows it. Putting the code in separate modules makes no difference, since labels are global.

Exactly!

Here is a simple solution, using SORF:

The real problem is that the polymorphism of spam and offer is too general. We should each define new classes

...

      class Has r "name" String => HasPersonalName r       class Has r "name" String => HasBrandName r

and make  each of our record types an instance of this class

...

      instance HasPersonalName EmployeeRecord       instance HasPersonalName CustomerRecord       instance HasBrandName FoodRecord

then we can define functions with a more specific polymorphism

...

      spam :: HasPersonalName r => r -> String       spam r = "Dear " ++ r.name ++ "\nHave you heard..."

...

      offer :: HasBrandName r => r -> String       offer r = "Reduced! " ++ r.name ++ " 50% off!"

Now there is no danger of confusing the two uses of "name", because my records are not instances of HasPersonalName, they are instances of HasBrandName. You only use the class Has if you really want things to be polymorphic over all records, otherwise you use the more specific class.

This seems to me a much simpler approach than building the mechanism in to the language as DORF does, and it's also more general, because it isn't hard linked to the module system. Does it have any disadvantages?

I can't tell offhand whether it has any drawbacks with respect to expressiveness. It seems to be a good solution to the stated problem, so thank you for proposing it. My objection is that I'm not sure if there is ever a case where "you really want things to be polymorphic over all records". There is nothing (as far as I know) analogous to this kind of implicit name-based polymorphism anywhere in Haskell. It doesn't seem like the Haskell way to have the less safe thing as the one that's default and convenient, and to allow the programmer to layer a more-safe thing on top of it if he or she wants to. It seems more like the Haskell way to have the safer thing be the default and to require extra work if you want to do something less safe*. In this specific case, is there any actual use case for global implicitly-polymorphic-by-name record fields, where that is actually what you want, and where the DORFish way which is analogous to classes-and-instances wouldn't be appropriate? * (Now granted, if pure code versus unsafePerformIO is white versus black, then this is shade-of-gray versus slightly-darker-shade-of-gray, but the principle is the same.)

On Sat, Feb 25, 2012 at 10:09 PM, Isaac Dupree wrote:

On 02/25/2012 10:18 AM, Gábor Lehel wrote:

...

...

This seems to me a much simpler approach than building the mechanism in to the language as DORF does, and it's also more general, because it isn't hard linked to the module system. Does it have any disadvantages?

I can't tell offhand whether it has any drawbacks with respect to expressiveness. It seems to be a good solution to the stated problem, so thank you for proposing it.

My objection is that I'm not sure if there is ever a case where "you really want things to be polymorphic over all records". There is nothing (as far as I know) analogous to this kind of implicit name-based polymorphism anywhere in Haskell. [...]

True enough.  But DORF doesn't, IMHO, really solve this concern.  If you choose to use DORF, then your PersonalName and BrandNames will still be overloaded in just the way you don't want.  The only way to avoid this is a pretty arbitrary stylistic decision whether to use Haskell98-style field-name-prefixes or use new-style overloading.

Could you elaborate on this? (What's the way I don't want? What do you mean by field-name-prefixes versus new-style overloading?) With DORF I have control over which fields are polymorphic over which records, very much like how I have control over which classes are polymorphic over which types. That's what I want.

Even SORF is better than, say, C++ overloading in the sense that adding another overload in SORF cannot cause code not to compile, nor change its behaviour.

Sure.

Convince me otherwise.

Your position seems to be that unless there is some kind of grave blocking problem with SORF, then we should go with SORF. I don't really understand this. I think we should go with the best solution available. I think DORF is a better solution than SORF, so we should rather go with DORF than SORF. You've just admitted that there is no actual use case for the behaviour of SORF, as opposed to that of DORF. What am I missing?

Isaac Dupree writes:

Darn, I misinterpreted DORF. There was too much text and too many options.

Sorry! You might do better to stick to the implementor's page if you want a less 'option-laden' description. Also better to skip the speculative bits until you've got the basics clear.

Tell me if I'm correct: A. Every declaration with record syntax creates Has instances for all fields [1].

Correct

B. "Has", "get" and "set" may not be written by users (guessing due to representation-hiding fail).

Correct: I want the implementors to have design space for the mechanics behind the scenes.

C. You create functions using "fieldLabel name [...]"

Correct-ish: create both functions and a proxy types. It's really the type that drives inference, not the function.

D. which have the magical effect of, when in scope unqualified, ...

Nothing 'magical' going on: they're ordinary functions and types, with ordinary import/export/hiding. And you can use them qualified if you'd rather.

... causing data types defined with record syntax to be accessible through that particular fieldLabel function (and no other way).

The fieldLabel function behaves very similar to the H98-generated function. The difference is with DORF it's overloaded, but H98 is monomorphic. You can still access the fields as per H98 through pattern match (using the data constructor), or positionally. [Yes I know that if we were designing a 'true' polymorphic record system we'd ban positional access.]

E. (When two fieldLabels of the same name are in scope unqualified, declaring a record containing that name is an error.)

Correct. Just like having any other clash of names in scope (for example all the competing declarations of `map`). And just like those, you can use module qualifiers to resolve the clash.

F. So adding an import (for some other reason for your code) that happens to include a fieldLabel can make your records accidentally be more visible, rather than be compile-error or no-effect.

Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to access a record with a field `name` declared in module B. You'll get a 'no instance' compile fail. Same familiar rules as for any instance resolution. This is the crucial difference compared to SORF: which can't control the scope of its String Kind. (Apologies that I added a speculative discussion of whether DORF could use String Kinds. I said that if doing so would open the 'back door' to the abstraction, then I'll stick with types.)

I feel weird about record fields having an option that depends on whether something's in scope and cannot be controlled syntactically. Maybe we can fix that without making the syntax worse.

Absolutely agree. I designed DORF to correct that deficiency in SORF (as I saw it).

G. It is possible (but rather ugly) to use dot-notation when there are multiple fieldNames of the same name in scope. [2]

Yep, agree with the "ugly".

Hmm. Maybe this is Haskelly as well as convenient enough. Did I get everything right? What do you think about my concern about F?

Well done! Nearly everything. I hope I've allayed your concerns re F. AntC

[1]

http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie... /ImplementorsView

[2]

http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie... /DotPostfix#UsingDotnotationamongstqualifiednames

Oliver Batchelor writes:

Hi,

...

Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to access a record with a field `name` declared in module B. You'll get a 'no instance' compile fail. Same familiar rules as for any instance resolution.

This is the crucial difference compared to SORF: which can't control the

scope

...

of its String Kind. (Apologies that I added a speculative discussion of whether DORF could use String Kinds. I said that if doing so would open the 'back door' to the abstraction, then I'll stick with types.)

Perhaps this situation could occur though?

Module A fieldLabel name String

Module B import A -- unknowingly picking up the name label

data Foo = Foo { name :: String } -- uses the name label by accident

So there'd have to be some syntax to make sure you intend to use a label rather than accidentally use it? (Not that this is a big issue, the situation is surely minor compared to sharing unrelated labels all the time)

Oliver

Thanks Oliver, hmm ... Did module B import A unqualified? Did module B not have its own declaration of fieldLabel `name`? And presumably module B has set the option to use DORF. Then DORF is going to take it that you mean to share the `name`. (And actually I don't see much harm resulting.) Them's the rules. If there's a fieldLabel `name` in Module B, Foo will use that. If furthermore B imports A unqualified, that's a clash of fieldLabels, so compile fail. If module B is compiled with H98 style records, there's a name clash with the H98 field selector function. I think this is no worse (and no better) than business-as-usual 'accidental' usage-without-declaration matching an unknowingly imported binding. (As part of the 'minimal changes' requirement, I'm trying to avoid syntax changes to record decls.) AntC

Isaac Dupree writes:

In the meantime, I had an idea (that could work with SORF or DORF) :

data Foo = Foo { name :: String } deriving (SharedFields)

The effect is: without that "deriving", the declaration behaves just like H98.

(For super flexibility, allow to specify which fields are shared, like "deriving(SharedFields(name, etc, etc))" perhaps.)

Is it too verbose? Or too terrible that it isn't a real class (well, there's Has...)?

-Isaac

Thanks Isaac, hmm: that proposal would work against what DORF is trying to do. You're right about the `deriving` syntax currently being used for classes. The fact of re-purposing the surface syntax is really no different to introducing different syntax. Apart from that, it might work for SORF -- and fall into exactly what I don't like about SORF, which is that it sabotages the namespace/module control that applies for every other user-defined name in Haskell. What you're not getting is that DORF quite intentionally helps you hide the field names if you don't want your client to break your abstraction. So under your proposal, a malicious client could guess at the fieldnames in your abstraction, then create their own record with those fieldnames as SharedFields, and then be able to update your precious hidden record type. And guessing the fieldnames is dead easy if you've exported the field selector function, to allow read-only access -- or so you thought. Under DORF, despite the client guessing the fieldnames, they can't use them at all if you don't export them -- because they're in a sealed-off namespace, just like regular Haskell. AntC

Isaac Dupree writes:

AntC (in an unrelated reply to Ian) :

...

I prefer DORF's sticking to conventional/well-understood H98 namespacing controls.

...

I'm not sure yet that DORF's namespacing is well-understood by anyone but you.

No of course I'm not saying DORF's namespacing is well-understood. I mean: 1. H98 namespacing controls are conventional and well understood. 2. DORF uses H98 controls and only them. Re 2: Partly you'll just have to take my word for it, but mainly the implementors will have to prove it to themselves if DORF is ever going to see the light of day, so I'd be daft to claim something I didn't have good evidence for. Also there's strong corroboration: there's a prototype implementation attached to the wiki. You can download it and compile it (one module importing the other), and run it and try to break the abstractions, and demonstrate sharing the fields that are sharable. You can inspect the code to see if I've desugarred my syntax correctly, or introduced some trick. (If you see anything 'suspicious', please ask.) In fact, doing all that would be a far better use of your time (and mine) than all that verbiage and word counting. AntC

Isaac Dupree writes:

...

...

In the meantime, I had an idea (that could work with SORF or DORF) :

data Foo = Foo { name :: String } deriving (SharedFields)

The effect is: without that "deriving", the declaration behaves just like H98.

Thanks Isaac, hmm: that proposal would work against what DORF is trying to

do.

...

What you're not getting is that DORF quite intentionally helps you hide the field names if you don't want your client to break your abstraction.

So under your proposal, a malicious client could guess at the fieldnames in your abstraction, then create their own record with those fieldnames as SharedFields, and then be able to update your precious hidden record type.

Show me how a malicious client could do that. Under DORF plus my mini-proposal,

module Abstraction (AbstractData) where data AbstractData = Something { field1 :: Int, field2 :: Int } ... --break abstraction how? let's try...

module Client1 where import Abstraction data Breaker = Something { field1 :: Int } deriving (SharedFields) -- compile fails because there are no field-labels in scope

Correct that the fieldLabel is not in scope, so that compile will fail; but what price did you pay? Hint: what did you import with `Abstraction`? Answer: you did not import `field1` selector function, nor the mechanism behind it. So in module Client1 you can't access the `field1` content of a record type AbstractData. OK, that's sometimes something you want: to be able to pass around records of a specific type without allowing the client to look inside them at all. But I was talking about the more common requirement for encapsulation. I want to control access to my record type: the client can read (certain) fields, but not update them. Other fields I don't want the client to even know about. (You've achieved the last part with your Client1, for all of the fields.) (FYI: that's how wiki pages turn out so long; specifying exactly all the ins and outs at that sort of subtle detail.) AntC

Barney Hilken writes:

...

My objection is that I'm not sure if there is ever a case where "you really want things to be polymorphic over all records".

Well, I don't have a simple, really convincing example, but there are

More importantly, DORF automatically attaches one class to each label, but

certainly things I want to play with. this is often not what you want. Barney, you seem to be very confused. Added to that you're mixing up DORF with SORF. Agreed both proposals are similar, but there are crucial differences and you've completely befuddled them. In DORF (and SORF) there is only one class -- namely `Has`, with methods `get` and `set`. SORF 'attaches' one Kind for each label. (I'm not sure 'attaches' is the right word -- perhaps 'provides' is better? It's a String Kind same as the label name.) In DORF you must _declare_ a _type_ for the label. (Hence "**Declared** Overloaded Record Fields".) Since it's declared and it's a type, it has usual namespace (module) control. You can declare as many as you want, providing you respect the namespacing.

For example, if you have two fields "firstname" and "lastname" the associated classes are less useful: what you really want is

...

class (Has r "firstname" String, Has r "lastname" String) =>

HasPersonalName r

That example is a SORF declaration: it uses String Kinds. The DORF equivalent would be: class (Has r Proxy_firstname String, Has r Proxy_lastname String) => HasPersonalName r Note: familiar Haskell proxy types, _not_ new/untried String Kinds. That Proxy stuff is a mouthful, and easy to mistype. I prefer the sugar: class (r{firstname, lastname :: String} ) => ...

so that you can define

...

fullname :: HasPersonalName r => r -> String fullname r = r.firstname ++ " " ++ r.lastname

You may also want to define subclasses to express more specific conditions. In general, the compiler cannot automatically deduce what is semantically important: you need to define it yourself. The Has class is the base on which you can build.

...

My approach achieves the same as DORF (and more), but using existing language features instead of introducing new ones.

Barney.

What you say there applies to SORF, not DORF. DORF deliberately uses existing class features and familiar type instance resolution. (Because I didn't like the 'experimental' Kinds in SORF, and you couldn't control their namespace.) So what you call "My approach" is almost identical to DORF -- except that you're confusing it with SORF syntax. What you're criticising is SORF, not DORF. AntC

I'm not sure it's a good proposal, but it seems like the only way to handle this issue is to (1) introduce a new kind for semantically-oriented field names, and (2) make the Has class use that kind rather than a type-level string.

The second half of my message showed exactly how to handle the problem, using nothing more than existing Haskel features (and SORF for the record fields). The point is that the extra complexity of DORF is completely unnecessary. Barney.