>Oberon-2 *restriction* proposal 
Author Message
 >Oberon-2 *restriction* proposal

: 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.

I'm wondering for long, for what good a type guard without any previous
type test is. Apart from very seldom cases, where I don't care about a
user's reaction to a trap, caused by a failed type guard.

: BTW, I find the function-like syntax of (ii)  VarIdent "(" TypeIdent ")"
: particularly confusing.  IMHO, at least (ii) could be dropped.

It's also confusing when writing a formal language specification which
is oriented by the traditional compiler phases: A parser needs to examine
context information to decide whether Ident1(Ident2) is a function call or
a type guard. As a possible solution M. Odersky suggests in "A New
Approach to Formal Language Definition and Its Application to Oberon"
the usage of "(v::T).f" instead of "v(T).f". I would like to hear the
reasons, why the ambiguous construct was chosen by the language designer.

Another strange issue of this subject is that only qualidents are
legal as "WITH-Expressions" (Guard = Qualident ":" Qualident.).

I.e. if you have

   TYPE T=POINTER TO ObjDescr; ObjDescr=RECORD ... END;
   VAR  v:ARRAY n OF T;

it is legal to speak of

   v[i](T)

but you are not allowed to write

   WITH v[i] : T DO.

Are there any deeper causes for this dis-orthogonality?

Finally, I think the definition of the with-statement in the
oberon-2 language report in terms of an example like

   "...the statement

      WITH v: T1 DO S1 | v: T2 DO S2 ELSE S3 END

    has the following meaning: ..."

is maybe a bit unfortunate. E.g. has the "withed" variable always to be
the same in all with-cases? If not, what could it be good for, to use
different "withed" variables?

Max Spring.



Sat, 24 Feb 1996 18:49:35 GMT  
 >Oberon-2 *restriction* proposal

Quote:

>Another strange issue of this subject is that only qualidents are
>legal as "WITH-Expressions" (Guard = Qualident ":" Qualident.).

>I.e. if you have

>   TYPE T=POINTER TO ObjDescr; ObjDescr=RECORD ... END;
>   VAR  v:ARRAY n OF T;

>it is legal to speak of

>   v[i](T)

>but you are not allowed to write

>   WITH v[i] : T DO.

>Are there any deeper causes for this dis-orthogonality?

Yes. The idea behind the WITH statement is that a type guard is made when
the statement is entered, and that during the whole statement sequence it is
known that the guarded variable is of type T. Unfortunately this does not
work for complex designators, e.g.

        WITH v[i]: T DO ...
          i := i+1;
          v[i] ...      (* what is the type of v[i] now? *)
          v[i+1] ...    (* what is the type of this? *)
        END

You can construct similar cases with pointer indirections. As pointed out in
another posting, it is already unfortunate that the WITH statement is not
completely safe in the presence of aliases, and allowing WITH statements on
designators would multiply these kind of problems.

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



Sat, 24 Feb 1996 22:48:28 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. One more Oberon restriction proposal

2. Oberon-2 *restriction* proposal

3. CCR restrictions (was Re: Local Antenna Restrictions)

4. Unofficial list of Oberon language and library proposals

5. Unofficial list of Oberon language and library extension proposals

6. proposal for a module for dynamic strings in Oberon-2

7. Closures in Oberon - A Modest Proposal (long)

8. Pas->Mod2->Oberon?

9. HELP>>>>>>>Fortran-Pascal Linking

10. >>>>>>>FROM SMTK TO C++

11. Proposal: S>UPPER etc /was: Standardising string primitives (was: Re: String)

12. Lisp --> Ruby project proposal

 

 
Powered by phpBB® Forum Software