I looked at the DORF implementers view http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/ImplementorsView
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 Thu, Feb 23, 2012 at 5:01 PM, Greg Weber <[email protected]> wrote: > On Thu, Feb 23, 2012 at 4:25 PM, AntC <[email protected]> wrote: >> Greg Weber <greg <at> gregweber.info> 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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
