Skip to content

value definitions before generator? #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fommil opened this issue Mar 30, 2018 · 4 comments
Closed

value definitions before generator? #2

fommil opened this issue Mar 30, 2018 · 4 comments

Comments

@fommil
Copy link

fommil commented Mar 30, 2018

Any chance you could implement scala/bug#907 ?

@oleg-py
Copy link
Owner

oleg-py commented Mar 30, 2018

The grammar of Scala defines for such that first generator is always an arrow
https://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#for-comprehensions-and-for-loops

So making it work nicely is not possible without actually modifying the syntax.

Some custom syntax can be made to work, however. E.g.:

for {
  x <- pure(42)
  y <- Option(33)
} yield x + y

This is syntactically valid, and after parser becomes:

pure(42).flatMap(((x) => Option(33).map(((y) => x))))

Which can be matched against and transformed into:

val x = 42 // parameter becomes a val
Option(33).map(((y) => x)) // lambda body of `flatMap` is inlined

This will save the user from needing to specify the monadic type they are operating on, as compared to 42.point[Option] and will not require pure to actually be available for the type.

@fommil
Copy link
Author

fommil commented Mar 30, 2018

"matched against and transformed into" ... and also that final .map could be removed if we're optimising for expansions 😄

pure is probably a bit of an overloaded term here, unless you're suggesting that this work for any definition of pure rather than a new one that you're proposing. I tend to use .pure[F] syntax in preference to pure(...)

@oleg-py
Copy link
Owner

oleg-py commented Mar 30, 2018

pure is probably a bit of an overloaded term here, unless you're suggesting that this work for any definition of pure rather than a new one that you're proposing

The idea is that initial pure calls in for-comprehensions are handled by the plugin whereas after first non-pure expression nothing is changed.

I used pure just to illustrate what is actually possible without modifying parser. Would actually be happy if anybody suggests something better.

also that final .map could be removed if we're optimising for expansions 😄

Well, for Option(<constant>), sure. Though I doubt it is used often enough for anybody to actually benefit from :D.

@fommil
Copy link
Author

fommil commented Mar 30, 2018

what I mean is that if a for looks like

for {
  ...
  a <- doA
} yield a

the final .map is redundant and is just extra runtime object allocs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants