Problem: macro expander doesn't like _ which we use for "I don't care about this"

[sjmackenzie]

eg:

 (edge "card-display-out" "out" "wsettings" "wsettings" "in" _)

this code implies: make a connection between node "card-display-out"'s "out" array output port on the element array "wsettings" and node "wsettings"'s "in" simple input port (as indicated by the "_").

Yet the new semantics seems like it doesn't map from the previous usage.

(with-node-name "card-display-out"
  (edge "out" #:selection "wsettings" "wsettings" "in")

What does this say?:
"Let's make a connection from "cardo-display-out"'s on the "out" ... #:selection... huh? what's selection? seems we're connecting an array port but how do we distinguish if the port to be connected to is a simple port or array port? there is no "_" to indicate it is a simple input port.

So the new approach of using #:selection really gets confusing fast especially when the current approach is

(edge "from-node-name" "from-node-port" "from-node-port-element-if-array-element" "to-node-name" "to-node-port" "to-array-port-selection-if-element-array")

so the original verbose way:

  (edge "card-display-out" "out" "new" "welcome" "in" _)
  (edge "card-display-out" "out" "summary" "summary" "in" _)
  (edge "card-display-out" "out" "wsettings" "wsettings" "in" _)
  (edge "card-display-out" "out" "receive" "receive" "in" _)

becomes:

  (with-node-name "card-display-out"
                  (edge "out" #:selection "summary" "summary" "in")
                  (edge "out" #:selection "send" "send" "in")
                  (edge "out" #:selection "receive" "receive" "in")
                  (edge "out" #:selection "wsettings" "wsettings" "in")
                  (edge "out" #:selection "new" "welcome" "in"))

note the new #:selection this breaks with the expected usage patterns.

Potentially using (2 "_") __ won't break the macro expander. So:

  (with-node-name "card-display-out"
                  (edge "out" "summary" "summary" "in" __)
                  (edge "out" "send" "send" "in" __)
                  (edge "out" "receive" "receive" "in" __)
                  (edge "out" "wsettings" "wsettings" "in" __)
                  (edge "out" "new" "welcome" "in" __))

[clacke]

How would you feel about:

(with-node-name "card-display-out"
                (edge #:array "out" "summary" "summary" "in")
                (edge #:array "out" "send" "send" "in")
                (edge #:array "out" "receive" "receive" "in")
                (edge #:array "out" "wsettings" "wsettings" "in")
                (edge #:array "out" "new" "welcome" "in"))

For me it's easy to miss adding or removing the _, I think spelling it out which is the array port makes thing more explicit.

Note that simple<->simple and array<->array don't need these, as they're unambiguous in their number of arguments.

[sjmackenzie]

Yeah, in my current opinion, it's hard to read if it's a simple or array port. So instead instill the convention and pattern (node port element (optional)) into the programmer. If you see

("dee" "day" "daa" ... 

you know immediately it's a element of an array port. If you see

("dee" "day" __ ... 

You know immediately it's a simple port. The simplicity of

( node 1 2 3 1 2 3)

Means you can quickly see what's connecting to what. For example:

(mesg "dee" "day" "daa" "fee" "fay" __) 

Is an array port connecting to a simple port. When using your convention:

(mesg "whisky" "distilled" "single-malt" "glass" "pour") 

it's not immediately obvious is "single-malt" a node name or port element?

(mesg "whisky" "distilled" "single-malt" "glass" "pour" __) 

Now it's clear.

I can't seem to read your #:array convention and why it needs to differ from the standard (node x y z x y z) understood, with-node allows you to do (mesg y z x y z).

In your example here:

(edge #:array "out" "receive" "receive" "in")

What does an array port connecting to an array port look like?

[sjmackenzie]

My main point is humans need predictable things, we need to teach a simple rule that reflects and transfers in spirit throughout each usage (node...) (mesg ...) and (edge ...). Any deviating from this rule will cause disturbances and people will drop out. I'm hoping for non-programmers to use this layer of code so it has to be predictable with minimal exceptions. Hence a with-node is risky (programmers will generally use this) cause it breaks the predictability rule but if we start using #:array instead of what the convention is __ which does exactly the same thing as #:array. But also makes the clauses variable lengths under different circumstances. 4 = what was it again? Ah simple<->simple, 5 = is what?Either a simple<->array or array<->simple depending on where the #:array is. 6 is arrayto array. It just adds too many exceptions to the predictability rule. It's already enough dropping the "node-name". Let's limit the predictability damage as much as possible.
To sum it up exceptions:

• variable lengths 4, 5 and 6
• addition of new keyword #:array which is exactly the same as _ in long form and only used when it's an array<->simple or visa versa. With _ you naturally discard anything that's irrelevant. From a programming language design (typically erlang, prolog and other languages) the _ is used for that so it isn't semantically alien.
• addition of new keyword with-node
• dropping of node-name when using with-node
• differing syntax between long form and short form

another approach its always six, and you just drop out the element if it's not applicable.
To sum it up exceptions:

• addition of new keyword with-node
• dropping of node-name when using with-node

[clacke]

Alright, I'm like +0 on #:array and -0 on __, so if you're +1 on __ then __ it is.

Maybe down the road we'll figure out how to do _ without resorting to traversing the syntax ourselves. Or maybe that's exactly what we'll do. But not right now -- for the moment I prefer the better readability and less effort that comes from syntax-case.

[clacke]

On second thought, I'll keep this open and close it with the relevant PR.

[sjmackenzie]

Actually by doing (define _ #f) we were kicking the can down the road to the point where we define our graph language. So at least keeping it within realms of ease of refactoring is important. If we use something that we know will be redefined it means we have so much more work to do to refactor. Hence why I treat this particular point with such careful attention. So I'd greatly appreciate a __ over #:array. It keeps with the general semantics of the language. Anyway we'll sort this out later. Thanks!