One more Oberon restriction proposal 
Author Message
 One more Oberon restriction proposal

Why no to restrict a withed object to passed by refernce  record variables
and either passed by value or defined as variables pointers to records?
This would solve the problem of aliasing with  WITH.

David Tolpin.



Mon, 26 Feb 1996 01:55:00 GMT  
 One more Oberon restriction proposal

Quote:

>Why no to restrict a withed object to passed by refernce  record variables
>and either passed by value or defined as variables pointers to records?
>This would solve the problem of aliasing with  WITH.

The restriction must be even stronger, namely the WITHed object must be
either a record passed as a VAR parameter, or a local variable or value
parameter of the same scope in which the WITH-statement is. In particular,
it cannot be a global variable. Here is another example where problems occur.

        PROCEDURE Proc0 (p: T0);

          PROCEDURE Modify;
          BEGIN NEW(p) END Modify;

          PROCEDURE Proc1;
          BEGIN
            WITH p: T1 DO
              Modify;
              (* here, p is no more a T1 *)
            END
          END Proc1;

        BEGIN ....
        END Proc0;

Instead of introducing such complex restrictions, I would rather restrict
the WITH statement to records passed as VAR parameters only. A WITH statement
of the following form, where p is a pointer:

        WITH p: T1 DO
          ...
        END

can easily be replaced by

        VAR p1: T1;
        ...
        p1 := p(T1);
        (* use p1 instead of p *)

In my opinion, one could even live with completely dropping the WITH statement.
If you use the guarded variable a small number of times in some context, it
is acceptable to have to write the guard every time. If you use it often, it
may be a good idea to write a procedure that does all this and which accepts
the extended type as a parameter. The variable is then guarded at the call
site, e.g.

        WITH msg: Oberon.InputMsg DO
          ... lots of operations on msg ...
        END

would become

        PROCEDURE HandleInput (VAR msg: Oberon.InputMsg);
        BEGIN ... lots of operations on msg ...
        END HandleInput;

        ....
        IF msg IS Oberon.InputMsg THEN HandleInput(msg(Oberon.InputMsg)) END

Marc

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



Mon, 26 Feb 1996 16:47:02 GMT  
 One more Oberon restriction proposal


Quote:
> A WITH statement
> of the following form, where p is a pointer:

>    WITH p: T1 DO
>      ...
>    END

>can easily be replaced by

>    VAR p1: T1;
>    ...
>    p1 := p(T1);
>    (* use p1 instead of p *)

Well, though this is easier to type/read than complex
IF-WITH-structures, it easily leads to a large amount of local
variables, of which only a few are really needed throughout the
whole procedure.

IMHO it would be nice thing if it were possible to restrict variables
to even smaller scopes, like

    IF p IS T1 THEN
      VAR p1 : T1;
      BEGIN         (* separates declarations from code *)
      p1 := p(T1);
      ...some commands using p1; not enough to justify a separate
         procedure, but enough to make typing 'p(T1)' a nuisance...
    END; (* p1 becomes non-existant again *)

--



Mon, 26 Feb 1996 20:25:02 GMT  
 One more Oberon restriction proposal

: In my opinion, one could even live with completely dropping the WITH statement.
: If you use the guarded variable a small number of times in some context, it
: is acceptable to have to write the guard every time. If you use it often, it
: may be a good idea to write a procedure that does all this and which accepts
: the extended type as a parameter. The variable is then guarded at the call
: site,
[ stuff deleted]

I agree. The WITH statement does too many things. It is a control
structure and it provides a scope feature. It is not surprizing that
it gives a gotcha with pointers. Maybe it should be simplified so
it was just a control structure.

WITH msg DO
  T1 : handleT1( msg(T1));
| T2 : handleT2( msg(T2));
| T3 : handleT3( msg(T3));
END;

Even this is not clear. As is the case if T2 is an extension of T1.

Dropping it is not be bad idea. I doubt it would be more than
a minor maintence problem to eliminate it from existing code.

Whitney



Thu, 29 Feb 1996 02:15:55 GMT  
 One more Oberon restriction proposal
        I think the WITH discussion has been both interesting
and educational so far.  And as long as we're all tossing out
the WITH statement :-), I personally find it tempting to
reconsider the presence of procedure variables in Oberon-2.  
        Although Prof. Wirth calls type bound procedures
(TBPs) a concession to traditional OO methods, I think a good
argument can be made that TBPs are generally better and that
procedure fields are therefore redundant.  
        For the sake of terminology, I'll call a "method" any
procedure that is bound to a record.  A method can be
implemented as a procedure variable field or a type-bound
procedure (TBP).

Why procedure variable methods are unneccessary:
        ()  Methods are rarely changed once they have been
initialized.
        ()  Methods are rarely intended to be different for
variables of the same type.
        ()  When needed, Oberon's flexible handler technique
can still be realized with a Handler TPB.
        ()  When needed, a procedure variable can be simulated
by a pointer to a record with a TPB.  The pointer can point to
extentions where the TPB is redefined.

Type-bound procedures are better in that:
        ()  A TPB call as message is faster than a long chain
of type tests for an extensible record message.
        ()  TPBs are safer in that they cannot be accidentally
assigned to a variable of the wrong type or even uninitialized
altogether.
        ()  TPBs are clearer for being explicitly bound to a
record type.
        ()  TPBs save space by not requiring an actual field
for each method.
        ()  TPBs avoid some textual redunancy and the
potential for typos.  E.g.,
"aLongVariableName.Method(argument)" vs.
"aLongVariableName.method(aLongVariableName, argument)".

        Prof. Wirth also says that method suites in Oberon can
substitute for type-bound procedures.  While strictly true,
they seem to me to become quite awkward once you extend a
record a few times.
        On the other hand, I vaguely remember a post here not
too long ago about some new chemistry modelling software that
somehow depended on the use procedure variables.  
        So, how would Oberon-2 do without procedure variables?
I've yet to do a large project in Oberon or Oberon-2 (but I
hope to be able to convince my boss eventually), so comments
and criticisms are welcome.

Some references:
        "Object Oberon - A Modest Object-Oriented Language"
        Structured Programming, Vol 10, No 4 (1989), pp 199-207.

        "OOP in Oberon-2"
        anonymous ftp neptune.inf.ethz.ch:/Oberon/Docu

        _Programming in Oberon: Steps beyond Pascal and Modula_

P.S.  I haven't read (or even seen) _Object Oriented
Programming in Oberon-2_ yet.  How is it?

--

I meant what I said and said what I meant,
An elephant is faithful one hundred percent.
                                -- Horton



Sat, 02 Mar 1996 23:25:37 GMT  
 One more Oberon restriction proposal
:         I think the WITH discussion has been both interesting
: and educational so far.  And as long as we're all tossing out
: the WITH statement :-), I personally find it tempting to
: reconsider the presence of procedure variables in Oberon-2.  

This might be intresting. I was ready to suggest tossing out
type-bound procedures. In my books of the things added in Oberon-2,
it comes behind pointers to open arrays, read-only marks and
 the for loop.

: Why procedure variable methods are unneccessary:
:         ()  Methods are rarely changed once they have been
: initialized.
:         ()  Methods are rarely intended to be different for
: variables of the same type.

On the other hand removing procedures variables would
remove that rarely needed flexibilty.

:         ()  When needed, Oberon's flexible handler technique
: can still be realized with a Handler TPB.

I have tried this and was not satisfied with it.
PROCEDURE  ( f : Frame ) Handler( VAR msg : Msg );
has the disadvantage that one can not subclass an object at
runtime. I suggest that both styles are needed - and may
occur within the same object. The procedure variable allowing
subclassing at runtime.

Object = POINTER TO ObjDesc;
ObjDesc = RECORD
  handle* : Handler; (* see defaultHandle *)
  PROCEDURE ( obj : Object ) Handle( VAR msg : Msg );
END;

PROCEDURE defaultHandle( obj : Object; VAR msg : Msg );
BEGIN
        obj.Handle( msg );
END defaultHandle;

:         ()  When needed, a procedure variable can be simulated
: by a pointer to a record with a TPB.  The pointer can point to
: extentions where the TPB is redefined.

This would be tedious in practice. It would generate too many
types.

:         ()  TPBs are clearer for being explicitly bound to a
: record type.
This explicit binding might be its greatest evil. It may result
in the binding methods that are too tightly bound to objects
and don't have the flexibility of being modified at runtime.

Contrary to my first statement, I don't think that type-bound
procedures should be dropped. They are useful for the reasons
you mention. On the otherhand I think they are used to frequently.
Many people repackage existing procedures to give it that OOP look.
This is particulary odd in windowing systems such as Windows 3.x
where the original _design_ was not based on a heirarchy of classes
with related features but rather of a modular style where objects
are independent of one another. Needless to say it is very
hard to read code which uses a mixture of redefined type-bound
procedures  and type-bound procedures where ordinary procedures would
do.

A related question to ask is :

Of the two techniques which one should be used when
one is uncertain whether type-bound procedure or
procedure variables are more appropriate for the task.
This uncertainity can arise when trying to anticipate
reusing a design for a future project.

Whitney



Sun, 03 Mar 1996 12:07:10 GMT  
 One more Oberon restriction proposal

Quote:

>        I think the WITH discussion has been both interesting
>and educational so far.  And as long as we're all tossing out
>the WITH statement :-), I personally find it tempting to
>reconsider the presence of procedure variables in Oberon-2.  

[...]

Funny. Few weeks ago there was a big discussion in comp.lang.eiffel
about why procedure variables are useful. Eiffel has no procedure
variables, so everything has to be done via inheritance and
redefinition.

The problem discussed was that of a generic sort. Let's say you have
an array of PERSON objects and you want to sort them by different
criteria (eg. last name or ZIP code). In Oberon (or Modula-2) you'd
write a sort routine that takes a compare routine as a parameter.

Without procedure variables, it's not clear how this should be done.
The most elegant Eiffel solution involves repeated inheritance. This
solution could not be used in Oberon, since Oberon supports only single
inheritance.

There are few other places where procedure variables are needed. For
example, to implement concurrent objects running in different processes,
you'd want to pass names of routines (as Strings) between
processes and have them 'point' to code to execute. This is trivially
done if the language has procedure variables. It's trickier if you
only have "methods".

...richie

--
* Richie Bielak   (212)-815-3072   |                                          *

* Bang {uupsi,uunet}!bony1!richieb |           is to invent it."              *
*    - Strictly my opinions -      |                      - Alan C. Kay -     *



Mon, 04 Mar 1996 20:34:27 GMT  
 One more Oberon restriction proposal

Quote:

>        Although Prof. Wirth calls type bound procedures
>(TBPs) a concession to traditional OO methods, I think a good
>argument can be made that TBPs are generally better and that
>procedure fields are therefore redundant.  

Look at it this way: a handler procedure lets you decide for each message
whether you want to:

0. handle it yourself,
1. inherit from a superclass,
2. inherit from a prototype,
3. delegate to another object,
4. broadcast to several other objects,
5. raise an error,
6. drop the message on the floor,

or anything else you want to do. Type-bound procedures make _some_ of
these options easier. Now, there's more to life than class inheritance,
and so there are times when you want to take one of the more {*filter*}
options. Using type-bound procedures for everything will only make
that harder.

And don't neglect option 6 above. It's the ability of objects to either
delegate or discard messages they don't understand that allows the Oberon
system to work at all. You can't do this without passing explicit messages
around.

Sean Case
--

"The day is surely coming when bank robbers will
plead in mitigation that the getaway car had its
hazards on." -- Ben Elton, _Gridlock_



Tue, 05 Mar 1996 19:48:16 GMT  
 One more Oberon restriction proposal

[ a lot of stuff deleted ]

Quote:
>Type-bound procedures are better in that:
>        ()  A TPB call as message is faster than a long chain
>of type tests for an extensible record message.
>        ()  TPBs are safer in that they cannot be accidentally
>assigned to a variable of the wrong type or even uninitialized
>altogether.
>        ()  TPBs are clearer for being explicitly bound to a
>record type.
>        ()  TPBs save space by not requiring an actual field
>for each method.
>        ()  TPBs avoid some textual redunancy and the
>potential for typos.  E.g.,
>"aLongVariableName.Method(argument)" vs.
>"aLongVariableName.method(aLongVariableName, argument)".

And one more important topic:
          () TBPs are more safe when unloading module.
If type procedure was assigned to the variable from another
module (eg. to do up-call) it is not so easy to determine
such case while unloading module.

As far as I know Oberon system on almost all platforms do
nothing in such case (I am right?).

-- Alex

-----------------------------------------------------
Institute of Informatics Systems, Novosibirsk, Russia



Tue, 05 Mar 1996 13:00:11 GMT  
 One more Oberon restriction proposal


Quote:

>[ a lot of stuff deleted ]

>>Type-bound procedures are better in that:
> deleted stuff about TBPs
>And one more important topic:
>          () TBPs are more safe when unloading module.
>If type procedure was assigned to the variable from another
>module (eg. to do up-call) it is not so easy to determine
>such case while unloading module.

>As far as I know Oberon system on almost all platforms do
>nothing in such case (I am right?).

The Ceres implementation will twiddle with the MMU, thus blocking the
free'd module's memory from access.  A reference to this code segment via
a procedure variable is supposed to result in a trap.

Many other ETH version do not do this.

Taylor 0X Hutt



Wed, 06 Mar 1996 05:43:38 GMT  
 One more Oberon restriction proposal

Quote:


> :         I think the WITH discussion has been both interesting
> : and educational so far.  And as long as we're all tossing out
> : the WITH statement :-), I personally find it tempting to
> : reconsider the presence of procedure variables in Oberon-2.  

> This might be intresting. I was ready to suggest tossing out
> type-bound procedures. In my books of the things added in Oberon-2,
> it comes behind pointers to open arrays, read-only marks and
>  the for loop.

        You won't get much argument from me.

Quote:

> :         ()  When needed, Oberon's flexible handler technique
> : can still be realized with a Handler TPB.

> I have tried this and was not satisfied with it.
> PROCEDURE  ( f : Frame ) Handler( VAR msg : Msg );
> has the disadvantage that one can not subclass an object at
> runtime. I suggest that both styles are needed - and may
> occur within the same object. The procedure variable allowing
> subclassing at runtime.

        Ah, this is the sort of thing I'm missing.  Could you
sketch an example?

Quote:

> : Why procedure variable methods are unneccessary:
> :         ()  Methods are rarely changed once they have been
> : initialized.
> :         ()  Methods are rarely intended to be different for
> : variables of the same type.

> On the other hand removing procedures variables would
> remove that rarely needed flexibilty.

> :         ()  When needed, a procedure variable can be simulated
> : by a pointer to a record with a TPB.  The pointer can point to
> : extentions where the TPB is redefined.

> This would be tedious in practice. It would generate too many
> types.

        Would it generate more types than the
record-as-message approach does?  E.g., for a graphics object
displayed on the screen: ShowMsg, HideMsg, CopyMsg, MoveMsg,
AttrMsg, AlterMsg . . .

Quote:

> :         ()  TPBs are clearer for being explicitly bound to a
> : record type.
> This explicit binding might be its greatest evil. It may result
> in the binding methods that are too tightly bound to objects
> and don't have the flexibility of being modified at runtime.

        I think it's also one of its greatest strengths.  
Maybe we could more easily get rid of TBPs if we had some kind
of constructor mechanism (which has several strengths of its
own).  Obj.New, BTW, is one of my favorite method calls.

--

In the beginning, the universe was created.  This made a lot of
people very angry, and has been widely regarded as a bad idea.
                                --  D. Adams



Wed, 06 Mar 1996 06:11:45 GMT  
 One more Oberon restriction proposal
Subject: Re: type-bound procs vs. proc variables (was Oberon restriction proposal)
Newsgroups: comp.lang.oberon


: > :         ()  When needed, Oberon's flexible handler technique
: > : can still be realized with a Handler TPB.
: >
: > I have tried this and was not satisfied with it.
: > PROCEDURE  ( f : Frame ) Handler( VAR msg : Msg );
: > has the disadvantage that one can not subclass an object at
: > runtime. I suggest that both styles are needed - and may
: > occur within the same object. The procedure variable allowing
: > subclassing at runtime.
:  
:         Ah, this is the sort of thing I'm missing.  Could you
: sketch an example?

MODULE Sketch; (* decorate with export marks to taste *)
TYPE
        Object = POINTER TO ObjDesc;
        Msg = RECORD END;
        Handler = PROCEDURE ( obj : Object; VAR msg : RECORD );
        ObjDesc = RECORD
                handle : Handle;
        END;

PROCEDURE ( obj ) Handle( VAR msg : Msg );
BEGIN
END Handler;

PROCEDURE Handle( obj : Object; VAR msg : Msg );
BEGIN  obj.handle(msg);
END Handle;

PROCEDURE ( obj : Object ) Init;
BEGIN
        obj.handle := Handler;
END Init;

PROCEDURE New;
BEGIN  NEW(obj); obj.Init;
END New;

PROCEDURE Broadcast( VAR msg : Msg );
BEGIN
        ..
        p.Handle(p, msg);
        ..
END Broadcast;

END Sketch.

MODULE Extension;
IMPORT Sketch;

VAR
        NewMsg = RECORD ( msg ) END;

PROCEDURE HandleNewMsg( obj : Object; VAR msg : NewMsg );
BEGIN
END HandleNewMsg;

PROCEDURE Handle( obj : Object; VAR msg : Msg );
BEGIN
        (* new subclassing *)
        IF msg IS NewMsg THEN
                HandleNewMsg( obj, msg( NewMsg) );
        ELSE
                Sketch.Handle( obj, msg );
        END;
END Handle;

PROCEDURE ReplaceHandle*;
VAR obj : Sketch.Object;
BEGIN
        obj := FictionalGetObjectRoutine();
        obj.handle := Handle;  
END ReplaceHandle;

PROCEDURE Do*;
VAR msg : NewMsg;
BEGIN
        Sketch.Broadcast( msg );
END Do;

END Extension.

:         I think it's also one of its greatest strengths.  
: Maybe we could more easily get rid of TBPs if we had some kind
: of constructor mechanism (which has several strengths of its
: own).  Obj.New, BTW, is one of my favorite method calls.

obj.New is my least favorite methods calls. It should call
NEW( obj ) and obj.Init.  Too many people Init stuff in New.
This is a pain  when one needs to create a new type that is
an extension of obj.

I don't like the constructors techiques that I have seen - too
automagical, to hard to maintain, and not powerful enough for my
taste. I'd much rather write a sequence of procedure calls to do
initialization. I think there is more "power" in statement sequences
than constructor techniques.

        NEW( obj );
        obj.setSize( 10 );
        width := 100*100;
        obj.setWidth( width );

I think constructors fall apart as a technique when when creating
things  like graphs, trees, lists, etc where the difference
between initialization and addition/deletion/maintence is pretty
fuzzy.

Whitney



Thu, 07 Mar 1996 08:24:38 GMT  
 One more Oberon restriction proposal

Quote:


>>        Although Prof. Wirth calls type bound procedures
>>(TBPs) a concession to traditional OO methods, I think a good
>>argument can be made that TBPs are generally better and that
>>procedure fields are therefore redundant.  

>Look at it this way: a handler procedure lets you decide for each message
>whether you want to:

[lots of neato stuff deleted]

Quote:

>or anything else you want to do. Type-bound procedures make _some_ of
>these options easier. Now, there's more to life than class inheritance,
>and so there are times when you want to take one of the more {*filter*}
>options. Using type-bound procedures for everything will only make
>that harder.

Note that handlers are a programming technique, not a language
feature.  Handlers can be type-bound procedures.
--

That in our day such giant shadows are cast by such pygmies
only shows how late in the day it has become.
                                -- Chargaff, referring to Watson & Crick



Fri, 08 Mar 1996 07:19:02 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. >Oberon-2 *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. Modula 3 or Oberon , which one !

9. Only one System (was: Oberon Newsletter)

10. Modula 3 or Oberon , which one !

11. Subject: A proposal (Another proposal)

12. How to replace one or two words with one word with one line of awk code

 

 
Powered by phpBB® Forum Software