MOPS 2.0 is "Savy"

By Jörg Langowski, MacTutor Editorial Board

“Object Forth news - MOPS 2.0”

We’ll interrupt our C++ course for one or two columns; I’d like to show you some other interesting things that I recently received in my mail. This month we’ll look again at one of the object-oriented Forth systems that I’ve been covering off and on. Michael Hore, from the Northern Territories of .oz land, far away from electronic mail and other goodies of modern civilization, has done a major upgrade of his MOPS system, version 2.0. I pre-announced it a couple of columns ago; now I received the disk in the mail, was impressed, and would like to share my impressions with you.

First of all: I can put the example program and the source text on the source code disk; but the complete Mops system fits just barely on an 800K floppy (in compacted form), and takes 1.6 MBytes on my hard disk when de-compacted. Therefore, I’m sorry, but you’ll have to get Mops through the network if you are interested to develop programs with it. Which I hope you are after reading about it. For the moment, I don’t know whether Mops is available through one of the Macintosh software depositories. I’ll try to put it on sumex-aim.stanford.edu; you may also look for it on oddjob.uchicago.edu, where Bob Loewenstein has put his Yerk system, which is very similar. People who have problems getting Mops can always contact me, langowski@frembl51.bitnet, and I’ll send you a copy.

If you want to write Michael Hore directly, this is his address:

Michael Hore, c/o MAF, P.O. Box 821

Nhulunbuy, NT 0881, Australia

Mops basics

Enough of a preface - we’ll quickly look at Mops, see what it does and how one can develop Macintosh applications with it. Mops is an object-oriented programming system based on Forth. A great part is a re-implementation of the NEON development system, which long-time subscribers of this journal might still remember. NEON, introduced in 1986 by Kriya Systems, was in my opinion one of the most successful attempts to create a simple object-oriented development system for the Macintosh, which allowed to create applications quickly and without the overhead that a powerful-but-huge system like MacApp required. Unfortunately, due to buggy first implementations it didn’t succeed in getting too large a customer base, and shortly after releasing the first stable version 2.0, the company more or less dropped the product.

Now, some people had gone quite far in developing applications in NEON, and when they slowly realized that they couldn’t expect customer support or upgrades from the original publishers anymore, rather than totally changing the implementation of their programs, they tried to make NEON work on their own. Bob Loewenstein, who you’ve read about in this column, modified the NEON kernel so that it would work on the new Macintoshes with 68020 and 68030 processors, and worked very hard on Kriya Systems in order to get NEON’s source code released in the public domain. This took about two years, but at the beginning of this year, he finally succeeded (you read about it). He called his upgrade of NEON Yerk, from the Yerkes observatory where he worked, and Kriya systems allowed him to release the NEON source code ‘for non-commercial use’, as long as it is not called NEON, but Yerk. So for all there is, Yerk is the semi-official successor of NEON. It is available from oddjob.uchicago.edu through anonymous FTP, directory ~pub/Yerk.

Michael Hore took another, more radical route, to get around the problems with NEON on the 68020 and with its customer support. He ‘simply’ re-wrote it. He implemented a new subroutine-threaded Forth kernel (for non-Forth readers, this is a Forth that creates directly-executable 680x0 machine code and not interpreted code), which works 4-5 times faster than the original Forth that NEON was based on. Then he made quite a few modifications to the implementation of the object support, and to the language syntax. The result, which is almost NEON- (excuse me, Yerk-) compatible, he called Mops, for Michael’s object programming system.

Some excerpts from the Mops documentation illustrate best what he did:

Mops philosophy (Michael Hore)

“The basic idea behind Mops, originally, was of a reimplementation of Neon to compile subroutine-threaded code, which would run faster than the Neon indirect threaded code. The goals have expanded somewhat in the direction of some modest evolution of the language itself, and full System 7 compatibility.

The speed goals have certainly been achieved. Mops not only compiles subroutine-threaded code, it also compiles straight native code for common sequences. A certain amount of local optimization is also done. The result is that Mops code should run 4-5 times faster than the equivalent Neon code. Some benchmarks may run outrageously fast under Mops, due to the optimization. The Sieve benchmark, for example, runs in about 3 seconds on a Mac Plus (Neon took 21). Floating point, if a 68881/2 FPU is installed, is very swift indeed. Compilation speed is also much improved, not only by the faster underlying execution speed but also by the 8-thread dictionary structure.

Seeing I was originally intending Mops just for my own use, not wanting to tread on Kriya’s toes, I also took the opportunity to incorporate a number of other improvements to Neon. At least to me, they were improvements. Others may disagree, especially if they hit trouble converting Neon code. However I will attempt here to document the differences between Mops and Neon, to try to make life easier for anyone changing over.” (end of excerpt)

Mops syntax

An object-oriented programming language must allow to define a class hierarchy, with methods and variables local to each class. Also, there must be a mechanism to send messages to an object, and implement early (compile-time) and late (run-time) binding of the message to the class of the object. Neon implemented this quite elegantly, and Mops does it even better. I have prepared a very simple example - a resizeable window with zoom box and scroll bars, but nothing in it - to illustrate Mops programming.

The window is an object of the class CtlWind, which is defined in the Mops source code. The definitions are included in the listing; however, lower level classes are not (for space reasons), so you must imagine by yourself that there are such things as scrollbar objects.

A class definition looks like the following:

\ 1

:class  myClass  super{   mysuperclass   }

\ instance variables (always private)
 ptr  a
 int  b
 
private  \ the following methods are private

:m methodA: doThisinSecret  ;m
:m methodB: doThatinSecret  ;m

public  \ publicly accessible methods

:m methodC: doThis   ;m
:m methodD: doThat   ;m

;class

and for creating an object myObject of myClass, one simply writes myClass myObject. The superclass is defined by super{ superclass1 superclass2 }; Mops supports multiple inheritance from a list of superclasses. You also see that Mops allows private and public methods; private methods can only be used on self and super, thus within the class hierarchy. Instance variables are always private, as they have been in Neon. You must write access methods to manipulate them from the outside. I like that concept, and if one wrote C++ that way, it would certainly be more readable. (Yes, I know: I haven’t done that in my examples, either. But it would be a nice idea.)

Method names must finish with a colon (error otherwise), to make them look like nice messages. A method call is made by e.g. methodC: myObject, and when parameters are passed to the method, like in any good Forth system they are put on the stack by preceding the method call with them: par1 par2 methodD: myObject.

Let’s look at the example in detail. The first thing one notices is the striking simplicity of Forth code lines over those from other languages. For conditionally including a file, if some definitions are not present, we need to write at least three lines in C++, e.g.:

/* 2 */

#ifndef __TYPES__
#include <Types.h>
#endif

In Mops, you simply write need Ctl if you want to include the Controls definitions in case they aren’t there yet.

The ‘object pointer’ objPtr is another interesting concept in an object Forth system: this is a pointer to an object whose class is determined at compile time. When you store a pointer in this variable, it is checked whether it really points to an object of the given class, and an error message is issued if not. That way, we can use early binding for sending messages to the object that the pointer points to, which is more efficient.

In the following lines you see that Mops can be used for defining :proc routines, which are Forth routines that do all the necessary register housekeeping to be called from toolbox routines (e.g. they can be used as filter or control action procedures).

For the remaining code, if you don’t know Forth or Neon, it might not be evident to read it. Try anyway, and keep in mind that arguments always precede a function call. In the method definitions, you see lots of examples of message passing, for instance the put: and get: messages which put a value into a variable or get it back, or enable: and disable: which can be sent to a scroll bar or a window. Remember that self and super are used to designate the class that the method is defined in, or its superclass (this or inherited in C++). The word CFAS{ is used to put a variable number of routine pointers on a stack. For instance, the line

\ 3

 CFAS{  lnup lndn 10up 10dn null  }  actions: vv1

will put five addresses on the stack, the first four being pointers to the handlers for the up and down arrows and the page regions of a scroll bar, null being a do-nothing routine (we don’t want any special handler for the thumb region). actions: vv1 sets the action vectors of the scroll bar vv1 to point to these routines.

Other Mops features

The example only gives a little glimpse of what you can do with Mops. There are many more new features added, I’ll list a few from the documentation that comes with Mops:

Object handles - “ to access the object, the method obj: anObjHdl returns a pointer to the object, and also locks the handle so that the object won’t be unceremoniously moved while we are doing things with it. Remember to unlock: anObjHdl when finished. When you are finished with the object, send Release: anObjHdl. This will automatically cause a late-bound Release: to be sent to the object itself, before its storage is released, in case it has some heap storage of its own.”

Late binding - “Late binding works exactly as in Neon. I had one problem in that I wanted to use [ and ] to replace <[ and ]> to turn compilation off and on, since this is what just about every other Forth-based system uses. So now [ and ] do double duty. If they follow a method selector, they cause a late bind as in Neon. In any other context they turn compilation on and off. To help avoid confusion, we have added another syntax for a late bind: method: ** to bind to whatever is on the top of the stack at run time. Thus instead of method: [ (some code) ] you can now put (some code) method: ** and maybe not get so confused with [ ... ] meaning two different things. Still, [ ... ] sometimes looks neater, so by all means feel free to keep using it.”

Optimization - “ (the) optimization technique has worked well in practice, and generally gives around a 15% improvement in execution speed and a 10% reduction in code size. Of course, some common code sequences are improved much more than this.”

Large arrays - “Objects in indexed classes may now have more than 32K elements. You have to declare the class as “LARGE”, thus:

\4

:class SomeClass  super{ someSuper }  n indexed  large

Indexing operations on LARGE classes will use 32-bit arithmetic, which will slow accesses very slightly (on 68000-based machines only).”

Profiler - “Another new whiz-bang feature in C and Pascal compilers is a profiler, to give statistics on time spent in various lines of code, and also the number of times they have been executed. Well, anything that can be done in C or Pascal can be done more easily in Mops [my underlining - JL], so we had to have a profiler too. Because of the hierarchical nature of the language, it seemed to make the most sense to base profiling on a given word, whose definition is profiled. This way bottlenecks can be tracked down interactively, and you can zero in on the places of interest, rather than have to wade through a mountain of useless information. Anyway, it was easier to implement this way.”

System 7 support and AppleEvents - “Mops is now “System 7 friendly”. Among other things, this means that it recognizes AppleEvents. Mops handles the “core” AppleEvents: OpenApplication, OpenDocuments, PrintDocuments and QuitApplication. These have to be available in the nucleus, so that the nucleus can be properly System 7 friendly. We have provided handlers for these AppleEvents, as required by Apple, and also four corresponding vectors so that your application can customize things.”

Some comments: AppleEvents are probably the most significant new feature of System 7. This is not often recognized, because for the average user nothing has changed much, and for the moment the core Apple events do their work in the background. Only very few applications allow “program linking” through Apple events so far. However, the far-reaching consequences of inter-application communication through Apple events - in my opinion - are as revolutionary as was the introduction of the Macintosh, now almost eight years ago. I’ll write a column about it soon, and most probably the examples will be in Mops, because it is so much easier (and takes less space) to implement a working example of something new in a Forth-like system than in C++, Pascal or some other heavy-handed language.

Finally, some thoughts by Michael Hore on future developments of his Mops system:

Coming attractions - “These are ideas that I may incorporate into future versions of Mops. However I make no promises as to when.

* I have been looking at some other object-oriented languages to get ideas. One possibility is to provide a bit more flexibility in the way a subclass overrides a method. At present, it either overrides or it doesn’t. If it does, it may or may not call the Super version of the method within the new definition. However the superclass itself has absolutely no way of limiting what a subclass may do. Some other languages such as Flavors and Eiffel provide a superclass with the power to limit the extent to which a subclass may override a method, basically by allowing the provision of code which must be executed BEFORE the subclass’s version of the method executes, and code which must be executed AFTER the subclass’s method has finished. These pieces of code can do things like check that certain constraints haven’t been violated. We may add a facility like this to Mops. It would not be obligatory, of course--existing code would not need to be changed.

* We might provide a way that a class could be exported from a module, and be allowed to instantiate objects outside the module. In many ways classes are “modular” in concept, and this would provide greater consistency in the language.

* We will probably provide an “AppleEvent Object” class to support the protocol defined for the operands of AppleEvents (System 7). This protocol is object-oriented, and so should fit into Mops quite nicely. However I need to give some thought to exactly what is the best way to do this.

* We still haven’t implemented the menu items “List objects” or “list Classes”. We may implement these as they were in Neon, or go to a more general class/object browser. Already you can type SEE xxx and get a structured display of whatever xxx is, including its superclasses if it’s a class or an object. Maybe we’ll enhance this. Anyway stay tuned.

* Apple has hinted that in future it may “encourage” a separation between an application’s code and data. This change would necessitate a change to the Mops addressing architecture, since we have so far followed the laid-back Forth philosophy of putting anything wherever we wanted to. This would probably be a painful change to make, may cause problems with some existing applications, and would not really benefit performance. Therefore I will only make this change if I am forced to. If, for example, Apple say that future versions of virtual memory will only be supported for applications that have separate code and data, then I will consider myself forced. Anyway, time will tell. I don’t think Apple will do anything in this area in a hurry, since they would break most existing applications if they did.”

And, most unbelievable, such a well thought-out system is in the public domain. I hope this short overview of Mops has convinced you as well. Just to repeat Michael’s words, “anything that can be done in C or Pascal can be done more easily in Mops”. That’s probably true.

Example: Simple scrollbar window in MOPS

\ ctlWind - Window subclass adding controls etc.

\ May  91 mrh  Extensively revised adding standard 
\ vert & horiz scroll bar and zoom box support.

decimal

need  ctl \ these files are included
need  vscroll    \ if necessary

 objPtr theSB  class_is vscroll
    0 value MPOINT


: CTLEXEC 
 \ ( part# ctlHndl -- )  Executes action for control.
 get-ctl-obj  exec: **  ;

\ CtlProc is the procedure to be executed 
\ when a control is being tracked.

:proc  CTLPROC \  ( ctlHndl int:part -- )
 word0 swap  ctlExec  ;proc

: CTLHIT?  { wind \ part ^ctl action1 action2 -- bool }
 \ Look for control click
 where: fEvent  g->l  -> mpoint    \ save mouse loc
 word0  mpoint  wind  theCtl  call FindControl
 word0  -> part  theCtl @  -> ^ctl \ ctl handle
 part
 CASE[ inThumb ],  [ inCheckBox ],  [ inButton ]=>
        \ Only exec after mouseUp
 0 ->  action1 
 \ 0 since gets passed to TrackControl
 [‘] ctlExec  -> action2
 DEFAULT=>
 drop  [‘] ctlproc -> action1  [‘] 2drop -> action2
 ]CASE
 ^ctl
 IF
 word0  ^ctl  mpoint  action1  call TrackControl  
 word0  ^ctl  action2 execute  true
 ELSE
 false
 THEN  ;


\ Note: if your Window is a subclass of CtlWind and has 
\ scroll bars, it should set the scroll bars to 255 hiliting 
\ on a deactivate event. This can be done via the Disable: 
\ method in VScroll. But if the scroll bars are default ones 
\ set up via setVscroll:  and setHscroll:, this will all be 
\ looked after for you.


:class  CTLWIND  super{ window }

\ instance variables
 ptr  ^VSCROLL
 ptr  ^HSCROLL

 bool ZOOMFLG
 
private  
 \ yes, private and public methods exist in Mops / JL

:m VSCROLL?:get: ^vscroll  nilP  <>  ;m
:m HSCROLL?:get: ^hscroll  nilP  <>  ;m
:m ?SBtoEdge:
 vscroll?: self  IF  get: ^vscroll  edge: vscroll  THEN
 hscroll?: self  IF  get: ^hscroll  edge: hscroll  THEN  ;m

public

:m SETZOOM: \ ( b -- )  Passed-in boolean indicates if 
 \ this window will be zoomable.
 put: zoomFlg  ;m

:m SETVSCROLL:  { vscr lo hi \ left top rt bot -- }

  \ Sets up a vertical scroll bar in the usual position. 
  \ vscr is the addr of a vscroll object, and lo and hi gives 
  \ the range. All the housekeeping for the scroll bar is 
  \ looked after automatically.

 vscr  put: ^vscroll   vscr -> theSB
 getVrect: self
 -> bot  -> rt  -> top  -> left
 left  top  bot 1+  ^base  new: theSB
 lo hi putRange: theSB  ;m

:m SETHSCROLL:  { hscr lo hi \ left top rt bot -- }
 
 \ Sets up a horizontal scroll bar in the usual position.

 hscr  put: ^hscroll   hscr  [‘] theSB  !  
 ( strictly, classes don’t match )
 getHrect: self
 -> bot  -> rt  -> top  -> left
 left  top  rt 1+  ^base  new: theSB
 lo hi putRange: theSB
 setView: self  ;m

:m NEW:
 { bndsRect tAddr tLen procID vis goAway \ s255 -- }

  \ Defines a new window on the heap with the 
  \ specified features. Not resource based.
  \ Only change in this subclass is to use
  \ zoomFlg to modify the procID.

 get: alive  ?EXIT \ Out if already alive
 ?disable_actW: self
 tAddr tLen  str255  -> s255
 0  ^base  bndsrect  s255  vis Tbool
 get: zoomFlg  8 and  procID + makeint
 inFront  goAway Tbool  0
 call NewWindow  drop
 initNewWindow: self  ;m

:m GROW:grow: super  ?SBtoEdge: self  ;m

:m ZOOM:zoom: super  set: super  ?SBtoEdge: self  ;m

:m ENABLE:
 vscroll?: self  IF  get: ^vscroll  enable: vscroll  THEN
 hscroll?: self  IF  get: ^hscroll  enable: hscroll  THEN
 enable: super  ;m

:m DISABLE:
 vscroll?: self  IF  get: ^vscroll  disable: vscroll  THEN
 hscroll?: self  IF  get: ^hscroll  disable: hscroll  THEN
 disable: super  ;m


:m DRAW:\ Draws the window with controls
 draw: super  ^base  call DrawControls  ;m

:m CLOSE: 
 \ Disposes of window’s controls and closes the window
 ^base  call KillControls  close: super  ;m

:m CONTENT: \ Handles a content click
 active: self
 IF
 ^base  ctlHit?
 NIF  exec: content  THEN
 ELSE
 select: self
 THEN  ;m

:m TEST:
 100 100 300 200 put: tempRect
 screenbits true setGrow: self
 tempRect  “ Test”  docWind  true true  new: self
 true  setZoom: self  ;m

;class


\ definitions for our test window

ctlWind WW
hscroll VV1
vscroll VV2

2 AppleMenu APPLEMEN
1 menu  FILEMEN
6 EditMenuEDITMEN

: 10UP  get: thisCtl 10 - 0 max  put: thisCtl  ;
: 10DN  get: thisCtl 10 +  put: thisCtl  ;

Rect temprect

: GO
 
 CFAS{ null doDsk } 1 init: appleMen
 CFAS{ bye }2 init: FileMen
 CFAS{ null null null null null null } 3 init: EditMen
 
 getnew: appleMen
 getnew: FileMen
 getnew: EditMen
 
 appleMen FileMen EditMen 3 init: menubar

 screenbits true  setGrow: ww
 true  setZoom: ww
 CFAS{  lnup lndn 10up 10dn null  }  actions: vv1
 CFAS{  lnup lndn 10up 10dn null  }  actions: vv2
 CFAS{  bye null null null  }  actions: ww
 
 0 36 300 200 put: tempRect
 tempRect  “ Test”  docWind  true true  new: ww
 vv1 0 20 sethscroll: ww  vv2 0 10 setvscroll: ww
 
 begin key drop again  
;