Why are ring parameters weird?

[bzzzz]

• Snap! 7.3.1
• explicit (variable) parameters:
  • can't call ring with 0 inputs
    
  • can call ring with more than 0 but not enough inputs (missing inputs will default 0)
    
  • can call ring with too many inputs
    
• implicit (empty slot) parameters:
  • can call ring with 0 empty slots with 0 inputs (makes sense)
    
  • can call ring with 0 empty slots with 1 input
    
  • can't call ring with 0 empty slots with more than 1 input
    
  • can call ring with more than 0 empty slots with 0 inputs
    
  • can call ring with 1 empty slot with 1 input and empty slot gets input (makes sense)
    
  • can call ring with 1 empty slot with more than 1 input but empty slot stays empty
    
  • can call ring with 2 empty slots with 1 input and all empty slots get input
    
  • can call ring with 2 empty slots with 2 inputs and nth empty slot gets nth input (makes sense)
    
  • can't call ring with more than 1 empty slot with too many inputs
    
• are there more weird ring parameters behaviours?
• what is logic? (I'm trying to make JavaScript compiled rings understand inputs at runtime)

[cymplecy]

I'd say not to worry about examples of user error of undefined or missing parameters and just handle the ones where a user hasn't made an error in the same way Snap! does

[bh]

@bzzzz

what is logic?

If you give the ring explicit formal parameters, then Snap! doesn't automatically fill empty slots at all.

If not, then the rules are

1. If you give exactly one actual argument, it is used to fill all the empty slots. So you can map over a list of numbers to get the squares of the numbers.

2. If you give more than one actual argument, and if the number of actual arguments is equal to the number of empty slots in the body, then each actual argument goes in one of the empty slots, left to right.

3. If neither of those, then no filling of empty slots is done, because Snap! can't read your mind about what you meant to go where.

[bzzzz]

What are rules for when to error?

Also why just spams Uncaught TypeError: Cannot read properties of null (reading 'fullCopy') in JavaScript console and doesn't show anything (not even Hmm...{newline}{error}) in result speech bubble?
But .
Why and don't behave same?

---

also

[bh]

Because nobody's worried about exactly what message we give when users do weird things. We worry about helpful messages for the usual run of errors, e.g., ALL BUT FIRST OF an empty list.

[odysseus_ssb]

@bh

If neither of those, then no filling of empty slots is done, because Snap*!* can't read your mind about what you meant to go where.

The way I imaagined it is that it would just keep cycling through the inputs each time one is used. So if there's three slots and two inputs it uses inputs (1, 2, 1). This is also consistent with the rules 1 and 2.

[bh]

@odysseus_ssb

So if there's three slots and two inputs it uses inputs (1, 2, 1).

If there are three slots and two inputs, and we assume you want to use each of the inputs at least once, then maybe you wanted (1,2,1) but maybe you wanted (1,1,2) or (1,2,2) or (2,1,1) or (2,1,2) or (2,2,1). I don't think any of these is a priori more likely than any other; it'd depend on the particular blocks and expression types involved.