On 1/02/2012, at 11:38 AM, AntC wrote:
As soon as you decide to make 'virtual record selectors' just ordinary functions (so they select but not update) , then you can see that field names are also just ordinary functions (for selection purposes). So the semantics for field 'selection' (whether or not you use dot notation) is just function application. So Type-Directed Name resolution is just instance resolution. So it all gets much easier.
Richard O'Keefe wrote: ... Making f x and x.f the same is pretty appealing, but it is imaginable that the former might require importing the name of f from a module and the latter might not. That is to say, it lets f and .f have completely different meanings. Oh the joy! Oh the improved readability! -- on some other planet, maybe.
Hi Richard, I'm not sure I understand what you're saying. I'm proposing x.f is _exactly_ f x. That is, the x.f gets desugared at an early phase in compilation. If the one needs importing some name from a module, than so does the other. A 'one-sided dot doesn't mean anything. (Also, I feel vaguely nauseous even seeing it written down.) Under my proposal, the only thing .f could mean is: \z -> z.f which desugars to \z -> f z which means (by eta-reduction) f And to complete the story: the only thing (x.) could mean is: \g -> x.g So a use like: (x.) f -- or z f, where z = (x.) would desugar to f x which is the same as x.f A use like (x.)f (no spaces around the parens) would amount to the same thing. This is all so weird I'm inclined to say that one-sided dot is probably a syntax error, and reject it. It's too dangerously ambiguous between the syntax for 'proper' dot notation and function composition. Or is there something I'm not understanding? [Good to see another NZ'er on the list, by the way.] AntC