Support more stack_ syntax

[riaqn]

This PR allows stack_ at more places:

let stack_ x = ...
let stack_ x : _ = ...
let stack_ f a b c = ...

[github-actions]

Parser Change Checklist

This PR modifies the parser. Please check that the following tests are updated:

• parsetree/source_jane_street.ml

This test should have examples of every new bit of syntax you are adding. Feel free to just check the box if your PR does not actually change the syntax (because it is refactoring the parser, say).

[riaqn]

Don't review yet - we need to support syntax currying...

let stack_ f : int -> int -> int = ... in

the stack_ keyword should influence the interpretation of int -> int -> int.

[goldfirere]

I haven’t looked at the code here, just the PR initial post… but is there a design doc for this? I’m worried we’re diluting the nice, simple meaning of stack_, which I thought was meant to apply only at an allocation site. (I could see allowing let stack_ f x y z = …, where the stack_ is meant to apply to the implicit fun. But I don’t know what it would mean for the other forms.)

[riaqn]

but is there a design doc for this?

TBF there is no documentation for stack_ in the first place, which is why it's not announced. I found this usability issue when adding stack_ documentation, which is at #3479

let stack_ x = .. is parsed as let x = stack_ (..), so all the typing rules stay the same, and everything is still nice and simple.

[lpw25]

I agree with @goldfirere: let stack_ f a b c = ... is good and worth including, the others are probably not a good idea.

[riaqn]

Discussed with Richard and agreed that let stack_ a = .. is not a good idea (because stack_ work shallowly, which is not obvious in this syntax). Will consult others for opinion on let stack_ f a b = ...