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!
Yes, Greg the quasifunctor stuff has been there for some time. You seem to be confused between polymorphic fields vs type-changing update. Quasifunctor is talking about type-changing update. (Look at the example given for `data R a`: there's no polymorphic field.) DORF already has a working approach to type-changing update. I make reference to quasifunctor in the DORF proposal. Essentially, if quasifunctor can be made to work for SORF, it can also be made to work for DORF. (Because what underlies both is to use a Has class with methods get/set.) No, I don't think anybody has a satisfactory approach to updating polymorphic/higher-ranked fields. (DORF mentions one, but it's a ghastly hack. In addition to higher-ranked types, SPJ is also concerned about h-r's with constraints. I've added a very speculative piece in DORF's comparison to SORF that considers using Constraint Kinds. (It's probably piling ghastliness upon ghastliness.)
... and not automatically abstract over fields. This leaves all of our future options open while satisfying the narrow issue at hand.
What on earth do you mean by "not automatically abstract over fields"? AntC
No, I don't think anybody has a satisfactory approach to updating polymorphic/higher-ranked fields. (DORF mentions one, but it's a ghastly hack.
So are the proposals dead until this is tackled, or should SORF/DORF propose not to allow that?
What on earth do you mean by "not automatically abstract over fields"?
Abstraction over fields is the ability to write a function that works on two records with the same field label.
Greg Weber
What on earth do you mean by "not automatically abstract over fields"?
Abstraction over fields is the ability to write a function that works on two records with the same field label.
Thanks Greg, I see you've put something on the wiki about "abstract over fields". The example code doesn't seem to be right, so I'm still confused what you mean ... The example has: getA = r.a I think that should be: getA r = r.a (Otherwise how does `getA` know which record to extract the `a` from?) And you give no type signature for getA so (at a wild guess) by "abstract" you mean that `getA` extracts the `a` from any record `r` with an `a` field(?) Under SORF: r.a desugars to a call to the `get` method. Under DORF: r.a desugars to (a r), then we can eta-reduce: getA r = r.a ==> (a r) getA = a Either way, I don't see that `getA` is adding anything over plain field `a`. There _is_ a difference between DORF and SORF here. In DORF I can declare: getF f r = r.f -- works for any field of any record -- RHS desugars to (f r), so getF === ($) And can use it, for example: getF lastName cust1 getF fullName person2 I don't think you can do this is SORF (but please check with SPJ). In particular, I don't think you could call this function and pass an argument into it for the field name. That's because in SORF the dot notation is desugarred at the point it occurs (according to the wiki on SORF), and the `f` appearing on the RHS is a bound variable, not a field name as such. (In fact, I wonder if SORF would take the dot notation and try to desugar it to field "f", then either get a type failure or (by accident) extract the wrong field.) Please correct this on the wiki. AntC
On Mon, Feb 27, 2012 at 4:52 PM, AntC
And can use it, for example: getF lastName cust1 getF fullName person2
I don't think you can do this is SORF (but please check with SPJ). In particular, I don't think you could call this function and pass an argument into it for the field name.
You only need some way to write a value of a type of kind String; the section "should Get have a proxy argument" of the "SORF" wiki page discusses approaches to this problem. This example demonstrates the flexibility of the Proxy-based approach, but does not distinguish between DORF and SORF. /g P.S. Perhaps we should find record proposals that don't sound like noises my cat makes when coping with a hairball? ;) -- "Would you be so kind as to remove the apricots from the mashed potatoes?"
Greg Weber
No, I don't think anybody has a satisfactory approach to updating polymorphic/higher-ranked fields. (DORF mentions one, but it's a ghastly hack.
So are the proposals dead until this is tackled, or should SORF/DORF propose not to allow that?
That's an important question. I've asked in the DORF proposal how big is the demand to update h-r fields? Note that is something you can do currently with H98 records/fields. Is it good enough to be able to extract and use h-r fields in polymorphic contexts? (Both SORF and DORF can do that.) Is it good enough to be able to create records with h-r fields (using the data constructor)? (Both SORF and DORF can do that.) AntC
participants (4)
-
AntC -
Anthony Clayden
-
Greg Weber -
J. Garrett Morris