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

[Steve Horne]

On 30/01/2012 07:09, Donn Cave wrote:
> ((separate . crack . .smallEnd) egg).yolk
> (f egg).yolk where f = separate . crack . .smallEnd

Scary - that ".smallEnd" worries me. It's like a field is being 
referenced with some magical context from nowhere.

Obviously I need to read that full proposal.

Sorry for going on about it, but this wouldn't happen in my idea. If 
field access functions are just items in a module, the . separates the 
module identification from the item name, same as always. The only 
difference is how you identify the module. There's no special 
interactions with function composition, or whatever it is that's 
happening here. If you want to composite the function with some other 
function without knowing in advance which record value you're dealing 
with, just get the access function from the record-type module.

If I'm correctly guessing what your code means, that reads as...

(f egg).yolk where f = separate . crack . (eggModule.eggType.smallEnd)

OK, in a sense specifying "eggModule.eggType" there is a bit redundant, 
but in general that isn't true - define f separately and it needs some 
clue for the type inference to decide where to look for "smallEnd", and 
"eggtype" provides it. I'd prefer a notation that allows me to reference 
the field without needing type inference to determine which record type 
it relates to.

But then again, I'm probably just not understanding the reason behind 
that wierdness - perhaps it wouldn't seem so wierd if I did. Or maybe 
it's just a familiarity issue.

First thought - I've not addressed access from within a polymorphic 
function with type class constraints. The situation there would (without 
extra features) be the same as it is now, with no TDNR support. Field 
access functions would have to be provided as explicit operations within 
the type class.

That said, it shouldn't be hard to handle. For example, a type class can 
explicitly state which field names it is interested in, and an instance 
can provide functions to access those fields. Alternatively, the 
instance might support using arbitrary functions (of the right type). 
This might allow some wierdness (fields that aren't really fields), but 
it may allow some useful flexibility (this particular type provides the 
field "daddy", that type provides "mummy", a third type has no named 
fields but has a function that works by pattern matching that can 
provide the positionally-defined field - either way, this type class 
will refer to "parent") so that polymorphic functions can use the dot 
notation, but the relationship between fields in the type class and 
fields in the instance type are flexible. It's really just syntactic 
sugar for what type classes have to do now - providing a dot notation, 
but still using vtable references to field access functions to do the work.