[Haskell-cafe] Some thoughts on Type-Directed Name Resolution
sh006d3592 at blueyonder.co.uk
Mon Jan 30 06:31:13 CET 2012
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> 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
>> 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
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.
More information about the Haskell-Cafe