more flexible partial application
Dinko Tenev
dinko.tenev at gmail.com
Fri Jan 27 06:15:55 EST 2006
On 1/26/06, Aaron Denney <wnoise at ofb.net> wrote:
> On 2006-01-26, Dinko Tenev <dinko.tenev at gmail.com> wrote:
> > On 1/26/06, Conor McBride <ctm at cs.nott.ac.uk> wrote:
> > [...]
> >> We'd do daft stuff like
> >>
> >> (200 * _ ^ 2) unitsquare
> >
> > Yes, I played with a concept like that at one point, and came to the
> > conclusion that it was better done with lambdas. I am all
> > specifically about function application, not arbitrary expressions.
>
> Arbitrary expressions are just function application.
...arbitrarily deeply nested.
I meant looking at a single level of function application, with all
the consequences for how high up the tree the underscore may "escape"
as a lambda. You're probably going to tell me that f x y z represents
3 different levels, but many folks would see this as little more than
a cute way of writing f(x, y, z), and they'll have a point, given how
the concept of "partial" application is bandied every so often.
It is quite reasonable to identify a minimal enclosing application,
with all visible arguments consumed up to the innermost enclosing pair
of parentheses. Sure, it's not a very elegant concept, but neither is
the current mechanism for operator sections (which does exactly the
same.) The only implication will be that you won't be able to use
sections *and* emphasize the order of application at the same time,
and I am yet to hear from anyone who prefer (((f x) y) z) to (f x y z)
in their code.
BTW, it just occurred to me that if this section syntax is extended to
operators as well, it would cure the rather embarrassing case of the
"-" operator :)
> >> If you do want to pull a stunt like this, you need some other funny
> >> brackets which specifically indicate this binding power, and then you
> >> can do grouping inside them, to create larger linear abstractions. You
> >> could have something like
> >>
> >> (| f (_ * 3) _ |)
> >
> > We already have lambdas for this, and they're shorter, clearer, and
> > more powerful.
>
> The same hold (except for shorter) for this whole extension, and I don't
> know that "shorter" holds here.
I missed an underscore, so you have your point about "shorter."
About the whole extension, (f x _ z) is arguably clearer than \y -> f
x y z, and is also really unobtrusive syntactic sugar, very much
unlike a new kind of brackets.
> --
> Aaron Denney
> -><-
Cheers,
Dinko
More information about the Haskell-prime
mailing list