With respect to dynamic type testing and guarding,
Oberon-2 offers some redundancy:

(i)   type test  (VarIdent "IS" TypeIdent),
(ii)  type guard  (VarIdent "(" TypeIdent ")"),
(iii) type tests with regional type guards  ("WITH" statement).

      (Recall that the WITH statement was promoted from a simple
       regional type guard in Oberon(-1) to a multi-case type test
       with guards in Oberon-2.)

Actually, (iii) covers (i) and (ii) and would thus be sufficient.
BTW, I find the function-like syntax of (ii)  VarIdent "(" TypeIdent ")"
particularly confusing.  IMHO, at least (ii) could be dropped.

Any Comments?

(Unless I get bashed too badly, my next proposal will possibly refer to
 the second-order facilities.)

--

        (a)     SomeProc(operand(Constant))

        (b)     SomeOtherProc(operand IS Constant)

        (c)     b.isConstant := (operand0 IS Constant) & (operand1 IS Constant)

        (d)     WHILE ~(block IS Header) DO ... END

        (e)     instr.operand(Constant).val := 0

(a) would require that you surround it with a WITH-statement, (b) requires an
additional WITH-statement and a boolean variable just to evaluate the
condition, (c) two nested WITH-statements, (d) two additional WITH-statements
and a boolean variable, and (e) a variable to keep "instr.operand".

On the other hand, the non-local effects of the WITH-statement are not such
a great thing. From the Oberon report (section 9.10 With statements):

        If a pointer variable or a variable parameter with record structure is
        of a type T0, it may be designated in the heading of a with clause
        together with a type T that is an extension of T0. Then the variable
        is guarded within the with statement as if it had been declared of
        type T. [...]

Now assume v is a parameter of this procedure of type T0, and we do have
another variable w of type T0.

        PROCEDURE p (VAR v: T0);
          VAR w: T0;
        BEGIN
          WITH v: T DO p(w) ... END
          ...

This procedure will not compile, as the parameter 'v' of 'p' looks as if it
had been declared as 'T' inside the WITH statement, so p(w) will not compile
as 'w' is not assignment compatible to 'v:T'.

This is one example of the non-local effects of the WITH statement. Another
one are problems with non-local pointers that lead to the warnings that the
compilers omit on encountering some WITH statements.

        VAR
          root: Node;

        PROCEDURE q;
        BEGIN NEW(root)
        END q;

        PROCEDURE p;
        BEGIN
          WITH root: ExtendedNode DO
            q;
            (* here, root is not an ExtendedNode any more, although the
               WITH statement implies this
            *)
        END p

Considering that the desired and safe effects of the WITH statement can be
achieved using (i) and (ii), I would rather vote for dropping (iii) and
leaving the other two in the language. The main objective against dropping
the WITH statement is performance, as it has to be replaced by guarding the
designator on each occurence. A simple compiler may not be able to remove
redundant guards, making some kinds of code considerably slower.

Marc

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland

wrote about the non-local effects of WITH statements:

A regional guard could very well be understood as a purely notational
facility which does not impair security (nor immediately implies
greater efficiency).

Section 9.11 in "The Programming Language Oberon-2" is self-
contradictory in this respect:  First, it states that WITH statements

  "... apply a type guard to every occurrence of the tested variable
   within this statement sequence";

later on, it speaks of the guarded variable

  "... where v is regarded as if it had the static type T1",

which suggests that there is only one type test at the entry of the
WITH statement but no further type tests in its body.

Which semantics was actually intended for the WITH statement?  Putting
things straight would give a reasonable basis for further discussion.

--

Performing p(w) outside the WITH statement, or within a with v:T0 would be
perfectly legal.

Taylor "FederalHolidayMan" Hutt
Favorite dessert: cheese cake.  Least favorite dessert: Bleu Cheese cake.

I wrote about the non-local effects of WITH statements:

In my opinion, there are enough cases where having just the WITH statement
would be a major inconvenience. Let me give you an additional example, where
it really is a pain.

        TYPE
          Node = POINTER TO NodeDesc;
          NodeDesc = RECORD
          END;
          ListNode = POINTER TO ListNodeDesc;
          ListNodeDesc = RECORD (NodeDesc)
            x: INTEGER;
            next: Node
          END;

        VAR
          p: Node;
        BEGIN
          p := root;
          WHILE (p # NIL) & (p(ListNode).x # key) DO
            p := p(ListNode).next
          END

Writing this using the WITH statement would get you more complex code which is
harder to read in my opinion.

        VAR
          found: BOOLEAN; p, q: Node;
        BEGIN
          p := root; found := FALSE;
          WHILE (p # NIL) & ~found DO
            WITH p: ListNode DO found := p.x # key; q := p.next END;
            IF ~found THEN p := q END
          END

        WITH p.next : ListNode DO ... END

? For a notational convenience, this looks reasonable to me. But there are
more complex cases, e.g.

        WITH p.a[i+1] : ListNode DO ... END

Which designators would that guard apply to? Would it mean that every
occurence of 'p.a[i+1]' (lexically) would be guarded, or would 'p.a[i]' also
be guarded?

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland

        WITH p: T1 DO
          p := q
          ...
        END

In this case, you can only compile it if 'q' statically is a T1 or an extension
of T1. This is not the same as

        p(T1) := q

where it is checked whether the object referenced by 'p' is a T1. Such
assignments to the WITHed variable are not dangereous, however, as the guard
made in the WITH clause still holds, and as T1 must be an extension of the
static type of p, you cannot make unsafe assignments this way.

The dangereous case is another one, and that one is not so simple to recognize.
It would require interprocedural information, and when used in conjunction
with other modules could not be recognized at all.

        VAR
          p: T;

        PROCEDURE Proc (VAR q: T);
        BEGIN
          WITH q: T1 DO
            NEW(p);     (* p will now point to a T, and not to an extension *)
            q.x := ...  (* dangereous operation, see below *)
          END
        END Proc;

        BEGIN
          Proc(p)
        END

In this example, 'q' is guarded to a T1, then 'p' is changed. If 'q' is an
alias for 'p' - which it is if you call Proc(p) - the modification of p will
also modify q and therefore violate the guard. The assignment to 'q.x' may
be outside of the allocated storage for 'p' and may even overwrite other
data structures.

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland