Oberon[-2] and Parameterized Types 
Author Message
 Oberon[-2] and Parameterized Types

Have there been any proposals to introduce parameterized types
(cf. C++ templates) in Oberon or Oberon-2?

What about exceptions?

I'd appreciate a recap of the prevailing ideas on these subjects
as they relate to Oberon.

Thanks!

--Larry %)



Wed, 22 Jun 1994 10:36:40 GMT  
 Oberon[-2] and Parameterized Types

|> Have there been any proposals to introduce parameterized types
|> (cf. C++ templates) in Oberon or Oberon-2?

This is absolutely unnecessary in Oberon because type extensions
are sufficient.

|> What about exceptions?

Exceptions are no problem -- provided you've coroutines.
Our implementation supports coroutines while the ETH implementations
of Oberon and Oberon-2 do not support them (as far as I know).

--



D-7900 Ulm, Germany     |   X.400:    S=borchert; OU=rz; P=uni-ulm; A=dbp; C=de



Wed, 22 Jun 1994 17:33:02 GMT  
 Oberon[-2] and Parameterized Types


   |> Have there been any proposals to introduce parameterized types
   |> (cf. C++ templates) in Oberon or Oberon-2?

   This is absolutely unnecessary in Oberon because type extensions
   are sufficient.

Doesn't using type extensions mean that for example, every element in
a list must be an extension of some ListElement type?  There was a
paper about this in the Beta language, but I wasn't convinced it is
the right way to do things.  Is it any different in Oberon-2?




Wed, 22 Jun 1994 21:04:19 GMT  
 Oberon[-2] and Parameterized Types

Quote:


>   |> Have there been any proposals to introduce parameterized types
>   |> (cf. C++ templates) in Oberon or Oberon-2?

>   This is absolutely unnecessary in Oberon because type extensions
>   are sufficient.

>Doesn't using type extensions mean that for example, every element in
>a list must be an extension of some ListElement type?  

Yes. And this is where parameterized type _could_ be useful. They are not
strictly necessary however.

--
Chuck Lins               | "Shut up! Be happy!" -- Jello Biafra
Apple Computer, Inc.     | Oberon-2 Paladin
20525 Mariani Avenue     |




Sat, 25 Jun 1994 01:58:26 GMT  
 Oberon[-2] and Parameterized Types


|>

|>    |> Have there been any proposals to introduce parameterized types
|>    |> (cf. C++ templates) in Oberon or Oberon-2?
|>
|>    This is absolutely unnecessary in Oberon because type extensions
|>    are sufficient.
|>
|> Doesn't using type extensions mean that for example, every element in
|> a list must be an extension of some ListElement type?  There was a
|> paper about this in the Beta language, but I wasn't convinced it is
|> the right way to do things.  Is it any different in Oberon-2?

No, this is not necessary. A common (and usually empty) base type is sufficient:

   MODULE Objects;

      TYPE
         Object* = POINTER TO ObjectRec;
         ObjectRec* = RECORD END;

   END Objects.

Then follow following convention:  declare each other record type which
needs not be an extension of another record type as extension of ObjectRec:

   MODULE OneModuleWhichDoesNotKnowAnythingAboutLists;

      IMPORT Objects;

      TYPE
         MyDataType* = POINTER TO MyDataTypeRec;
         MyDataTypeRec* =
            RECORD
               (Objects.ObjectRec)
               (* some useful record components *)
            END;

   END OneModuleWhichDoesNotKnowAnythingAboutLists.

Now, you're able to put MyDataType in any data structure --
not only those which have been known at the time of writing
OneModuleWhichDoesNotKnowAnythingAboutLists.

On the other side, it's a bad design if you enforce
a specific base type (e.g. ListElementRec) to be able to put objects
into a list. Further, of course, it is not wise to put additional
information into such a specific base type (e.g. a next pointer).
The former restricts one object to be contained only in one
type of containers and the latter even removes the possibility
of putting one object in more than one container.

--



D-7900 Ulm, Germany     |   X.400:    S=borchert; OU=rz; P=uni-ulm; A=dbp; C=de



Sat, 25 Jun 1994 15:15:28 GMT  
 Oberon[-2] and Parameterized Types
[long embedded quotes all deleted]

Assume you have a type

TYPE Object* = POINTER TO ObjectData;
     ObjectData* = RECORD END;

and this becomes the root type of all other subtypes (by convention not mandate).

Now you're List classes, Tree classes, Set classes, etc. all accept Objects
as the type of their component elements. All well and good.

Now let's derive my special type,

TYPE FooObjectData = RECORD (ObjectData) (* my special foo stuff *) END;
     FooObject = POINTER TO FooObjectData;

Everything is fine with the world because I can use FooObjects just like I can
Objects wrt my generic container classes (Lists, Sets, Trees, etc).

Now let's add another subtype,

TYPE BarObjectData = RECORD (ObjectData) (* my special bar stuff *) END;
     BarObject = POINTER TO BarObjectData;

Suppose I want a List of FooObjects. BarObjects are not valid in this list, only
FooObjects and their descendants. With a generic List class accepting Objects,
you can't stop the programmer from erroneously inserting a BarObject into this
list. With parameterized container types, you could add this restriction which
would be checked at compile-time.

The way Oberon and Oberon-2 are defined right now, you cannot have parameterized
container classes. (I wouldn't hold my breath waiting for them either.)

I'll will not take any sides as to whether this is good or bad. I have no
intention of starting a holy war.

--
Chuck Lins               | "Shut up! Be happy!" -- Jello Biafra
Apple Computer, Inc.     | Oberon-2 Paladin
20525 Mariani Avenue     |




Sun, 26 Jun 1994 06:35:13 GMT  
 Oberon[-2] and Parameterized Types



   |> Doesn't using type extensions mean that for example, every element in
   |> a list must be an extension of some ListElement type?  There was a
   |> paper about this in the Beta language, but I wasn't convinced it is
   |> the right way to do things.  Is it any different in Oberon-2?

   No, this is not necessary. A common (and usually empty) base type
   is sufficient:

      MODULE Objects;

         TYPE
            Object* = POINTER TO ObjectRec;
            ObjectRec* = RECORD END;

      END Objects.

   Then follow following convention:  declare each other record type which
   needs not be an extension of another record type as extension of ObjectRec:

[ Aside : This is the method used in the Beta paper I mentioned. ]
How do I have a list of integers?  Do I have to create a record
extension containing an integer?

      MODULE OneModuleWhichDoesNotKnowAnythingAboutLists;

         IMPORT Objects;

         TYPE
            MyDataType* = POINTER TO MyDataTypeRec;
            MyDataTypeRec* =
               RECORD
                  (Objects.ObjectRec)
                  (* some useful record components *)
               END;

      END OneModuleWhichDoesNotKnowAnythingAboutLists.

   Now, you're able to put MyDataType in any data structure --
   not only those which have been known at the time of writing
   OneModuleWhichDoesNotKnowAnythingAboutLists.

   On the other side, it's a bad design if you enforce
   a specific base type (e.g. ListElementRec) to be able to put objects
   into a list.

If I just use the ObjectRec as the type for the procedures doesn't it
mean I can end up with hetrogeneous lists i.e. the type system will
let me put say a Window record and a Book record in the same list?  If
this is true, how do I enforce homogeneous lists without specifically
doing a type test when inserting values.




Sat, 25 Jun 1994 19:27:15 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. parameterized class types as parameters

2. Parameterized data type example.

3. Parameterized Types

4. parameterized derived types

5. Fortran 88 Parameterized Data Types

6. Szyperski & parameterized types in Oberon?

7. Type extension (was Oberon)

8. Real Types and Lightniing Oberon

9. Oberon/F: Returning extended types.

10. Type guard error (?)/SPARC Oberon

11. Enumerations in Oberon (was: Re: Enumerated types)

12. Oberon-2: Type Bound Proc question

 

 
Powered by phpBB® Forum Software