Scratch

bharvey wrote:

Panther allows it by having an orange oval with a text slot inside it into which you can type a name or drag an expression that computes a name.  Is that what you're after?  I suppose it's possible -- Logo does it, Panther does it, so we could too.

I don't like this solution.
I think variables should have a drop-down menu button on the left (it won't be "embedded" like the other drop-downs) where the user can select from the following menu:

Foo
Bar
Baz
----
text

The first few are variables names, useful for using a new variable name or dragging the wrong block in. "text" lets the user type in a variable name or use a reporter (which can also be dragged onto the little drop-down arrow directly.

Demo:
     (some reporter)
(MyVar▼)
          ↑ only an area around this is the drop zone
↓

( (some reporter)▼)

From here, if the user selects something from the drop-down the reporter will be kept in the world but moved slightly down and left from where it was and the user's selection will come up on the reporter.

Last edited by nXIII (2010-09-03 22:06:58)

I think there should be something as simple as a {create variable [] } block. That would solve the problem without too much hassle.

shadow_7283 wrote:

I think there should be something as simple as a {create variable [] } block. That would solve the problem without too much hassle.

I went back and re-read your original post (a page ago) that started this discussion, and I realized that I don't really see how your proposed feature would help solve the problem you give as an example.

Here's the APPEND block in tools.ypr:



I didn't have to create variables on the fly for this; I just used a small number of fixed-name local variables.  Could you give details about how you'd use your CREATE VARIABLE block to do this?

I'm not saying this to oppose the idea; I just don't think I'm understanding what's behind it and need clarification.

Last edited by bharvey (2010-09-04 02:00:59)

[join lists [list1] [list2] ]
set i to 1
repeat length of list1
create variable join [a] (i)
set join [a] (i) to item i of list1
change i by one

set i to 1
repeat length of list1
create variable join [b] (i)
set join [b] (i) to item i of list1
change i by one

repeat list1 + list2

Ahh... wait. I can't do that.
So yeah, I guess it wouldn't help solve this particular problem. But I still want temporary variables!

bharvey wrote:

fullmoon wrote:

Then we'd need the Panther universal variable block, right?

Right.

Which basically turns the variable space into an array with string keys! Don't we have a library for that? 

fullmoon wrote:

Which basically turns the variable space into an array with string keys! Don't we have a library for that? 

Indeed.  Two of them so far, yours and Rubik's.  (Well, technically, variables are a little different because they have scoping rules, whereas a dictionary is flat.  But still, basically the same idea.)

What Shadow wants is a different syntax, in which you don't have to call a block like LOOKUP <text> <dictionary> but can instead just invoke <text>.  Also he wants them temporary, meaning that they disappear when a script is done, but that can be handled by putting a dictionary in a local variable.

And I'm pleased to report, Shadow and nXIII, that BYOB can already handle the syntactic part; I just did an experiment.  Make a block, call it FOO, then in the block editor, click on the word FOO in the prototype and change it from title text to input name, of type Text.  Tada!  The Panther variable block.  (Supposing that you give it a script that looks up the text in a dictionary.)

bharvey wrote:

nXIII wrote:

No! Use my block! It acts like a normal variable block, but it can accept reporters and gives you the (largely hidden) option to type into it.

I see, the reason you like this approach is that it discourages people from creating variable names on the fly, even while allowing it?

Why not include both?
One can make a variable that stays, and one is temporary!
(I discourage arguing over blocks  )

bharvey wrote:

And I'm pleased to report, Shadow and nXIII, that BYOB can already handle the syntactic part; I just did an experiment.  Make a block, call it FOO, then in the block editor, click on the word FOO in the prototype and change it from title text to input name, of type Text.  Tada!  The Panther variable block.  (Supposing that you give it a script that looks up the text in a dictionary.)

I don't want a type-in variable reporter!

bharvey wrote:

But we seem to have just demonstrated that anyone who wants it can provide it as a library.  Umm, if we want an exact simulation of variable syntax, then it would be nice to be able to have a SET [text] TO (value) block distinct from the primitive SET {dropdown} TO (value) block.  Jens, what do you think about allowing overloading like that?

I asked for that before! I want that too!

In fact, just overload BYOB3 with features. Fill it to the brim! 

Tell me whatcha think!!!!

bharvey wrote:

xly wrote:

bharvey told me that this was incompatible with the "pick-and-stick" Scratch design.

It's certainly a move in the direction of conventional text-based programming languages.  I'm pretty sure that if we proposed this as a language primitive the Scratch Team would promptly reject it as unScratchly.

But we seem to have just demonstrated that anyone who wants it can provide it as a library.  Umm, if we want an exact simulation of variable syntax, then it would be nice to be able to have a SET [text] TO (value) block distinct from the primitive SET {dropdown} TO (value) block.  Jens, what do you think about allowing overloading like that?

As for the Logo DEFINE, that's doable too, with a dictionary in which the values are scripts.

Now all we need is dynamic scope and we'll have all of Logo! 

Well,whatever you're talking about,I know that some functions are impossible to create even with a program as powerful as BYOB 3.

bharvey wrote:

it would be nice to be able to have a SET [text] TO (value) block distinct from the primitive SET {dropdown} TO (value) block.

Hey, it turns out that you can make a custom block of that form in BYOB. 

So we can easily provide Panther-style variables, with a couple of caveats: (1) These variables are all essentially global, not scoped.  This can be fixed by starting a new dictionary on entry to the relevant blocks and restoring the old one on exit.  (2) These variables are separate from the ordinary Scratch-style variables.  You can't type the name of an ordinary variable into the text field and expect that variable to be set or read.