🚀 go-pugleaf

In article <749@unc.cs.unc.edu> rentsch@unc.UUCP (Tim Rentsch) writes:
>In some previous article lindsay@cheviot (Lindsay F. Marshall) writes:
>> 
>> I think mesa is a dreadful language.
>
>Interesting opinion.  Would you mind defending your opinion with
>some facts (or even just some reasons)?
>

Hear, hear!  How about it Lindsay?  

[I'd love to see an example where you'd need to use LOOPHOLE in Mesa 
 and not in Modula-2!!]

I've been using Mesa for 2 years or more now, and I guess I've 
written something close to 100K lines of code.  Before switching,
I worked mostly in Modula-2 (20K lines or more), so I believe I 
am in a position to make an informed comparison between the 2
languages.  [I've done no more than read the Ada ref manual so
I'm not qualified to comment there ...]  

In my experience, Mesa is on a par with or better than Modula-2 
in all significant respects.  The only exceptions to this are some
implementation restrictions, and some minor syntactic warts that
arise from the way that Mesa evolved.

The Mesa type system allows both short and long forms of 
integers, cardinals and pointers.  Record types can have bit 
fields.  The SEQUENCE type allows you define arrays with run-
time bounds, and arrays can be "sliced" using DESCRIPTORs.
The STRING type is superior to the equivalent in Modula-2.  

Mesa has constructors for both records and arrays.  An array
for example can be initialised as follows

  a: ARRAY [1..20] OF CARDINAL <- ALL[42];

  b: ARRAY [1..2] OF ARRAY [1..2] OF CARDINAL <-
    [[1, 2], [3, 4]];

Furthermore, Mesa types can be defined with partial or 
complete default initialisers.  [And the compiler tells
you about uninitialised variables!]

Mesa's modularisation is superior to Modula-2's.  In Modula-2,
you are restricted to a 1-to-1 relationship between definition
and implementation modules.  In Mesa, the relationship can be
many-to-many.  Mesa does not restrict opaque types to being
one size.  

Mesa allows you to use local procedures as procedure values.
(In Modula-2 only global procedures can be used in this way)
This makes the following sort of thing possible.

List: TYPE = POINTER TO Cell;
Cell: TYPE = RECORD [value: CARDINAL, next: List];

Enumerate: PROC [list: List, enumProc: PROC [elem: List]] = {
  FOR l: List <- list, l.next 
      WHILE l # NIL DO 
    enumProc[l] 
    ENDLOOP};
  
...

DoThingsToList: PROC [list: List] =
  BEGIN
  sum, nos: CARDINAL <- 0;

  SumEm: PROC [elem: List] = {sum <- sum + elem.value};
  CountEm: PROC [elem: List] = {nos <- nos + 1};

  Enumerate[list, CountEm];
  Enumerate[list, SumEm]
  END;

Mesa has a very powerful resumption model exception handling 
system.  Some people think it is too general, but on many
occasions I have been glad of its generality.  Modula-2 on
the other hand has no exceptions at all.  [This is one of
the reasons I made the switch from M2 to Mesa.]

Mesa's support for concurrency is vastly superior to Modula-2's.
FORK and JOIN, condition variables with WAIT, NOTIFY and BROADCAST, 
two flavours of monitors, [plus a whole lot more in the Mesa runtime 
system ...]

And so on ...

I'm not saying that Mesa is a perfect language.  Far from it!  For
example, I find the absence of garbage collection and closures in Mesa
to be a severe limitation in my work.  Plus there are the implementation
and syntactic warts I alluded to.  [They say that Cedar fixes a lot
of these problems ... sigh].  However, I am prepared to forgive these 
shortcomings considering that Mesa predates Modula-2 by a small number 
of years.  The real pity that the Xerox corporate and marketing bods 
kept Mesa inside the company for so long.

-- Steve