The ModulaTor

Erlangen's First Independent Modula_2 Journal! Nr. 10, Nov-1993 
_______________________________________________________________


Remarks about Languages and their Compilers                                                        

This is an extract from the OM2 User's Guide (Chap. III) 

written by Guenter Dotzel, ModulaWare GmbH, Erlangen. 

OM2 is a 32 Bit Oberon-2 and Modula-2 Compiler and programming system for 
PC/DOS. 

Some general remarks about non-standard language features 

This article is not meant to offend any person or organisation. The following should be 
considered as a warning not to use non-standard language extensions, however 
attractive they are. 

OM2 has some non-standard language extensions. Non-standard means, that new 
features are provided which are 

- neither contained in N. Wirth's "Programming in Modula-2", 3rd. ed, 

- nor contained in H.P. M~ossenb~ock's Oberon-2 language report, 

- nor contained in ISO 10154 Modula-2 (2nd CD, Dec-1992). 

Non-standard also includes 

- syntactical differences, 

- differences in static or dynamic semantics, 

- conditional compilation and pragmas, even when specified in comments or so called 
compiler directives. 

The most important non-standard language extension of OM2 is the ability to combine 
Oberon-2 and Modula-2 in one project and to use features available only in Modula-2 
(e.g. such as enumerations and subranges) in Oberon-2 modules and vice versa. This is 
accomplished through a common symbol file format for separately compiled modules. 

Not all extensions are disabled by default. Especially, if you compile separate modules 
with different compilation options, there is a good chance to inherit and use non-standard 
extensions without noticing, simply by importing non-standard features. This is the case 
for example if you've compiled a module with the "noext" option, but importing StdIO 
which (1) is not a ISO M2 Std Lib module and (2) it contains a SEQ parameter which 
allows to pass an arbitrary number of parameters. This is also the case for example if 
you declare and export a pointer to an open array type in Oberon-2 and by importing and 
using this type in Modula-2. 

Warning: Do not rely on non-standard language features. They are not guaranteed to be 
available in future releases of OM2. Their semantics might eventually change with a 
future release and also source code using compiler implementation specific extension is 
not portable. 

Even if portability is not your primary goal, keep in mind that things in computing industry 
are changing faster and faster. You might sooner or later end-up developing on another 
platform with a different compiler, processor or operating system. And you usually don't 
want to throw away your source code when switching platforms. 

With programming languages, there are four different groups, each with different tasks 
and responsibilities: 

Language designers, standardisation organisations, compiler developers, and compiler 
users. 

Compiler developers have the greatest responsibility and power. They have to do a 
non-creative job in that they have to implement what was described by the designer. 
Mostly the language report is to vague and this gives the compiler developers some 
creativity, because they have the freedom of their own interpretation. 

If a standardisation team creates an exact specification of the language (as it was done 
by the ISO SC22.WG13, Modula-2) then there is not much left for the compiler writer's 
interpretation and it is simply boring to implement something what was prescribed by a 
third party. Even when a full-blown standard was internationally agreed (as with ISO 
Modula-2) there is always a desire for extensions, be it platform specific or to add foreign 
language support. It's no surprise that compiler writers will try to give their compiler 
product a personal touch by trying to make their own language extensions. They believe, 
that this makes a product unique and that it would be a nice marketing plus. 

For the compiler users, it is quite seductive to follow the implementor and to use all 
features offered by a product. But this is the trap door, which the compiler developers 
has provided to catch the users. The trap door is closed but not locked. The key is public 
and it might be called either compilation option, switch, pragma or directive. 

When looking at the successors of Pascal, with the step from Modula-2 to Oberon-2, you 
should have realised that it is not so important what features were added during this 
evolutionary process; it is much more important what features were thrown out of a 
language. If compiler developers put in extensions, they do not create but destroy 
innovation, regardles whether the compiler writers or users consider certain extensions 
as useful or not. In any case, on long term, non-standard features will turn out to create 
more problems than they tried to solve. 

In this chapter I've tried to explain, why there happen to be extensions in a compiler 
implementation of a programming language and that users of a compiler are reponsible 
not to use any of the compiler specific extensions. Keep this in mind when reading 
chapter IV, which describes some of OM2's extensions. 

This chapter could also be considered as a critique of OM2. Working in the OM2 
Association International since the fall 1992, I've constantly criticised the compiler writers 
for their incompatibilities and non-standard extensions, especially in the Modula-2 
language. I've tried to convince them to strongly adhere to ISO Modula-2 only, when 
doing extensions. I'm not sure that they got the message. 

What about Oberon-2? Unlike Modula-2, there is no official standardisation effort. Will 
there be a non-ambiguous language specification? Will there be extensions or dialects? 

Since June, 1993, there is a cooperative Oberon-2 standardisation effort which was 
initiated by a British/Russian group. The draft for comment, called Oakwood Guidelines 
was distributed to a small number of Oberon-2 compiler developers in Nov, 1993. The 
part of the document that deals with so-called optional language extensions was heavily 
influenced by the Russian OM2 developers. Needless to say, that I'm not in favour of the 
most language extensions that were proposed in the guidelines. The editor[s] of the 
guidelines blocked-out most proposals submitted by others, but included their own, 
considered useful extensions. I'd call that information hiding policy and I don't expect an 
agreement on these extensions real-soon-now. 

The library part of the guidelines is mainly due to proposals of H.P. M~ossenb~ock. The 
proposed set of library modules are similar to those of ETH Oberon System but not 
identical. 
________________________________________________________________________


The ModulaTor Forum 

New books: If you want to learn more about what's currently going on in Russia, then 
read the new book entitled Russland in Aufruhr. Innenansichten aus einem rechtlosen 
Reich, Piper Verlag, 1993, written in German by Christian Schmidt-H~auer,
living in Moscow and working for the German weekly newspaper Die Zeit. The book is really 
up-to-date (Jun-1993). 

prawowoj bespredel ;-) 

 

The Oberon-Day '93 

A personal summary by Josef Templ, ETH-Zuerich. 

This is a short summary of my personal impressions about the Oberon-Tag '93, which 
took place on Nov. 12th at ETH Zurich. The convention has been organized by the 
"Fachgruppe Oberon" in cooperation with the Institute For Computer Systems, ETH 
Zurich. The topic of the convention was "Oberon for End-Users" with special emphasis 
on Oberon System-3. 

The interest from industry, universities and interested individuals was enormous. There 
were about 300 participants and there was a very friendly mood in the auditorium and 
during the breaks. Talks have been given by the authors of the Oberon system, Prof. N. 
Wirth and Prof. J. Gutknecht, three assistents gave demonstrations of innovative 
end-user applications implemented in Oberon. Finally, there were two talks given by 
ETH-external speakers, one from the University of Linz (Austria) and one from Oberon 
microsystems, a company located in Basel. 

Prof. N. Wirth explained in his 20 minutes opening talk the various research directions 
related to the Oberon system (Concurrent Oberon, System-3 , V4). He pointed out that 
the "stable" official version is supposed to be V4. This is the version which is described in 
the books, although in the meantime, there have been some minor changes. When 
asked about a possible unification of the different branches, he answered that he had not thought about
it yet and that he is not sure that one wishes to unify them. 
The drawback, Wirth said, is the size of the resulting system and inconsistencies with the 
Oberon books.

Prof. J. Gutknecht explained in his 90 minutes keynote speach the main concepts of 
Oberon System-3 and pointed out that he does not consider the numbering of the 
systems as a challenge but he is interested in the thing itself. He also pointed out that the 
core of System-3 is not much larger than the core of V4. In his talk, which was at a rather 
high technical level, he explained the novel message distribution style implemented in 
System-3. Messages are never sent directly to an object but always to the display space. 
From there, the messages are then broadcasted to smaller display units (frames) and 
possibly manipulated on the way down to the receiver. One of the interesting effects of 
this technique is the possibilility to make the context of an object (e.g. the enclosing 
panel) accessible for the object's message handler. Thus, an object may react differently 
depending on its environment. This message distribution style also fits well with the 
generalisation of the tree structured display hierarchy of V4 to a DAG in System-3. He 
also pointed out that this OO-style would not have been possible with type-bound 
procedures (C++ virtual functions) but requires messages to be first class (message 
variables). There were many other technical points and finally there was a demonstration 
of a smart card simulation implemented in System-3. The interesting point about this was 
that a company had tried to develop this simulation using Borland C++ and resigned 
after 8 month. In Oberon System-3 the development was finished after 2 person-weeks 
including a couple of days to understand the specification. 

The afternoon session was started with three demonstrations, one for the Gadgets 
UIMS, which allows to compose user interfaces without the need of programming. 
Another demonstration was about the document editor Leda, which follows a wysiwyg 
approach but is augmented with knowledge about typographical rules. The third 
demonstration showed steps towards an electronic textbook which includes active 
formulae (formulae which can not only be edited within a text but also evaluated by 
connecting a computer algebra system, e.g. Maple), teletext access and a geographical 
information system. Especially attractive was the combination of the latter two facilities, 
namely the display of the actual weather as received via teletext into a map of 
switzerland. 

The second part of the afternoon session was devoted to external developments. One 
presentation was about a native Oberon development system for stand-alone 16-bit 
Windows applications. The development system (named POW!) has been codeveloped 
by Robinson Associates (London) and the University of Linz (Austria). It features 
Windows look-and-feel, a multi window editor, project management facilities, a speed 
bar and much more. The major drawback of the system is the absence of a garbage 
collector. The last talk of the day was held by a representative of Oberon microsystems 
Inc., a small ETH spin-off company devoted to the development of professional Oberon 
systems. The speaker mentioned (as a side remark) that they are going to produce a 
development system which features platform specific look-and-feel and at the same time 
full program portability. The initial target system is the Macintosh, versions for Windows 
and Motif are planned as well. 

As a member of the organization committee, I have been pleased very much with this 
first Oberon convention and look forward to Oberon-Tag '94. 

IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be taken as working papers and personal rather than organizational statements. Items are printed at the discretion of the Editor based upon his judgement on the interest and relevancy to the readership. Letters, announcements, and other items of professional interest are selected on the same basis. Office of publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached by tel/fax: [removed due to abuse] or by mailto:[email deleted due to spam]