Jens decided that the script made by JOIN of a syntax tree should not be a closure; it has no access to any variables outside of itself, not even global ones. I think you can work around this with
so jens basically hates this? but hes googly eyes over javascript prototypes? which you hate... god how come the stuff i want to make has to have some war raging on about it that i dont care about. but check it out, i had an idea; link
you're misrepresenting me here. I was pointing out to Brian that JavaScript is exactly doing what he thinks a prototype system à Henry Lieberman should be doing, and that he's wrong about what he claims JS does. Yes, I love it. And yes, I also love closures and whatnot and all the functional hacks. But I don't believe in abusing them to make functional programming become stateful. For this there's OOP. Real, actual, OOP, either prototypical or classical. In general, abusing closures (or promises, continuations etc.) as "callbacks" to enable reentrancy after being forced to yield to some priority "system" process must be among the worst hacky, brittle and fragile architectures ever invented.
apropos: When Dan Ingalls first wrote Smalltalk he did not use LISP, but he wrote it in BASIC.
no. i wasnt representing you those are ? marks, i dont understand what frustrates you but i feel like its alot of the things i like to do, or try to do. sometimes i use snap to make a project. but its not my first or second or third choice... its too slow to build anything big and ive made big projects that ive spent lots of time on but had to give up on because there was just too much going on for it to keep up with. but i do use snap alot to visualize programming concepts. i love how you can see the structure of an algorithm, i like designing things like data structures and all the different operations that can be preformed on them. i will never get tired of implementing vector dot product, norm, abs, cross prod, ill always implement every single trig function into my complex number libraries even though ill be using three of them. and im not even talking about snap, well, i am but i just like that kind of thing in programming. i also like to rebuild things im familiar with from javascript or elsewhere in snap. like objects, not oop objects just key value associated arrays, functions i can define in the script with a name that i can call. and i do like abusing programming techniques and do things the 'wrong' way. i literally have a tapermonkey script for the snap editor that literally has
lol. just waiting for that to break when someone makes a shiftKey = world.currentKey === 16 variable.
i taught myself how to program so i really dont understand alot of the, i guess passion behind different conventions and rules to what youre 'allowed' to do or should be allowed to do or whatever. especially in snap where it literally seems like there are pieces of all different kinds of programming practices like you have oop AND functional pieces already so why is it when i want to utilize these pieces to do something that seems so natural to me (functions with closures), why does that cross the line. i dont even necessarily want 'abuse' it i just want to be able to see it in action. and everything is abusable. you can abuse the call stack and crash snap. ive done that numerous times, on accident. but i dont even know what you mean;
i have like the vaguest idea of what you actually take issue with, i dont know if it with what im doing or how what im doing relates to all that, i have no idea beyond what youve mentioned who Henry Lieberman or Dan Ingalls are, and im not stupid its just foreign to me. i didnt go to school for this, and i have alot of hacky, brittle, fragile architectures i hold close to my heart.
For what it's worth, I don't think there's such a thing as "abuse" of a feature. Sometimes there are better ways to do something, and the job of a teacher is to provide examples of the better way, but in the specific case of functions as callbacks, I think that's far from abusive; it's one of the things first class procedures are for! I don't understand why that pushes Jens's buttons either.
So, the takeaway message for you is that it's possible for people to collaborate, really closely and (imho) successfully, without agreeing about everything. That includes you; you don't have to agree with Jens or with me about how to program!
If it were me, I would have made JOIN make a procedure that at least closes over the global variables, if not the current environment. That would make it easier to use in contexts other than the ones Jens had in mind when he built it. But I think, I'm not sure, the issue for Jens is that he wants us to think of JOIN as making a script, rather than as making a procedure. At one stage in the development of that feature he was even considering wrapping something other than a gray ring around the result to emphasize that it's a piece of syntax rather than something callable. Perhaps we should have a LAMBDA block that you could wrap around the script from JOIN to close it in the current environment!
But instead we have the THIS block that makes environments first class, and instead of a LAMBDA block we use OF to combine a script with an environment.
But anyway, you can use dardoro's code to achieve your goal, I'm pretty sure.
Oh, Dan Ingalls was the principal author of Smalltalk, the language that introduced object oriented programming to the world. If you're interested, you could check out this great talk that he gave about it:
Henry Lieberman is an MIT computer scientist who developed the framework for prototyping OOP that we use in the design of sprite clones. Here's his paper explaining the ideas:
jesus christ im saying that youre talking about all these technical things im not familier with!
this i reread over a few times and did google because i wasnt sure what it meant.
i have no idea what distinction youre making. dont know what fake oop is
dont know how they work, barely know how to use them
black magic
what are you talking about
dont know what it means
dont know
what any
of this
stuff is!!!
ive never written in smalltalk lisp or basic. if i have its been practically negligible. and what do these things have to do with what im trying to do??? im starting to doubt that you really even know what youre talking about because youd rather gloat over me not knowing things rather than explain yourself. why are you so mean? its really incredible you can be so smart and yet not know how to be treat people... i hold no ill will toward you so you have no right to be as rude as you are to me! ffs i thought of you as someone worth looking up to but now im just losing my respect for you.
That one you could have just looked up! It means "about," or "having to do with." :~)
I don't know what Jens means about "fake OOP" either.
A promise is just a procedure with no inputs, being used to represent an action you're going to take "later." Sort of like "I would gladly pay you tomorrow for a hamburger today." (Does anyone know about Popeye any more?) We use promises to make streams, which are like lists, except that only the first item has actually been computed; it's combined with a promise to compute the rest later. The TAIL OF STREAM function cashes in on the promise, but don't think that does all the work at once, because the tail of a stream is another stream, so TAIL just computes its first item (the second item of the original stream) and makes a promise to compute the rest later.
The reason promises work as desired is that when you wrap a procedure (a gray ring) around an expression, the resulting procedure remembers the environment (the variable name➞value bindings) in which it was created. So, no matter when it's cashed in, it does the computation that was intended when it was made.
Continuations are indeed pretty magical, but think what Snap! has to do when it's partway through carrying out a script. Once it finishes handling the block it's handling right now, it has to think, "okay, what's left to do?" That "what's left" is called the continuation of the current block. Every interpreter for every programming language has that notion of "what's next"; sometimes they call it the PC, for Program Counter, which is a pointer to the next machine language instruction in memory. What's special about Scheme interpreters, including Snap!, is that we reify the continuations, which means that we make them visible to the Snap! programmer as data. That's what turns the simple PC idea into something magical, by letting the user arrange to redo the computation following this block from some other point in the program.
I hope that's a little helpful. But it's not crucial that you understand promises or continuations to program in Snap!.
Really the main point is that Jens sounds arrogant in this thread because you think he's talking to you, when he's really talking to me. (He may think he's talking to you, too; I'm not sure. But he's really talking to me.) The two of us are jointly guilty of hijacking your thread, for which I apologize. I like to think it's helpful for the users to listen in on our arguments, but that could be wrong.
He's still someone worth looking up to; you were right the first time. :~) I promise, his stance toward you is anything but gloating.
The proper use according to Jens, you mean? Bear in mind that I'm not Jens, and this isn't a complete answer, but the simple answer is that he expects you to use the script you made with JOIN as the procedure-body input to the DEFINE block. When you make a procedure in the block editor, the script hanging below the hat block doesn't have any particular environment in mind as a piece of notation (syntax). It's just blocks. When you say OK in the block editor, it turns that script into a procedure, along with its inputs and any variables available globally.
I don't have the time or energy to debug your code right now, so I can't really say whether you've run up against a limitation in Snap!, as you think, or just a place where the necessary incantations are less than obvious. I'll try to get back to it later this week but lately I've been bad about keeping promises so I'm not going to make this one. :~/