Activity
added Tfeature request Trac import typechecker labels
You are the first person to ask for TDNR! Generally the proposal elicited approximately zero reaction, somewhat to my surprise. Personally I like the idea very much, but it's a significant implementation task, and of course an ongoing maintenance load. So I'm only going to do it if there's a significant body of support. The more support you can drum up the better. Adding some notes about why you like it (ie how it'd help solve your problem) would help to substantiate the motivation.
Simon
I strongly dislike this idea. Using two functions of the same name creates confusion and leads to countless times of trying to figure out why an incorrect version compiles (it's using the wrong function), but a corrected one doesn't (it still contains bugs).
One of the reasons I love Haskell is that it's very clean and readable, and this proposal, if approved, would make it significantly less readable.
changed milestone to %7.2.1
Well, you can do
xs .reverse .(filter isEven) .(map double)today, without a GHC extension, by defining
x . f = f xbut most people don't.
In fact, I wonder if adding an
obj.methodstyle will be a hinderance to beginners, as it obscures what type inference can do. For example, if you are used to OO-stylemySet.insert, then it may be less clear (or more magical) that an unqualifiedemptycan be used for the empty set, with the type being inferred from the context.changed milestone to %7.6.1
For the record(!) there's been a long and convoluted thread around alternative proposals for the 'narrow namespacing issue' with Haskell 98's record system. The wiki page is here: http://hackage.haskell.org/trac/ghc/wiki/Records. (Some proposals are developments from TDNR, using more recent features in GHC.)
I agree with SPJ for raising the importance of dot notation for record access, and his observation about the thinking style this engenders of object -> access, rather than Haskell's function prefix style.
But I'm against the specifics of TDNR. In particular I think there should be only one variety of Type-Directed xxx Resolution in Haskell, and that should be the familiar class and instance mechanism. The Proposal says: "TDNR is not "overloading" in the sense of type classes". I think that'll be confusing.
H98 record selectors are functions. Record selection is therefore function application. TDNR proposes "The dynamic semantics of a.f is simply reverse application (f a)." I think dot notation should be just sugar for (reverse, tight-binding) function application, with the same semantics and the same instance resolution mechanism. http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix
(Though I'm not going to 'die in a ditch' over which specific operator we use in the sugar. Since dot is currently function composition, there have been voiciferous requests to keep it so.)
So to be able to use the same field name (that is, selector function) in multiple record types, I'd be looking to overload the function. As SPJ notes, there are already GHC extensions (
DisambiguateRecordFieldsand friends) for other use cases of same name/multiple record types.changed milestone to %7.6.2
What's the estimated difficulty of implementing TDNR? I have for a long time been interested in this language feature in particular and now I'm about to start on my master's thesis, which is about a semester of dedicated work.
What got me so interested in this feature is that you have to repeat yourself in record syntax, like
data MyRecord = MyRecord { myRecordLength :: Int, myRecordWidth :: Int}rather than justdata MyRecord = MyRecord { length :: Int, width :: Int}. I found that frustrating and I wondered why nobody else have went ahead and implemented this language feature yet. Now I found myself with one semester of time to do something like this.Is there any high-level sketch of the implementation on top of SPJ's head? Or is it still not clear which approach is best for doing type checking and name resolution at the same time?
Finally, if you think this is too difficult for a somebody who have not hacked ghc before. Would you suggest him to make a prototype in a smaller haskell compiler?
Best, Arash Rouhani rarash@student.chalmers.se
See wiki:/Records/OverloadedRecordFields/Plan. Adam is on this.
Simon
Trac metadata
Trac field Value CC gideon@accursoft.com, griba2001@gmail.com → adam.gundry@strath.ac.uk, gideon@accursoft.com, griba2001@gmail.com Replying to [ticket:4479#comment:72451 simonpj]:
"we propose no changes to dot syntax for the time being" Looks like Adam is specifically ignoring it?
Replying to [ticket:4479#comment:72461 gidyn]:
"we propose no changes to dot syntax for the time being" Looks like Adam is specific ignoring it?
I'm not ignoring TDNR so much as implementing an alternative solution to essentially the same problem, namely the desire to overload record field names. In fact, an earlier version of my proposal did suggest changing dot syntax, but quite a few people weren't keen on it, so the current plan is to leave dot alone for the time being. There is the possibility of treating dotaspostfixfunctionapplication.
I don't have anything as organised as a blog, but I'm keeping the pagethatSimonlinkedto updated with the design and implementation notes, and discussion of the proposal is happening on the glasgow-haskell-users list.
changed milestone to %7.10.1
Trac metadata
Trac field Value CC adam.gundry@strath.ac.uk, gideon@accursoft.com, griba2001@gmail.com → adam.gundry@strath.ac.uk, griba2001@gmail.com changed milestone to %8.0.1
Trac metadata
Trac field Value CC adam.gundry@strath.ac.uk, griba2001@gmail.com → adamgundry, griba2001@gmail.com @gidyn, I don't see what that proposal has to do with dot as postfix function apply (?)
This dot as ... idea is not the same as in TDNR -- despite spj's first comment 6 years ago. Dot as ... is purely syntactic sugar for function apply, with type-directed resolution as per standard class/instance semantics.
There's already too many proposals for records (and related enablers), without mixing them up.
Yes, Records/DeclaredOverloadedRecordFields/DotPostfix is orthogonal to type directed name resolution, although spj's original TDNR proposal included both.
This ticked was originally about TDNR, then wondered into DotPostfix as an add-on to ORF. As the dot notation has attracted a fair amount of controversy, and ORF only gives TDNR for records, I've brought up a proposal for TDNR over any function but without syntax changes.
Then @gidyn, anybody reading this ticket is going to get totally confused -- as I am now. (That's why I'm replying here rather than privately.) Can you change the whole subject of a ticket like that? And then change it back much later? It's bound to invalidate a large proportion of the comments.
I would have thought much better to close this ticket; open new one(s) for TDNR and dot postfix.
For the record(!) again: TDNR includes two elements:
- using dot postfix to signal 'here comes a record label'.
- using type directed name resolution for that label at that use site.
But the DORF proposal is purely to use dot postfix as syntactic sugar for function apply. Its purpose is (somewhat) incompatible with TDNR point 1, although the syntactic behaviour for dot is the same.
As far as I can see, these two subjects should never have gotten on the same ticket.
Replying to [ticket:4479#comment:121055 gidyn]:
There's a proposal for TDNR without syntax changes at SyntaxFreeTypeDirectedNameResolution.
Hmm. That really is not up to being called a 'proposal'. Contrast its hand-waving with the careful detail in the original TDNR. I've added a couple of links to a ghc-users thread and to what Adam has just delivered in 8.0 DuplicateRecordFields. I think what Adam has delivered is a reasonable stab at the TDNR idea without changing any syntax. (I've made that point several times in the discussion.) I've not seen any detailed explanation that would disagree with that. (There is comment about the full ORF Part 3 Magic type classes.)
If it was my call, and assuming this ticket 4479 is about TDNR, I would close this as fixed by DuplicateRecordFields.
gidyn, thanks for starting a new proposal. Your effort to push this along is appreciated!
I think your idea for doing TDNR without any syntax can indeed be seen as a proper generalization of
DuplicateRecordFields, which permits syntaxless TDNR in the special case of record field names.Unfortunately I tend to agree with AntC that the proposal needs more precision. We want to avoid the situation that the programs GHC accepts depend on implementation details of the type-checker. This means that we need a (possibly hypothetical) declarative specification of what the typing rules should be for ambiguous names.
Moreover, it's probably best if introducing or removing an ambiguity doesn't lead to different valid types for the same program. This implies that disambiguation should use information gleaned from the existing bidirectional typing rules, but not do additional inference. This requirement is why approaches based on deferring name resolution to the constraint solver, like ORF's magic classes, use a syntactic cue to indicate that the identifier should be treated specially.
These are tough goals to meet, and explain why the current
DuplicateRecordFieldsis quite conservative in what it will accept (see #11343 (closed)). No doubt it is possible to do something more general, but it's hard to specify, let alone implement. I think that is part of the reason that TDNR has languished over the years.[AntC already mentioned this on the wiki page, but for future reference, this mailing list thread is very relevant: https://mail.haskell.org/pipermail/glasgow-haskell-users/2016-May/026225.html]
added OverloadedRecordFields label
added Plow label
I'm going to boldly close this ticket, because things have moved on in the intervening years (with
DuplicateRecordFieldsandOverloadedLabelsimplemented, andNoFieldSelectorsandRecordDotSyntaxin progress), and I don't think there is anything clearly actionable here. Records-related features are being tracked at #18598 (closed), and we don't currently plan to implement TDNR more generally (indeed we are reducing the reliance ofDuplicateRecordFieldson TDNR).
