[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[Steve Horne]

On 30/01/2012 04:23, Steve Horne wrote:
> On 28/01/2012 13:00, Paul R 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 
> 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.