Partial application and currying

[darrenjw]

I've updated all of the Dex examples in my logistic regression repo and FP crash course. It all went reasonably smoothly, and I generally prefer the new syntax, but it did throw up a couple of issues.
First, it turns out that I use partial application a lot. eg. I would typically do something like:

glpi = grad lpi

which now doesn't work. Obviously I can use a lambda for this:

glpi = \x. grad lpi x

But that's not quite as clean. In Scala you could partially apply a function like this with something like:

glpi = grad(lpi) _

or

glpi = grad(lpi, _)

The errors I get from Dex suggest that this might be on the roadmap? Something like this would be good.
But irrespective of this, some functions are probably better explicitly curried. eg. I would have thought that grad would be better curried by default.
Similarly, for any random functions (including the draw function in the stats library), it might make sense to always have the key curried off separately at the end of the type signature. This way the partially applied function represents the random variable that can be mapped over keys. But actually, this throws up something else I didn't quite get. I can define a random function as described. eg.

def rexp(rate: Float) -> (Key) -> Float = \k. log1p (-rand k) / -rate

I can partially apply this, and map it over keys as expected.

rexp2 = rexp 2
k = new_key 42
rexp2 k
keys = for i:(Fin 8). ixkey k i
map rexp2 keys

I can also apply it directly using parenthetical syntax

rexp(2)(k)

But I can't using the "old" syntax

rexp 2 k

since this gives an error. I expected this to work due to tight left binding. Am I misunderstanding something?

[dougalm]

Hi Darren, thanks for the feedback and for putting up with our extremely breaking changes!

Syntactic sugar for partial application

This is definitely on the roadmap. As you suggest, having a "placeholder" symbol in argument position seem like the way to go. We already use _ to mean "infer me" so what placeholder symbol should we use instead? One option is ., as in foo(x, ., y). But @, ?, *, and - also seem reasonable. Any preference?

New function application syntax

I can also apply it directly using parenthetical syntax

rexp(2)(k)
But I can't using the "old" syntax

rexp 2 k
since this gives an error. I expected this to work due to tight left binding. Am I misunderstanding something?

Yes, this is confusing. In the new syntax, f x y parses as binary application (i.e. f(x, y)) rather than as repeated left-associative unary application as it used to (i.e. (f(x))(y)). The rule is that if the left-hand side of a juxtaposition is itself an application then we extend its argument list to the right. I agree that it's a strange choice but here's the rationale:

The main reason to keep application-via-juxtaposition at all was to handle trailing continuations without having closing parens many lines down:

with_state(init) \ref.
  ...
  ...

I initially tried just adopting the convention of writing functions like with_state in the curried style. But it made them more awkward to implement and it became hard to keep track of which functions were curried and which weren't.

Meanwhile I was also trying to figure out how to handle a "pipe" operator. Unix-style pipelines are such a nice way to write programs when the main data flow is a chain. If everythig is curried we can make an ordinary infix operator like | or |> that does left-application. But with n-ary functions it gets more awkward.

But both problems go away if we're willing to treat | and $/juxtapose as part of function application syntax rather than as standalone operators. We can even make | prepend the argument to the left of the rest. This lets us adopt a convention where the most important argument goes first, which I find more natural than putting config flags first as curried fp style encourages.

So that's where I ended up. I know it's a bit complicated but it's purely syntactic, and I think it handles those three dataflow styles pretty well:

• balanced-ish tree dataflow: f(g(x,y), h(z,w))
• chained dataflow: x | some_filter(y, z) | some_other_filter(w)
• dataflow via continuation: each(xs) \x. ...

A lot of program text ends up being about routing data between functions. So function application seems like a good place to spend some of our syntactic sugar budget. That said, we now have six different ways to write function application: parens, infix ops, pipe, juxtaposition, dollar, and dot-method access. And then we have named optional args and currying syntax on top of that! Have we gone too far?

Currying some things by convetion

I totally agree with you about grad and key-accepting random functions wanting to be written curried. Those were the main two cases I encountered updating the corpus too. For the random functions, this will be solved once we have user-extensible effects, so we can write (uncurried) functions like: randn : () -> {Random} Float. If we do it right we should be able to have the best of both worlds: the convenience and safety (meaning safety against accidental key reuse) of implicitly passing PRNG keys, and the reproducibility, parallelism, and trick-enablement of splittable PRNGs. @alexreinking made a start on a user-extensible effects system and I'm hoping to pick it up again soon.

[darrenjw]

That all makes sense, thanks. I don't have a strong preference over the symbol to use in partial application, though I wonder if it would be better to avoid . as that already means something else in Dex.