d2ir: Implement lazy globs and triple glob

[nhooyr]

This finishes up the globs implementation!

See tests for what I mean by lazy globs and what the triple glob does.

[alixander]

failed to compile: /Users/alexanderwang/dev/d2-docs/static/bespoke-d2/triple-glob.d2:1:11: fill must be style.fill

***.style.fill: yellow
**.shape: circle
*.style.multiple: true

x: {
  y
}

layers: {
  next: {
    a
  }
}

[alixander]

applying too many times

# Create a shape `a`
a

* -> y

b
c

[alixander]

**.child

a
b
c

[nhooyr]

Fixed.

[alixander]

i think globs need to be overridable. currently a is yellow with this script, but it should be red.

**.style.fill: yellow
**.style.fill: red

a

If a parent board has a triple glob, it should also be overrideable by globs in the current board, e.g.

***.style.fill: yellow

layers: {
  hi: {
    **.style.fill: red
    # should be red, but it's yellow right now
    a
  }
}

[nhooyr]

Certainly was the intent, not sure how that's happening.

[nhooyr]

fixed.

[alixander]

did u hardcode the word layers in that last fix? i get this err again if i just change to scenarios

**.style.fill: red

scenarios: {
  b: {
    a -> b
  }
}

[alixander]

(*** -> ***)[*].label: hi

a -> b

layers: {
  hi: {
    (*** -> ***)[*].label: bye

    scenarios: {
      b: {
        # This label is "hi", but it should be "bye"
        a -> b
      }
    }
  }
}

[nhooyr]

did u hardcode the word layers in that last fix? i get this err again if i just change to scenarios

nope using d2graph.BoardKeywords so I'm very confused by that too.

addressed

[alixander]

what do you think about this one?

(*** -> ***)[*].label: hi

# This is "hey" right now but should be "hi"?
a -> b

(*** -> ***)[*].label: hey

interpretation 1: i've defined the first glob and expect all connections to lazily apply it until it's overridden, so the current behavior is broken.

interpretation 2: globs are global. i've defined two globs of the same pattern, so the last one should win, no matter what order of statements come in between/around them, so the current behavior is correct.

---

i'm leaning to interpretation 1. i.e. Globs should apply backwards unless an identical pattern already has lazily applied to it.

[nhooyr]

I think number 2 is the right behavior as it's implemented now. Last one to apply always wins as that's consistent with the rest of the language. Otherwise you can't override/unset globs which isn't good. Especially if you're importing a d2 file you don't control.

Why are you leaning towards 1? Under what kind of scenario do you see this coming up where 1 is preferable?

[nhooyr]

lazily apply it until it's overridden, so the current behavior is broken.

But you did override it with the second one?

[nhooyr]

i'm leaning to interpretation 1. i.e. Globs should apply backwards unless an identical pattern already has lazily applied to it.

In this case the final glob isn't being applied backwards. It's being applied normally.

[alixander]

ok, i can see that. moving on, this one's a bug for sure:

(*** -> ***)[*].label: hi

a -> b: {
  label: bye
}

[nhooyr]

🤦🏼 another good catch

[alixander]

looks like with filters, it's not overriding

x

*.style.opacity: 0.1
*: {
  &label: x
  style.opacity: 1
}

[nhooyr]

First one fixed, working on this next one.

[nhooyr]

Also btw #1552 (review) was because of *** being changed to **, not because of layers -> scenarios.

And I think this next one isn't related to globs but that label isn't handled specially by filters to match the ID of a field without a label.

[alixander]

@nhooyr

nah i just tried this and it's the same issue

*.style.opacity: 0.1
*: {
  &label: x
  style.opacity: 1
}

x: x

[nhooyr]

Same issue there, label needs special handling. Pushed fix for *Field but I think I need to add the same exception for *Edge too. So hold on.

[nhooyr]

Fixed.

[alixander]

is it easy to get globs working for imports? right now this doesn't work but i definitely see the utility

rules.d2

*.style.fill: red

index.d2

...@rules
x

[nhooyr]

Right now no unfortunately. Would require changing how imports work to merge ASTs together instead of IRs.

[alixander]

i think that can be another use case of ***. they cross board boundaries and file boundaries

[alixander]

can we encode globs into the IR? i think imports should continue just dealing with IRs, globs just need to be in there

[nhooyr]

Perhaps, I'm not sure of a good way to do it right now.

[alixander]

the fill isn't applying, but if I remove the x, it works. Looks like something straightforward missed?

(left is index)