More defined syntax analysis for variadic inputs

[warped_wart_wars]

@warped_wart_wars

Yeah, I'll add that.

I added it.

@warped_wart_wars

What else am I supposed to call what gets SPLIT from a variadic input or gets JOINed into one?

I renamed it variadic-input, still not sure if that's right.

[bh]

@warped_wart_wars

There isn't really any difference between how they're executed, only in how they're used to make a program.

Again, the goal is to faithfully reproduce the user's code as an abstract syntax tree. And there are differences about what you can put into each kind of ring iirc.

@warped_wart_wars

What else am I supposed to call what gets SPLIT from a variadic input or gets JOINed into one?

I had suggested nonterminals variadic-inputs and variadic-input-list.

[warped_wart_wars]

@bh

I had suggested nonterminals variadic-inputs and variadic-input-list.

Where?

---

@bh

And there are differences about what you can put into each kind of ring iirc.

Yes, that's what I meant by

@warped_wart_wars

in how they're used to make a program.

BTW only script rings have restrictions on what can be put in them.

---

@bh

variadic-inputs

I renamed it to that.

[warped_wart_wars]

@warped_wart_wars

BTW only script rings have restrictions on what can be put in them.

BTW I found out this:

When CALLed, it gives this:

When CALLed a bunch of times:

A couple more:

[bh]

@warped_wart_wars

Where?

Uh oh isn't that what I said before? Well, anyway, I'm suggesting it now!

[warped_wart_wars]

@bh

where compound-expression, variadic-inputs, text, and multiline-code are nonterminals.

is the only place I saw it. (Edge thinks that should be a question.) And anyway,

@warped_wart_wars

I renamed it to that.

[bh]

Righto.

[warped_wart_wars]

Does this look good?

stack := hat? instruction*
hat := a hat block
instruction := command-block input*
command-block := a command block
input := literal | expression | variadic-inputs
literal := a text | a boolean | a number
expression := expression-block input*
expression-block := a reporter block | a predicate block | ring
variadic-inputs := variadic input*
ring := expr-ring | stack-ring
expr-ring := expression formal-params
stack-ring := stack formal-params
formal-params := variadic formal-param*
formal-param := a formal parameter
variadic := marks variadic inputs

[bh]

@warped_wart_wars

instruction := command-block variadic-inputs

No, the command block doesn't have to have variadic inputs. Just inputs.

input ::= single-input | variadic-input | variadic-input-list
variadic-input ::= single-input*
variadic-input-list ::= list

... but I'm worried that we are wrongly conflating formal inputs (the slots in the empty block) with actual inputs (the expressions filling those slots in this instance of using the block). In other words, that there's no way to denote what the block is asking for, as distinct from what it's getting. But maybe that's okay? Maybe for custom blocks the information about what it's asking for comes from its definition, and for primitives it's just listed in the syntax.

[jens]

this discussion will end up suggesting static types in 3...2...1...

[bh]

@jens

this discussion will end up suggesting static types in 3...2...1...

What? Why do you think that? Languages with dynamic typing can still have a formal syntax. Scheme, for example.

[warped_wart_wars]

@bh

No, the command block doesn't have to have variadic inputs. Just inputs.

Woops! Fixed.