related to some discussion here
i don't know if this should be a feature request or a bug fix
there are many places that refer to scripts and blocks:
STOP [this script v]
STOP [all other scripts v]
STOP [all other scripts in sprite v]
STOP [this block v]
(THIS SCRIPT)
SCRIPT VARIABLES (upvars)...
CREATE [script v] VAR (create variables library)
MY [scripts v]
MY [blocks v]
(all the metaprogramming blocks that create, change, and delete blocks)
(create a block manually)
i will create some terminology myself so i can actually explain what's going on with all of these, and i will always bold them for clarity (if something isn't bolded or part of a block it's a mistake, let me know):
blocks are the colorful things you can drag from the palette and put together to create visual scripts, not including hats (hats can't go in procedures)
custom blocks are the blocks created by users, used for things like splitting up visual scripts
procedure refers to code under a hat block, in a custom block, or in a ring. a procedure doesn't include what's outside its ring or visual script (excluding metaprogramming), it does include any rings inside it, but not the contents of custom blocks. these can be found by creating variables with the SCRIPT VARIABLES block, and seeing whether that variable can be accessed from that location.
visual scripts are the blocks that can be seen as visually attached in the editor. they often have a hat block at the top.
control scripts are the blocks that run
this mostly matches the visual script, except that LAUNCH contains a separate control script, and the contents of blocks are all part of the same control script. all control scripts are part of sprites (this is a bug! i'll link the thread here when i create it)
these can be distinguished by putting a wait block somewhere, and seeing if code in another place keeps running. if it does, they aren't the same control script.
everything that's called "script" has very different behaviors:
STOP [this script v] stops the control script
STOP [all other scripts v] stops other control scripts
STOP [all other scripts in sprite v] stops other control scripts that have an environment that goes up to the same sprite (conveniently all scripts have a parent sprite, see the bug above)
SCRIPT VARIABLES (upvars)... creates variables in the procedure
everything in the create variables library is somewhat confusing, getting the variable with the text block doesn't behave the same as the regular variable reporters. i think (VAR [ v]) and <DOES VAR [ v] EXIST> gets variables in the control script? all these oddities seem to be from these primitives being used in custom blocks, which aren't part of the same function. this could be fixed by modifying the environment of a continuation.
MY [scripts v] reports all the visual scripts of a sprite
"block" is mostly consistent, except for STOP [this block v], which jumps to the end of the visual script.
note that there's no way to stop a procedure without reporting (which should error if CALLed), other than just getting to the end.
(my actual suggestions for blocks will be in the next post, i'm tired of writing this)
I don't think scripts should necessarily have hat blocks. You can run them by clicking on them. I often leave debugging or initialization scripts lying around hatless.
I'm sometimes sloppy about this, but I prefer to use "function" only for blocks that implement functions in the mathematical sense, so, not including RANDOM or ITEM RANDOM OF, no use of global variables, and not including command blocks.
I'm not sure I understand "control script." Does that just mean a script that's running right now?
If you're really trying to explain everything, you should probably include "body" in your vocabulary.
Your explanation for why users make custom blocks seems to me to leave out a lot. The neatness of the scripting area is the least of the reasons. Abstraction, modularity, recursion, building up a library, etc.
i said "should have a hat block" to be more clear, in cases where scripts are clicked it doesn't apply, but in the context of a project you would need a hat block for it to be useful
i wouldn't say a control script is what's running, but it's what will run independently. for example, if you have a LAUNCH block, it and its contents are the same visual script, but different control scripts (they run independently). i don't think whether the script is running should be part of the definition, because without it it's a nice word for analyzing how a script might behave (for example, you could say "find all the possible control scripts of this visual script")
i think all this is missing the point a bit, i'm not trying to give definitions that explain how every person has and will used snap, it's just to get points across. i think most people can understand what a custom block is, i just want to be specific enough that it isn't confused with other words.
what do you suggest i use instead of function? ring doesn't work, not all functions are surrounded by rings, and i think ring just refers to only that ring part, not what's inside. if anything lambda would be even more restrictive than function if you mean the mathematical sense, and i think function is common enough in the coding sense that it's perfectly fine here.
Only if you plan to show your project to other people in presentation mode. If it's a project you're making for yourself, headless scripts are still useful.
I try to use "procedure" instead of "function." Both terms imply that the procedure/function remembers its creation environment. The thing that doesn't (perhaps because its defining procedure hasn't run yet, for example) is called a "script."
And I still have no clue what you mean by "control script."
I find them very useful for many of my projects that I share. Together with comments, they are approximate Jupyter notebooks. And I usually add set presentation mode to false under a green flag hat and share them with &editMode in the URL.
