Path: 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 ListOrganization: The Internet Lines: 120 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: 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 Sender: Info-Modula2 Distribution List 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)" 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++); /* */ } 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