scc@cl.cam.ac.uk (Stephen Crawley) (07/14/87)
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. [Ada is a different matter ...] 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
scc@cl.cam.ac.uk (Stephen Crawley) (07/29/87)
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
ralphw@ius2.cs.cmu.edu (Ralph Hyre) (07/31/87)
I've heard some say that Modula-2 is a Mesa rip-off, since Wirth spent
a year sabbatical at Xerox Parc. I prefer CLU myself.
--
- Ralph W. Hyre, Jr.
Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PAscc@cl.cam.ac.uk (Stephen Crawley) (08/06/87)
In article <1246@ius2.cs.cmu.edu> ralphw@ius2.cs.cmu.edu (Ralph Hyre) writes: >I've heard some say that Modula-2 is a Mesa rip-off, since Wirth spent >a year sabbatical at Xerox Parc. That's what I heard too. Modula-2 is Mesa with the good bits left out (:-) > I prefer CLU myself. [Please note: I've never written anything other than toy programs in CLU, so I can't talk with any authority.] CLU has a lot going for it. It is generally a cleaner, better designed language than Mesa. It also language has features that I miss in Mesa ... abstract data types, type parameters and garbage collection spring to mind as being important. On the minus side (compared with Mesa), CLU has no support for concurrency and it is exceedingly difficult to do low level register poking and pointer bashing in CLU [can you say "CLU compatible assembler"?]. In my case, the decision to go for Mesa rather than CLU was motivated by pragmatic considerations. The CLU linker is painfully slow, and the CLU/UNIX runtime environment is sparse compared to Mesa/XDE. I was (and still am) keen on an open OS environment with light-weight processes and dynamic loading of code. Address space firewalls (like between 2 UNIX processes!) are a pain in my line of work. That having been said, if I were to make the choice today with the benefit of hindsight, I think it might well go the other way. The reason is that I find that most of the problems in my work (persistent object management) are due to Mesa having no garbage collection. When I changed to Mesa a couple of years ago, I thought that GC was a no-no for OS type work because of the performance implications. I've since changed my mind. -- Steve