The paradigm of containers and self-referenced names

Dar Scott dsc at swcp.com
Wed Mar 23 11:36:45 CST 2005


On Mar 23, 2005, at 9:58 AM, Ken Ray wrote:

>> The meaning of a name in Revolution--container or literal--depends on
>> its usage beyond a particular instance.
>
> I think that if Rev were modified so that it would not accept unquoted
> strings to be assigned to variables we'd be in a much better place, 
> and it
> wouldn't give aid to "sloppy" (IMHO) programming.

(I'm not sure why the "to be assigned to variables" qualification.  I 
assume you mean anywhere.)

I see merit to this.  It would not break my scripts, but I suspect it 
will break a lot of scripts.  I would not whine if this happened.

However, there might be a compromise that preserves some of the 
heritage:

1
One possibility might be as you state, but add a new declaration, 
perhaps like this...

token apple

...which is virtually equivalent to...

constant apple = "apple"

...but might take up less memory.


2
Another might be a great simplification of the rule that determines 
which it is.  Along with reliable highly-differentiated colorization, 
too!  I think this would respect the heritage.

This would break very few scripts and those it does break are probably 
in trouble.

This might be the friendliest to the heritage.


3
Another might be that the initial value of every container is its name 
and there are no unquoted literals.  This is gentle to both 
traditionalists and crossover programmers.  Some crossover programmers 
make this assumption at first.

That would break some of my sloppy scripts and I imagine would break 
other folk's.  This would be mostly in the initial value of a container 
that accumulates values as a loop executes.

Some scripts would have to add...

local newList = ""

.. or ...

put empty into newList

... at the top.

Even though this would break some of my scripts, I would be fine with 
this.

This would break a few traditional scripts in places that depend on 
name/literal differentiation in strange ways.  Those may be flawed 
anyway, but I'm not sure.


4
Other?


Dar Scott




More information about the use-livecode mailing list