Optional parentheses for 1-ary function application

[extemporalgenome]

In CUE, we have a closed builtin. #571 proposes a not builtin, and #575 proposes a must/constrain builtin.

(all of these [proposed] builtins are unary/1-ary, taking a single argument).

It's plausible that one or more of the following will occur over time:

• The CUE language will gain more builtins.
• A rich integration ecosystem may develop, such as being able to import 3rd party Go code for functions in addition to CUE definitions sourced from Go code.
• The CUE language may begin to support user-defined functions for use-cases that fit well in the language.

In such cases, we could imagine that function applications will be nested, such as:

// toy example
field: must(not(binaryFunc(field, somethingElse) < 5))

In such cases, we have the opportunity to make this read more nicely if we allow the application of unary/1-ary functions to omit parentheses and syntactically be right-associative and have precedence higher than '&' and '|', but lower than that of other operators, so the following would be equivalent to the above:

field: must not binaryFunc(field, somethingElse) < 5

Use of the closed builtin could be:

field: closed {x: int}

Arguably some unary functions should stylistically still be parenthesized even if this idea has merit, such as strings.MinRunes(5). We can infer a reasonable formatting/semantic rule, however: strings.MinRunes is really a binary function (with an implicit first argument), thus would require parentheses (since it's not semantically unary). must and not are truly unary (taking an explicit constraint as its only argument), thus may omit parentheses.

CUE feels like a language that could take a few different directions in terms of new features added and the syntactic tradeoffs that result from that. If CUE goes in the direction of more builtins (particularly unary/filtering builtins), omitted parentheses would give the language more of a fluent DSL style. Conversely, if CUE favors new operators or syntactical forms to manage indirect constraints, builtins will play a lesser role and this idea would have little benefit.

[verdverm]

RE: user defined functions / builtins discussion in #350

Query Proposal is relevant here too #165

There are more I am likely missing that would be of interest.

Cue's syntax is solidifying. The intention is to make the same guarantee about v1 as Go did, and while 1.0 is probably a ways off, @mpvl wants to get backwards incompatibilities all taken care of in 0.3.0

[mpvl]

We will probably shift this intention to getting v0.3 out sooner and more rapidly adding small backwards-incompatible changes to v0.x.0 releases, so that people can migrate small steps at a time. But either way, there are very few backwards-incompatible changes still considered, so timing wise this won't make much of a difference.

[mpvl]

not is defined differently, so in this case one should write must(binaryFunc(field, somethingElse) >= 5) but I see your point.

I'm thinking it may possibly result in too many ambiguities and complications, but I see your point.

There are a bunch of other builtins being designed in unison with must and not to clear up the meaning of (and get rid of) comparisons to _|_ (officially unsupported), make "switching" nicer, and probably to deprecate _|_ altogether in the process. It may be best to suggest it there, if it still makes sense.

[extemporalgenome]

Understood, thanks! I look forward to seeing how all those new pieces fall into place together

[cueckoo]

This discussion has been migrated to cue-lang/cue#697.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.