Alternative BSN Syntax: <> Entity Syntax

[cart]

This is a potential alternative BSN syntax that attempts to resolve some issues with the current BSN syntax. It comes down to introducing new <> syntax to indicate the bounds of an Entity.

First, here is an example with the current bsn! syntax:

bsn! {
    Node { width: px(100) }
    BackgroundColor(GREEN)
    [
        (
            Node { width: px(10) }
            BackgroundColor(RED)
        ),
        (
            :checkbox
            InteractionDisabled
            Children [
                Text("Hello there")
            ]
        ),
        Node { width: px(10) }
    ]
}

And here is the <> syntax:

bsn! {
    Node { width: px(100) }
    BackgroundColor(GREEN)
    <
        Node { width: px(10) }
        BackgroundColor(RED)
    >
    <
        :checkbox
        InteractionDisabled
        <Text("Hello there")>
    >
    <Node { width: px(10) }>
}

Resolved Issue: Over-indentation / newlines

In the current syntax, children with more than one component use () for clarity. This sadly results in both over-indentation and unnecessary newlines:

Node { width: px(100) }
BackgroundColor(GREEN)
[      // This is awkward!
    (  // This is also awkward!
        Node { width: px(10) }
        BackgroundColor(RED)
    )
    (
        Node { width: px(10) }
        BackgroundColor(RED)
    ),
]

The proposed <> syntax resolves these problems:

Node { width: px(100) }
BackgroundColor(GREEN)
<
    Node { width: px(10) }
    BackgroundColor(RED)
>
<
    Node { width: px(10) }
    BackgroundColor(RED)
>

Resolved Issue: Eliminates the RelationshipTarget [] vs Component [] ambiguity

The current [] shorthand for Children [] creates ambiguities with SomeParentComponent [] and RelationshipTarget []. This new syntax removes the [] shorthand, freeing up RelationshipTarget [] (if we still want it in this new world ... coming up a with a new syntax might be better).

Resolved Issue: Syntax Noise

Currently defining children involves a mix of [], (), and ,:

// Note this doesn't use newlines like it normally would to put the focus on the syntax
Node [(Node Marker [ Node ]), (Node Marker [ Node ])]

<> syntax cuts this down substantially:

Node <Node Marker <Node>><Node Marker <Node>>

Resolved Issue: Child misalignment

Currently for terseness, children don't require () wrappers for small numbers of components:

Node [
    // Omitting `()` is encouraged here
    #Child1 [
        Node
    ],
    // Including `()` is encouraged here
    (
        #Child2
        Marker
        [
            Node
        ]
    )
]

This makes it visually challenging to pair #Child1 and #Child2 together. <> syntax would be required, which forces a "pairing" between them:

Node
<
    #Child1
    <Node>
>
<
    #Child2
    Marker
    <Node>
>

Resolved Issue: Where to put commas

The current BSN syntax has rules that feel a bit "arbitrary". Components within a single entity do not use comma separators, lists of entities do:

Node // no commas here
Marker 
[
    Node, // commas here
    Node,
]

Some people find this confusing / arbitrary. <> removes the comma case from the "structural BSN syntax", reserving it only for initializing rust types:

Node // no commas
Marker 
<Node> // no commas
<Node>

BSN currenty exists in a middle ground where it largely feels like Rust, but it makes targeted departures from Rust syntax in the interest of ergonomics or clarity. This creates a kind of "wait why aren't there commas here" discomfort in some people, as it feels like a violation of Rust-like expectations (ex: (Node Marker) when defining a child entity instead of (Node, Marker)). Adding commas to that case feels ergonomically non-viable to me in the context of BSN.

The proposed <> helps resolve that discomfort by more fully decoupling ourselves from the Rust context. <> feels less "Rust-ey" and more "user-interface-ey". When defining hierachies in <> elsewhere (ex: the web), people expect no commas:

<button style="width: 10px" onclick="button_click" />

We're just replacing these attributes with components (and abandoning the "closing" aspect of XML):

<:Button Node { width: px(10) } on(button_click)>

Resolved Issue: Removes an annoying "syntax refactor" case

Currently, adding a component can force a move from the "shorthand" approach to the () wrapper approach:

// before
Node [
    Node,
    Node [
        Node
    ],
]
// after
Node [
    Node,
    (
        Node 
        BackgroundColor(RED)
        [
            Node
        ]
    ),
]

With <> syntax, this is not necessary:

// before
Node
<Node>
<
    Node
    <Node>
>
// after
Node
<Node>
<
    Node
    BackgroundColor(RED)
    <Node>
>

New Issue: What do we do for custom relationships?

Previously, all "hierarchical relationships" felt the same:

bsn! {
    Node { width: px(10) }
    [
        Node,
        Node,
    ]
}
// which is just shorthand for
bsn! {
    Node { width: px(10) }
    Children [
        Node,
        Node,
    ]
}
// other relationships pair nicely
bsn! {
    Node { width: px(10) }
    Inventory [
        Item,
        Item,
    ]
    Children [
        Node,
        Node,
    ]
}

We will almost certainly lose that pairing in the new world, and are likely to lose the "shared levels of indentation".

// Option 1: Keep the "RelationshipTarget []" syntax (it is no longer ambiguous)
// This currently has my preference
bsn! {
    Node { width: px(10) }
    Inventory [
        <Item> 
        <Item> 
    ]
    <Node>
}

// Option 2: Alternative RelationshipTarget syntax
bsn! {
    Node { width: px(10) }
    Inventory:
        <Item> 
        <Item>
    // Note that this is relying on newlines to avoid ambiguity ... not ideal
    <Node>
}

// Option 3: rely on the relationship name w/ new syntax
bsn! {
    Node { width: px(10) }
    // This feels awkward to me
    InInventory: <Item> 
    InInventory: <Item> 
    <Node>
}

// Nonviable Option 1: Use the Relationship component + #Name features as currently proposed
bsn! {
    #Root
    Node { width: px(10) }
    // this would _need_ to also add the Item entities as Children, as we want to support
    // layering additional relationships on top of children.
    <Item InInventory(#Root)> 
    // this also requires more boilerplate: specifying the relationship for each Inventory item,
    // _and_ defining a #Name _and_ passing it in for each Item
    <Item InInventory(#Root)> 
    <Node>
}

New Issue: XML / HTML similarity

<> introduces a similarity to XML / HTML that may cause some developers to wrongly assume they are compatible. I personally think this is worth it.

Note that I think embracing more XML syntax would make things worse (ex: "closing syntax like </div>" or <button /> syntax would degrade our ergonmics)

Alternative: Use () instead of <>

// <> Syntax
bsn! {
    Node { width: px(100) }
    BackgroundColor(GREEN)
    <
        Node { width: px(10) }
        BackgroundColor(RED)
    >
    <
        :checkbox
        InteractionDisabled
        <Text("Hello there")>
    >
    <Node { width: px(10) }>
}
// () Syntax
bsn! {
    Node { width: px(100) }
    BackgroundColor(GREEN)
    (
        Node { width: px(10) }
        BackgroundColor(RED)
    )
    (
        :checkbox
        InteractionDisabled
        (Text("Hello there"))
    )
    (Node { width: px(10) })
}

Pros:

• Feels more Rust-ey
• Drops the "xml similarity"

Cons:

• Losing special "entity syntax" means it is harder to pick out entities / children from other rust code. Everything starts to blur together. Consider this:

  Node
  Thing(RED) // These two lines feel
  (Red)      // very similar

• Perhaps too Rusty ... people expect to use commas inside ()

I'm personally still biased toward <>.

[cart]

Hmm one problem: providing an inline bsn list is now ambiguous with providing a single BSN:

// before 
bsn! {
   Node [
      {children}
   ]
}

// after
bsn! {
  Node
  // this expects an `impl Scene` not an `impl SceneList`
  {children}
}

[TheShowMy]

Here's a random shower thought: define the entire hierarchy upfront, and then create the specific entities directly at their correct level. Just spitballing here!

bsn! {
    {
        bg
        bg_top
        bg_top_label
        bg_checkbox
        bg_bottom
    },
    bg{
        Node { width: px(100) }
        BackgroundColor(GREEN)
    }
    bg_top{
        Node { width: px(10) }
        BackgroundColor(RED)
    }
    bg_checkbox{
        : checkbox
        InteractionDisabled
        Children[
            Text("Hello there")
        ]
    }
    bg_bottom{
        Node { width: px(10) }
    }
}

bsn! {
    {
        *bg
        **top
        ***top_label
        **checkbox
        **bottom
    },
    bg{
        Node { width: px(100) }
        BackgroundColor(GREEN)
    }
    top{
        Node { width: px(10) }
        BackgroundColor(RED)
    }
    checkbox{
        : checkbox
        InteractionDisabled
        Children[
            Text("Hello there")
        ]
    }
    bottom{
        Node { width: px(10) }
    }
}