The paradigm of containers and self-referenced names

[Dar Scott]

On Mar 22, 2005, at 10:18 AM, Mikey wrote:

>> A scary example of that ......
>> I bet most Rev programmers would agree that
>>     put myVar+3 into myVar
>> and
>>    add 3 to myVar
>> mean the same thing (assuming myVar is an ordinary local variable).
>> But if myVar is an implicit, not yet initialized, variable, then the
>> latter works ok, resulting in myVar containing 3; whereas
>>    put myVar + 3 into myVar
>> results in an execution error.
>
> Of course it does.  RR and its cousins have a different paradigm for
> variables, which is part of the reason why BA referred to them as
> "containers" in the original HC, which is appropriate on so many
> levels.

I agree that it is good to understand and exploit a paradigm.

In this case, the paradigm--as implemented in Revolution--is flawed.

The container is a good concept.  It is naming that closely represents 
how it behaves.  Languages like BASIC use containers, too, but call 
them variables eroding the math knowledge of students.  BASIC adds to 
this injury by calling the operation that puts a value in a container 
"let".

By using "put" and equals-for-equals (=) xTalk has some honest math 
friendly features.

We need a word for the destination of "put" and "add".  I think 
"reference" can work.  In other languages folks use LHS, but since the 
LHS is on the right side in these examples, that can be confusing.

One of the problems with the paradigm is that the meaning of a 
statement depends not on the statement itself, or the statement and 
declarations of components, but on its context.

Even then, there might be a simple rule to consider the context.  Maybe 
it could be this:

    If a name in an undeclared value or reference context
    is used anywhere in the handler as a reference it is
    a container with an initial value of empty, otherwise
    it is a self-referencing name or string constant.

If one wants to avoid the concept of a self-reference name or
trying to come up for a better name for it, this is equivalent:

    If a container is used anywhere in the handler as a
    reference, its initial value is empty, otherwise its
    initial value is its name.

Unfortunately, those equivalent rules won't work in Transcript.

So what is the rule?

Is it one of these:

     1. Like above only the context is execution until that point.

     2. Like above only the context is the set of handler lines before
        that point, as seen by the compiler.

     3. Like 2 except some commands spoil it.

     4. Something else.

     5. Like 2 except not on a line basis, but even parts of a line
        are considered and then in an undefined order.

Do you know?  Each person can ask himself.

(What about hidden reference uses as in parameters to some user 
functions?)

What good is a paradigm when people don't know how it works?

We can ask RunRev to simplify it.  Or we can give the paradigm a good 
review and recommend the paradigm shift.  (And then it can be 
documented.  If documentation is too hard, it isn't ready yet.)

As it is, it is broken.

>> Another good reason for always declaring variables, and always quoting
>> strings used as strings.
> I tend to disagree.  This is similar to the argument that
> traditionalists in more conventional 3GL and 4GL's make for typing all
> variables, even if the compiler will do it for you.

I don't think this is a good analogy.

Either declaring variables or quoting can be a strategy to work in a 
simplified model, even though the compiler does not.  (One need not do 
both for this particular concern.)

Personally, I quote all string literals.  I sometimes declare variables 
to document the use of the initial empty value.  (For customers with a 
particular style requirement, I follow that.)

For me (a big qualifier, since we all know I'm weird), I find field 
"Last Name" easier to read than field lastName and less ambiguous.  
(Yeah, I know, purists would use fld lastName and then say it is 
readable.)

Dar

-- 
**********************************************
     DSC (Dar Scott Consulting & Dar's Lab)
     http://www.swcp.com/dsc/
     Programming Services and Software
**********************************************