🚀 go-pugleaf

In article <4jrm9b$l8m@newsbf02.news.aol.com>, mhamburg@aol.com (M Hamburg) wrote:
>Another solution is to say that WITH p: T introduces a new variable named
>p within the scope of the WITH statement that is distinct from the
>variable of the same name in the containing scope. The variable created
>within the WITH cannot be assigned to. Since assigning to a WITH'd
>variable is generally bad form anyway, this definition doesn't cause a
>problem for "well formed" programs, and it is safe for "ill formed"
>programs.
>
>Mark

There is a variant of this solution where you don't even need to restrict 
assignments. The only problem with WITH arises when an extended pointer 
variable is reallocated while inside the WITH block. Instead have WITH 
introduce a new pointer variable when extending the static type of pointers 
and have it behave as before in all other cases. If you have WITH use an alias 
pointer and the original pointer is reallocated or reassigned then the alias 
refers to the original record rather than the new one. The only question is 
whether changes to the value of the aliased pointer should be propagated to 
the original; if they are it could lead to some obscure bugs (in exactly the 
same places you had WITH bugs before, but safer ones), but if they aren't it 
could be quite confusing to the writer of the WITH block when their changes 
(to the pointer variable, not the referenced value) are undone after the 
block. It may not be what was originally intended but it would be safe, and 
any side effect can be well documented in the language manual. 

This would be a simple change to either OP2 or a GSA based compiler like OOC. 
You would just allocate a new variable at the beginning of the WITH block if 
the original variable is a pointer type. If you are propagating changes then 
every change to the pointer variable in the code in the WITH block would 
change both the alias and the original. No changes would be needed in other 
code. 

I think that if you propagate changes from the alias to the original then any 
existing code would run without change. Any place that you would have an alias 
bug before you would have one now, but this bug wouldn't violate type safety 
and corrupt the heap--instead you would just be referring to the old record 
instead of the new one, a bug that could be useful sometimes.

So what do you think?

Brian Hawley
bhawley@luc.edu