The paradigm of containers and self-referenced names

[Dar Scott]

On Mar 24, 2005, at 1:28 PM, Mark Wieder wrote:

> Actually I'd like variable typing as well <g>. But only when I want
> it. Otherwise I also like the freedom and the fact that the engine
> converts everything for me. No more ugly casts. Not declaring
> variables before use, though... consider
>
> on Gimme val1, val2
>
>   put val1 * 10 into val3
>   put val2 * 5 into val5
>   return val3 + val4
> end Gimme
>
> where I accidentally typed "val5" instead of "val4" (slip of the
> finger). You're not going to find this error (if you find it at all)
> until runtime. The simple addition of the line
>
> local val3, val4
>
> and enabling variable checking allows you to catch the error at the
> time you click the "Apply" button. Why not let the compiler help you?

However, that is stronger than what you need to catch this particular 
problem.

The declaration adds redundancy, just as a checksum at the end of a 
message might add some redundancy for checking.  In general, there is 
nothing wrong with that.  (As always, the trick is to have a rich and 
productive language with just the right amount of redundancy.)

Here are some ways that would not need the redundancy:

1
In this particular narrow case, constant folding would catch this.  
Suppose "val3 + val4" is translated to this:

    plus( makeNumber( fetch( getVar("val3") ), makeNumber( 
literal("val4") ) )

By the time constant simplification gets to the second makeNumber(), it 
will create an error.

2
This can also be caught by a compiler warning of unused variables or 
data flows.  Container val5 is unused.

3
If, just as an example, the language was changed to not allow unquoted 
literals or the use of uninitialized variables, then the use of val4 
would create an error.

4
This can also be caught by other heads-up methods.  If the editor was 
super smart, it could italicize names known to represent numbers.  The 
person typing this might catch that val4 is the only container not 
italicized.

5
Hmmm.  An analysis like that would catch things even the constant 
simplification would not catch.  It would allow the compiler to remove 
the makeNumber() in some cases.  OK.  I'll add this kind of compiler 
checking to my list.


Even though the declaration is stronger than what is needed to catch 
this, it is not as strong as typing as some might think of typing.

Just musing.  I ain't picking on any of this.

Should the redundant decoration on 'end' be optional?

Dar

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