Skip to content
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

Make assignment (match) in comprehension work as strict generator #9153

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

richcarl
Copy link
Contributor

@richcarl richcarl commented Dec 7, 2024

It would be useful to be able to easily bind variables in the qualifiers of a comprehension, for example:

[Z || X <- Ls,
      {foo, Y} = g(X),
      Z <- f(Y, h(Y))].

You can do this today by writing a singleton generator:

[Z || X <- Ls,
      {foo, Y} <- [g(X)],  % produce single element
      Z <- f(Y, h(Y))].

but this has some drawbacks: the intent is not clear to the reader; you have to remember to write a single element list around the right hand side argument (which itself could be a list); you probably want it to be a strict generator so typos don't just silently yield no elements; and someone might edit the code later and accidentally add extra elements to the right hand side, causing unintended Cartesian combinations.

It is in fact already allowed syntactically to have a = match expression in the qualifiers, but this is just interpreted as any other expression - thus expected to produce a boolean value, and if false, the current element will be skipped. Hence, any qualifier to the right of a V = Expr match will only execute if V is true. We can therefore expect that no such uses exist in practice. (The OTP code base has been checked and does not contain any.) To be completely safe, matches in a comprehension qualifier position can first be made an error, and then allowed with these binding semantics in the following major release.

This is related but orthogonal to #9134. It would make those few cases where variables have been exported from subexpressions of qualifiers much nicer to rewrite than requiring them to be singleton generators.

Copy link
Contributor

github-actions bot commented Dec 7, 2024

CT Test Results

    2 files    332 suites   10m 23s ⏱️
  834 tests   831 ✅ 2 💤 1 ❌
5 581 runs  5 578 ✅ 2 💤 1 ❌

For more details on these failures, see this check.

Results for commit c77dfe2.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

// Erlang/OTP Github Action Bot

@richcarl
Copy link
Contributor Author

richcarl commented Dec 7, 2024

Correction: 1 occurence in the OTP test suites, in singleton_inference.erl, which is weird enough that I won't even try to rewrite it myself. Maybe @jhogberg who wrote it (commit ebc461e) can help?

@rickard-green rickard-green added the team:LG Assigned to OTP language group label Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team:LG Assigned to OTP language group
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants