any all operators

[Charles]

These are implemented and checked in. The intermediate release notes read:

Added new `all` and `any` unary operators that take something enumerable (such as a list, set or generator) and return a boolean (true or false) indicating if all or any of the elements are true. These operators increase expressiveness in conditions. For example, a contract might use these operators:

def foo(items as IList<of Item>)
    require all for item in items get item.name.trim.length > 0

The general form is:

all <enumerable> # --> bool
any <enumerable> # --> bool

These are general purpose expressions so they can be used with "if" statements, "while" statements, "assert", "print", "trace", etc.

As mentioned before, it's tempting to consider other, more expressive syntactic forms for these operators as seen below, but for now I'm refraining.

require all numbers > 0
require for item in items all item.name.trim.length > 0

[Kurper]

I guess it's a little late, but is there any reason these couldn't just be ordinary functions? I'm not a big fan of keyword proliferation when it could just as easily be a function (at the cost of a few parentheses and maybe a "use cobra.EnumerableStuff" at the top). Having actual code inside an interface doesn't really work, so the standard .NET OO solution of "make it a method of IEnumerable" doesn't seem to work as well.

Admittedly, that does prevent things like:

Code: Select all

require all numbers > 0

but allowing it to take a lambda expression as a second argument would make that feasible, and probably more flexible than the operator syntax.

[Charles]

I went with "all" and "any" being unary ops because I think it makes for clean, expressive code and opens up possibilities down the road including slicker syntax and compiler optimizations. I guess I prefer "all/any" ops over functions in the same way that I prefer a "for" expression over a "map" function.

Some of these keywords have already been reserved for awhile with no ill effect or complaints. Also, Cobra doesn't restrict method or property names from coinciding with keywords so when appropriate you could have a method called "all", for example. Methods always get dotted or underscored so there is no ambiguity.

Regarding lambdas, we'll have those eventually, but in some places where you might use them, a simple for expression works fine. In fact, the Python devs rejected giving Python's all() and any() functions a second parameter to take a lambda because a "for" generator expression could be used to do the filtering (don't have the link handy but believe I ran across that thread when googling for "Python all any").

-Chuck