More defined syntax analysis for variadic inputs part 2

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

(auto-closed just (2 days) after when I wanted to bump the topic...)

I like this one better than the first.

I actually made an algorithm to detect how many inputs there are in a block. I use it in my block encoder

I assume this is done using one of the multiple ways to get the prototype of a block (by getting Snap! to turn it into a string)?

Yes, but if you want I can make another one that does not use the prototype of the block.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.