Allow const keyword to prevent extra closure allocations when using pipelines with higher order functions

[micahscopes]

I've been thinking about the memory issues outlined in #221, and wondered about the possibility of adding the following syntax to let people "bake" the closures from curried/higher order functions when performance is a concern, like this:

// calls to `hof1` and `hof2` are fixed on their first invocation
x |> const hof1(P) |> const hof2(Q) |> constFunction

A bigger example using F# pipes:

import { hof1, hof2 } from 'external-library' // some higher order functions

const process = (P, Q) => x => x |> const hof1(P) |> const hof2(Q)

import { pt, transform, render } from 'another-library'

const [ P, Q ] = [ 2, 3 ]
for (let [i,j,k] of ...) {
  pt(i,j,k) |> transform |> const process(P, Q) |> render
}

[js-choi]

Hey, thanks for the good suggestion. (Context for this thread comes from #221 (comment) and #221 (comment)).

I appreciate this idea, since it tries to directly address a key disadvantage of F# pipes and PFA syntax, both which I like. Unfortunately, it would probably run into several problems.

In fact, I do kind of recall the champion group talking a long time ago about something like this before when we were trying to figure out ways to make F# pipes + PFA syntax (without Hack pipes) more optimizable. (To recap #221 (comment), performance concerns were not the only important concerns that F# and PFA syntax have encountered from TC39 representatives over the years, but they were still ones that we have to address before unsuccessfully.)

From what I recall, the main problems we figured with a “baking” syntax included:

1. The detailed, technical semantics of its non-lexical scoping were quite difficult to figure out. Do they get “hoisted” to the beginning of the current block? When are they out of scope; when do they become able to be deallocated by the garbage collector? We could not figure out satisfactory answers to these. (The non-lexical scoping also possibly broke several important assumptions that browser engines make for optimizability and for garbage collection; I don’t remember the specifics of this part.)
2. A baking syntax would have to be opt in for each step (as is proposed here). Would users of F# pipes actually use an opt-in baking syntax whenever they would call curried functions or other HOFs? It seemed even longer than using an explicit placeholder, and so an opt-in baking syntax might end up being rarely used by F#-pipe users.
3. A baking syntax would give similar functionality to assigning variables to each HOF call’s result. Both were seen as fairly tedious, but at least assigning variables does not require exotic non-lexical scoping rules.

I appreciate this idea, since it tries to directly address a key disadvantage of F# pipes and PFA syntax, both which I like. I think it is unlikely that we would pursue such an approach, which has and would continue to encounter concerns such as those I listed above. (My apologies if this answer is discouraging! We really do appreciate the suggestion.)

[tabatkins]

I believe it would be appropriate to close this issue, as it would be a significant separate proposal from the pipeline operator, and not really appropriate to pursue as part of this proposal. (Like partial-application, which while entangled with pipeline is a completely separate proposal.) Thoughts?

[js-choi]

I’m fine with closing. I think that it is not viable for the reasons I gave above (non-lexical scoping is probably difficult for both developers’ reasoning and engine implementation).

But I do appreciate the thought behind this proposal!