On 30/01/2012 04:23, Steve Horne wrote:
AntC> Steve, I think that proposal has been rather superseeded by AntC> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields, which AntC> draws on TDNR. But SORF is best seen as an evolving design space, with precise AntC> details yet to be clarified/agreed. I've put my own variation into the ring: AntC> http://www.haskell.org/pipermail/glasgow-haskell-users/2011- AntC> December/021298.html -- which seems to have fallen into a black hole :-(
AntC> One of the aspects of TDNR that wasn't so popular was that its type-directed AntC> resolution was very similar to instance resolution, but subtly and confusingly AntC> different.
AntC> I guess we have to be very careful about the dot. It seems to be in a AntC> very 'crowded' syntax space, so if we implement the wrong way, we could end up AntC> shutting the door with the keys left inside.
AntC> (...)
All this dot syntax magic frankly frightens me. Haskell, as a pure functionnal language, requires (and allows !) a programming style that just does not mix well with object oriented practices. Stretching the syntax to have the dot feel a-bit-but-not-really like object oriented programming, mainly to have IDE autocompletion on some cases, does not make much sens. That's a benefit of my idea. Modular programming used the dot long before OOP became popular - OOP stole the dot from modular
On 28/01/2012 13:00, Paul R wrote: programming! If a record is a module, that only means that one thing can be both a module and a type (or value) at the same time. It takes little from OOP that OOP didn't already take from the more fundamental modular programming - and Haskell already has modules.
Sorry for replying to myself - I just thought I could explain this better. I'm basically asserting that a record in standard Pascal (without any of that OOP Turbo Pascal 5.5+/Delphi stuff) is a module. It doesn't matter that the only names that can be held in that module are field names - it's still a container of named items and therefore a special case of a module. In the Pascal case (like C structs), the content of the module doesn't include functions or methods or whatever, it only includes fields. And the module is only accessible via the record instances, not via the record type (there's nothing like C++ member pointers). Converting this to Haskell - well, we already use field-access functions, so why not move those to the record-instance module instead of having them pollute some existing namespace? Since naming the same thing twice (once to identify the module, once to specify the instance parameter) would be annoying, why not auto-curry that parameter? The result is still a function living in a module. And rather than lose the original function, why not move that to another scope - a module that's associated with the record type rather than the record instance? If you don't specify an instance, you can't curry that parameter - it still makes sense. There's no inheritance here, no virtual functions, no OOP features at all - just Pascal-like records adapted for immutability by supplying a field access function rather than e.g. a field offset. The function placed in the record-type module would be the exact same function we get now, just in a different scope. However, once you have the idea that a record is a module, maybe it makes sense to put some other functions in there too? As a minimal solution no, but it's nice to know there's room for future expansion. There's nothing OOP about this at all - it's really just adapting and extending what standard Pascal does. You could extend it to include OOP if you really wanted to, but the minimal solution just moves the existing Haskell access functions to another scope, and adds a pre-curried version in a further scope, associating those scopes with the record type and record instances respectively.