[comp.lang.modula2] Warning From uucp

uucp@wb3ffv.UUCP (08/20/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/17)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0eda

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Wed Aug 17 13:19:25 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA02421; 17 Aug 88 13:19:25 EDT (Wed)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA00910; 17 Aug 88 04:59:59 EDT (Wed)
Received: from [128.237.2.253] by rutgers.edu (5.59/1.15)
        id AA06990; Wed, 17 Aug 88 03:04:11 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA19886; Tue, 16 Aug 88 23:37:15 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    4715; Tue, 16 Aug 88 13:51:43 EDT
Received: by BITNIC (Mailer X1.25) id 2525; Tue, 16 Aug 88 13:52:35 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA16482; Mon, 15 Aug 88 19:05:36 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA26548; Mon,
          15 Aug 88 17:22:54 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
Organization: Sun Lab, Swarthmore College PA
Message-Id: <2033@carthage.cs.swarthmore.edu>
Date:         Mon, 15 Aug 88 14:36:59 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Hal Pomeranz
              <rutgers!swatsun.swarthmore.edu!pomeranz>
Subject:      Modula-2 on Suns (again, sorry)
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>


Could somebody please email me the collected opinions on the various modula-2
compilers available for the Suns.  Any further opinions would be appreciated,
but email them to me rather than rehashing the subject on this board.

Thanks,
Hal Pomeranz
System Administrator
Swarthmore College

--
______________________________________________________________________________
|UUCP: ...!rutgers!bpa!swatsun!pomeranz          | Living on a lighted stage
|CS Net: pomeranz@cs.swarthmore.edu              |    approaches the unreal...
|BitNet: vu-vlsi!swatsun!pomeranz@psuvax1.bitnet |                  -Rush

uucp@wb3ffv.UUCP (08/20/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/17)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0edb

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Wed Aug 17 13:19:29 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA02426; 17 Aug 88 13:19:29 EDT (Wed)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA01953; 17 Aug 88 06:18:59 EDT (Wed)
Received: from [128.237.2.253] by rutgers.edu (5.59/1.15)
        id AA14069; Wed, 17 Aug 88 05:45:08 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA25713; Wed, 17 Aug 88 02:15:42 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    7911; Tue, 16 Aug 88 22:13:58 EDT
Received: by BITNIC (Mailer X1.25) id 3244; Tue, 16 Aug 88 22:15:41 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA29225; Tue, 16 Aug 88 19:00:52 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA18300; Tue,
          16 Aug 88 14:07:06 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
References: <79500004@p.cs.uiuc.edu>
Message-Id: <3740004@wdl1.UUCP>
Date:         Tue, 16 Aug 88 16:55:12 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Rion Cassidy <rutgers!ford-wdl1.arpa!rion>
Subject:      Re: C v.s. Modula II
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>


 gillies@p.cs.uiuc.edu writes:

>When I first came to grad school, and began writing C code again, I
>was unexpectedly disappointed.  I had grown used to a Modula-II like
>language (MESA).  Some of the things that really bothered me about C
>were:

[complaints deleted]

You didn't say where you learned Mesa, but since Xerox is the only
place that uses it, I'd assume you came from there.

Your comments are interesting because when I interveiwed with Xerox
they said that Mesa was more like C than Pascal or M-2.

Rion Cassidy
rion@wdl1.arpa

uucp@wb3ffv.UUCP (08/20/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/17)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0edd

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Wed Aug 17 13:19:37 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA02436; 17 Aug 88 13:19:37 EDT (Wed)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA03918; 17 Aug 88 08:12:41 EDT (Wed)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA16539; Wed, 17 Aug 88 06:29:50 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA27634; Wed, 17 Aug 88 03:04:02 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    8514; Wed, 17 Aug 88 02:15:43 EDT
Received: by BITNIC (Mailer X1.25) id 4554; Wed, 17 Aug 88 02:17:30 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA00790; Tue, 16 Aug 88 23:11:12 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA25690; Tue,
          16 Aug 88 20:32:29 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
Message-Id: <3740005@wdl1.UUCP>
Date:         Tue, 16 Aug 88 19:36:32 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Rion Cassidy <rutgers!ford-wdl1.arpa!rion>
Subject:      JPI Modula-2
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>


Does anybody have any experience with JPI (Jensen Partners
International) Modula-2?

The latest issue of CACM has an ad for JPI M-2 that makes the usual
claims about being significantly faster than the competition,
reasonably priced, and quoting a reviewer who had some praise for the
product.

But has anybody out there in netland actually been using it?  What are
the pros and cons of JPI M-2?

Rion Cassidy
Ford Aerospace

** PLEASE REPLY TO: **
rion@ford-wdl1.arpa
...{sgi,sun,ucbvax}!wdl1!rion

My other computer is a Cray.
Programmers go down faster.

uucp@wb3ffv.UUCP (08/20/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/17)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0ede

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Wed Aug 17 13:19:40 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA02441; 17 Aug 88 13:19:40 EDT (Wed)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA03923; 17 Aug 88 08:12:44 EDT (Wed)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA16598; Wed, 17 Aug 88 06:32:33 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA27672; Wed, 17 Aug 88 03:05:28 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    8535; Wed, 17 Aug 88 02:18:14 EDT
Received: by BITNIC (Mailer X1.25) id 4591; Wed, 17 Aug 88 02:18:09 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA00741; Tue, 16 Aug 88 23:01:46 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA24365; Tue,
          16 Aug 88 19:28:23 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
Organization: National Semiconductor (IC) Ltd, Israel
Message-Id: <2107@ima.ISC.COM>
Date:         Thu, 11 Aug 88 10:09:14 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Rick Pelleg <rutgers!husc6.harvard.edu!compilers-sender>
Subject:      Size of enumerations/subranges in Modula-2
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>

We have written a Modula-2 compiler which produces code for the NS32000
family of CPUs.  One problematic implementation issue is that of the size
of enumeration types and subrange types.

The two possibilities are:
  1. An enumeration/subrange occupies the least possible amount of bytes (the
     NS32000 are byte addressable machines).
  2. An enumeration/subrange always occupies four bytes (a double-word).  This
     is the "natural" size on the NS32000.

The issue is the usual "speed vs. space" tradeoff.  The first possibility of
course saves space, but is slower whenever doing mixed sized calculations
or array indexing, because of the conversions that must be done.

Any opinions about this issue?  In particular, I am interested in the following
two questions:
  1. How do Modula-2 compilers you know implement enumerated types and
     subranges?
  2. How would you like to see them implemented?

I'll summarize any interesting email I receive on the subject.

Thanks,
--
--- Rick Pelleg
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel  Tel. (972)52-522264
rick%taux01@nsc.com @{hplabs,pyramid,sun,decwrl}
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

uucp@wb3ffv.UUCP (08/20/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/17)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0ed8

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Wed Aug 17 13:19:17 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA02411; 17 Aug 88 13:19:17 EDT (Wed)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA00900; 17 Aug 88 04:59:48 EDT (Wed)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA07998; Wed, 17 Aug 88 03:24:33 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA20572; Tue, 16 Aug 88 23:52:08 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    4832; Tue, 16 Aug 88 14:02:48 EDT
Received: by BITNIC (Mailer X1.25) id 3112; Tue, 16 Aug 88 14:04:33 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA17147; Mon, 15 Aug 88 20:26:11 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA28394; Mon,
          15 Aug 88 18:46:57 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
References: <79500004@p.cs.uiuc.edu>
Message-Id: <79500010@p.cs.uiuc.edu>
Date:         Mon, 15 Aug 88 02:45:00 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: rutgers!p.cs.uiuc.edu!gillies
Subject:      Re: C v.s. Modula II
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>


I will elaborate, since I think parts of my posting were misunderstood:

>Adding an else-clause can require you to restructure the {}'s.

Here is an extreme example, and many others exist:

if (a)
        if (b)
                if (c) do_something_useful();

/* Add an else-clause for the second -if- produces */

if (a)  {
        if (b) {
                if (c) do_something_useful();
        }
        else    c_sucks_the_big_wazoo_sometimes();
}

Look at all the braces which had to be added to make the else clause
bind correctly!

>Often, for(;;) loops are written with *no body*, and adding additional
>commands can require major restructuring of the loop.

/* Here is a way to copy a string */
for(p=charbuf, q=copybuff; *p++=*q++;);

/* What if I wanted to debug this, and print characters as they were copied? */
for(p=charbuf, q=copybuff; *q;) {
        putchar(*p++=*q++);             /* <theoretical example only> */
}

Notice how I had to restructure the looping condition to make this
change.  Things can be much worse with a more complicated loop.

>6.  C has no provision for callback procedures (you need nested
>procedures and the right semantics for the 'display').  So data
>abstraction is hindered in C.

Let us say I have a data-abstract code package that exports a procedure
that traverses a dictionary data structure.  The format of the data
structure is proprietary.  Callback requires ONE level of procedural
nesting for each nested loop.  How can I express something like this
in C?

dict: Dictionary.Handle;                -- global variable

PrintDictionary: PROCEDURE = {
  wh: Window.Handle := Somewhere.GetAWindowHandle[];     -- used in callback
  -- A CallbackProc is a PROC[a:LONG STRING] RETURNS[BOOLEAN];
  ShowName: Dictionary.CallbackProc = {
    Put.String[wh, a];
    Put.CR[wh];
    RETURN[TRUE]
  }
  Dictionary.Enumerate[dict, ShowName];
}

I call the Dictionary.Enumerate[] procedure, and it repeatedly makes
call to the ShowName procedure. FURTHERMORE, from within the ShowName
procedure, I can access & change the variables global to
PrintDictionary (wh, the window handle).  This is crucial if you want
to get something done, in a type-safe manner.  I don't think C++'s
pointer parameters cut the mustard.....

Callback procedures are a nice way of supporting abstract enumeration
when the language lacks something like CLU's explicit enumerators.


Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies

uucp@wb3ffv.UUCP (08/20/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/17)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0ed9

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Wed Aug 17 13:19:21 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA02416; 17 Aug 88 13:19:21 EDT (Wed)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA00907; 17 Aug 88 04:59:56 EDT (Wed)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA11676; Wed, 17 Aug 88 04:52:32 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA23497; Wed, 17 Aug 88 01:22:17 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    5077; Tue, 16 Aug 88 14:29:35 EDT
Received: by BITNIC (Mailer X1.25) id 4157; Tue, 16 Aug 88 14:31:16 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA19041; Tue, 16 Aug 88 02:30:21 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA06462; Tue,
          16 Aug 88 01:33:05 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
References: <79500004@p.cs.uiuc.edu>, <79500010@p.cs.uiuc.edu>
Message-Id: <13019@mimsy.UUCP>
Date:         Tue, 16 Aug 88 07:32:11 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Chris Torek <rutgers!mimsy.umd.edu!chris>
Subject:      Re: C v.s. Modula II
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>

In article <79500010@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>I will elaborate, since I think parts of my posting were
>misunderstood:

(Some were; some I answered just a few minutes ago)

>Often, for(;;) loops are written with *no body*, and adding additional
>commands can require major restructuring of the loop.
>/* Here is a way to copy a string */
>for(p=charbuf, q=copybuff; *p++=*q++;);
>
>/* What if I wanted to debug this, and print characters as they were copied? */
>for(p=charbuf, q=copybuff; *q;) {
>       putchar(*p++=*q++);             /* <theoretical example only> */
>}

Well, you *could* write

        for (p = charbuf, q = copybuf; putchar(*p++ = *q++););

but all of these examples are grotesqueries.

>Notice how I had to restructure the looping condition to make this
>change.  Things can be much worse with a more complicated loop.

I will agree that if you are going to revise a loop you must look
at the `for' part as well as the body.  So what?  If I am going to
revise a

        # unspecified generic odd-looking fully-bracketed language:
        for i from 31 to 97 do a[i] <- f(i); rof;

into a

        for i in a[] do a[i] <- f(i); rof;

I will have to look at the `for' part as well as think about what
is going on.

Certainly C's for statement can be abused, but I think the flexibility
it provides is worth it---look at the number of syntaxes for the Mesa
FOR statement to see what I mean.

>... callback procedures ... How can I express something like this
>in C?

>dict: Dictionary.Handle;               -- global variable
>
>PrintDictionary: PROCEDURE = {
>  wh: Window.Handle := Somewhere.GetAWindowHandle[];     -- used in callback
>  -- A CallbackProc is a PROC[a:LONG STRING] RETURNS[BOOLEAN];
>  ShowName: Dictionary.CallbackProc = {
>    Put.String[wh, a];
>    Put.CR[wh];
>    RETURN[TRUE]
>  }
>  Dictionary.Enumerate[dict, ShowName];
>}
>
>I call the Dictionary.Enumerate[] procedure, and it repeatedly makes
>call to the ShowName procedure. FURTHERMORE, from within the ShowName
>procedure, I can access & change the variables global to
>PrintDictionary (wh, the window handle).  This is crucial if you want
>to get something done, in a type-safe manner.  I don't think C++'s
>pointer parameters cut the mustard.....

Yes they do, but I will write this in C, rather than in C++.  (C++ can
make short work of it by using classes, so that is no fun at all.  It
is interesting, though, to note that either Dictionary or Window must
be a subclass of the other to do it.  That problem vanishes with
multiple inheritance, coming soon to a C++ compiler near you :-) .)

        /* typedef int boolean; */ /* in some header; or just use int */

        Dictionary_Handle dict;         /* global, as before */

        struct communique {
                Window_Handle wh;
                /*
                 * any other variables local to PrintDictionary
                 * that might be needed/modified in ShowName
                 * go here too.
                 */
        };

        static boolean ShowName(void *private_data, char *a) {
                struct communique *vars = private_data;

                Put_String(vars->wh, a);
                Put_CR(vars->wh);
                return TRUE;
        }

        void PrintDictionary() {
                struct communique vars;

                vars.wh = Somewhere_GetAWindowHandle();
                Dicationary_Enumerate((void *)&vars, dict, ShowName);
        }

>Callback procedures are a nice way of supporting abstract enumeration
>when the language lacks something like CLU's explicit enumerators.

Yes, they are.  While the above lacks the elegance of Mesa's syntax, it
works; it is portable; it can do everything the Mesa version can do.
Moreover, it does not require displays.  (One can simplify the above
example, eliminating the structure entirely, since there is only a
single pointer variable communicated.  In the general case, though, the
structure is required.)

Personally, I would rather use the elegant syntax.

Note that uplevel variable accesses can always be transformed into
references via an opaque pointer, as I did it above, at no cost to
those routines that do not participate.  The compiler must be able to
tell which procedures have such references, which which procedures call
such procedures, which procedures call procedures that . . ., etc.  A
better method, which does not require recursive inference, is to
generate new functions on the fly that automatically provide the
appropriate hidden argument.  This can be done with some cooperation
from the hardware and the O/S.  David Chase recently stirred up a fuss
in comp.lang.c by mentioning this technique.  (Search for the subject
`partial application', but be forewarned: it quickly evolved into a
debate about self-modifying code.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu     Path:   uunet!mimsy!chris

uucp@wb3ffv.UUCP (08/20/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/17)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0edc

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Wed Aug 17 13:19:32 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA02431; 17 Aug 88 13:19:32 EDT (Wed)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA01964; 17 Aug 88 06:19:12 EDT (Wed)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA12529; Wed, 17 Aug 88 05:12:49 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA23926; Wed, 17 Aug 88 01:36:04 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    5438; Tue, 16 Aug 88 15:08:03 EDT
Received: by BITNIC (Mailer X1.25) id 4091; Tue, 16 Aug 88 14:29:30 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA18820; Tue, 16 Aug 88 01:55:05 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA06019; Tue,
          16 Aug 88 01:01:47 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
References: <8808151857.AA05996@klaus.olsen.uucp>
Message-Id: <13018@mimsy.UUCP>
Date:         Tue, 16 Aug 88 06:47:29 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Chris Torek <rutgers!mimsy.umd.edu!chris>
Subject:      Re: C v.s. Modula II
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>

>Chris Torek writes:
>>Mesa is considerably more useful for writing Real Programs than is
>>Modula-II, if only because its I/O really is standard (or at least
>>only has to deal with one O/S!).  So this is more of a Mesa-vs-C:

In article <8808151857.AA05996@klaus.olsen.uucp> nagler%olsen@unizh.UUCP
(Robert Nagler) writes:
>There is more than enough supporting evidence to the contrary since
>DEC-SRC (loaded with PARC people) have been using M2+ which merely
>has built-in monitors, exceptions, and generic pointers.

`Merely'?!

>>>2.  Local changes can require non-local code restructuring.

>>Not if you format well :-) .

>What if you change a parameter from by-value to by-reference (for
>performance reasons).

You have me there (but then that was why I put in the `:-)' ).  But
this is irrevocably tied in with the `var' parameter declaration
format, which I personally hate.

>>>Adding an else-clause can require you to restructure the {}'s.

>>Nope:

>Yup:
>    if (a)
>        if (b)
>            do_this;
>goes to:
>    if (a)
>        if (b)
>            do_this();
>    else
>        do_that();

But (says he) the original code is not `well-formatted':

    if (a) {
        if (b) {
            do_this;
        }
    }

Adding the else is now trivial.

Basically, this just means using full bracketing even though the
language does not provide fully bracketed constructs (I happen to like
fully bracketed syntax a la Algol, even to the silly sdrawkcab
spellings).

>>>3.  Include files are hard to keep track of, nest, and structure in a...

>>Any automated scheme (Mesa's is semi-automated) tends to work better...

>Wrongo! The advantage of Mesa is *compiled* interfaces.

Funny, our Mesa people seem to spend about half their time working
around this `advantage', since Xerox keeps sending incompatible
revisions of things.  (Not a problem with the language!)

>This is the most significant advance in programming since type checking
>(in my humble opininion).

Hm?  It *is* type checking.  Mesa embeds it in the language by
providing syntax and semantics for it.  You still have to use it by
hand (hence `semi-automated').

>>>5.  I miss MESA INLINE procedures.  They are simpler and (often) more
>>>efficient than C's macro expansions.

>>   inline int unique_integer() { static int next; return (next++); }

>In M2 (Mesa), you would never write a procedure this way.
>Module variables are used instead of static variables.  In fact,
>you wouldn't write a macro this way in C?  What language is that?

It is one of the GNU C compiler's (numerous) extensions to C.

A Mesa module variable is simply a static variable that is local to a
module, just like C file-static (or if exported, just like C
file-global).  As such, it cannot be part of an inline function that is
also accessible-but-still-in-line outside that module.  GCC gets this
right, by allowing inline functions outside modules (and playing naming
games to get it to work at all).

>>Someone else complained about a lack of `var' parameters....
>>      munch(a, b, &c, d, e + 7);
>>I can assume that it cannot change a, b, and d....

>Almost every parameter (>int) in C is passed by-reference, so you
>never know what's being modified.

I disagree with this claim, but even granting it (temporarily! :-) ),
while I do not know what *is* being modified, I *do* know what *cannot*
*be* modified, which to me is at least as important.

>... My biggest problem with Unix man pages is
>that you never know what the function is expecting unless you read
>the detailed descriptions of all the parameters).

Funny, the same would be true if it were M2 and the parameters were
declared `var', without any other changes.  What is needed is access
rights (e.g., Ada---much as I think that language is overdone).

>One of my favorite features of C is:
>    scanf( "%d", i );

# this is one reason why `lint' should be run every time you run the
# compiler (not that there are no reasons not to run lint every time):
% cat t.c
main() { int i; scanf("%d", i); exit(0); }
% lint t.c
t.c:
t.c(1): warning: scanf argument is type (int) rather than pointer (arg 2)
t.c(1): warning: i may be used before set
scanf returns value which is always ignored
%

A deficient implementation is not a reason to complain about the
language!  And, similarly, a good but extended implementation, such as
your M2+, or any other M2 with the (remarkably few, but sometimes
remarkably large, as in I/O) holes filled in is not a reason to praise
the language.

[comparison of 4.2BSD setitimer declarations vs. newly created
equivalent M2 declarations]

>... I needless to say had to read the man page several times to figure
>out that "it_value" was relative to now and that "it_interval" would be
>reloaded *after* "it_value" expired.

In other words, the names and comments in the first part of the manual
entry---the part where the type of the function (including arguments)
is described---are insufficient.  You then provide a different version
written in M2 syntax, with *different names* and *different comments*:

>The first thing to note is that there are no descriptions of the names!
>I don't have comments like "/* and microseconds */" to clutter up the
>brain.   Comments contain *new* information which generally contains
>some semantic content that could not otherwise be provided by the
>M2 part of the declaration.  With this (C-like) M2 declaration,
>I believe I could have guessed how setitimer works.

And from changing the names and the comments, you conclude that the M2
declaration (which you wrote, so naturally you will understand it) is
inherently superiour to the C declaration?

C declarations do have their problems.  The major complaint seems to be
that they are overly terse; I also believe that the various pre- and
post-fix styles are part of the problem.  If `pointer' always came
after the name, or if `function returning' always came before, most of
the mysterious parentheses in C declarations like

        void (*signal(int sig, void (*sigfn)(int sig)))(int sig);
        /* to use the dpANS declaration syntax */

would go away.  But you seem to imply that M2 would somehow automatically
improve naming conventions and commenting, which I find unlikely.

>PROCEDURE Insert(
>    key   : ARRAY OF SYSTEM.BYTE;       (* BTW, can I do HIGH( key ) in C? *)
>    );

I have forgotten what HIGH(key) is supposed to do, but assuming that it
does the obvious---returns the size of the array, in whatever units---
the answer is `yes and no': you can get the size, but the caller must
provide the size; the called procedure can no longer obtain it.  This
is done so that the procedure call conventions need not provide array
descriptors, and because arrays are second-class data objects in C
(which, incidentally, *is* one of C's serious shortcomings).

        void Insert(void *key, size_t keylength);
        /* again, dpANS syntax. also legal is:
        void Insert(void *, size_t)
           but I think not using parameter names is dumb */

>TYPE
>    IntPtr = POINTER TO INTEGER;
>    SomeProc = PROCEDURE (
>        Object,
>    ) : IntPtr;
>PROCEDURE Foo(
>    bar : Object;
>    val : CARDINAL
>    )   : SomeProc;

(I do not understand the syntax `PROCEDURE(Object,)'.  Since M2 does
not have first class functions, I assume that SomeProc is actually
a pointer to some sort of procedure.  Anyway:)

        typedef int *IntPtr;
        typedef IntPtr (*SomeProc)(XXX);/* where XXX depends on what
                                           the above means */

        SomeProc foo(Object bar, unsigned val);

>TYPE
>    Values = [ 0 .. 65535 ];    (* int? short? char? Your guess... *)
>    Bits   = SET OF [ 0 .. 15 ];        (* ditto *)

Ranges are another real shortcoming in C.  But I do wonder what
you get if you declare, e.g.,

TYPE small = [0..12]; VAR a, b : small; ...
     a := 9; b := 11; a := a + b;

How is this defined?  I hope it must be a (presumably run-time) error,
with a compile-time warning allowed if the compiler is good.  (If the
compiler is good enough and can prove that the code above must execute,
a compile-time error would be even better.)

For minimum ranges, the dpANS says that an `unsigned short' must
be able to hold the values in 0..65535, hence it would suffice for
both types above.  Speaking of sets, has M2 fixed the Pascal hole
about sets?  That is, must the compiler do the right thing for

    TYPE bigset = SET OF [0..41];

?  (Pascal allows compilers to abort if the set contains more bits than
fit in a `machine word'---whatever that may be :-) .  While some
implementations allow larger sets, it is NOT part of the language, and
this must be considered in any language discussion.  More below:)

>What's bad about M2?  There are two flavors of implementations:
>one-pass and two-pass.  The two-pass systems are more mature.
>The one-pass systems are probably better, but it is hard to use them
>because we wrote 500 modules using the two-pass style (anyone written
>an automatic converter yet?).

Why should one need a converter?  Either forward declarations are
unnecessary and the compiler had better do the right thing no matter
how many passes it uses internally, or they are required and a two
(or N) pass compiler had better complain if they are not there.
Anything else is not M2 (unless the language definition really says
that compilers can complain depending on how they are implemented!).

[more woes about existing implementations deleted]

The implementation is not the language.  No doubt there are some
terrible implementations of M2, as well as some good ones.  The same is
true of C.  The biggest hole in the language is that it does not
provide any I/O.  Neither does C-the-language-syntax-and-semantics, but
stdio is considered a part of `the language'.  If there were a standard
I/O package for M2, the hole would vanish.

As a `for instance', consider VAX/VMS FORTRAN.  By all accounts this
is a wonderful implementation, and is a language in which it is easy
to write reasonable code that runs quickly and does whatever task is
at hand.  On the other hand, the 4.2BSD f77 FORTRAN compiler is slow,
buggy, produces lousy code, and has a weak library.  Neither one says
anything about the language *per se*.

Basically, my point can be stated thus:  If you have to extend the
language---either in internal syntax or in support libraries---to
accomplish what you must do, the language is insufficient for your
needs.  Since literally everyone has to extend Modula II for anything
that reads input or prints a result, that language is insufficient for
those needs.  Clearly, if you finish your task, the (new) language
*is* sufficient for those needs.

Anyway, while it is possible to compare specific features of one
language with those of another, I think blanket comparisons will always
fail in some way.  I will not claim that C is `better' than M2, nor
vice versa.  I *will* say that I like this feature, or dislike that
one.  I will also go so far as to say that discarding some features in
favour of `better' ones from another language might not improve the
first language after all.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu     Path:   uunet!mimsy!chris

uucp@wb3ffv.UUCP (08/23/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/21)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0f03

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Sun Aug 21 07:12:06 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA03264; 21 Aug 88 07:12:06 EDT (Sun)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA09450; 19 Aug 88 22:37:16 EDT (Fri)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA24953; Fri, 19 Aug 88 19:42:41 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA22748; Fri, 19 Aug 88 16:19:55 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    8230; Thu, 18 Aug 88 13:37:14 EDT
Received: by BITNIC (Mailer X1.25) id 6600; Thu, 18 Aug 88 13:20:40 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA12947; Thu, 18 Aug 88 08:04:41 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA15731; Thu,
          18 Aug 88 07:27:08 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
Organization: ETH Zuerich
References: <8808151857.AA05996@klaus.olsen.uucp>
Message-Id: <579@ethz.UUCP>
Date:         Wed, 17 Aug 88 21:50:04 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Robert Marti <rutgers!uunet.uu.net!marti>
Subject:      Re: C v.s. Modula II
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>

In article <8808151857.AA05996@klaus.olsen.uucp>, nagler%olsen@unizh.UUCP
(Robert Nagler) writes:

> We use a lot of C-Unix interfaces in our Modula-2 via special definition
> modules supported by the Sun Compiler (thanx Sun).

The thanks go to Oce Wissenschaftlisches Forschungsinstitut, Zurich,
and in particular to Leo Geissmann.


> What's bad about M2?  There are two flavors of implementations:
> one-pass and two-pass.

Make that one-pass and multi-pass.


> Rob Nagler     mcvax!olsen!nagler@uunet.uu.net
> Olsen & Associates/Research Institute for Applied Economics/Zuerich

--
Robert Marti                    Phone:       +41 1 256 52 36
Institut fur Informatik
ETH Zentrum                     CSNET/ARPA:  marti%ifi.ethz.ch@relay.cs.net
CH-8092 Zurich, Switzerland     UUCP:        ...uunet!mcvax!ethz!marti

uucp@wb3ffv.UUCP (08/23/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/21)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0efd

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Sun Aug 21 02:42:37 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA00208; 21 Aug 88 02:42:37 EDT (Sun)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA04652; 19 Aug 88 18:29:54 EDT (Fri)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA20837; Fri, 19 Aug 88 18:02:17 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA16034; Fri, 19 Aug 88 14:31:58 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    6979; Thu, 18 Aug 88 11:15:21 EDT
Received: by BITNIC (Mailer X1.25) id 2064; Thu, 18 Aug 88 11:13:03 EDT
Received: from CUNYVM.BITNET by UCF1VM.BITNET (Mailer X1.25) with BSMTP id
          1478; Wed, 17 Aug 88 22:48:47 EST
Received: from CUNYVM by CUNYVM.BITNET (Mailer X1.25) with BSMTP id 8612; Wed,
          17 Aug 88 22:44:55 EDT
Received: from decwrl.dec.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP;
          Wed, 17 Aug 88 22:44:45 EDT
Received: from gilroy.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34) id AA19585;
          Wed, 17 Aug 88 19:45:24 PDT
Received: from localhost by gilroy.pa.dec.com (5.54.5/4.7.34) id AA00422; Wed,
          17 Aug 88 19:45:22 PDT
Message-Id: <8808180245.AA00422@gilroy.pa.dec.com>
Date:         Wed, 17 Aug 88 19:45:20 -0700
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
From: rutgers!wsl.dec.com!haynes
Subject:      Re: Mesa
To: "(no name)" <decwrl.dec.com!info-modula-2>

Rion Cassidy writes

> gillies@p.cs.uiuc.edu writes:
>
>>When I first came to grad school, and began writing C code again, I
>>was unexpectedly disappointed.  I had grown used to a Modula-II like
>>language (MESA).  Some of the things that really bothered me about C
>>were:
>
>[complaints deleted]
>
>You didn't say where you learned Mesa, but since Xerox is the only
>place that uses it, I'd assume you came from there.
>
>Your comments are interesting because when I interveiwed with Xerox
>they said that Mesa was more like C than Pascal or M-2.
>
>Rion Cassidy
>rion@wdl1.arpa

As a former member of the Xerox Mesa Group, I'd like to know who told
you that! I want to laugh in their face. Modula-2 owes quite a bit to a
sabbatical that Niklaus Wirth spent at Parc. Modula-2 is at least a
nephew to Mesa, if not a direct decendant. Mesa's relationship to "C"?
Hostile? Nonexistant? I'm struggling for the appropriate word. Perhaps
"imagined" or "hallucinated" best describes their relationship.

    Charles "give-me-back-my-SIGNALs-and-MONITORs"  Haynes

uucp@wb3ffv.UUCP (08/23/88)

We have been unable to contact machine 'sarin' since you queued your job.

        sarin!mail eric   (Date 08/21)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:

        uustat -ksarinN0f02

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Sun Aug 21 07:12:01 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA03259; 21 Aug 88 07:12:01 EDT (Sun)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA09445; 19 Aug 88 22:37:07 EDT (Fri)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA22221; Fri, 19 Aug 88 18:36:32 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA18477; Fri, 19 Aug 88 15:08:23 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    7255; Thu, 18 Aug 88 11:46:18 EDT
Received: by BITNIC (Mailer X1.25) id 2198; Thu, 18 Aug 88 11:17:20 EDT
Return-Path: <editor%ucf1vm.BITNET%jade.berkeley.edu@CUNYVM.CUNY.EDU>
Received: from ucbvax.berkeley.edu by jade.berkeley.edu (5.54 (CFC
          4.22.3)/1.16.18B) id AA12380; Thu, 18 Aug 88 06:38:22 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA14748; Thu,
          18 Aug 88 06:21:58 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
          info-m2@ucf1vm.bitnet (info-modula-2@ucf1vm.bitnet) (contact
          usenet@ucbvax.Berkeley.EDU if you have questions)
Organization: Atari Corp., Sunnyvale, CA
References: <49@volition.dec.com>
Message-Id: <1120@atari.UUCP>
Date:         Tue, 16 Aug 88 21:56:34 GMT
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Comments:     Warning -- original Sender: tag was
              editor%ucf1vm.BITNET@JADE.BERKELEY.EDU
From: Ken Badertscher <rutgers!uunet.uu.net!kbad>
Subject:      Re: C vs. M2
Comments: To: info-modula-2@ucf1vm
To: "(no name)" <decwrl.dec.com!info-modula-2>

in article <49@volition.dec.com>, vixie@decwrl.dec.com (Paul Vixie) says:
> Yes, it's true, a good compiler will find the best way no matter how you
> say it.  But again, appearance gets my vote:
>
>       foo[i]->bar.size += newsize;
> vs.
>       foo[i].bar.count = foo[i].bar.count + newsize;
>
> I get to say what I mean.  Yes, I know about INCR, but this is only one case.

  Don't forget WITH!

        WITH foo[i].bar DO
                count = count + newsize
        END;

  Or even, since you mentioned it,

        WITH foo[i].bar DO INC(count,newsize) END;

  And to jump into the middle of the discussion, all I really have to add
is that Modula-2 "feels" a lot nicer to me.  The verbosity doesn't bother
me, as someone said, I find myself being more eloquent with the more
eloquent language.  I do think it is valid to compare the languages,
but many of the discussions I've ever read end up haggling over natty
details like case sensitivity and amount of typing (hmm... unintended
double entendre there, I initially meant "number of keystrokes", but
"strict type checking" applies as well ;-).
  I spent my software engineering "apprenticeship" helping build a set of
libraries for a Modula-2 environment, and I now find myself doing most
of my programming in C (not by choice, I assure you).  I miss the comforts
of strong type checking and DEFINITION MODULEs, and the rest.  Some find
it oppressive, I find it helpful.  And the bigger the program, the more
helpful it is, in my experience.

--
 Ken Badertscher                 | Hey, umm, the stuff I said up there
 Atari R&D Software Test/Support | is, like, what _I_ think, okay?
 {portal,ames,imagen}!atari!kbad | So, y'know, don't bug Atari about it.