SIP: Comprehensive Comprehensions

OOOOOOPS :-)

You are "the SIQ people" ... sorry, didn't look at the authors of this mail/the draft.

Bye,


Simon

Looks nice, but I really dislike the "then"/"group" thing. Is there no other (syntactical) alternative?

Have you looked at how the SIQ people solved that problem? I think they got it to wok somehow without these changes ...

Thanks and bye,


Simon

On 2011-10-24 9:20, Simon Ochsenreither wrote:
> Looks nice, but I really dislike the "then"/"group" thing. Is there no
> other (syntactical) alternative?

There certainly are alternatives. We can pick combinations of new or
existing keywords and symbols. In the special position where these
clauses are allowed, most other language constructs are forbidden, so it
should be easy to disambiguate. I think the main questions that need to
be answered are:

- Should we prefer symbols or keywords?

- Can we afford to introduce new keywords?

If your question refers to the syntactical distinction between the
sortBy and groupBy cases: This can be removed but it results in a rather
complicated desugaring and is IMHO not a good fit for Scala. It was
actually the approach I took in draft 1
(https://docs.google.com/document/d/1vE7ftE_czD7OC70zq19nbbWWuEuRHFXDzv3M...).

> Have you looked at how the SIQ people solved that problem? I think
> they got it to wok somehow without these changes ...

SIQ uses this method for ordering:

trait Iterable[A]{
def orderBy( o:(A => Order)* ) : Iterable[A]
}

In order to be usable with the proposed syntax, it would probably have
to be changed to take a single Order which can be a combined ordering
over multiple columns. The current version is slightly easier to use
than Scala's sortBy without Comprehensive Comprehensions syntax. To my
knowledge, SIQ does not support groupBy or any other operators of a
similar structure. In any case, it uses plain Scala method calls, just
like the collections library does.

Comprehensive Comprehensions are orthogonal to the implementation
semantics of the desugared method calls. My proposal uses plain Scala
collections (and many of the already existing collections methods fit
nicely into this approach) code but it would be equally amenable to
writing database queries, either using an LMS (light-weight modular
staging) approach as in SIQ or code lifting (as in LINQ on .NET).

Cheers,
Stefan

This is pretty exciting to see! Best of luck with this.

On Oct 24, 2011, at 3:46 AM, Stefan Zeiger wrote:
> If your question refers to the syntactical distinction between the sortBy and groupBy cases: This can be removed but it results in a rather complicated desugaring and is IMHO not a good fit for Scala. It was actually the approach I took in draft 1 (https://docs.google.com/document/d/1vE7ftE_czD7OC70zq19nbbWWuEuRHFXDzv3M...).

Can you elaborate more on this? I think the first version is a lot more readable.

Thank you.

On 2011-10-25 2:04, Jori Jovanovich wrote:
> On Oct 24, 2011, at 3:46 AM, Stefan Zeiger wrote:
>> If your question refers to the syntactical distinction between the sortBy and groupBy cases: This can be removed but it results in a rather complicated desugaring and is IMHO not a good fit for Scala. It was actually the approach I took in draft 1 (https://docs.google.com/document/d/1vE7ftE_czD7OC70zq19nbbWWuEuRHFXDzv3M...).
> Can you elaborate more on this? I think the first version is a lot more readable.

The only actual difference at the syntax level is that the second
version needs separate keywords "then" and "group", whereas the first
version can get by with a single keyword "then" for both cases (because
"group by" semantics with an identity functor can subsume "order by"
semantics).

I assume you like the example code in the first version better because
it uses e.g. "groupBy" instead of "_.groupBy", but that is actually a
downside of this encoding. "groupBy" is a function which needs to be
defined somewhere and imported. It is required by the first version
because the existing collection methods like List.groupBy do not have
the required encoding. In the second version, "_.groupBy" is a plain
method call to List.groupBy. If you wanted to, you could define wrapper
functions like they are used in version 1, but it is not necessary.

Cheers,
Stefan