any all operators

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

any all operators

Postby Charles » Thu Jul 31, 2008 2:50 am

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 > 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 > 0
Posts: 2514
Location: Los Angeles, CA

Re: any all operators

Postby Kurper » Thu Jul 31, 2008 8:34 am

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.
Posts: 6

Re: any all operators

Postby Charles » Thu Jul 31, 2008 12:22 pm

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").

Posts: 2514
Location: Los Angeles, CA

Return to Discussion

Who is online

Users browsing this forum: No registered users and 9 guests