🚀 go-pugleaf

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

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

In article <4jv1c1$drh@artemis.it.luc.edu>,
Brian Hawley <bhawley@luc.edu> wrote:
>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
...deleted...
>So what do you think?
>
>Brian Hawley
>bhawley@luc.edu

The solution most in the "Spirit of Oberon" would be to drop WITH on pointers
altogether.
This was suggested in Szyperski's "ETHOS" thesis and discussed at the Institute
at length. The reason we left it the way it is, was that too much System3 code
would have needed a rewrite.

I strongly advocate dropping WITH on pointers in commercial compilers.
It's a hole in the type system, and it needs to be plugged!

  Stefan H-M Ludwig              mailto:ludwig@inf.ethz.ch
                                 http://www-cs.inf.ethz.ch/~ludwig
  Institute for Computer Systems
  Swiss Federal Institute of Technology (ETH)
  CH-8092 Zurich, Switzerland

  Phone: 41-1-632 7301
  Fax  : 41-1-632 1307

Stefan Ludwig wrote:
> [deleted]
> 
> The solution most in the "Spirit of Oberon" would be to drop WITH on pointers
> altogether.
> This was suggested in Szyperski's "ETHOS" thesis and discussed at the Institute
> at length. The reason we left it the way it is, was that too much System3 code
> would have needed a rewrite.
> 
> I strongly advocate dropping WITH on pointers in commercial compilers.
> It's a hole in the type system, and it needs to be plugged!

XDS Oberon-2 (starting from v2.12) reports an error if the value of pointer may be changed
inside WITH, like in 

TYPE 
  P = POINTER TO R;
  R = RECORD i: INTEGER END;
  P1 = POINTER TO R1;
  R1 = RECORD (R) n: INTEGER END;

PROCEDURE proc1(p: P);
  PROCEDURE proc2;
  BEGIN
    p:=NIL;
  END proc2;
BEGIN
  WITH p: P1 DO
    proc2;
  END;
END proc1;

I think it is better solution then dropping WITH on pointers.

-- Alex

In article <318BAE1B.443@iis.nsk.su>, Alex Nedorya  <ned@iis.nsk.su> wrote:
>Stefan Ludwig wrote:
>> I strongly advocate dropping WITH on pointers in commercial compilers.
>> It's a hole in the type system, and it needs to be plugged!
>
>XDS Oberon-2 (starting from v2.12) reports an error if the value of
>pointer may be changed inside WITH, like in 
>
>TYPE 
>  P = POINTER TO R;
>  R = RECORD i: INTEGER END;
>  P1 = POINTER TO R1;
>  R1 = RECORD (R) n: INTEGER END;
>
>PROCEDURE proc1(p: P);
>  PROCEDURE proc2;
>  BEGIN
>    p:=NIL;
>  END proc2;
>BEGIN
>  WITH p: P1 DO
>    proc2;
>  END;
>END proc1;
>
>I think it is better solution then dropping WITH on pointers.
>
>-- Alex

You cannot check this for all cases! It's not safe. Consider the following:

MODULE A;
	VAR p*: Pointer;
END A.

MODULE B;
	IMPORT A;
	PROCEDURE Change*;
	BEGIN NEW(A.p)
	END Change;
END B.

MODULE C;
	IMPORT A, B;
	...
	PROCEDURE Crash*;
	BEGIN
		WITH A.p: Extension DO
			B.Change;
			do something with A.p.extendedField ... uh oh!
		END
	END Crash;
END C.

I agree, it's a pathological case, but most of the time, it's those
pathological cases that get you!

In the example above, unless you do global system analysis, you cannot find
an inconsistency (unless you're conservative and flag everything that might
change the WITH'ed pointer). IMHO, dropping WITH on pointers is the better
solution and much more readable as well...

Regards,

  Stefan H-M Ludwig              mailto:ludwig@inf.ethz.ch
                                 http://www-cs.inf.ethz.ch/~ludwig
  Institute for Computer Systems
  Swiss Federal Institute of Technology (ETH)
  CH-8092 Zurich, Switzerland

  Phone: 41-1-632 7301
  Fax  : 41-1-632 1307