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]
Home Site_index Contact Legal Buy_products OpenVMS_compiler Alpha_Oberon_System DOS_compiler ModulaTor Bibliography Oberon[-2]_links Modula-2_links