Objective Modula-2 (or ObjM2) is an extension to Modula-2 which follows the Objective-C object model and retains the bracketed Smalltalk message passing syntax introduced in Objective-C. Like Objective-C, Objective Modula-2 is a reflective, object oriented programming language with both static and dynamic typing. It is intended as a safer alternative to Objective-C for Cocoa and GNUstep software development.
I think that Modula-2 is a very good and modern imperative language that yields most of the Ada features without most of its complexity. Unfortunately it’s a descendant of Pascal and now the wave is C (follow the wave…)
This is old news on tacojuice (august 20) and it’s not fully developed or even specified yet. So don’t hold your breath just now. The Idea of the developer(s) appears to be to give all the old Mac Pascal programmers a language they can be happy with.
While that may be true I would suggest that Oberon/Oberon-2 are languages that are much closer to this goal. All that’s need is an extension of the basic module set to handle Cocoa objects. There is a good cross compiler available at http://ooc.sourceforge.net/ . Oberon and it’s successor are both simplifications of Modula-2 designed by Wirth with object oriented facilities, and is much cleaner than even Modula-2.
Oberon is uninteresting for several reasons. 1) the guys doing the work on Objective Modula 2 are the people working on Gnu Modula 2. 2) Oberon is object oriented already, the objective extension to Modula 2 is supposed to make Modula 2 object oriented. 3) the object orient extension to Modula is supposed to make it integrate with objective-c based environments (cocoa and gnustep) easy, hence the syntax is similar and the object model is the same.
More on the discussion here:
http://lists.apple.com/archives/Objc-language/2005/Aug/threads.html
There are two reasons why we chose Modula-2 and not Oberon.
First, the members of the core team are all Modula-2 veterans. Some have been part of the ISO Modula-2 working group and the leader of the GNU Modula-2 compiler project is also participating.
Secondly, it is wrong to assume that it is easier to add Cocoa support to a language simply because it was designed as an object oriented language. As a matter of fact, in most cases it is quite the opposite.
It is far easier to add Objective-C style language extensions to a non-OO language in order to support the Objective-C object model directly than it is to write and maintain a bridge to translate from one object model to another. Building bridges is a very troublesome business.
Check out the source code of some of the Cocoa bridges which are open sourced, eg. PyObjC. You will find there are plenty of “special cases” that need workarounds and “problem cases” the bridges cannot handle at all. Consequently, not all of Cocoa is covered by a bridge. Not even Apple’s Java Bridge covers all of Cocoa.
You also have to take into account that Cocoa objects are dynamic, they can be dynamically typed and they are linked at runtime, not at compile time. None of the object models found in the Pascal family are dynamic. This makes it even more difficult to build a bridge.
What we wanted was to AVOID the need for a bridge altogether. We also acknowledge the merits of the Smalltalk derived message-passing syntax of Objective-C. Its expressiveness adds to clarity and maintainability of the code.
This meant that a language without any OO features would be preferable because we were going to add the Objective-C object model inclusive of its message-passing syntax to it.
Of course you could let the existing OO features coexist with the added Objective-C OO model, which is basically how Apple’s Objective-C++ works, but this is not what we wanted to do.
BTW, ISO Modula-2 is an OO language and it has exception handling, termination, generics etc etc. In other words, ISO Modula-2 is to Modula-2 what C++ is to C.
Yet, we found that all those extras in ISO M2 are actually getting in the way. We don’t want Cocoa support to be duct taped to whatever looks like it fits the duct tape. What we want is full Cocoa support embracing the Cocoa philosophy in its entirety.
Our specification is therefore predominantly targeted at Base Modula-2, which is to say M2 as defined by Wirth in PIM or ISO Modula-2 as defined by the base standard.
However, we are careful not to add syntax that would later make it impossible to use the ObjM2 extensions with the extended ISO Modula-2 standard. As GNU Modula-2 will gradually evolve to eventually support all three parts of the ISO M2 standard, there could well be a mode in which the compiler operates as an ObjM2++ compiler so to speak. However, this would be similar to Apple’s Objective-C++ where there is no interchange between C++ objects and Objective-C objects. Likewise, without a bridge, there would be no interchange between ObjM2 (=ObjC) objects and ISO M2 OO objects.
Last but not least, Oberon is a poor choice in respect of the available target groups. First, we are not aware of any Oberon compiler that integrates with the GNU compiler collection (and thereby with Xcode), which is a significant disadvantage for acceptance by Cocoa developers. Second, for Pascal, Delphi, Modula-2, Modula-3 or Ada developers it is generally acceptable to use any of those languages, but Oberon is often not as it removed to many features they have come to appreciate. Likewise, for most Objective-C developers, Oberon would be difficult to swallow.
The feedback we are getting so far would seem to suggest that we made the right choice and that we are doing the right things in respect of those target groups, which includes Objective-C developers, some of whom have joined our project.
with regards from
the ObjM2 project
Whoever is interested in this, check this out for similar ideas from 8 years ago (but already based on the M2-successor): http://dmoz.org/Computers/Programming/Languages/Lagoona/
This shows how little is needed to add to language, to give it a lot of power.
Smalltalk doesn’t have “bracketed message passing syntax.” The brackets in Smalltalk are used for constructing blocks, which are similar to closures. Objective-C doesn’t really share much with Smalltalk in terms of syntax.
How to send a parameterless message:
someObject msg.
How to send a message with one parameter:
someObject msg: argument.
How to send a message with multiple parameters:
someObject msg: argument msg2: argument2.
How to send two parameterless messages to the same object (“cascading”):
someObject msg; msg2.
Send msg to someObject and then send msg2 to the resulting object:
someObject msg msg2.
Compare whether x is larger than y, and if it is then send msg to someObject:
(x > y) ifTrue: [ someObject msg ].
Notice that [ someObject msg ] is an object (a block) passed as a parameter in the message ifTrue sent to the boolean returned by the binary message >.
1 to: 10 do: [ :n | someObject msg: n ].
Count from 1 to 10, sending each number as a parameter to msg being sent to someObject. Notice how the block has been created to expect a parameter when it’s invoked.
If you’re familiar with Objective-C, you’ll notice how different this is from how you program with Objective-C. Smalltalk is a fairly elegant, simple language.
My point is mostly that Objective-C just has named (labeled, keyword, …) parameters, and not really Smalltalk-style messaging syntax. The selectors in both use semicolons, and from there things stray.
That should read “colons.” Edit functionality would do wonders for my brash impatience and flagrant ineptitude.
In response to japail on 2005-09-04 20:56:19 UTC saying …
‘Smalltalk doesn’t have “bracketed message passing syntax.”‘
Well, that’s precisely why the Objective-C variant is called bracketed Smalltalk message-passing syntax.
It means Smalltalk message-passing syntax, enclosed in brackets.
Which it isn’t, as I’ve pointed out through numerous examples.
I just think this is a really great idea. If it is not ready yet, then get involved. C is very limited for Cocoa-level application programming. Bringing more languages with different characteristics a mature API is great (um… groovy, .NET anyone?)
Building an API is a hard job, bringing well known and well loved (by some) langauages to the API is a very useful thing.
It has got me thinking about objective caml bindings for Cocoa…..
Congrats to whoever manages to get this up and running.