An alternative to Comprehensive Comprehensions: First-class "for" scopes

349 views
Skip to first unread message

Stefan Zeiger

unread,
Apr 23, 2014, 7:28:01 AM4/23/14
to scala-internals
Hi,

I wrote down some ideas for an alternative to Comprehensive
Comprehensions (see the discussion on scala-sips) which is simpler and
avoids controversial features like rebinding variables to different
types. Comments are welcome:
https://docs.google.com/a/typesafe.com/document/d/1eb3Xx22SEWqm6h27qnp9l-Ea-FagM5rn8tuyfpSq72o/edit#heading=h.grk92auzj4ry

-sz

virtualeyes

unread,
Apr 23, 2014, 11:33:36 AM4/23/14
to scala-i...@googlegroups.com
Brilliant, love the concision.
for {
  a
<- as
  b
<- bs
 
then _.sortBy(_.a.name)
} yield (a.name, b.name)

In the footnotes there's a reference to a limitation with groupBy:

this proposal does not provide any special support for automatically mapping through a nested functor (as in groupBy). Users are required to do that manually (and are enabled to do so by preserving bound names)

How will groupBy differ from sortBy in above comprehension?

If accepted an implementation in 2.12 would be most welcome, and failing that, whenever Dotty comes on the scene ;-)

Stefan Zeiger

unread,
Apr 23, 2014, 2:32:41 PM4/23/14
to scala-i...@googlegroups.com
On 2014-04-23 17:33, virtualeyes wrote:
Brilliant, love the concision.
for {
  a
<- as
  b
<- bs
 
then _.sortBy(_.a.name)
} yield (a.name, b.name)

In the footnotes there's a reference to a limitation with groupBy:

this proposal does not provide any special support for automatically mapping through a nested functor (as in groupBy). Users are required to do that manually (and are enabled to do so by preserving bound names)

How will groupBy differ from sortBy in above comprehension?

You wouldn't be able to use automatic imports with groupBy, so that would have to be:

for {
  a
<- as
  b
<-
bs
  (k, vs) <-
then _.sortBy(_.a.name)
} yield (k, vs.map(_.b.name))

C# would import the "Key" and "Values" automatically but that either requires dedicated support for groupBy (as in C#), or deferring the desugaring until after type-checking (which is not how Scala and Dotty work).

Adriaan Moors

unread,
Apr 23, 2014, 2:36:02 PM4/23/14
to scala-i...@googlegroups.com
I like it! This is the perfect time to start work on this for inclusion in 2.12. Comments in the doc. 
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--

virtualeyes

unread,
Apr 23, 2014, 3:38:40 PM4/23/14
to scala-i...@googlegroups.com
Ok, well given that groupBy and sortBy are often good friends (i.e. together), and that such a combination would completely right the ship in terms of comprehension boilerplate, is it worth exploring, or is that a massively complex endeavor/not possible?

Just seeing this proposal is like finding the holy grail of for comprehensions, well almost ;-)

Nice work...

Matthew Pocock

unread,
Apr 24, 2014, 7:10:46 AM4/24/14
to scala-i...@googlegroups.com
HI,

So I've had a read through some of the docs, but I'm left not quite sure what problem extended for comprehension syntax solves. The rather ugly for-comprehensions in the examples look a lot like the sort of ugly nesting that the async/await macro does away with when working with futures. Perhaps I'm just not understanding.

Matthew




-sz

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550

Stefan Zeiger

unread,
Apr 27, 2014, 3:07:14 PM4/27/14
to scala-i...@googlegroups.com
On 2014-04-23 21:38, virtualeyes wrote:
> Ok, well given that groupBy and sortBy are often good friends (i.e.
> together), and that such a combination would completely right the ship
> in terms of comprehension boilerplate, is it worth exploring, or is
> that a massively complex endeavor/not possible?
Special support for nested functors fro groupBy leads to Comprehensive
Comprehensions (or at least I don't have any better idea than that). We
already explored those and didn't gain much support because it
complicates the language too much.

Stefan Zeiger

unread,
Apr 27, 2014, 3:15:18 PM4/27/14
to scala-i...@googlegroups.com
On 2014-04-24 13:10, Matthew Pocock wrote:
> HI,
>
> So I've had a read through some of the docs, but I'm left not quite
> sure what problem extended for comprehension syntax solves.

It makes complex queries with operations like sortBy and groupBy (that
act on the whole collection at some point in the query) more readable.
The example in the document is a leftover from my Comprehensive
Comprehensions proposal and maybe not the best one for the new approach.

> The rather ugly for-comprehensions in the examples look a lot like the
> sort of ugly nesting that the async/await macro does away with when
> working with futures. Perhaps I'm just not understanding.

async/await does a cps transform to put imperative code into a monadic
context (I think it's still limited to Future at the moment). It doesn't
deal with computations on the monadic values, only with computations on
the elements, so it's orthogonal to this.

virtualeyes

unread,
May 1, 2014, 3:38:40 AM5/1/14
to scala-i...@googlegroups.com
As an end user and an idealist I can't help but think how awesome for comprehensions with embeddable groupBy/sortBy would be.

Certainly would launch Slick adoption through the roof, IMO, you'd have a near pure LINQ syntax with excellent performance characteristics to boot (i.e. benefit from existing statement caching that's been there from SQ to Slick).

I know Dotty is about simplifying the language but perhaps there's room for added functionality where the gain outweighs the pain.

Obviously easier said than done ;-)

Hopefully your colleagues at Typesafe warm up to this approach; otherwise perhaps some Macro evolution will happen during the next year that makes the currently impossible, possible.
Reply all
Reply to author
Forward
0 new messages