some terms that are related and get thrown around:
sprite
object
lambda/function
environment
dictionary
assoc(iation list)
i think the way MOST people think of things in snap is that a sprite is an object, a lambda has an environment, and a dictionary can only be created as an assoc.
the way i think of it is that sprites and lambdas are objects, objects have environments, environments are dictionaries, and an assoc is a different datatype that serves the same purpose as a dictionary, but is more accessible due to scratch limitations.
rethink the _ of _ block! take your variables, make new ones, pass them around, etc.
@bh i think this helps illustrate some of my concepts from these posts, some less than others:
Everything is an object, in the sense that what we pass around is a pointer to the actual datum.
It was very natural to expose some of the innards of sprites-as-objects because Scratch already had the idea of one sprite being a clone of another sprite (but not really, because their MAKE A CLONE block actually makes a copy, with nothing actually shared with its parent).
No block language before us had lambdas, so we could think of them however we wanted. So we followed the precedent from Scheme (as we do for most new language features), in which functions, while first class, have no user-visible insides. You can't even ask for the code inside a lambda expression, let alone its environment. We have just, for the first time, changed that to provide a primitive metaprogramming toolkit. ("Primitive" as in "feeble," not as in "built in." Working on hygienic macros.)
Lambdas actually get their remembered environment not only from the procedure in which they were created, but also from the sprite in which they were created. The latter is a richer kind of environment, including all sorts of data other than variables: its position, its direction, its pen color, its costume, and so on. If we're going to expose all that to users as a dictionary, we'd want to do some hard thinking about how that'd affect the total design of Snap!.
How you implement dictionaries is an irrelevant side issue. All that matters is its visible behavior, namely, you can add words and their values, and you can ask for the values of a word.
(By the way, ASSOC is the name of the lookup procedure for dictionaries, but you don't use it as a noun. The corresponding data structure is called an alist (pronounced "ay' list").)
You want continuations to be properties of lambda expressions, but lambda expressions don't have continuations. A running λ has a continuation, namely the code outside it in its context in the larger script.
I think it would be possible to give you some of what you want, but it's not going to help with your original problem about pausing a script, because that's against a Rule, namely that all scripts run in lockstep, to make results repeatable. This is a longer discussion than I have the energy for right now, but Jens believes in it quite strongly, which is why there's no PAUSE THIS SCRIPT block.
You want continuations to be properties of lambda expressions, but lambda expressions don't have continuations. A running λ has a continuation, namely the code outside it in its context in the larger script.
i don't want continuations to be properties of lambdas, i'm well aware of that. i'm thinking more along the lines of (continuation(s) of [other functions in environment v]), and i've put some ideas in this project
i was going to try and put some more work into it first but i feel like i'm getting misinterpreted too quickly and need to try and correct it
Okay, sorry, I'll look at your project after I eat some food. I'm faint with hunger!
Yum! An unsolicited testimonial to Kevin's Cilantro Lime Chicken (somewhere near the Pulled Pork at your grocery) and Double Rainbow Ultra Chocolate ice cream!
I looked at your project. You have some interesting ideas.
There's some history about the scope of "stop this block" and "report." Namely, people want to say, e.g.,
or, if BAZ is a command block, STOP [THIS BLOCK] instead of the REPEAT.
(Never mind that we made FIND FIRST ITEM a primitive!)
That's what everyone wants: THIS BLOCK means BAZ anywhere in the block definition. It turned out to be hard to implement that, but Jens did it eventually and we're unlikely to change it.
CONTINUATIONS OF [ALL BUT THIS SCRIPT] is a little unclear in specification. What if 100 clones are running this script at once?
Okay, that's all I can do until I get some sleep. Bodies are annoying.
from what i've seen, THIS SCRIPT, W/CONTINUATION, and STOP all operate on the script, which is just the blocks that can be seen connected at once in a sprite, and would have to have a hat block at the top to ever be ran. any blocks called from it are part of the script, since STOP THIS SCRIPT will stop areas outside a block.
stop this block is similar, but without the sprite rule, it's just the blocks that can literally be seen connected
interestingly, if sprite A tells sprite B to run a script, it's in sprite B's context, but it's sprite A's script.
i think ALL BUT THIS SCRIPT is clear enough, when you STOP THIS SCRIPT, it doesn't stop the same string of blocks in every clone. this means that ALL BUT THIS SCRIPT would get the continuations of all of those.
i don't have much issue with the existing controls for these blocks, and i'm not suggesting changing them, just adding new ones that work based on environment instead, so if sprite A tells sprite B to run a script, telling sprite B to STOP OTHER SCRIPTS IN ENVIRONMENT will stop it, continuations can be grabbed from existing functions, and told to stop, etc
also i think continuations would actually be easier with that dropdown because now that i'm thinking about it, i don't know if continuations normally operate on the script or the block. i think it would also help that it's more clearly related to the stop block and that it subtly points out that the reason it's RUN WITH CONTINUATION and not just a CONTINUATION reporter is that it gets the continuation of the area after that block, and needs a way to do something with it before running it
Ah, something I actually understand. A CONTINUATION reporter would, I presume, be used /inside/ the script, so its continuation would include the rest of the script, which isn't what you want. You want just what's outside the script, so the capture of the continuation has to happen outside the script. But if the reporter is used outside the script, then the continuation would include saving the continuation, so when someone eventually calls the continuation it'd overwrite itself with who knows what.
Maybe that's what you said, I'm not sure.
A variant of call/cc that some people like is let/cc, so you can say
(let/cc my-continuation (action-of-block))
which automatically makes a temporary variable holding the continuation that's available inside the action part.
that's exactly what i said. my proposal has a RUN W/CONTINUATION(S) with dropdowns for everything that includes the script itself, but a CONTINUATION(S) OF for everything that doesn't include that script (getting the continuations of other scripts).
all the dropdowns in that project have all the things listed in them unless they say otherwise (usually just missing sprites from the dropdown), you can see exactly what they should look like
just don't get them confused with the actual current blocks
