Article View: comp.lang.modula2
Article #4384Warning From uucp
From: uucp
Date: Sat, 20 Aug 1988 02:00
Date: Sat, 20 Aug 1988 02:00
120 lines
5183 bytes
5183 bytes
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
Technical Details
Message-ID:
<8808182358.AA14689@wb3ffv.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att!ucbvax!wb3ffv.UUCP!uucpShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att!ucbvax!wb3ffv.UUCP!uucp From: uucp@wb3ffv.UUCP Newsgroups: comp.lang.modula2 Subject: Warning From uucp Message-ID: <8808182358.AA14689@wb3ffv.UUCP> Date: 20 Aug 88 02:00:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Info-Modula2 Distribution List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> Organization: The Internet Lines: 120