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.