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