> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
