Lambda the Ultimate

book* AWbooks = bib.book[it.publisher == "Addison-Wesley" && it.year > 1991];

[...] represent a filtering expression.

Obviosuly, what you want inside the [..] is a lambda expression (i.e., an annonymous function). But what would its signature be like? So we provide a magic variable it. Not very sexy.

I wonder what happens when these expressions are nested...

   book* AWbooks = bib.books[it.publisher == "Addison-Wesley" && it.year > 1991]; 

   <T> T -> boolean

   <Collection C, T> C<T> and T->boolean

My assumption was that we would want the magic variable for method calls (rather than for the field access shown). Maybe they just think this sugaring will be more acceptable in a mainstream language:

   bib.books[it.publisher == "Addison-Wesley" && it.year > 1991]; 

   bib.books.filter(book it => it.publisher == "Addison-Wesley" && it.year > 1991); 

The concept of methods that return multiple times is also available in XQuery, which (confusingly) uses the return keyword instead of yield. It is also supported by several other programming languages including Icon, Clu, and Python, and will be in the next version of C#.

Ideally the entire square bracket notation would be have lazy semantics and the implementation would have access to the internal representation of the collection of books in order to perform an efficient query plan.

Right?

Who's to say how big this database is, or if it all fits in RAM?

Erik calls filterable objects "streams", so it's not unthinkable that it will be possible to retrieve one item at a time from the database.

About the syntax: I'm working on similar syntax for Loell 2, but with {} instead of []. ([] is was already occupied) The code between {} is run as a method on each item, so the shortest syntax would be:

bib.books{.publisher == "Addison-Wesley"; .year > 1991}

This is actually a lambda expression, where the argument defaults to me. If you want to give it a name, you can do that too:

bib.books{|book| book.publisher == "Addison-Wesley"; book.year > 1991}

The only thing the paper mentions about handling streams is this filtering and apply-to-all. In Loell all operations on streams are applied element wise, f.e.:

aStreamOfNumbers + 1

would return a new stream with each number in it increased by one. The result effect is that when you want to perform operations on the data as a whole, you'll have to collect the elements in a collection first, f.e.:

GetTotalByZip = {|books,zip| [>books{.zip = zip}] sum {.price * .quantity } }

As I pointed out in that discussion, I don't get the need to extend the PL with domain-specific extensions where perfectly good general purpose facilities are already available. Instead of implementing an XML-only extension to C#, they could have built on the existing deletagte functionality that is already available. All they need to do is provide a bit of syntactic sugar for it.