Celestin Apprentice 2/Apprentice-Release2.iso/Information/Languages/Oberon/Oberon-FAQ⁄language

Text File | 1994-12-03 | 11.6 KB | 304 lines | [TEXT/R*ch]

Newsgroups: comp.lang.oberon,comp.answers,news.answers
Path: bloom-beacon.mit.edu!grapevine.lcs.mit.edu!olivea!charnel.ecst.csuchico.edu!psgrain!m2xenix!mikeg
From: [e-mail] (Mike Gallo)
Subject: Comp.lang.oberon FAQ (monthly) 2/3
Expires: Tue, 11 Oct 1994 00:00:00 GMT
Reply-To: [e-mail]
Organization: PSGnet, Portland Oregon US
Date: Mon, 12 Sep 1994 05:33:50 GMT
Approved: [e-mail]
Message-ID: <[e-mail]>
Followup-To: comp.lang.oberon
Summary: This posting contains a list of Frequently Asked Questions (and their answers) about Oberon.  It should be read before posting to the Comp.lang.oberon newsgroup.
Lines: 288
Xref: bloom-beacon.mit.edu comp.lang.oberon:2871 comp.answers:7202 news.answers:25502

Archive-name: Oberon-FAQ/language

(*  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  *)

Many FAQ lists, including this one, are available by anonymous ftp from
rtfm.mit.edu in the /pub/usenet/news.answers directory.

Although I have aimed for accuracy, there is no guarantee that the
information in this document is error-free.  Neither the FAQ maintainer nor
anyone else associated with this document assume any liability for the
content or use of this document.  If you find any errors, please report them
to the address below.

Thanks to all who have contributed!  Further additions, corrections, and
suggestions are welcome.

[e-mail]

(*  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  * *  *)

Comp.lang.oberon Frequently Asked Questions: The Programming Language

Copyright 1994 Michael Gallo
(c) 1994 Michael Gallo


This is one of three documents that attempt to answer some frequently asked
questions (FAQs) about Oberon.  This text concerns the Oberon languages,
while the other two are about general topics and about Oberon the operating
system.


THE PROGRAMMING LANGUAGE OBERON

>From "From Modula to Oberon"
    The programming language Oberon is the result of aconcentrated effort to
increase the power of Modula-2 andsimultaneously to reduce its complexity.
Several features were eliminated, and a few were added in order to increase
the expressive power and flexibility of the language. This paper describes
and motivates the changes. The language is defined in a concise report.
    Whereas modern languages, such as Modula, support the notion of
extensibility in the procedural realm, the notion is less well established in
the domain of data types. In particular, Modula does not allow the definition
of new data types as extensions of other, programmer-defined types in an
adequate manner. An additional feature was called for, thereby giving rise to
an extension of Modula.
    The evolution of a new language that is smaller, yet more powerful than its
ancestor is contrary to common practices and trends, but has inestimable
advantages. Apart from simpler compilers, it results in a concise defining
document, an indispensable prerequisite for any tool that must serve in the
construction of sophisticated and reliable systems.

Among the eliminations in the move from Modula-2 to Oberon are variant
records, opaque types, enumeration types, subrange types, the basic type
CARDINAL, local modules, and Modula's WITH statement.  The major addition to
Oberon is the concept of type extension (i.e., single inheritance) for
records.


OBJECT ORIENTED PROGRAMMING IN OBERON

Oberon does not offer multiple inheritance.  However, it has been shown that
multiple inheritance can be efficiently implemented in terms of single
inheritance and been argued that MI is therefore syntactic sugar that is
rarely used in practice.  For details, see Templ (1993) and Mssenbck
(1993).

The original Oberon language does not offer built in "methods" as do many
other languages supporting OOP.  Instead, conventional virtual methods can
easily be implemented as a pointer to a procedure table, or "messages" can be
sent to procedures as extensible records.

While some people complain about Oberon's minimalistic support of object
oriented programming, others feel that this is one of Oberon's strengths,
that the language does not institutionalize aparticular approach to OOP (see
the Comp.object FAQ list for an examination of several variations on the
object oriented paradigm).  For another discussion, see Oberon2.OOP by H.
Mssenbck.


THE PROGRAMMING LANGUAGE OBERON-2

>From "Differences between Oberon and Oberon-2"
    Oberon-2 is a true extension of Oberon. . . .
    One important goal for Oberon-2 was to make object oriented programming
easier without sacrificing the conceptual simplicity of Oberon. After three
years of using Oberon and its experimental offspring Object Oberon we merged
our experiences into a single refined version of Oberon.
    The new features of Oberon-2 are type-bound procedures [i.e., virtual
methods], read-only export of variables and record fields, open arrays as
pointer base types, and a with statement with variants. The for statement is
reintroduced after having been eliminated in the step from Modula-2 to
Oberon.


THE "OBERON FAMILY" OF LANGUAGES

Mona is an experimental dialect (but not a superset) of Oberon which provides
recursive data types (trees) as a first class data-structure.  It attempts to
reduce reliance on pointers and to offer a faster alternative to automatic
garbage collection.  For details, see ETH technical report 102.

Oberon-V is an experimental dialect (but not a superset) of Oberon.  It is
concerned with issues of numerical computing, array processing, and code
verification.  It's primary new features are the ALL statement (much like a
parallel version of the FOR loop) and array constructors for open array
parameters.  Since it was originally aimed at vector architectures in general
and the Cray Y-MP in particular, no Oberon-V compiler has been implemented
for the Oberon System.  For details, see Griesemer (1993).


COMMON PROBLEMS PROGRAMMING IN OBERON

On numerical programming:

[e-mail] (Whitney de Vries) writes:
    The gist of the situation is that numeric expressions [can be] too complex
for the backend of the Oberon for Windows compiler. . . .  Complex
expressions ( particularly those with floating point operations ) quickly
exhausts the short supply of registers on the Intel chips. At this point it
is worth noting that the ETH supports Oberon for Windows but does not
consider the Intel chips to be an intresting research topic ( the answer to
the Intel problem is to have more registers ).  I think it is unlikely that
Intel compiler will ever be as robust as the POWERoberon compiler.
    At any rate you will probably get your code to work if you simplify the
expressions.
(* Before *)
    VAR node : Node;
    BEGIN
        node.elem[x*5,y*2] := 1.0;
(* After *)
    VAR node : Node; elem : Element; x0, y0 : INTEGER;
    BEGIN
        elem := node.elem;
        x0 := x*5;
        y0 := y*2;
        elem[x0,y0] := 1.0;

The WITH statement:
    "This [compiler error] has to be a bug, correct me if I'm wrong! (I'm going
nuts over this)"

TYPE
    Obj* = POINTER TO Empty;
    Empty = RECORD (*nothing*) END;

    OpObj = POINTER TO OpNode;
    OpNode = RECORD (Empty)
        name : CHAR;
        left, right : Obj;
    END;

PROCEDURE doeval (ex: Obj): REAL;
    BEGIN
        WITH ex : OpObj DO
            CASE ex.name OF
                "+" : RETURN doeval(ex.left (* err 113 *))
                    + doeval(ex.right (* err 113 *));
                "-" : (* clever code here *)
                "*" : (* more clever code *)
                "/" : (* you get the idea *)
            END;
            (* et cetera *)
        END;
    END doeval;

Error #133 is an "incompatible assignment".  ex.left and ex.right certainly
seem to be of type Obj.  Why won't doeval accept them?

As [e-mail] (Taylor Hutt) points out,
    This is not a bug.  The WITH statement actually changes the static type of
the WITHed variable for the entire duration of the WITH statement.  A
workaround to this problem is to assign the parameter to a temporary variable
and to use the WITH on the temp.  A type guard will not work properly in this
case, do not attempt to use it.

Some people on Comp.lang.oberon think that the WITH statement should be
avoided entirely because of its non-local effects.  They point out that a
programmer can use individual type guards or, if a guarded variable is used
very many times, can pass the variable to a procedure.


BIBLIOGRAPHY

Sources cited in the FAQ list that are not listed in thebibliography are
electronically available in PostScript and/or Oberon text formats from ETH
Zrich.  They can be acquired by anonymous ftp from
ftp.ethz.ch:/pub/Oberon/Docu.

"Type Extensions" by N. Wirth; ACM Transactions on Programming Languages and
Systems; 10, 2 (April 1988) 204-214.

"From Modula to Oberon" by N. Wirth; Software: Practice and Experience; 18,7
(July 1988) 661-670.

"The Programming Language Oberon" by N. Wirth; Software: Practice and
Experience; 18,7 (July 1988) 671-690.

"Variations on the Role of Module Interfaces" by J. Gutknecht; Structured
Programming; 10,1 (January 1989) 40-46.

"Object Oberon -- A Modest Object-Oriented Language" by H. Mssenbck and J.
Templ; Structured Programming; 10,4 (April 1989) 199-207.

A New Approach to Formal Language Definition and Its Application to Oberon by
M. Odersky; Verlag der Fachvereine Zrich; 1989.

"The Programming Language Oberon-2" by H. Mssenbck and N. Wirth; Structured
Programming; 12,4 (April 1991).

Programming in Oberon: Steps Beyond Pascal and Modula-2 by M. Reiser and N.
Wirth; ACM Press; 1992.

"A Systematic Approach to Multiple Inheritance Implementation" by J. Templ;
ACM SIGPLAN Notices; Volume 28, Number 4 (April 1993).

Object Oriented Programming in Oberon-2 by H. Mssenbck; Springer Verlag;
1993.

"A Programming Language for Vector Computers" by R. Griesemer; Swiss Federal
Institute of Technology (ETH Zrich); Dissertation Number 10277, 1993.


OBERON COMPILERS

Please note that mention of a product or company does not necessarily imply a
recommendation.  For Oberon compilers developed outside ETH Zrich contact:

VAX/VMS:
    ModulaWare GmbH, Wilhelmstr. 17A, D-91054 Erlangen/F.R.Germany
        Modula-2 & Oberon-2 Compiler Manufactur
        Tel. [phone], Fax [phone].
        E-mail/Internet:
        [e-mail]
        [e-mail]

MS-DOS and Windows:
    ModulaWare GmbH, Wilhelmstr. 17A, D-91054 Erlangen/F.R.Germany
        OM2 32 Bit Oberon-2 and Modula-2 Compiler for PC/DOS'386/'486
        native code for DOS with DPMI Driver/Host and for DOS sessions under
Windows 3.1 and OS/2 2.1
    COP2 (Oberon to C translator)
        contact Taylor Hutt, e-mail: [e-mail]
    Oberon-M
        contact E. Videki, e-mail: [e-mail]
    Extacy
        Real Time Associates Ltd.
        Canning House, 59 Canning Road
        Croydon, Surrey, CRO 6QF
        England
        Tel.: [phone]
        Fax: [phone]
        E-mail: [e-mail]
        [e-mail]
    Pow! (Programmers Oberon Workbench)
        It works with MS-Windows and can be used to create native Windows
applications (EXE's and DLL's).
        Ftp: ftp.fim.uni-linz.ac.at:/pub/soft/pow-oberon2, or
            galileo.meakins.mcgill.ca:/Oberon/CommercialDemos/POW
        E-mail: [e-mail]
        Mailing list: [e-mail] "subscribepow-list"

Amiga:
    A+L AG
        Daederiz 61
        CH-2540 Grenchen
        Tel.: [phone]
    Oberon-A
        A freely-distributable, stand-alone Oberon-2 compiler for the Commodore
Amiga.
        It can be obtained from AmiNetsites, including ftp.cdrom.com and
ftp.wustl.edu.
        E-mail: [e-mail]

DECstation (Ultrix, OSF/1), Intel386 (SVR4, OS2, Solaris), Sparc(Solaris):
    Office of Commercial Services
    Queensland University of Technology
    GPO box 2434, Brisbane Q4001
    Australia

Atari:
    Martin Momberg
    Hahlgartenstr. 13a
    D-64331 Weiterstadt
    Germany
    E-Mail: Inet:[e-mail]
    Ftp: ftp.th-darmstadt.de:/pub/machines/atari/programming/stoberon