Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtech.ARPA
Path: utzoo!dciem!nrcaero!pesnta!hplabs!amdahl!rtech!mark
From: mark@rtech.ARPA (Mark Wittenberg)
Newsgroups: net.lang.c
Subject: Re: Pascal vs. C
Message-ID: <125@rtech.ARPA>
Date: Fri, 1-Feb-85 20:48:38 EST
Article-I.D.: rtech.125
Posted: Fri Feb  1 20:48:38 1985
Date-Received: Thu, 7-Feb-85 07:25:17 EST
References: <4859@utzoo.UUCP> <11@mit-athena.ARPA> <177@gcc-opus.ARPA> <7055@brl-tgr.ARPA> <25@seismo.UUCP> <6283@boring.UUCP> <250@gumby.U Fri, 1-Feb-85 20:48:38 EST
Organization: Relational Technology, Berkeley CA
Lines: 71

> >> Just to add coals to the fire, between Modula-2 and Concurrent Euclid
> >> I'd choose CE anyday.
> >> 
> >> Mark Wittenberg
> >> Relational Technology, Inc.
> >> Berkeley, CA
>  
> >No arguments from me, Mark.  CE is indeed a VERY beautiful language.
> >-- 
> >      Dan Frank
> >      U of Wisconsin CS dept
> 
> In which case, I'm afraid I can't resist an opposing view. 
> 
> CE compares favourably with Modula-1 but not with the more recent Modula-2.
> 
> (1) The concurrency features (processes/monitors/signals) are just
>     what the original Modula-1 offered. They are implemented by magic
>     kernel primitives over which you have no control. In particular,
>     you can't create new processes dynamically at run-time. Modula-2
>     is lower level and gives you coroutines out of which you can build
>     a library module which gives you all the CE/Modula-1 concurrency stuff
>     if you want it, or anything else if you don't. OK, so you lose a bit
>     of syntactic sugar, but you gain in flexibility.
> 
> (2) The separate compilation/strong type checking stuff in CE is again
>     more like Modula-1 than Modula-2. In CE there is no separation
>     between the implementation part of the module, and the interface to
>     the module - in Modula-2 these are two separate bits of the module
>     which must each be compiled individually. Both the compiler and the
>     linker will check for and enforce consistency - the version of CE I saw
>     just used the standard Unix linker so didn't do any consistency
>     checking at link time - it would have been easy to get the versions
>     mixed up and link incompatible code, completely subverting the original
>     intention of the type checking.
> 
> All this modulo the particular Modula-2 and CE implementations I played
> with circa 1981.
> 
> Robert Stroud,
> Computing Lab,
> University of Newcastle upon Tyne.
> 
> ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa
> UUCP ...!ukc!cheviot!robert
> 
> "Strong typing is for people with weak memories"
> 

1) Modula-2 gives you co-routines, not processes.  Mutual exclusion with
   co-routines is much simpler than it is with processes.  It is easy to
   implement co-routines in CE, but not to implement processes in M-2.
   You are right that you cannot dynamically create processes in CE.
   Monitors are implemented in the kernel but they aren't "magic" (by
   which I mean the implementation is straight-forward and reasonable).

2) CE does separate implementation from interface, but you are correct
   in noting that the linker doesn't enforce it.

Nothing's perfect.  In particular, you didn't mention that in CE you
can't separate a monitor from the data it's protecting, by which I
mean that if you have two object that you wish to protect in identical
fashion you must write two monitors: you can't write one monitor and
point it first one object and then to another.  Too bad.

Thanks for the best short note I've seen describing where M-2 might
reasonably be considered better than CE.

Mark Wittenberg
RTI
Berkeley, CA