Do you think beginners would understand what it means to split a block?
maybe not, but i think simpler is better here.
well, better for human reading, but maybe not for programmatic reading.
And programmatic reading (I thought it was "programmic") is what splitting by blocks is usually for.
Yes, but I think the current syntax can be read fairly well,
And it isn’t cluttered with labels like “variadic-1” all over
The place
This discussion isn’t getting anything accomplished. I’m going to stop continuing it
the label "variadic-1" is the text in the variadic input. It's not a label, it was just there for demonstration purposes. I could've used anything.
Sure, we should first settle on the formal syntax and then SPLIT BY BLOCKS should follow it. Probably it starts with
stack ::= headless-stack | headed-stack
stack-body ::= instruction*
headless-stack ::= stack-body
headed-stack ::= head-block stack-body
...
That may be more nonterminals than necessary. Maybe just
stack::= (head-block)? (instruction)*
except I'm spacing on the right notation for "zero or one of these."
PS Actually instead of a "block" nonterminal we might use "reporter-block" or "predicate-block" as appropriate. An expression can't start with a command block. (That's an instruction.)
I have no idea what you mean by "spacing".
Oh and I made a spelling mistake in that: I used "expresssion" with three "s"s.
Oh and what's the difference between a headed stack and a headless one?
Edit: I'll reply to whatever you're replying later today.
Short for "spacing out," meaning, in this case, a momentary lapse of memory. Also used for when you're supposed to be doing something but your mind wanders onto something else entirely.
Whether or not it starts with a hat block. I confused you by calling it a "head block," another case of spacing out. :~)
Well for that, we'd need to be able to ringify hat blocks.
Ah. Anyway, you got it right. (question mark)
Getting an accurate formal description of Snap! syntax comes first. Then we can decide how to represent the abstract syntax tree as first class data, and you're right, there should be a way to construct a headed scrtipt.
seems good. I definitely don't want all of this:
Yes, please.
I prefer to think of it as non-terminal at the root of every subtree rather than non-terminal as the first element of every sublist ... Not sure if it ends up different.
So we have this?:
stack := hat? instruction*
hat := a hat block
instruction := command-block variadic-inputs
command-block := a command block
input := literal | expression | variadic-inputs
literal := a text | a boolean | a number
expression := expression-block variadic-inputs
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
Yes, you're right of course, but we represent trees as lists with the root datum as the first item and the subtrees as the butfirst.
But we could just define type every non-terminal :~)
More or less. I think this
isn't quite right because the syntax has to allow for the three different ring shapes. And I'm not sure that just including input-list as a kind of input is adequate to account for variadic inputs; there should be a "variadic" nonterminal. And "input-list" confused me because that more properly names the INPUT LIST: variant for variadic inputs. (Yes, it comes to the same thing semantically, but the goal is to be able to represent the user's code faithfully.)
There willl be lots of details to work out. Think about trying to represent how Snap! decides whether to substitute actual arguments into empty input slots in an instruction/expression under RUN/CALL.
There isn't really any difference between how they're executed, only in how they're used to make a program.
Yeah, I'll add that.
What else am I supposed to call what gets SPLIT from a variadic input or gets JOINed into one?