Revise terminology for classifying expressions

[1ec5]

We lack an unambiguous vocabulary for classifying expressions. The style specification says:

The expression_name is the name of a specific expression, e.g. '*' or 'case'. Each argument_i is either a literal value (a string, number, boolean, or null), or else another expression in the array form above.

The wording “a specific expression” conflates the concept of an expression (an instance of the value that a paint/layout property or filter is set to) with the subset of expressions being described. Even “expression name” implies that “expression” is the entire subset of expressions. Meanwhile, the “Get started with Mapbox GL JS expressions” guide refers to “expression types”, which risks confusion with an expression’s evaluated data type.

Making matters worse, the style specification also describes a subset of expressions as “property expressions”. This term is supposed to refer to expressions that contain references to feature properties, but you set a paint or layout property to an expression whether or not the expression refers to a feature property.

I propose the following terminology:

• expression — an instance of the value that a paint or layout property or filter is set to
• expression operator — the first part of the expression array; by metonymy, the subset of expressions that begin with a given operator
• data expression — an expression that contains the get operator somewhere within
• camera expression — an expression that contains the zoom operator somewhere within (with a nod to Rationalize and simplify the taxonomy of functions #4154)

One thing going in favor of expression operator is that filters are classified by “operators” too.

/cc @mapbox/gl @colleenmcginnis

[davidtheclark]

an instance of the value that a paint or layout property or filter is set to

@1ec5 I'm having some trouble understanding this phrase. Could you clarify a bit more?

[1ec5]

Sure: you set text-field or filter to an expression (which may contain subexpressions). That isn’t new to this proposal, but what’s new is that case is no longer considered an “expression name”; instead, it’s an operator.

[colleenmcginnis]

Meanwhile, the “Get started with Mapbox GL JS expressions” guide refers to “expression types”, which risks confusion with an expression’s evaluated data type.

I did struggle to find a neutral word to use here that would also be intuitive. I think "expression operator" is a good fit.

[stevage]

Are curve and let and concat examples of "expression operators" too? That seems a bit awkward, as they would be statements or functions in other languages.

[1ec5]

This syntax doesn’t distinguish between binary and n-ary operators. I agree that let is a bit awkward for the “operator” term if you’re already familiar with that keyword from other languages like JavaScript or Swift. “Function” could work too, but it comes with some baggage, having been applied to property functions in the pre-expression days.