any feedback would be appreciated as I am about to change a whole
bunch of documentation and source code. thanks.
Yes. Class is a record. But it's more and less.
That's why Wirth and Gutknecht created Oberon: Modula-2 without some
'dangerous' constructs (like my favorite LOOP/END), plus inherited
records. If you are like I am, and you ONLY use qualified imports, it
becomes very clear that Modula-2 was the basis for C++. Stroustrup
just copied Modula-2 and Oberon to C, borrowed the C cyntax and stole
the C language name and instructions. As I and other told here:
http://fruttenboel.verhoeven272.nl/Langs/index.html and related
Also read this http://www.ittybittycomputers.com/IttyBitty/CppHarm.htm
for a thorough discussion of it all.
Please be so kind to read the bottom part of this:
http://fruttenboel.verhoeven272.nl/Langs/against.html.gz in which
Dennis Ritchie is not very pleased.
In short: Oberon is Modula-2 with inherited records. If you want
classes added to Modula-2, consider the FST compiler (it had classes
built-in) but Roger Carvalho is not very interested in porting the lot
to Linux. Or switch over to Oberon. There even is an LNO (Linux Native
Oberon) but it doesn't run anymore on newer kernels. It ran in kernels
upto version 2.4.x
Also consider reading this: http://fruttenboel.verhoeven272.nl/Langs/limerick.html
> In short: Oberon is Modula-2 with inherited records. If you want
> classes added to Modula-2, consider the FST compiler (it had classes
> built-in) but Roger Carvalho is not very interested in porting the lot
> to Linux. Or switch over to Oberon. There even is an LNO (Linux Native
> Oberon) but it doesn't run anymore on newer kernels. It ran in kernels
> upto version 2.4.x
Thank you for your feedback. Perhaps I should mention that the
objective of the Objective Modula-2 project is *not* to invent yet
another way to add OO to Modula-2. The objective is to add native
support for Cocoa and GNUstep, without implementing a translation
layer that converts between two otherwise incompatible object systems.
Although it is interesting to study how various compilers' OO
extensions work, and possibly getting some inspiration in the process,
picking an existing Modula-2 compiler with OO extensions does not
achieve the objective. In order to support Cocoa/GNUstep natively, the
object model will have to be that of Objective-C and the way in which
classes are declared and methods overridden or added should be
conducive to the way the Objective-C object model and runtime system
works. We also wanted Objective Modula-2 to have all the capabilities
that Objective-C has, not like a number of bridge implementations
which only provide a subset of the features possible in Objective-C.
In particular the facility that Objective-C categories provide
presented a challenge. A category is a container for method
declarations for methods which are to be added to an existing class
for which one does not have the source code. This seemed to
necessitate a specialised container (or module). And indeed, in
Objective-C a category is a special kind of module, so it seemed a
foregone conclusion to devise a special kind of module in Objective
Modula-2 as well.
However, the distinction between "initial" methods and those added
"later" in Objective-C is syntactic sugar (or salt, depending on your
view). The Objective-C runtime library does not actually make that
distinction because all classes and methods are added at runtime in
the same way.
From this angle, one does not necessarily need to map the Objective-C
syntax 1:1, at least not if functionality and expressive power are
preserved. The key to eliminating category modules was the ability to
define a method outside of its class definition, which is what Wirth's
type bound procedure syntax does.
However, this may just have been a lucky coincidence. If the facility
had not been conducive to the way the Objective-C object model works,
then it would not have been suitable for the purpose of implementing
native Cocoa/GNUstep support.
Funny. Some people say: "ISO killed Modula-2". Could be, but it's not
Good luck. May the force be with you.
As far as I understood ObjM2 is the actual project of one man while ISO
Modula-2 was the outcome of a group (scientists,programmers).
> Funny. Some people say: "ISO killed Modula-2". Could be, but it's not
> for me.
When ISO Modula-2 was published the sometimes possible success of
Modula-2 was history. In my opinion the ISO library is a clean and very
well structured thing which always can teach a lesson. Beside of that
the existing compilers always let us choose if we want to use
ISO-features - in reality there isn't much difference if you don't know
or don't want to use ISO.
A couple of books I can recommend that discuss these sorts of topics at
1. H. M�ssenb�ck "Object-Oriented Programming in Oberon-2"
Details of the book and a number of other Object-Oriented related papers are
on M�ssenb�ck's webpage at:
As the book is an expanded version of the paper with the same name you can
get a good idea of what the book is like by downloading the paper from:
Hanspeter M�ssenb�ck was jointly (if not primarily) responsible for the
additional O-O facilities (i.e. type-bound procedures and regional
type-guards) added to Oberon when it became Oberon-2.
2. Clemens Szyperski with Dominik Gruntz and Stephan Murer "Component
Software - Beyond Object-Oriented Programming"
Whereas I found the first book to be very readable this one was much harder
going and I wouldn't recommend it to the faint hearted. However, it is
relevant as Clemens Szyperski was involved in the development of Component
Pascal which is basically Oberon-2 with additional, more advanced, O-O
capabilities e.g. EXTENSIBLE, ABSTRACT and LIMITED record types and methods:
What is not covered in Szyperski's book is probably not worth worrying
Armaide v2.0: ARM Oberon-07 Development System
> I read that the makers of Objective Modula-2 are the same that made an
> ISO Modula-2.
I don't know where you read this and I am not sure I understand what
you mean by "made *an* ISO Modula-2", but I assure you that nobody who
has participated in the Objective Modula-2 effort so far has "made an
ISO Modula-2" compiler.
Two of the participants in the language design brainstorming/
discussion group were former participants in the ISO Modula-2
committee. But, you would be mistaken if you concluded that this means
the design was done without concern for simplicity.
In fact, if you look at
you will see that we have removed a number of the things which Wirth
omitted in Oberon. This doesn't mean that the language extensions for
Cocoa and GNUstep support could not be added to an ISO Modula-2
compiler, it only means that our reference compiler just so happens to
be based on a subset of PIM.
The rationale for this is that when you program in Cocoa or GNUstep,
you will use Cocoa/GNUstep classes for just about anything that isn't
control flow. In other words, you use the base language almost only
for control flow and the Cocoa/GNUstep language extensions and classes
for building models. Consequently, you don't need to have a large base
For any new development, this would be the recommended way. But, for
existing Modula-2 code to be augmented with a Cocoa or GNUstep based
GUI, there will need to be a solution that allows legacy code to be
compiled, too. This means that at some point in the future full PIM
(or even ISO) dialect support may have to be added as an option. There
is also some interest to add support for the Cocoa/GNUstep language
extensions to the GNU Modula-2 compiler at some point in the future.
> Funny. Some people say: "ISO killed Modula-2".
There is probably some truth to that, but if so, then it is most
likely to be found in the fact that the standardisation took more time
than it might have, causing both users and compiler implementors to
wait and that may have contributed to a decline in use.
Following this line of thought, one might argue that had the ISO
committee stuck solely to clarification of ambiguities and defining a
standard library, it might have been able to ratify a standard much
earlier, compiler vendors might all have supported that standard
fairly soon and perhaps the decline in use and popularity might then
not have happened.
> Could be, but it's not for me.
The problem with a larger language is predominantly a problem for a
compiler implementor, less so for the compiler user. As a user you can
always avoid the additional features in your code, but as a compiler
implementor you have extra work to do whether anybody actually wants
them or not.
> Good luck. May the force be with you.
:-) thank you
> As far as I understood ObjM2 is the actual project of one man while ISO
> Modula-2 was the outcome of a group (scientists,programmers).
The project started off as a discussion and brainstorming group in
which about seven or eight people participated. Two of those
participants had also participated in the ISO committee. Two or three
of the participants were Objective-C developers who had not previously
had any exposure to Modula-2. Also, Brad Cox, the creator of Objective-
C kindly participated providing helpful background information about
why certain things in Objective-C turned out the way they are and why
other approaches hadn't worked out that well, thus often saving us the
trouble to find out the hard way.
More recently the focus has moved to formally defining a subset of PIM
for use as a base language. That effort is undertaken by a team of
two, a Modula-2 scholar/author and myself.
As for the compiler, I was and still am the only developer. However,
there are one or two other developers who have expressed interest to
join and a repository will soon be set up to facilitate that. Other
than that, there's somebody who sporadically helps out with the
Thank you for clarifying -
For the non initiated, annotated the methods with what kind it is. (virtual
etc, when it is overrriden). How is self typed for overriden virtual methods
Another thing is that the matrix PDF rambles on about "class modules", while
the text doesn't seem to define them. Are FooBar class modules? Can modules
have multiple classes? Questions that aren't answered. H
I also miss examples how to handle forward class defines (Defining a
collection that knows its items and the other way around is the classic
The advantages of pulling the methods out of the container are not really
clear to me either. There is first a clutter argument, and then a "you can
add methods everywhere" argument. The first is subjective, the second, while
possibly a major feat is not explained.
How does it work? How does the compiler know which modules the include so
that all methods are found (IOW is this real, or some "class helper" hack?)
Finally we come to the "protocol". Apparantly the source fragment "Barbaz"
should fully explain it, but I honestly have no clue. I don't even know
where it comes from, is it something from later Wirthian languages, or a
COCOA concept, or both (Obj-C/COCOA concept matched to similar Wirthian
concept) ? Is it an interface or other kind of class contract?
There might be more detail points to clear up, but since the text doesn't
really make me understand it, I can't come up with them before it is
In short: the text assumes to much knowledge to make a point.
> For the non initiated, annotated the methods with what kind it is. (virtual
> etc, when it is overrriden).
The Objective-C runtime (which Objective Modula-2 plugs into) treats
all methods the same because all methods are added to a class at
runtime. There is no distinction between adding and overriding. There
is however a distinction between class and instance methods. In a
nutshell, class methods return instances of a class, they are used as
factory or initilisation methods.
> How is self typed for overriden virtual methods
self is always of the type indicated in the method declaration, that
CLASS METHOD ( self : Foo ) init : Foo;
self is of type Foo.
> Another thing is that the matrix PDF rambles on about "class modules", while
> the text doesn't seem to define them. Are FooBar class modules? Can modules
> have multiple classes? Questions that aren't answered.
The matrix represents the class-is-a-module approach which the class-
is-a-record approach discussed in the article is intended to replace.
Consequently, there are no more class nor category modules in the
class-is-a-record based syntax. That's the whole rationale of it
> I also miss examples how to handle forward class defines (Defining a
> collection that knows its items and the other way around is the classic
Yes, this isn't shown in the article, but will be in the revised
grammar and language overview document. As in Objective-C, a forward
declaration of a class will be an incomplete type declaration such as:
TYPE Foobar = CLASS;
> The advantages of pulling the methods out of the container are not really
> clear to me either. There is first a clutter argument, and then a "you can
> add methods everywhere" argument. The first is subjective, the second, while
> possibly a major feat is not explained.
No, clutter was a problem of the earlier attempt to use class-is-a-
record with methods inside the record declaration. Another problem of
the class-is-a-record with methods inside the record declaration is
that it doesn't work for categories because you would have to declare
the class multiple times.
The class-is-a-module approach solved both the clutter and the
category problem. However, it broke orthogonality. It requires eight
different modules each of which have different rules for what is
allowed in them and what isn't. Further, the same kind of directives
in different kinds of module have different semantics, var
declarations for instance. This is a potential source of programmer
confusion and thus prone to programming errors. It also makes syntax
and semantic analysis more complex than it ought to be.
The benefit of the class-is-a-record with type bound methods outside
the class record declaration is that orthogonality is reinstated while
clutter is avoided and the functionality that categories provide is
When I say methods declarations to add methods to a class can be
anywhere, that is to say, there is no special syntax required for a
special container. You can use an ordinary library as a container for
your add-on methods. An example of this is shown in the article. The
important thing is that no special category record or category module
> How does it work? How does the compiler know which modules the include so
> that all methods are found (IOW is this real, or some "class helper" hack?)
Through import lists as usual.
> Finally we come to the "protocol". Apparantly the source fragment "Barbaz"
> should fully explain it, but I honestly have no clue. I don't even know
> where it comes from, is it something from later Wirthian languages, or a
> COCOA concept, or both (Obj-C/COCOA concept matched to similar Wirthian
> concept) ? Is it an interface or other kind of class contract?
A protocol is an instrument to implement multiple inheritance of
specification (not implementation). Both the instrument and the
terminology comes from Smalltalk from where Objective-C inherited it.
If you are familiar with Java, the same facility is called interface
there. If you are not, basically this is a collection of method
declarations that a class must implement if it adopts the protocol.
> There might be more detail points to clear up, but since the text doesn't
> really make me understand it, I can't come up with them before it is
> improved :-)
The article does assume that you have read the language overview
document so you know the current syntax to compare the new syntax to.
I will update the article to recommend reading that first. Sorry for
Nevertheless, thanks for the feedback.
... and the paper titled 'Modula-2 and Object-Oriented Programming'
presented by Niklaus Wirth at the First International Modula-2 Conference at
Bled in 1989. You can download a copy of the paper from the ETH Technical