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