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

Easier conditional groups in list comprehension #798

Closed
cueckoo opened this issue Jul 3, 2021 · 5 comments
Closed

Easier conditional groups in list comprehension #798

cueckoo opened this issue Jul 3, 2021 · 5 comments
Labels
FeatureRequest New feature or request wontfix This will not be worked on

Comments

@cueckoo
Copy link
Collaborator

cueckoo commented Jul 3, 2021

Originally opened by @verdverm in cuelang/cue#798

Is your feature request related to a problem? Please describe.

I have a list which has elements that are conditionally included. Some of them are groups and always appear together. The way to write this most intuitively is an error.

Describe the solution you'd like

a: "on"

l: [
        if a == "on" {
                "a",
                "A",
        },
        "b",
        "c",
]
l.0: conflicting values "A" and "a":
    ./list.cue:5:3
    ./list.cue:6:3

Describe alternatives you've considered

  • wrapping each in the same conditional (bad UX)
  • extracting the group into its own list and putting the conditional in a nested list comp [for x in aa if a == "on" { x } ]
@cueckoo cueckoo added FeatureRequest New feature or request wontfix This will not be worked on labels Jul 3, 2021
@cueckoo cueckoo closed this as completed Jul 3, 2021
@cueckoo
Copy link
Collaborator Author

cueckoo commented Jul 3, 2021

Original reply by @myitcv in cuelang/cue#798 (comment)

This will be addressed by the query proposal in #165:

a: "on"

l: [
        if a == "on" {
                ["a", "A"].*
        },
        "b",
        "c",
]

@cueckoo
Copy link
Collaborator Author

cueckoo commented Jul 3, 2021

Original reply by @verdverm in cuelang/cue#798 (comment)

Is there anything that hard prevents the suggested syntax above? (@mpvl)

The benefit I see with it is:

  • the ease of line edits, i.e. I can add or remove a line rather than editing within a line
  • no need for extra list style syntax, the query syntax is only marginally better than the list comp syntax

@cueckoo
Copy link
Collaborator Author

cueckoo commented Jul 3, 2021

Original reply by @myitcv in cuelang/cue#798 (comment)

Is there anything that hard prevents the suggested syntax above?

It's (currently) illegal because it's neither a valid embedded scalar, nor it is a valid struct value.

the ease of line edits, i.e. I can add or remove a line rather than editing within a line

Like this?

a: "on"

l: [
        if a == "on" {[
                "a", 
                "A"
        ].*},
        "b",
        "c",
]

no need for extra list style syntax, the query syntax is only marginally better than the list comp syntax

It's true there is a close relationship between the two, but I'm not sure we'd want to introduce a "third" way of writing things.

Re-opening for @mpvl's answer in any case.

@cueckoo
Copy link
Collaborator Author

cueckoo commented Jul 3, 2021

Original reply by @verdverm in cuelang/cue#798 (comment)

For some extra context, this started from a discussion on Slack, where one of the examples is the following

a: "on"
x: "on"
b: "on"
c: "off"
aa: ["a", "A", "eh?"]
xx: ["x", "x", "ex"]
l: [
        for A in aa if a == "on" { A }
        for X in xx if x == "on" { X }
        if b == "on" {
                "b"
        }
        if c == "on" {
                "C"
        }
]
  • I was surprised that commas are optional
  • I bring it up for the sequential list comps that end up flattened in l, which feels like weird syntax to me

@cueckoo
Copy link
Collaborator Author

cueckoo commented Jul 3, 2021

Original reply by @mpvl in cuelang/cue#798 (comment)

@verdverm: the suggested syntax would contradict what that syntax typically means. It already means something in one context and it would be very unsurprising to have it mean something else in another. There are probably also cases where the original syntax has meaning in this context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant