fancy-app scope

[samdphillips]

@mflatt wrote in #180 (reply in thread) :

For fancy-app — that is, using _ in place of an expression within a sufficiently simple expression to create an anonymous function — there was general agreement that it's worth supporting. More experiments are needed to see how deeply it needs to be embedded in the expansion protocol to work nicely with general operators. (While we discussed precedence a little, but I think that was a detour caused by me not understanding how _ works. The most helpful example for me was _ * 2 + 1, which does not mean fun (x): x * 2 + 1 as I expected, but means (fun (x): x * 2) + 1; the "smallest enclosing expression" rule avoids various problems.)

@plane wrote in #180 (reply in thread) :

The most helpful example for me was _ * 2 + 1, which does not mean fun (x): x * 2 + 1 as I expected, but means (fun (x): x * 2) + 1; the "smallest enclosing expression" rule avoids various problems.

The current PR (mflatt/shrubbery-rhombus-0#4) seems to have the former behavior:

val f: _ * 2 + 1
f(10)               // => 21
(_ * 2 + 1)(10)     // => 21

The latter behavior seems like it could surprise everyone else, too. How would you write fun (x): x * 2 + 1 using fancy-app in that case?

@Metaxal wrote #180 (reply in thread) :

The most helpful example for me was _ * 2 + 1, which does not mean fun (x): x * 2 + 1 as I expected,

That's what I was expecting too.

but means (fun (x): x * 2) + 1; the "smallest enclosing expression" rule avoids various problems.)

While I can imagine there are a number of gotchas otherwise, that one behaviour seems to greatly limit the utility of fancy app, as it does not seem possible to use it to obtain (fun (x): x * 2 + 1), which is in itself surprising.

One possibility is to specify the enclosing context explicitly, e.g., { _ * 2 + 1} (or whatever other brackets make sense), but that's becoming closer to using fun altogether. Alternatively, (fun: _ * 2 + 1) (note the lack of parentheses) which avoids naming arguments.

(Then again, I don't use fancy app in general, and I expect to stick with s-exp syntax in the foreseeable future anyway.)

[samdphillips]

That's what I was expecting too.

This was my expectation too. I think one reason this seems possible is that the term _ * 2 + 1 looks like a single flat thing even though it isn't.

I may be misremembering, one of the reasons that it should be (fun (x): x * 2) + 1 is that it may be easier to implement if the reach of the hole was limited. Another reason would be that it is closer to other, non s-expr, languages (Scala?) that have this feature.

[sorawee]

For the record, here's what I said earlier in the meeting.

There are two main uses of this _ * 2. One is from fancy-app. Another is from threading. Which one do people use more often?

The differences of fancy-app and threading are:

• In fancy-app, you can generate a standalone lambda. E.g., let f: _ * 2. In contrast, threading only allows _ in the right operand of the |> operator. E.g., let x: 3 |> _ * 2.
• fancy-app doesn't work well with macros. threading works well with macros.
• fancy-app supports multiple arguments. threading supports only one.
• Both fancy-app and threading are shallow: _ * 2 + 1 is essentially (fun (x): x * 2) + 1. But it would be easier to adjust threading to support (fun (x): x * 2 + 1) (doesn't look like anyone wants this feature though, so nvm about this).

[rocketnia]

Here's a message I sent on September 28 in the Racket Discord's #rhombus channel:

Scala has that kind of partial application, and these are the kinds of scenarios I'm wary of:

https://stackoverflow.com/questions/7627117/scala-underscore-error-missing-parameter-type-for-expanded-function

https://stackoverflow.com/questions/44579207/scala-partial-application-via-underscore-when-composing-function-literals

I found these by searching for them, so it's biased sample, and I'm not sure if it's as big a deal as I'm worried about.

Looking back at these examples, I'm surprised to notice that they nearly match my intuitions now.

Personally, I expect _ * 2 + 1 to work. I also expect both foo(_.bar) to mean foo(x => x.bar) and baz(foo(_.bar)) to mean baz(x => foo(x.bar)), so I don't even know anymore.

So, whatever ideas I might come up with for making this notation more well-behaved, I'll probably end up with something that causes the same confusion Scala's approach does.

Scala has the more concise notation x => ... for lambdas, compared to Rhombus's fun (x): .... If it were possible to write |> x => for threading in Rhombus, would that be concise enough? What about some dedicated sugary lambda-making brackets, like Groovy's { println it; }, Clojure's #(prn %), or Arc's [prn _]? I much prefer explicit variable declarations, even ones as concise as these special brackets, over the fancy-app approach.

Scala seems to treat _ as being scoped to the nearest fluent chain of method calls and property accesses, but I don't think that's much of a boundary. The same boundary without an _ inside does something completely different.

Oh, hey, even if you don't use => for every other kind of lambda, it could at least be the way to write _-binding lambdas. Then you wouldn't even need to write a parameter list before it, and threading could look like |> =>.

[samdphillips]

Something else I think @sorawee brought up on the PR is, does this feature need to be baked deeply into the enforestation/expansion process? Or can it (potentially) be implemented as a library feature on top of the existing machinery?

[rocketnia]

One approach is that certain syntaxes could do local expansion, then ask "does this subexpression have one or more _ free variables?" and if it does, rename those variables and insert a lambda that binds them.

It sounds like the threading |>, at least, would be one syntax that would do that.

Hm, actually, what if we wrote [1, 2, 3].map(|> _ + 1)? That is to say, if |> ... |> ... |> ... is used without a preceding expression, it turns into fun (x): x |> ... |> ... |> .... Then we could say |> is the only syntax that interacts with _ expressions, the threading examples become just as concise as people want them to be, and the scope of _ is unambiguous just the way I like.

I hope it doesn't create some terrible ambiguity in parsing. If it does, perhaps something like fun|> would be less ambiguous.

[rocketnia]

the threading examples become just as concise as people want them to be

For reference, in the meeting, when I was skeptical about fancy-app, this piece of threading code was pointed out as a particularly motivating one. That's what I mean by "the threading examples" here. :)

[jackfirth]

Another thing to mention is that we can probably at the very least make some misuses of _ emit warnings. For example, _ * 2 + 1 could emit a warning with a suggestion to rewrite it to fun (x): x * 2 + 1.