🚀 go-pugleaf

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