Oberon language standard 
Author Message
 Oberon language standard

Despite developing a C compiler, I have kept a strong interest in Oberon
for a long time. I am thinking about doing an Oberon front-end for the
compiler I am working on. However, the language seems to be in a bit of
a mess right now. There are so many different new versions - Lightning
Oberon, Component Pascal, OberonX, ActiveOberon. There also seems to be
quite a few important features missing - e.g. C++ and Java linkability,
multi-threading, standard libraries. I am, of course, thinking of Oberon
as a language for multiple platforms, rather than the Oberon system.

Why not have a new, open Oberon standard that can be agreed on?

Here are some suggestions:
    Some kind of preprocessor that lets you add macros, like in C. This
is extremely useful when writing code for multiple platforms or
compilers.
    Operator overloading. This is in OberonX, but I haven't seen
complete documentation of how this should work.
    External definition modules that let you link to C and C++.
    Exceptions. These can be so useful in windowing applications.
    Multiple inheritance. Java's system of interfaces gives multiple
inheritance without the speed drop (or without a big speed drop).
    Dots in module names, like in Java. This makes it easier to link to
Java and also helps when distributing libraries.
    Pointers to members. I have written an experimental version of this,
which is type-safe and simple. It can be extremely useful and lets you
take advantage of most of the features of C's pointers, without the
dangers.
    Structured constants. In some programs, this can be essential.
    Multi-threading. Makes garbage collection a little trickier, but
Modula-3 does it so why shouldn't Oberon?
    Object finalization. This has been added to a few of the Oberon
extensions, but I think it should be standardized.
    Weak references. This seems to be in the Oberon system from the
start and used for storing fonts. But why isn't this within the language
standard? It is such a useful feature.
    COM and CORBA support. Component programming has become incredibly
important - and also makes it easier to use a less "mainstream"
language, so there should be an elegant and standard way of creating
them.
    Some extra operators for vector maths. This is important to me
because of all of the 3D work I do. I would reallly like dot-product,
cross-product and maginitude.
    Unicode. LONGCHAR?
    64-bit integers. HUGEINT?, HUGECARD?

OK, I know Oberon is meant to be small, but computers have become much
larger and more powerful since it was originally designed, so I think
the definition of a "small" language should be extended. What is
important to me is that it is possible to understand every language
feature, that the language be safe and that you can easily write
readable code (and find it difficult to write unreadable code). I don't
like using C++ because it is far too easy to write something that no-one
could ever work out what it means.

Andrew Richards



Thu, 27 Feb 2003 19:52:46 GMT  
 Oberon language standard

Quote:

> Despite developing a C compiler, I have kept a strong interest in Oberon
> for a long time. I am thinking about doing an Oberon front-end for the
> compiler I am working on. However, the language seems to be in a bit of
> a mess right now. There are so many different new versions - Lightning
> Oberon, Component Pascal, OberonX, ActiveOberon. There also seems to be
> quite a few important features missing - e.g. C++ and Java linkability,
> multi-threading, standard libraries. I am, of course, thinking of Oberon
> as a language for multiple platforms, rather than the Oberon system.

> Why not have a new, open Oberon standard that can be agreed on?

From time to time this kind of suggestion has been raised in this place.
Based on past discussions, I think that agreement might be difficult to
achieve. Various groups appear to be evolving the language with
differing ends in mind. My impression is that most of the important
design decisions are not being made under an open process. To my
knowledge, the only open compiler/language system is OOC
(http://ooc.sourceforge.net).

Quote:
>     Some kind of preprocessor that lets you add macros, like in C. This
> is extremely useful when writing code for multiple platforms or
> compilers.

I think a generalised macro preprocessor (as in C) would probably be a
bad idea as it can lead to some very twisted coding. Conditional
compilation (eg. XDS, OOC) is quite useful.

Quote:
>     Operator overloading. This is in OberonX, but I haven't seen
> complete documentation of how this should work.

I think Native Oberon also supports this.

Quote:
>     External definition modules that let you link to C and C++.

XDS, Component Pascal and OOC have quite comprehensive systems for
interfacing to C. These allow pretty much equivalent functionality, but
vary in details. For example:

Component Pascal:
- untagged records and arrays are declared with [untagged]
- alignment is declared with [noalign], [align1], [align2], ...
- NIL may be passed to VAR parameters declared [nil]
- strings be assigned to any variables of type "POINTER TO ARRAY
[untagged] OF CHAR/SHORTCHAR"

OOC:
- all records and arrays in interface modules are untagged
- alignment is declared with [NOALIGN], [ALIGN1], [ALIGN2], ...
- NIL may be passed to VAR parameters declared [NIL_COMPAT]
- string constants assigned to relevant pointer variables tagged
[CSTRING]

XDS have a translator for generating (Modula-2) interface modules from C
include files. I'm working on a similar system for OOC/Component Pascal
(perpetually under development ;-)

Generalised C++ support would be hard to achieve because C++ compilers
vary so much in their implementation. To support overloading, function
names are mangled by the compiler to include type information. There is
no standard for this so it would be difficult to build generalised
interfaces to C++ object files. Providing a binary interface via
something like COM is not too hard, but would need to work without
access to C++ constructors/destructors/templates/RTTI etc.

Quote:
>     Exceptions. These can be so useful in windowing applications.

OOC provides this at the library level, but its not as slick as
exceptions in Java, or Microsoft's C extensions. There has been some
interesting work implementing exception handling in Oberon using
meta-programming:
  http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html

Quote:
>     Multiple inheritance. Java's system of interfaces gives multiple
> inheritance without the speed drop (or without a big speed drop).

This has been proposed for Oberon, but I don't know if anyone
implemented it. See A. E. Nedorya, E. V. Tarasov and A. D. Hapugin -
Restricted Multiple Inheritance - JMLC'94
(http://www.ics.uci.edu/~pfroehli/mirror/rmi.pdf).

Quote:
>     Dots in module names, like in Java. This makes it easier to link to
> Java and also helps when distributing libraries.

OOC implements a structured module name space.

Quote:
>     Pointers to members. I have written an experimental version of this,
> which is type-safe and simple. It can be extremely useful and lets you
> take advantage of most of the features of C's pointers, without the
> dangers.
>     Structured constants. In some programs, this can be essential.

This is particularly useful for embedded systems with small RAM.

Quote:
>     Multi-threading. Makes garbage collection a little trickier, but
> Modula-3 does it so why shouldn't Oberon?
>     Object finalization. This has been added to a few of the Oberon
> extensions, but I think it should be standardized.

Some Oberon impelementations do this at the library level. Component
Pascal rightly includes it in the language.

Quote:
>     Weak references. This seems to be in the Oberon system from the
> start and used for storing fonts. But why isn't this within the language
> standard? It is such a useful feature.
>     COM and CORBA support. Component programming has become incredibly
> important - and also makes it easier to use a less "mainstream"
> language, so there should be an elegant and standard way of creating
> them.

Component Pascal has a nice COM interface, but its an expensive addition
to the standard compiler, and is currently only supported on Win32.

OOC has a generalised vtable interface which means that you can define
abstract types that mirror COM interfaces or C++ abstract types.
Concrete extensions of these types are binary compatible with C++/COM.

This is absolutely essential if you want to work with any of the newer
Windows facilities (eg. SAPI, DirectX, etc).

Quote:
>     Some extra operators for vector maths. This is important to me
> because of all of the 3D work I do. I would reallly like dot-product,
> cross-product and maginitude.

I think a COMPLEX data type would be quite useful, especially for
scientific applications. Having this built into the language would be
much cleaner and more efficient than attempting to implement it via a
library. It might also map onto some machine primitives on the newer
CPUs.

The same could be said of strings. Currently, Oberon only defines
strings as constants. Component Pascal includes them as true types, but
they are still bound up with character arrays.

Quote:
>     Unicode. LONGCHAR?
>     64-bit integers. HUGEINT?, HUGECARD?

A standard for CHAR/INTEGERs would be nice.

          OOC        CP
char8:    CHAR       SHORTCHAR
char16:   LONGCHAR   CHAR
int8:     SHORTINT   BYTE
int16:    INTEGER    SHORTINT
int32:    LONGINT    INTEGER
int64:    HUGEINT    LONGINT

Quote:
> OK, I know Oberon is meant to be small, but computers have become much
> larger and more powerful since it was originally designed, so I think
> the definition of a "small" language should be extended.

From many points of view, "small" is nice. It makes the language easy to
implement and easy to use. Unfortunately, it also means that people will
need to add their own extensions when they reach the limit of what can
easily be done. A suitably extended Oberon would still be smaller than
C++ or Java.

I think your list is probably a fair one. There are a few items I would
add myself:

- STRING type
- enumerated types
- parametric types or generics.
  (see http://www.fit.qut.edu.au/~szypersk/pub/JMLC97.ps.gz)
- compound types
  (see http://www.abo.fi/~mbuechi/publications/OOPSLA98.html)

Hmm. That should about do it ;-)

Quote:
> important to me is that it is possible to understand every language
> feature, that the language be safe and that you can easily write
> readable code (and find it difficult to write unreadable code). I don't
> like using C++ because it is far too easy to write something that no-one
> could ever work out what it means.

I came to Oberon from C++ in an effort to maximise my own effectiveness
as a programmer. The language is not as expressive as I would like, but
that's a tradeoff I'm prepared to accept for the moment.

Cheers,
  Stewart



Fri, 28 Feb 2003 12:22:51 GMT  
 Oberon language standard

Quote:

> Despite developing a C compiler, I have kept a strong interest in Oberon
> for a long time. I am thinking about doing an Oberon front-end for the
> compiler I am working on. However, the language seems to be in a bit of
> a mess right now. There are so many different new versions - Lightning
> Oberon, Component Pascal, OberonX, ActiveOberon. There also seems to be
> quite a few important features missing - e.g. C++ and Java linkability,
> multi-threading, standard libraries. I am, of course, thinking of Oberon
> as a language for multiple platforms, rather than the Oberon system.

> Why not have a new, open Oberon standard that can be agreed on?

The whole ETH Oberon system is written in Oberon-1, with open array
pointers.  All our mainstream compilers support this language as a subset.

Quote:
>     Some kind of preprocessor that lets you add macros, like in C. This
> is extremely useful when writing code for multiple platforms or
> compilers.

Preprocessor directives and macros are also the reason why many C
programs are a mess.  Superficially macros seem to make the programs
more readable, but actually they serve only to obscure what the
code is really doing.

For portability, rather build your system to provide base libraries
with portable interfaces.  And select a subset of the Oberon language
that works on all (or most) compilers.  Automatic translation to this
subset might also be an option.

Quote:
>     Operator overloading. This is in OberonX, but I haven't seen
> complete documentation of how this should work.

See Chapter7.Text in the Native Oberon distribution, or look at:
  http://www.oberon.ethz.ch/native/misc/Chapter7.pdf

Quote:
>     External definition modules that let you link to C and C++.
>     Exceptions. These can be so useful in windowing applications.
>     Multiple inheritance. Java's system of interfaces gives multiple
> inheritance without the speed drop (or without a big speed drop).
>     Dots in module names, like in Java. This makes it easier to link to
> Java and also helps when distributing libraries.
>     Pointers to members. I have written an experimental version of this,
> which is type-safe and simple. It can be extremely useful and lets you
> take advantage of most of the features of C's pointers, without the
> dangers.
>     Structured constants. In some programs, this can be essential.
>     Multi-threading. Makes garbage collection a little trickier, but
> Modula-3 does it so why shouldn't Oberon?
>     Object finalization. This has been added to a few of the Oberon
> extensions, but I think it should be standardized.
>     Weak references. This seems to be in the Oberon system from the
> start and used for storing fonts. But why isn't this within the language
> standard? It is such a useful feature.
>     COM and CORBA support. Component programming has become incredibly
> important - and also makes it easier to use a less "mainstream"
> language, so there should be an elegant and standard way of creating
> them.
>     Some extra operators for vector maths. This is important to me
> because of all of the 3D work I do. I would reallly like dot-product,
> cross-product and maginitude.
>     Unicode. LONGCHAR?
>     64-bit integers. HUGEINT?, HUGECARD?
> OK, I know Oberon is meant to be small, but computers have become much
> larger and more powerful since it was originally designed, so I think
> the definition of a "small" language should be extended. What is
> important to me is that it is possible to understand every language
> feature, that the language be safe and that you can easily write
> readable code (and find it difficult to write unreadable code). I don't
> like using C++ because it is far too easy to write something that no-one
> could ever work out what it means.

Add all the above to Oberon and you would end up with the same result :-)

-- Pieter

--
Pieter Muller, Institute for Computer Systems, ETH Zurich
Native Oberon OS: http://www.oberon.ethz.ch/native/



Fri, 28 Feb 2003 17:53:13 GMT  
 Oberon language standard


Quote:

> > Despite developing a C compiler, I have kept a strong interest in
Oberon
> > for a long time. I am thinking about doing an Oberon front-end for
the
> > compiler I am working on. However, the language seems to be in a
bit of
> > a mess right now. There are so many different new versions -
Lightning
> > Oberon, Component Pascal, OberonX, ActiveOberon. There also seems
to be
> > quite a few important features missing - e.g. C++ and Java
linkability,
> > multi-threading, standard libraries. I am, of course, thinking of
Oberon
> > as a language for multiple platforms, rather than the Oberon system.

> > Why not have a new, open Oberon standard that can be agreed on?

> From time to time this kind of suggestion has been raised in this
place.
> Based on past discussions, I think that agreement might be difficult
to
> achieve. Various groups appear to be evolving the language with
> differing ends in mind. My impression is that most of the important
> design decisions are not being made under an open process. To my
> knowledge, the only open compiler/language system is OOC
> (http://ooc.sourceforge.net).

Without getting into a drawn-out argument about what is/isn't true
"open source" I will add that the source code for most Oberon
compilers including the ones that come with V4 and System 3 are
freely available.  Also the "StrawHat" Oberon compiler is explicitly
GPL.  But I will agree that OOC has probably done the best at
"group compiler" development.

Quote:
> >     Some kind of preprocessor that lets you add macros, like in C.
This
> > is extremely useful when writing code for multiple platforms or
> > compilers.

> I think a generalised macro preprocessor (as in C) would probably be a
> bad idea as it can lead to some very twisted coding. Conditional
> compilation (eg. XDS, OOC) is quite useful.

I think it would be nice to embed certain extensions like preprocessors
in comments.  For example :

  WriterDesc* = RECORD [ABSTRACT]
    (BinaryRider.WriterDesc)
  END;

Could be written as :

  WriterDesc* = RECORD (*.ABSTRACT.*)
    (BinaryRider.WriterDesc)
  END;

The only change to the compiler would be to define (*. as the start
of extension code.  When a compiler that didn't understand the
extension code saw this it would view it as a comment and not
break.

- Show quoted text -

Quote:
> >     Operator overloading. This is in OberonX, but I haven't seen
> > complete documentation of how this should work.

> I think Native Oberon also supports this.

> >     External definition modules that let you link to C and C++.

> XDS, Component Pascal and OOC have quite comprehensive systems for
> interfacing to C. These allow pretty much equivalent functionality,
but
> vary in details. For example:

> Component Pascal:
> - untagged records and arrays are declared with [untagged]
> - alignment is declared with [noalign], [align1], [align2], ...
> - NIL may be passed to VAR parameters declared [nil]
> - strings be assigned to any variables of type "POINTER TO ARRAY
> [untagged] OF CHAR/SHORTCHAR"

> OOC:
> - all records and arrays in interface modules are untagged
> - alignment is declared with [NOALIGN], [ALIGN1], [ALIGN2], ...
> - NIL may be passed to VAR parameters declared [NIL_COMPAT]
> - string constants assigned to relevant pointer variables tagged
> [CSTRING]

> XDS have a translator for generating (Modula-2) interface modules
from C
> include files. I'm working on a similar system for OOC/Component
Pascal
> (perpetually under development ;-)

Oberon System 3 and V4 also support linking to DLLs that are written
in C or any other language.  After all that's how those systems are
able to access the windows GDI for implementing the Oberon user
interface.  And the XDS c-header translator is just as helpful to
the Sys 3 or V4 developer as to the XDS developer.

Quote:
> >     Exceptions. These can be so useful in windowing applications.

> OOC provides this at the library level, but its not as slick as
> exceptions in Java, or Microsoft's C extensions. There has been some
> interesting work implementing exception handling in Oberon using
> meta-programming:
>   http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html

I think I recall that this has been ported to Sys 3 as well, but I
could be wrong.  It would be nice if a library method for this could
be found that worked both for OOC and Sys 3/V4 but I don't know if
that's possible.

Quote:
> >     Multiple inheritance. Java's system of interfaces gives multiple
> > inheritance without the speed drop (or without a big speed drop).

> This has been proposed for Oberon, but I don't know if anyone
> implemented it. See A. E. Nedorya, E. V. Tarasov and A. D. Hapugin -
> Restricted Multiple Inheritance - JMLC'94
> (http://www.ics.uci.edu/~pfroehli/mirror/rmi.pdf).

I'm still not sold on the value of multiple inheritence, especially
the Java variation which is really only interface reuse as opposed
to code reuse.

Quote:
> >     Dots in module names, like in Java. This makes it easier to
link to
> > Java and also helps when distributing libraries.

> OOC implements a structured module name space.

I'm a little confuse here.  Oberon has suppored dotted module names
from WAY back.

Quote:
> >     Pointers to members. I have written an experimental version of
this,
> > which is type-safe and simple. It can be extremely useful and lets
you
> > take advantage of most of the features of C's pointers, without the
> > dangers.

I'm a little confused here also.  Member variables can be pointers
in Oberon and that's from WAY back in Oberon-1.  I guess I'd need
to see an example.

Quote:
> Component Pascal has a nice COM interface, but its an expensive
addition
> to the standard compiler, and is currently only supported on Win32.

From what I read on the BlackBox mailing list (which has been
unfortunately quiet as of late) it's possible to do COM without
the DTC add-on, but the DTC add-on makes it much easier.

That being said I do believe that Oberon Microsystems priced
themselves out of the market.  Admittedly I've never run a software
business.  But it seems to me that back when OMI was winning
awards from Byte for their DTC product they would have gotten
more people to gamble ~ $200.00 to try it out than the
approx $1,400.00.  Also compared to programming COM in C++
DTC is much easier, but comparing COM to VB it seems to be
about the same level of difficulty.  DTC COM components are
probably faster than their VB equivilents, but who's going
to shell out $1,400.00 just to try that out?  Also there was
a complete dearth of advertising of DTC, but the JBed spinoff
is at least doing better in this department.

Quote:
> I think a COMPLEX data type would be quite useful, especially for
> scientific applications. Having this built into the language would be
> much cleaner and more efficient than attempting to implement it via a
> library. It might also map onto some machine primitives on the newer
> CPUs.

At this point since there AREN'T any mainstream CPUs with direct
support for COMPLEX math I would strongly argue for the library
approach.  Using Native Oberon style operator overloading it
would be exactly as a language extension from the point of view
of the end programmer.  In fact providing a way for those who
want to add COMPLEX/matrix/vector/fill_in_the_blank types to
Oberon to do so without burdening the language is perhaps the
best argument for operator overloading.

Quote:
> The same could be said of strings. Currently, Oberon only defines
> strings as constants. Component Pascal includes them as true types,
but
> they are still bound up with character arrays.

Well I disagree with your assessment that Oberon only defines strings
as constants.  String procedure parameters are well defined as
open arrays of char.  I do agree that the addition of the $ and +
operators to Component Pascal does greatly enhance the use of
strings since they allow the assignment of different size string
variables and a clean way to do string concatenation.

That pretty much covers what I need in terms of strings.  I suppose
a dynamic string datatype would be nice.  I know some use Text for
that purpose.  Unfortunately the Text datatype has not remained
constant accross V4, Sys 3, BB.  And it seems overkill for some
jobs that might benifit from dynamic strings.

Quote:
> >     Unicode. LONGCHAR?
> >     64-bit integers. HUGEINT?, HUGECARD?

> A standard for CHAR/INTEGERs would be nice.

>           OOC        CP
> char8:    CHAR       SHORTCHAR
> char16:   LONGCHAR   CHAR
> int8:     SHORTINT   BYTE
> int16:    INTEGER    SHORTINT
> int32:    LONGINT    INTEGER
> int64:    HUGEINT    LONGINT

I made a post about this a few months ago, but no one followed
up on it.  I would really like to hear how my library solution
to this problem works under OOC on a 64 bit machine.  Here's
the code for Component Pascal.

MODULE SystemTypes;

TYPE
  Int64* = LONGINT;
  Int32* = INTEGER;
  Int16* = SHORTINT;
  Int8* = BYTE;
  MaxInt* = Int64;

  Char8* = SHORTCHAR;
  Char16* = CHAR;

  Real32* = SHORTREAL;
  Real64* = REAL;
  MaxReal* = Real64;

END SystemTypes.

Then if you declared a data type as "SystemTypes.MaxInt" you would
never have to worry about your code being "32 bit restricted".  On
a 32 bit machine it would compile to a 32 bit integer.  On a 64
bit machine it would compile to a 64 bit integer.  Also you could
be explicit about how many bits you wanted a particular field to
be without having to worry about LONGINT being 32 bits on OOC and
64 bits on CP or XDS.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 01 Mar 2003 01:53:12 GMT  
 Oberon language standard


Quote:
> Despite developing a C compiler, I have kept a strong interest in
Oberon
> for a long time. I am thinking about doing an Oberon front-end for the
> compiler I am working on. However, the language seems to be in a bit
of
> a mess right now. There are so many different new versions - Lightning
> Oberon, Component Pascal, OberonX, ActiveOberon. There also seems to
be
> quite a few important features missing - e.g. C++ and Java
linkability,
> multi-threading, standard libraries. I am, of course, thinking of
Oberon
> as a language for multiple platforms, rather than the Oberon system.

I'll make one initial prediction.  I bet this thread will grow to
be very large.  Language extension threads in this newsgroup have
a tendancy to do that.  ;-)

Quote:
> Why not have a new, open Oberon standard that can be agreed on?

I proposed to have an online "Oakwood-2" conference some years ago
to do just that, but there weren't any takers.  At this point I no
longer see that as feasible.  The various groups have too much
invested in what they've already done agree on a single way of
doing it.  For example, OOC and Component Pascal both support
abstract records, but they use a (slightly) different syntax to
accomplish this.  And from what I can tell abstract records
accomplish the same thing as interfaces in Lightning Oberon
(in fact I think the .NET version of Component Pascal proves
this) but again a different syntax.

At this point I'm far more interested in an "Oberon convergence"
project.  The basic idea is to look at ways to do things that
will work on more than one Oberon compiler/system.  Project
Voyager is very much along the lines of what I'm considering.

http://www.statlab.uni-heidelberg.de/projects/voyager/

Quote:
> Here are some suggestions:
>     Some kind of preprocessor that lets you add macros, like in C.
This
> is extremely useful when writing code for multiple platforms or
> compilers.

Personally I still think the best way to handle platform differences
is to abstract those differences into system dependent modules rather
than to use conditional compilation.  The original Oberon system was
quickly ported to quite a few different platforms using this method.
With all of the supposed "power" of conditional compilation in C
and the supposed "power" of C make files every time I've had to
install some significantly large package like Mesa I've had to jump
through all sorts of (unnecessary in my opinion) hoops.

Quote:
>     Operator overloading. This is in OberonX, but I haven't seen
> complete documentation of how this should work.

As someone else pointed out operator overloading is available in
the Native Oberon compiler.  It's probably helpful from the standpoint
of "defending" the compiler from too many extensions since it allows
clean library implementation of things like COMPLEX types and matrix
types.

Quote:
>     External definition modules that let you link to C and C++.

Are you talking about static linking or dynamic linking?  It's
already possible to link to DLLs from just about every version
of Oberon that I can think of.

Quote:
>     Exceptions. These can be so useful in windowing applications.

As someone has already pointed out exception handling can via a
library.  Now doing this in a way that's portable between the
various systems/compilers would be a challenge.

Quote:
>     Multiple inheritance. Java's system of interfaces gives multiple
> inheritance without the speed drop (or without a big speed drop).

I'm not sold on multiple inheritence, especially Java's version which
is only interface inheritence.  I personally haven't run into any
situations that couldn't be handled by single inheritence and I think
Smalltalk is "proof-by-example" that it's not vital.  Mind you, I'm
sure some people find it useful.  (Not trying to start an inheritence
holy war here.)

Quote:
>     Dots in module names, like in Java. This makes it easier to link
to
> Java and also helps when distributing libraries.

Oberon has always allowed dots in module names.  At least that's true
for V4 and System 3.

Quote:
>     Pointers to members. I have written an experimental version of
this,
> which is type-safe and simple. It can be extremely useful and lets you
> take advantage of most of the features of C's pointers, without the
> dangers.

I'm not sure what you mean by this.  Oberon member variables can be
pointers.  Perhaps if I saw an example of what you can accomplish
with your experimental version that you can't accomplish easily with
Oberon-2.

The only thing that I missed from C pointers was the performance
enhancement of pointer arithmetic over the array indexing.  In
Oberon-SA (an experimental language by N. Wirth used in a robotic
helicopter project) this is handled type-safely by array riders.
But the same thing has been accomplished via Oberon-2 libraries
also.

See : ftp://ftp.inf.ethz.ch/pub/ETHOberon/Contrib/MultiArray/

Quote:
>     Structured constants. In some programs, this can be essential.
>     Multi-threading. Makes garbage collection a little trickier, but
> Modula-3 does it so why shouldn't Oberon?

Again multi-threading can, and has been implemented without extension
to the Oberon-2 language.  However, to my knowledge, this has been
done mainly as "student project" or "dissertation" work.

Now as to why was multithreading initially put in Modula-3 and not
Oberon?  To understand that you need to read the book "Project Oberon".
Modula-3 and Oberon were designed with two different ideas in mind.
Modula-3 was initially built as an experimental language on top of
Unix.  Oberon was built as an experimental language on top of Oberon.
Thus Modula-3 could make certain assumptions about the underlying
system without adding extra cost to the Modula-3 compiler.

Beyond that there are advantages/disadvantages to both single process
multitasking (which Oberon has) and multi-threading.  The biggest
problem as I see it is getting comfortable with the SPM programming
model.  There simply aren't enough good examples out there.  A few
years ago I was working on a project in BlackBox and I kept thinking
"this would be SO much easier if I either had modal dialog boxes
or pre-emptive multitasking."  Eventually I reformulated my program
to better fit what I had to work this.  The surprise is that I ended
up with a much better program as a result.

Quote:
>     Object finalization. This has been added to a few of the Oberon
> extensions, but I think it should be standardized.
>     Weak references. This seems to be in the Oberon system from the
> start and used for storing fonts. But why isn't this within the
language
> standard? It is such a useful feature.

I'm not sure what "weak references" are, but if it can be handled
nicely at the system language, then why would it need to be a part
of the language?

Quote:
>     COM and CORBA support. Component programming has become incredibly
> important - and also makes it easier to use a less "mainstream"
> language, so there should be an elegant and standard way of creating
> them.

As has already been pointed out there is a COM add-on for BlackBox
Component Pascal.  But J. Gutknecht has also implemented a COM
server running under Oberon System 3.

http://www.inf.ethz.ch/publications/abstract.php3?no=tech-
reports/3xx/323

With the changes in the air due to COM+ and .NET building something
to work with COM may be a bit late at this point.  It is good to
see that there's a .NET version of Component Pascal and of course
there is Lightning Oberon.

On a side note I'm about 75 - 80% finished with an IDL-to-Oberon
translator for CORBA.  Due to personal time constraints I have
no idea when I'd be finished with that though.

Quote:
>     Some extra operators for vector maths. This is important to me
> because of all of the 3D work I do. I would reallly like dot-product,
> cross-product and maginitude.

Is this something that could be done with operator overloading?

Quote:
>     Unicode. LONGCHAR?
>     64-bit integers. HUGEINT?, HUGECARD?

See the other post I made in this thread concerning this.

Quote:
> OK, I know Oberon is meant to be small, but computers have become much
> larger and more powerful since it was originally designed, so I think
> the definition of a "small" language should be extended.

"Small" language design is useful for more than just how much the
compiler taxes the hardware.  It also deals with how hard the language
is to learn.  And somewhere, somehow one MUST make tradeoffs.   The
things you'd like added to Oberon might not seem like much, but if
every little extension that everyone might possibly like added to
the language was added it would be end up being larger than C++,
Modula-3 and Java put together.  The only way that I see around this
is to use something like Forth or YAFL where the end programmer
literally has complete control of the compiler.  Then if I need,
for example, language extensions that help with 3D graphics I
can add them without adding extra burden to the programmer who's
just using the system for database programming.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 01 Mar 2003 04:34:51 GMT  
 Oberon language standard

Quote:


> > Despite developing a C compiler, I have kept a strong interest in
Oberon
> > for a long time. I am thinking about doing an Oberon front-end for
the
> > compiler I am working on. However, the language seems to be in a
bit of
> > a mess right now. There are so many different new versions -
Lightning
> > Oberon, Component Pascal, OberonX, ActiveOberon. There also seems
to be
> > quite a few important features missing - e.g. C++ and Java
linkability,
> > multi-threading, standard libraries. I am, of course, thinking of
Oberon
> > as a language for multiple platforms, rather than the Oberon system.

> > Why not have a new, open Oberon standard that can be agreed on?

> The whole ETH Oberon system is written in Oberon-1, with open array
> pointers.  All our mainstream compilers support this language as a
subset.

Then does Lightning Oberon support Oberon-1 as a subset?  Or is
Lightning Oberon not considered a "mainstream ETH compiler"?

Quote:
> >     Some kind of preprocessor that lets you add macros, like in C.
This
> > is extremely useful when writing code for multiple platforms or
> > compilers.

> Preprocessor directives and macros are also the reason why many C
> programs are a mess.  Superficially macros seem to make the programs
> more readable, but actually they serve only to obscure what the
> code is really doing.

> For portability, rather build your system to provide base libraries
> with portable interfaces.  And select a subset of the Oberon language
> that works on all (or most) compilers.  Automatic translation to this
> subset might also be an option.

I agree totally (to a point).  Porting a program from System 3 for
windows to System 3 for Linux seem MUCH easier than porting the
same C++ program from say Linux to Solaris.  On the other hand
porting it from System 3 to V4 is more involved.  That's probably
more akin to porting a C++ program from Linux to Windows without
the help of some commercial "cross-platform" library.

- Show quoted text -

Quote:
> > OK, I know Oberon is meant to be small, but computers have become
much
> > larger and more powerful since it was originally designed, so I
think
> > the definition of a "small" language should be extended. What is
> > important to me is that it is possible to understand every language
> > feature, that the language be safe and that you can easily write
> > readable code (and find it difficult to write unreadable code). I
don't
> > like using C++ because it is far too easy to write something that
no-one
> > could ever work out what it means.

> Add all the above to Oberon and you would end up with the same
result :-)

> -- Pieter

> --
> Pieter Muller, Institute for Computer Systems, ETH Zurich
> Native Oberon OS: http://www.oberon.ethz.ch/native/

Well I think a lot of that can (and should) be added via libraries
as opposed to language extensions.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 01 Mar 2003 04:41:24 GMT  
 Oberon language standard
Oberon is a popular base language for experimenting with new language
features. It seems a pity that to use all of these advanced features, you
have to switch to a C-like language like Java, C++ or C#. Why not a
Modula/Oberon descendant that has a wide range of language features, but
added with great care so as not to make the language confusingly complex? The
result probably wouldn't be Oberon any more, though.  Modula-3 has a lot of
these features, but I prefer Oberon syntax. Also, Modula-3 is missing some of
the newer ideas.

Andrew



Sat, 01 Mar 2003 17:41:18 GMT  
 Oberon language standard
[...]

Quote:

> > >     Exceptions. These can be so useful in windowing applications.

> > OOC provides this at the library level, but its not as slick as
> > exceptions in Java, or Microsoft's C extensions. There has been some
> > interesting work implementing exception handling in Oberon using
> > meta-programming:
> >   http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html

> I think I recall that this has been ported to Sys 3 as well, but I
> could be wrong.  It would be nice if a library method for this could

afaik, yes, see http://www.cs.inf.ethz.ch/~zeller/plugins.html

Bernhard



Sat, 01 Mar 2003 19:54:19 GMT  
 Oberon language standard


Quote:
> Oberon is a popular base language for experimenting with new language
> features. It seems a pity that to use all of these advanced features,
you
> have to switch to a C-like language like Java, C++ or C#. Why not a
> Modula/Oberon descendant that has a wide range of language features,
but
> added with great care so as not to make the language confusingly
complex? The
> result probably wouldn't be Oberon any more, though.  Modula-3 has a
lot of
> these features, but I prefer Oberon syntax. Also, Modula-3 is missing
some of
> the newer ideas.

> Andrew

Why not add the features to the system as opposed to the language?
That's what has been done with exception handling.  It's been
incorporated as a library and the syntax is just as clean (perhaps
even cleaner) than similair syntax in languages that have exception
handling built in the compiler.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 01 Mar 2003 22:33:38 GMT  
 Oberon language standard
It seems that Oberon is a popular choice of language to try out experimental
language features on. Probably because of its simplicity. It just seems a pity
that the available extensions and ideas haven't been put together into a new
Oberon-like language. Other languages, like Modula-3, Java and C# seem to be
heavily Oberon-influenced, but I still prefer the form of the Oberon language
and its efficiency. I just need some extra features!

Maybe it's time for a new, larger language, with some of these ideas. It is
clear to me now that result wouldn't be Oberon, but hopefully a lot of the
spirit would remain.

Andrew Richards

Quote:


> > Despite developing a C compiler, I have kept a strong interest in Oberon
> > for a long time. I am thinking about doing an Oberon front-end for the
> > compiler I am working on. However, the language seems to be in a bit of
> > a mess right now. There are so many different new versions - Lightning
> > Oberon, Component Pascal, OberonX, ActiveOberon. There also seems to be
> > quite a few important features missing - e.g. C++ and Java linkability,
> > multi-threading, standard libraries. I am, of course, thinking of Oberon
> > as a language for multiple platforms, rather than the Oberon system.

> > Why not have a new, open Oberon standard that can be agreed on?

> From time to time this kind of suggestion has been raised in this place.
> Based on past discussions, I think that agreement might be difficult to
> achieve. Various groups appear to be evolving the language with
> differing ends in mind. My impression is that most of the important
> design decisions are not being made under an open process. To my
> knowledge, the only open compiler/language system is OOC
> (http://ooc.sourceforge.net).

> >     Some kind of preprocessor that lets you add macros, like in C. This
> > is extremely useful when writing code for multiple platforms or
> > compilers.

> I think a generalised macro preprocessor (as in C) would probably be a
> bad idea as it can lead to some very twisted coding. Conditional
> compilation (eg. XDS, OOC) is quite useful.

> >     Operator overloading. This is in OberonX, but I haven't seen
> > complete documentation of how this should work.

> I think Native Oberon also supports this.

> >     External definition modules that let you link to C and C++.

> XDS, Component Pascal and OOC have quite comprehensive systems for
> interfacing to C. These allow pretty much equivalent functionality, but
> vary in details. For example:

> Component Pascal:
> - untagged records and arrays are declared with [untagged]
> - alignment is declared with [noalign], [align1], [align2], ...
> - NIL may be passed to VAR parameters declared [nil]
> - strings be assigned to any variables of type "POINTER TO ARRAY
> [untagged] OF CHAR/SHORTCHAR"

> OOC:
> - all records and arrays in interface modules are untagged
> - alignment is declared with [NOALIGN], [ALIGN1], [ALIGN2], ...
> - NIL may be passed to VAR parameters declared [NIL_COMPAT]
> - string constants assigned to relevant pointer variables tagged
> [CSTRING]

> XDS have a translator for generating (Modula-2) interface modules from C
> include files. I'm working on a similar system for OOC/Component Pascal
> (perpetually under development ;-)

> Generalised C++ support would be hard to achieve because C++ compilers
> vary so much in their implementation. To support overloading, function
> names are mangled by the compiler to include type information. There is
> no standard for this so it would be difficult to build generalised
> interfaces to C++ object files. Providing a binary interface via
> something like COM is not too hard, but would need to work without
> access to C++ constructors/destructors/templates/RTTI etc.

> >     Exceptions. These can be so useful in windowing applications.

> OOC provides this at the library level, but its not as slick as
> exceptions in Java, or Microsoft's C extensions. There has been some
> interesting work implementing exception handling in Oberon using
> meta-programming:
>   http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html

> >     Multiple inheritance. Java's system of interfaces gives multiple
> > inheritance without the speed drop (or without a big speed drop).

> This has been proposed for Oberon, but I don't know if anyone
> implemented it. See A. E. Nedorya, E. V. Tarasov and A. D. Hapugin -
> Restricted Multiple Inheritance - JMLC'94
> (http://www.ics.uci.edu/~pfroehli/mirror/rmi.pdf).

> >     Dots in module names, like in Java. This makes it easier to link to
> > Java and also helps when distributing libraries.

> OOC implements a structured module name space.

> >     Pointers to members. I have written an experimental version of this,
> > which is type-safe and simple. It can be extremely useful and lets you
> > take advantage of most of the features of C's pointers, without the
> > dangers.
> >     Structured constants. In some programs, this can be essential.

> This is particularly useful for embedded systems with small RAM.

> >     Multi-threading. Makes garbage collection a little trickier, but
> > Modula-3 does it so why shouldn't Oberon?
> >     Object finalization. This has been added to a few of the Oberon
> > extensions, but I think it should be standardized.

> Some Oberon impelementations do this at the library level. Component
> Pascal rightly includes it in the language.

> >     Weak references. This seems to be in the Oberon system from the
> > start and used for storing fonts. But why isn't this within the language
> > standard? It is such a useful feature.
> >     COM and CORBA support. Component programming has become incredibly
> > important - and also makes it easier to use a less "mainstream"
> > language, so there should be an elegant and standard way of creating
> > them.

> Component Pascal has a nice COM interface, but its an expensive addition
> to the standard compiler, and is currently only supported on Win32.

> OOC has a generalised vtable interface which means that you can define
> abstract types that mirror COM interfaces or C++ abstract types.
> Concrete extensions of these types are binary compatible with C++/COM.

> This is absolutely essential if you want to work with any of the newer
> Windows facilities (eg. SAPI, DirectX, etc).

> >     Some extra operators for vector maths. This is important to me
> > because of all of the 3D work I do. I would reallly like dot-product,
> > cross-product and maginitude.

> I think a COMPLEX data type would be quite useful, especially for
> scientific applications. Having this built into the language would be
> much cleaner and more efficient than attempting to implement it via a
> library. It might also map onto some machine primitives on the newer
> CPUs.

> The same could be said of strings. Currently, Oberon only defines
> strings as constants. Component Pascal includes them as true types, but
> they are still bound up with character arrays.

> >     Unicode. LONGCHAR?
> >     64-bit integers. HUGEINT?, HUGECARD?

> A standard for CHAR/INTEGERs would be nice.

>           OOC        CP
> char8:    CHAR       SHORTCHAR
> char16:   LONGCHAR   CHAR
> int8:     SHORTINT   BYTE
> int16:    INTEGER    SHORTINT
> int32:    LONGINT    INTEGER
> int64:    HUGEINT    LONGINT

> > OK, I know Oberon is meant to be small, but computers have become much
> > larger and more powerful since it was originally designed, so I think
> > the definition of a "small" language should be extended.

> From many points of view, "small" is nice. It makes the language easy to
> implement and easy to use. Unfortunately, it also means that people will
> need to add their own extensions when they reach the limit of what can
> easily be done. A suitably extended Oberon would still be smaller than
> C++ or Java.

> I think your list is probably a fair one. There are a few items I would
> add myself:

> - STRING type
> - enumerated types
> - parametric types or generics.
>   (see http://www.fit.qut.edu.au/~szypersk/pub/JMLC97.ps.gz)
> - compound types
>   (see http://www.abo.fi/~mbuechi/publications/OOPSLA98.html)

> Hmm. That should about do it ;-)

> > important to me is that it is possible to understand every language
> > feature, that the language be safe and that you can easily write
> > readable code (and find it difficult to write unreadable code). I don't
> > like using C++ because it is far too easy to write something that no-one
> > could ever work out what it means.

> I came to Oberon from C++ in an effort to maximise my own effectiveness
> as a programmer. The language is not as expressive as I would like, but
> that's a tradeoff I'm prepared to accept for the moment.

> Cheers,
>   Stewart



Sat, 01 Mar 2003 22:33:00 GMT  
 Oberon language standard


Quote:
> It seems that Oberon is a popular choice of language to try out
experimental
> language features on. Probably because of its simplicity. It just
seems a pity
> that the available extensions and ideas haven't been put together
into a new
> Oberon-like language. Other languages, like Modula-3, Java and C#
seem to be
> heavily Oberon-influenced, but I still prefer the form of the Oberon
language
> and its efficiency. I just need some extra features!

> Maybe it's time for a new, larger language, with some of these ideas.
It is
> clear to me now that result wouldn't be Oberon, but hopefully a lot
of the
> spirit would remain.

> Andrew Richards

What is confusing me is why you seem to think that the only way to
add features to a language is to extend the compiler itself.  For
example, rather than ask "how do you link external modules to Oberon"
you just assume that it can't be done an that it's a "missing
feature".  Rather than ask "how can COM servers be written in Oberon"
you just assume that it can't be done and that it's a "missing
feature".  The same goes for exception handling.

Also some of the features your asking about aren't in any
mainstream language and probably never will be.  For example, I
doubt that dot product and cross product will make it into the
next version of C++ or Java as intrinsic operators.  On the other
hand if this is something that can be handled through operator
overloading than you might see it in someone's C++ 3D graphics
library (but not in Java since Java doesn't support operator
overloading).  At some point its better to write a new language
specifically for supporting the domain that you're working on.
That's what Wirth did with the hardware description language
Lola.  The Modula-3 designers did the same thing with the
Obliq which is a small language that runs on top of Modula-3
but has an independent syntax.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 02 Mar 2003 00:43:49 GMT  
 Oberon language standard

Quote:

> Oberon is a popular base language for experimenting with new language
> features. It seems a pity that to use all of these advanced features, you
> have to switch to a C-like language like Java, C++ or C#. Why not a
> Modula/Oberon descendant that has a wide range of language features, but
> added with great care so as not to make the language confusingly complex? The
> result probably wouldn't be Oberon any more, though.  Modula-3 has a lot of
> these features, but I prefer Oberon syntax. Also, Modula-3 is missing some of
> the newer ideas.

> Andrew

Not to be an irritant but doesnt c# look a whole lot like java on some levels?


Sun, 02 Mar 2003 06:47:07 GMT  
 Oberon language standard
This may be a small point, but adding COM into the language would result
in a language that was, by definition, MS specific.  And if MS ever
changed their definition...


Sun, 02 Mar 2003 09:44:47 GMT  
 Oberon language standard


Quote:
> Oberon is a popular base language for experimenting with new language
> features. It seems a pity that to use all of these advanced features,
you
> have to switch to a C-like language like Java, C++ or C#. Why not a
> Modula/Oberon descendant that has a wide range of language features,
but
> added with great care so as not to make the language confusingly
complex? The
> result probably wouldn't be Oberon any more, though.  Modula-3 has a
lot of
> these features, but I prefer Oberon syntax. Also, Modula-3 is missing
some of
> the newer ideas.

> Andrew

When you mentioned Modula-3. Take Oberon-*, add exceptions, generic
interfaces, safe code isolation, concurrent programming, and
other "cool features", and eventually you'll finish with m3. Andrew
said, he preferred O2 syntax to m3 syntax. I guess that is a minor
issue, since their syntaxes are pretty similar. However, as I
understand there is *only one* m3 implementation with some variations
(different distros). The reason for that is that complexity of M3 (* I
don't want to open a new syntax war here, but IMO m3 *is* complex *)
From another side you have variety of Oberon implementations, and at
the same time many extensions, sects, and schisms. There is a trade-
off. How much do you want a language that never changes? How much do
you want to invest in porting your code to a "better"
language/implementation/platform?

Personally, I don't see balkanization of Oberan as necessary bad. I
rather see it as "the survival of the fittest" that will keep language
young, simple, and powerful. Interlingual communication enabled
by .NET, JVM, and Native Oberon is in that direction.

I see the future of Oberon as a collection of specific-purpose simple
languages that effectively cooperate. Oberon System is an exensible OS,
and an extensible compiler would be just a big plus.

So adding operator overloading, concurrency, exception handling,
properties, interfaces, etc. is not so bad idea. Just don't add all
them in one language.

Anes

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 02 Mar 2003 10:05:10 GMT  
 Oberon language standard

Quote:

> Personally I still think the best way to handle platform differences
> is to abstract those differences into system dependent modules rather
> than to use conditional compilation.

Agree completely. :-)
Conditional code can be a real mess. When I read code, I don't want to
read it for every covered platform. When you want to add a platform you
have to change every module containig conditionals.

An example. See the source code of the FreePascal compiler
(www.freepascal.org). You cannot see the real algorithm from all these
conditionals.

Anes Sadikovic

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 02 Mar 2003 11:21:54 GMT  
 
 [ 38 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Oberon language without Oberon System

2. Language Standard - Coding Standard

3. Implemented Security Standards in Oberon

4. Standard Timer Mod in Oberon ?

5. Standard Oberon Modules

6. Why not Oberon/F as a standard?

7. Oberon ISO-Standard?

8. Oberon Language Extensions and portability

9. Top 10 Language Constructs (Oberon)

10. Unofficial list of Oberon language and library proposals

11. Unofficial list of Oberon language and library extension proposals

12. Unofficial list of Oberon language and library wishes extensions

 

 
Powered by phpBB® Forum Software