Scratch

Jens wrote:

And yes, everything will be incredibly clever, of course! 

I forget who said this, some software engineering guru, but since it's harder to debug code than to write it in the first place, if you write code as cleverly as you can, then you can't debug it!

So, you mean, everything will be incredibly standard and built out of off-the-shelf components whenever possible, right? 

shadow_7283 wrote:

Is there someway to prevent this behavior?
EDIT: I thought "Copy of" would do the trick, but I suppose I was wrong.

"Copy of" will do it unless you have a list of lists; "Copy of" does only a toplevel copy, so sublists are still identical in the two versions.  You can write your own "Deep copy of" that recursively copies sublists.

I'm a little surprised that you want a deep copy, though; that's unusual.

PS  It's not that the variable changes when you change the list.  The value of the variable is a pointer to the list; that pointer remains constant even as the contents of the list change.  Technically every value is a pointer, but you can't tell the difference unless the thing pointed to is a mutable structure.  For instance, if there were a "Replace letter (n) of (string) with (letter)" command, the same issues would arise with strings.

EDIT:  I keep bugging Jens for a version of = that tests pointer equality (EQ?) rather than value equality (EQUAL?), but we need suggestions about a good name for it.  IDENTICAL? is one semi-standard name, but I'm not sure it's self-explanatory if you don't already know.  I'm almost tempted to call it ENTANGLED?, as in quantum entanglement, where changing one particle magically changes the other one, but I'm not sure that passes the obvious-to-an-eight-year-old test.  And technically entanglement is different because there really are two separate particles, whereas there's only one list if the two inputs are EQ?.

Last edited by bharvey (2012-10-02 00:11:31)

I wanted to make a value comparison between two lists- one from an older point in time in order to test for potential changes.

bharvey wrote:

EDIT:  I keep bugging Jens for a version of = that tests pointer equality (EQ?) rather than value equality (EQUAL?), but we need suggestions about a good name for it.

IS?

@jens, es funktioniert alles ausser die drop-downs (oder wie sie auch immer heissen), z.B. left arrow, last, number/list/Boolean..., das mit dem Turtle Kostüm und dem About Text, der nicht übersetzt wurde (ob es auch sinnvoll wäre?)
gute Arbeit!

Last edited by roijac (2012-10-02 08:52:05)

Hardmath123 wrote:

In my perfect world, (deep)copying would be implicit. To create a pointer, you would use a special syntax

That's like the C &var notation for "the address of var."

But in a really perfect world, people would program functionally, and would refrain from mutating things, and would construct a new partial list when necessary to update a value, and then the old variable would still point to the old list as shadow wants.

But, the point is, there's a difference between pointers (which are unavoidable) and making pointers visible to the user.  You need pointer variables only if some values are pointers and some aren't.  If every value is a pointer, as in Lisp-based languages, the user never has to see a pointer, because the language semantics automatically dereferences them.  Java took a step in that direction by replacing C's pointer values with reference values, but (as with a lot of Java features) they compromised about it, leaving the references user-visible.

For the kind of huge data sets seen in real-world programming these days, putting gratuitous deep-copying into a language would really slow things down a lot!

joefarebrother wrote:

bharvey wrote:

shadow_7283 wrote:

Is there someway to prevent this behavior?
EDIT: I thought "Copy of" would do the trick, but I suppose I was wrong.

EDIT:  I keep bugging Jens for a version of = that tests pointer equality (EQ?) rather than value equality (EQUAL?), but we need suggestions about a good name for it.  IDENTICAL? is one semi-standard name, but I'm not sure it's self-explanatory if you don't already know.  I'm almost tempted to call it ENTANGLED?, as in quantum entanglement, where changing one particle magically changes the other one, but I'm not sure that passes the obvious-to-an-eight-year-old test.  And technically entanglement is different because there really are two separate particles, whereas there's only one list if the two inputs are EQ?.

<() exactly the same as ()>, maybe?

too long and confusing

maybe <() points to ()>
also, i wouldn't restrict it to lists, as sprites (clones) and scripts are also mutable.

Hardmath123 wrote:

Scripts aren't mutable (yet), right?

but it would make sense if they would be, when jens gets to scripts manipulating

Hardmath123 wrote:

roijac wrote:

Hardmath123 wrote:

Scripts aren't mutable (yet), right?

but it would make sense if they would be, when jens gets to scripts manipulating

How would you even go about representing a script as something mutable? As a list-of-lists structure?
[/offtopic]

Yeah, I agree with roijac.

list of callables (blocks, lambdas, etc.)

Last edited by roijac (2012-10-03 06:00:24)

bharvey wrote:

Hardmath123 wrote:

How would you even go about representing a script as something mutable? As a list-of-lists structure?
[/offtopic]

Not offtopic at all.  Yes, lists of lists of values, including procedure values.  But that isn't actually the internal representation of a script, so I envision a SCRIPT->TEXT block whose input is a script, reporting a list, and a TEXT->SCRIPT block that does the opposite.  Or perhaps, as in Logo, a DEFINE (name) (text) block that makes a new block in the current scope from a list-of-lists.  But, note, this means that scripts themselves would not be mutable.  You'd turn the script into a list, mutate that, and create a new script that might replace the old one as the definition of a block.

Sprites, though, are a better argument, since they have local state variables and are therefore already mutable.

The trouble with () POINTS TO (), in my mind, is that it suggests an asymmetry: the left input has data type "pointer" and the right one doesn't.  COLOCATED WITH says exactly the right thing, but it's a mouthful.  Maybe we should just stick with EQ? or, for non-Lispers, ==.

maybe rename <() = ()> to <() equals ()> and then we have also <() is ()>? then the difference is clearer.

#scripts, i suggest to implement scripts as lists of blocks, and make kind of (args of ()) block or something. what do you say?

@bharvey
" as in Logo, a DEFINE (name) (text) block that makes a new block in the current scope from a list-of-lists."
As far as I remember (30 years ago !) the DEFINE Logo procedure is composed of a header (name of the procedure), then a kind of "constructor" and the "body" made from a list (or list-of-lists)...The result is that you can change "interactively", directly from an application the nature and the role of the procedure created by DEFINE (adding or deleting items).It' s a self-adaptive custom block. This could probably be emulated in Snap! using  C-Shape like instructions.

How about a list-of-list structure of lambdas?

when gf clicked
say ((1)+(1))

becomes

[
 [when gf clicked],
 [say, [+, 1, 1]]
]

where +, say, and when gf clicked are actually the lambda (the () block) versions rather than text? You'll also need a (lambda = lambda?) operator, though.