# More defined syntax analysis for variadic inputs

Currently, splitting variadic inputs by blocks simply puts all of the input's items as separate items in the list without anything else:

I think this might lead to less clean code when dealing with analyzing variadic inputs, requires you to add special cases when another input is after a variadic input, and makes it impossible to differentiate when there are 2 variadic inputs in 1 block.
I propose 2 different solutions to this:

1. Report an integer denoting how many of the next items are going to be items of a variadic input, then list off the variadic items, kinda like how the join block handles constructing variadic inputs:
2. Report a list containing the variadic input's items

in this project there is a block

that splits into that format.

That's for JOIN blocks. not SPLIT by blocks blocks.

It doesn't:

(EDIT: It does, but not for all blocks and I don't think it can differentiate between 2 different variadic inputs in a block anyways)

Honestly I think this might be the best solution. Also, it doesn't take long to test if something is a block.

yes, sorry i am going to try to fix that

Clarifying more about the confusion with block inputs, this is what analyzing a code input looks lke:

So a list property in a splitted block could either mean block input or variadic input, as both are lists.
EDIT: Actually, this won't cause confusion as direct blocks can't be inputs of an analyzed block, only list items representing analyzed blocks.

to work around that, just use input list

For what I'm primarily suggesting this for (my Snap! -> scratchblocks project) this isn't really gonna work for accurate or easy conversions.

I’m going to work on this. It will still only work on a predefined list of blocks, but You can edit that list, and I’m going to try to make it differentiate between different variadic slots
Edit: ok, this might be too hard for me
Well, I hope you find something that works for you

I think small-integer-based solutions are kind of kludgy. (I'm not excited about Jens' use of that either.)

There's a profound underlying problem here that I think might entail a redesign of SPLIT BY BLOCKS to solve. A real abstract syntax tree has a nonterminal symbol as the first element of every sublist. We haven't done that because we haven't written a formal syntax for Snap!, but maybe it's time to bite that bullet. So the JS Function example might end up looking like this:

where compound-expression, variadic-inputs, text, and multiline-code are nonterminals. (There would also be a variadic-input-list one.) (It's called compound-expression to distinguish it from literal data such as the text nonterminal.) Somewhere in the formal syntax would be

literal-data ::= text | number | Boolean | multiline-text | multiline-code
expression ::= literal-data | compound-expression

or maybe including "variable" as a separate nonterminal from compound-expression if we decide that a variable reporter is essentially different from any other niladic reporter.

I hesitate to bring up such a major change to this introspection feature at this late date, but better late than never I guess.

No offence, but that looks like a really bad idea.

I don't know... it might be better, and maybe easier to understannd.

Vs

definitely not easier to understand. but i guess it would help with stuff

Ok, maybe it's easier for a program to understand it, but maybe not ideal for a human.

yeah.
i like the current syntax for variadic inputs, i just wish that it worked for split

I do think that the current syntax works for joining, but maybe not for splitting.

You wanna explain why? (I'm not offended; it's not my idea but rather the standard practice in programming language research.)

No, all the other stuff would be sublists of the EXPRESSION list; an expression consists of a block and its inputs.

it isn't very readable, it has a lot of more complex words like "variadic" "expression" that beginners wouldn't be able to understand at all. i like the current syntax, but i wish it worked with split

Edit:

Using blocks for code instead of text isn’t the standard practice