🚀 go-pugleaf

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

        sarin!mail eric   (Date 08/23)
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 -ksarinN0f14

        Sincerely,
        wb3ffv!uucp

#############################################
##### Data File: ############################
>From aplcen!mimsy!rutgers!ucf1vm.bitnet!INFO-M2  Tue Aug 23 02:12:49 1988 remot
   e from wb3ffv
Received: by wb3ffv.UUCP (Smail-2.5)
        id AA00322; 23 Aug 88 02:12:49 EDT (Tue)
Received: by mimsy.UMD.EDU (smail2.5)
        id AA08848; 22 Aug 88 20:20:48 EDT (Mon)
Received: from AJPO.SEI.CMU.EDU by rutgers.edu (5.59/1.15)
        id AA14783; Mon, 22 Aug 88 20:18:04 EDT
Received: from cunyvm.cuny.edu by decwrl.dec.com (5.54.5/4.7.34)
        id AA00250; Mon, 22 Aug 88 16:25:45 PDT
Received: from BITNIC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id
    4992; Fri, 19 Aug 88 21:53:51 EDT
Received: by BITNIC (Mailer X1.25) id 1932; Fri, 19 Aug 88 21:45:39 EDT
Return-Path: aplcen!wb3ffv!uucp%mimsy.umd.edu@CUNYVM.CUNY.EDU
Received: from rutgers.edu by cancer.rutgers.edu via TCP; Fri Aug 19 11:11 EST
Received: by rutgers.edu (5.59/1.15) with UUCP id AA01519; Fri,
          19 Aug 88 11:11:17 EDT
Received: by mimsy.UMD.EDU (smail2.5) id AA09395; 19 Aug 88 01:38:13 EDT (Fri)
Received: by wb3ffv.UUCP (Smail-2.5) id AA14713; 18 Aug 88 23:58:48 EDT (Thu)
Message-Id: <8808182358.AA14713@wb3ffv.UUCP>
Date:         Fri, 19 Aug 88 21:00:48 EST
Reply-To: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
Sender: Info-Modula2 Distribution List <rutgers!ucf1vm.bitnet!INFO-M2>
From: rutgers!mimsy.umd.edu!uucp
Subject:      Warning From uucp
To: "(no name)" <decwrl.dec.com!info-modula-2>

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