I don't think this works; this says that I can pass any arbitrary expression, but doesn't say how that expression is interpreted. Does this mean I can pass any expression to any function, or do we need to have a way to define that a function takes an expression?

How would we differentiate between passing the value of the expression (as we do with firstMemberExpression today) and passing the expression itself? For example, how do I differentiate between passing the value for revenue versus the expression revenue?

Hubert, Martin, Gerald and I discussed this and we think that we don't need that distinction in the URL "signature"; it's a server secret of how it evaluates this expression.The Function element is just telling the client how to call it.

We are not defining a programming language.

Correct, we don't think any consumer/client would need to know how/when the expression gets evaluated but the only 'missing' piece for generic consumers/clients would be the 'scope' in which the expression gets evaluated. In the TopN example we have in the description the value for N for exampe could have been "count() div 2" for example meaning I want the top half of the set. The N expression would be expected to execute in the scope of the collection where count would return the number of entities in that collection whereas the value expression is an expression that is executed within the scope of each and every entity in that collection. Generic query tools might/would need to know/understand this presumable. We discussed introducing an annotation for that which would effectively specify the scope, typically a type, in which the expression would be executed. Interesting remaining question though would be how to specify this for super functions that are not specifically bound to a particular type like TopN?

I don't think that leaving the scope of where the expression is evaluated up to the server works.

As Hubert says, generic query building tools, as well as generic OData URL parser libraries, can't rely on back-end specific secrets in order to understand how to build/parse the request. That's why, even for the built-in any() and all() functions, we use lambdas to have a well defined way to represent expressions that should be passed to the function as opposed to evaluated in order to pass the value in to the function.

If we wanted to implement such "super functions" we would need to do something like lambdas, including the ability to define a function signature that took a lambda of a particular type.

I'm concerned about the complexity of adding this type of functionality to this release, in a general way, and getting it right.

The implementer of the function knows the scope of the expression so the producer/server doesn't have an issue. Relaxing the definition of a Function Parameter to allow common expressions gives us all we need in that respect and the type of the parameter would even tell the consumer what type the expression would have to produce. The only thing the consumer, especially those generic once, wouldn't know is 'what' the expression is going to be evaluated against. Typically this would the type of whatever the collection it acts on is holding but it could even be something else for some very fancy functions.

We'd propose add annotations to give those generic query tools just enough information about these. Even if we introduced a special type, say expression, for those parameters the consumer would need additional information to understand the context in which this expression would be executed. Therefore we feel we wouldn't need an additional type, just he appropriate annotation(s).

Closed paren