2 bugs in "create variables" library

  1. I am in sprite2 script and i want to create a local var in sprite (another sprite) so i tell sprite to create a sprite var. If this var already exist in the local sprite (here:sprite2), the var wasn't created in the sprite environnement... but if the local sprite doesn't have this var in his environnement, it work, the var will be created in the sprite environnement

don't work:
image
result:
image
.
.
.
will work:
image
result:
image
.
.
.
this one work:
image
result:
image
.
.
.
2) I am in a sprite2 script, if i execute this (tell sprite), it is executed locally instead of in "sprite" even if i "ask sprite for"...
image

Just tried 1 out in Snap!7 dev and it seems to work OK

Issue 2 doesn't work for me in Snap!7 dev

This modification seems to work

image

Folks, I don't see any use case for the make-variables library except for some funky initialization of mostly badly designed libraries (like the abominable case-sensitivity flag in the strings lib). You need to learn about using lists! Also, this horrible pattern of writing a "master" script that remote-controls other objects via tell and ask is really, really worrying me. Where does it even come from? Each sprite has its own scripting area and its own local variables. Where does all this horrendous need for meta-programming come from? Nobody ever dynamically creates or accesses variables in Python or Java! What's even going on here?

I think I'm going to take out the make-variables library for v7 altogether and make it so you can't use it outside of a few legacy situations.

I'm also really, really worried that these discussions convey the impression that adults and professionals somehow code in enigmatic ways and always use tell and ask. Please, please, please don't do that to learners! Snap! is an actor system with parallelism, not a graphical framework for BASIC.

Like so many teens trying to find some deeper truth in JS that's not there you're chasing an illusion with using the variables library. Names are for wimps, that's why we have first-class things in Snap!

I personally thought that was what these blocks are meant to do.

What was the original purpose of providing them?

Just "asking" :slight_smile:

tell and ask are indeed meant to let one object communicate with another. What's puzzling - and annoying - me is the combination with "making variables". I repeat, there is not a single case where going meta on variables is even the beginning of a good idea, nobody ever does it in the real world.

For what it's worth, I think (1) we shouldn't try to prevent people from using a programming style we don't like; and (2) if I did want to rule out bad programming style, there are lots of things higher on my list than programmatically making variables, such as repeatedly copy-pasting code instead of writing a procedure.

Here's an example in which real-world programmers create variables programmatically: You're writing a declarative programming system, and in the resolver, when you find a rule whose conclusion matches the query, you rename all the variables in that rule, and take the body of the renamed rule as a new query.

Long ago, when I wrote a Basic compiler in Logo for CSLS, a Basic variable FOO was compiled into a Logo variable %FOO.

Could those examples be done using an association list to simulate variables instead? Yes, of course. Anything can be done on a Turing machine with no variables at all. But using variables to simulate variables is more natural and, I think, leads to a more readable program.

And in the Lisp community there are macrologists who do metaprogramming all the time! You can use macros to layer a domain-specific language on top of Lisp. I'm only a novice macrologist, so I don't have examples at my fingertips, but your sweeping characterization of metaprogramming as something nobody does is wrong.

Would you be happier, by the way, if the variable creation was in a method of the target sprite, and the TELL just told that sprite to run its method? In other words, how much of your annoyance is about putting all of the program in one sprite and just using the others as slaves? That annoys me, too, although I think it's a natural first step for someone who learned to program in a non-OOP language in which there's just the one program, without a thread scheduler. So I would want to wean such programmers away from that style gradually and without yelling at them.

Nobody writes constraint solvers that way in Snap, this is ridiculous. And you pointing out that some obscure contraptions resort to meta-programming makes it all worse, because now folks actually believe that what is really an intellectual mirage might be some super advanced hackery. I repeat: If you find yourself needing to dynamically create variables you're doing it wrong, and I will tell you, so you know better. Make a list, make a dictionary. Just because you find a library with blocks that look like they address your issue doesn't fix your wrong concept.

Afaik nobody's written a logic programming resolver (not quite the same thing as a constraint solver, I think) in Snap! at all! But it's on my list, and when I do it, that's how I'll do it, because that's the textbook solution. It's how you're supposed to do it.

Another example is hygienic macros, which also work by renaming variables, although they do it in a local scope so you don't see those generated variables among the global ones.

I don't think that's fair. Okay, my program to compile Basic into Logo is an obscure contraption, but logic programming and hygienic macros are totally well known, at least in the programming language community.

We can talk more about this after I see your macro project tonight!