The result of this script is unexpected and inconsistent.
"delete idx of list" for idx:
0 - removes last element
-1.. - (last - abs(idx) )
Expected behavior (one of):
a)Throw an error for idx not belonging to [1..list.length]
b) Do nothing, at least for "0". Useful for
c) follow the JS for "splice" (idx < 0 as relative to end of list) AND b)
IMHO c) is the greatest result with minimal effort.
I think 0 should do nothing and negative numbers count from the end. (My PL enilKode would do that.)
EDIT: I agree with c)
I would throw an error for 0; I don't like it when a command does nothing because it makes code hard to debug. But this may be a losing battle; we inherited from Scratch any number of cases of a block silently doing nothing for bad inputs.
As for accepting negative numbers, I'm neutral, except to note that if we make that change in DELETE we should do it in all the List blocks that take index inputs, starting with ITEM.
What are some examples of this?
Thanks. I totally forgot about putting variables into the inputs. Most of those blocks prevent you from putting wrong values in by hand, so you would assume they would give an error with the wrong input, but they do not. I would argue for giving an error, if you really need the functionality of errors passing silently, just using a try-except block. In my opinion, giving no errors is useless: the block does nothing, but it also acts as if nothing is wrong. It is not as big of a problem with the blocks such as 
, because the input obviously has to be a number..This could be especially annoying in cases like the 
, as the input is not the wrong type, you could have just spelled a sprite wrong.
The original (Scratch) theory was, I believe, that errors are offputting to beginners and so there shouldn't be any.
The new (Jens) theory is that putting type checks in primitives is a significant slowdown of Snap!, and not useful in what is hopefully the common case in which the user didn't make a type error.
I agree that for our main use case of teaching teenagers computer science, an error message is much better than a silent failure, because it helps tremendously in debugging.
This is the one benefit of strongly typed languages (i.e., ones in which types are associated with variables rather than with values): They get to have their cake (catching type errors) and eat it too (no type checks at runtime).
Would this slowdown affect errors such as 
, where variable is not the name of a sprite, if such error checking was implemented?
Yeah, but I'm sure we do check that; you don't get an error message but you do get False, rather than Snap! blowing up.
additional informations:
if Jens want to keep "0 or negative index" in the delete block, i've made some tests with others blocks
This result is ok (delete block):
This result is ok (delete block):
This result is ok (insert block):
This result isin't ok (insert block):
.
.
.
All blocks should act in the same way:
Nothing appends here:
(should insert "thing" at record 4)
Nothing appends here:
(should insert "thing" at record 3)
Nothing appends here:
(should report 13)
Nothing appends here:
(should report 12)
we use negative indices in different ways in Snap, not meaning offset from the end of the list. This actually turns out to be an important feature in many of our MediaComp projects, it lets us create beautiful audio-effects such as "echo" in very expressive and concise ways. For the replace block we have altogether very different plans of how to use indices in a much, much more general way that also embraces non-numerical indices. This has been a longstanding design plan that I just didn't yet get around to implementing, as other features have been more urgent (such has helping educators hide stuff and turning of functionalities so teachers can produce dumbed down little programming languages of their own, grump ^^).
