-
Notifications
You must be signed in to change notification settings - Fork 67
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
Draft: comprehension assignment #74
Conversation
eeps/eep-0076.md
Outdated
executed if `Var` has the value `true`. We can therefore expect that | ||
no such uses exist in practice, because `Var` would be fully | ||
redundant. (The OTP code base has been checked and does not contain | ||
any.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say this is still a backwards incompatible change, because if someone relies on it, the behaviour will change in very subtle ways:
2> [{X, Y} || X <- [1, 2.0, 3], Y = is_integer(X)].
[{1,true},{3,true}]
Also, for completeness, one could introduce maybe expressions' ?=
operator in comprehensions, which would work similar to an assignment + filter (as it will discard the element if it does not match the pattern).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is an incompatible change, yes. To protect against that, one could start with making Pat = ...
an error in OTP 28, and then add the new interpretation in OTP 29. I really did not want to add yet another special token. (?=
could be useful though). One possibility is to use the so far reserved token 'let' as a prefix: let Pat = ..., ...
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an option of making it an error in 28, and introducing an opt-in feature that uses the new semantics (rather than erroring), and in 29 making this feature the default.
This way, it won't silently change semantics, but won't delay the new syntax for another release for people that are ready for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a winner to me.
8c54377
to
628c65e
Compare
628c65e
to
0a3486d
Compare
We will review this in the near future. Thanks for your contribution |
@richcarl We will wait a bit to see how the community (Erlang Forums and interested people reading this EEP) sees this change. Thanks |
This EEP adds assignments to comprehension qualifier lists.
Reference implementation PR: erlang/otp#9153