Date: Wed, 15 Nov 89 19:04:27 EST From: "Pandora B. Berman" Subject: Getting onto BUG-LOOP To: PIRINEN%csc.fi@KICKI.STACKEN.KTH.SE cc: BUG-LOOP%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <669809.891115.CENT@AI.AI.MIT.EDU> Date: Sat, 11 Nov 89 20:48 EET From: INTELLITECH Subject: Getting onto BUG-LOOP To: bug-loop-request@mc.lcs.mit.edu Please add us to the BUG-LOOP mailing list. Our InterNet address is: pirinen@csc.fi In case you're interested, IntelliTech is a finnish artificial intelligence company. We have built an implementation of Common Lisp for 386-based PCs, Entity Common Lisp. I would be thankful if you could help me in any way with the following questions: We have a copy of LOOP where the last change is: ;;; [jeff@palladian] 22-jul-87 19:44 Export loop-simple-error. There must be a newer version? Would it be available from MIT: ;;; The current version of this file will be maintained at MIT, available ;;; for anonymous FTP on MC.LCS.MIT.EDU from the file "LSB1;CLLOOP >". ;;; This location will no doubt change sometime in the future. Is the documentation situation still as follows? ;;; It is Technical Memo 169, "LOOP Iteration Macro", and is very old. ;;; The most up-to-date documentation on this version of LOOP is that ;;; in the NIL Reference Manual (TR-311 from LCS Publications); while ;;; you wouldn't I also have the document called "The Loop Facility" by Miller, Lyris and White, First Edition (May 1988), and copyrighted by Lucid, Inc. However, not only does it describe a version more advanced than what we actually have, but the copyright prevents us from sharing it with anybody else. Pekka P. Pirinen Director of R&D IntelliTech oy Hietalahdenkatu 2 B 14 SF-00180 HELSINKI FINLAND phone: +358 0 605604 fax: +358 0 603639 Bitnet: pirinen@finfun InterNet: pirinen@csc.fi PS. I sent a similar message to INFO-LOOP-REQUEST as well. BUG-LOOP and INFO-LOOP are pretty quiet if not entirely dead by now. i have added you to BUG-LOOP. BUG-LOOP is too old and specialized a list to have its own auxiliary -REQUEST list; your mail to BUG-LOOP-REQUEST was therefore diverted to a generic BUG- list, which exists so that any mail which might concern possibly (serious) bugs will be seen by someone. i enclose your full msg so that the BUG-LOOP folks might be able to answer your questions.  Date: Tue, 7 Feb 89 03:18:56 EST From: "Pandora B. Berman" Subject: The INFO-LOOP mailing list To: "IDA.LIU.SE!UDA@KICKI.STACKEN.KTH.EDU"@AI.AI.MIT.EDU cc: BUG-LOOP@AI.AI.MIT.EDU Message-ID: <533460.890207.CENT@AI.AI.MIT.EDU> Date: Wed, 18 Jan 89 20:52:46 +0100 From: Ulf Dahlen To: postmaster@MC.LCS.MIT.EDU Subject: The INFO-LOOP mailing list Sorry to bother you, but: Is there supposed to be a INFO-LOOP mailing list at MC.LCS.MIT.EDU? I have trouble getting the message below through (I get a "unknown recipient" error message from COMSAT@MC.LCS.MIT.EDU). However, my add request for the BUG-LOOP mailing list seems to have been successful (it was addressed to BUG-LOOP-REQUEST). ----- [your erring msg removed] you're a little confused. just because a mailing list exists doesn't mean that there is an auxiliary -REQUEST list. -REQUEST lists generally exist only for large, heavily used lists with many list members at foriegn sites, from which they can't add/change/remove their own addresses on the lists. there is no BUG-LOOP-REQUEST list; however, your mail to that address did reach some people here due to a feature in COMSAT, our mailer. this feature works as follows: any mailing list which begins BUG- is considered important, because historically BUG-BAZ was the list of people who fixed BAZ (the Baz hardware or the BAZ program or whatever BAZ happened to be). but sometimes folks would send mail to BUG-BAZ when no list of that particular name existed. so to make sure -someone- responsible saw the mail, and either fixed the problem him/herself or forwarded the complaint to where it should have been sent, the COMSAT hackers included a special catch-all for addresses beginning with BUG-. when no explicit address BUG-BAZ exists, all mail addressed to BUG-BAZ is sent to this catch-all address. that is where your mail to BUG-LOOP-REQUEST went, because although there is no list of that name, that address does begin with BUG-. similarly, there is no INFO-LOOP-REQUEST. and since that address does not begin with BUG-, COMSAT's special BUG- kludge is not invoked by mail to that address; instead, COMSAT looked for the address, didn't find it, and therefore returned the mail to you indicating an unknown address. i have added you to BUG-LOOP and INFO-LOOP. my understanding is that these are not high traffic lists, so you should not be surprised if this results in no mail for you.  Date: Fri, 13 Jan 89 01:59:05 EST From: "Pandora B. Berman" Subject: add req?? To: BUG-LOOP@AI.AI.MIT.EDU Message-ID: <519142.890113.CENT@AI.AI.MIT.EDU> Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 9 Jan 89 08:32:23 EST Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 9 Jan 89 08:22:54 EST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA21726; Mon, 9 Jan 89 08:21:22 EST Received: by mcvax.cwi.nl via EUnet; Mon, 9 Jan 89 14:09:09 +0100 (MET) Received: from kth.se by enea.se (5.57++/1.90) via EUnet id AA26247; Mon, 9 Jan 89 13:16:59 +0100 (MET) Received: from majestix.ida.liu.se ([130.236.30.102]) by kth.se (5.57+IDA+KTH/3.0) id AA24058; Mon, 9 Jan 89 13:14:14 +0100 Received: by majestix.ida.liu.se; Mon, 9 Jan 89 13:20:35 +0100 Date: Mon, 9 Jan 89 13:20:35 +0100 From: Ulf Dahlen Message-Id: <8901091220.AA21483@majestix.ida.liu.se> To: BUG-LOOP-REQUEST@MC.LCS.MIT.EDU Subject: Add request Would you please add me to the BUG-LOOP mailing list. __________ Ulf Dahlen Dept of Computer & Info Science, University of Linkoping, Sweden Troskaregatan 51:23 | uda@ida.liu.se S-583 30 LINKOPING | uda@majestix.liu.se, uda@majestix.UUCP SWEDEN | {mcvax,munnari,seismo}!enea!liuida!uda "The beginning is a very delicate time." does BUG-LOOP even function any more?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Dec 87 12:48:33 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 8 Dec 87 12:41:05 EST Received: from VERMITHRAX.SCH.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 297837; 8 Dec 87 12:03:54 EST Received: from BINKLEY.SCH.Symbolics.COM by VERMITHRAX.SCH.Symbolics.COM via CHAOS with CHAOS-MAIL id 104675; Tue 8-Dec-87 09:01:28 PST Date: Tue, 8 Dec 87 09:02 PST From: kao@VERMITHRAX.SCH.Symbolics.COM Subject: definition of ELEMENTS loop iteration path To: GSB%Jasper%LIVE-OAK.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Bug-Symbolics-software%JASPER.PALLADIAN.COM@STONY-BROOK.SCRC.Symbolics.COM, Customer-reports@VERMITHRAX.SCH.Symbolics.COM cc: bug-loop%mc.lcs.mit.edu@STONY-BROOK.SCRC.Symbolics.COM, moon%stony-brook.scrc.symbolics.com@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <871206012648.3.GSB@DWORKIN.PALLADIAN.COM> Message-ID: <871208090245.7.KAO@BINKLEY.SCH.Symbolics.COM> Date: Sun, 6 Dec 87 01:26 EST From: Glenn S. Burke Thanks for your time and thought. Your message had been forwarded to our developers. Unfortunately, according to them, we do not currently plan to do any future enhancements to the LOOP macro. Instead, we plan to implement a new CL iteration standard when it becomes available. The definition of the ELEMENTS loop iteration path by the compiler (implemented by compiler::elements-path, q.v.) is very poor for a number of reasons. First and foremost, LOOP iteration paths are not package specific. As a consequence of this, the path named ELEMENTS, as implemented, is being imposed upon all users. Besides being a "good" name, it is being assigned semantics contrary to what it should have had, historically. The ELEMENTS iteration path is for iterating over sequences (in the Common Lisp sense) -- objects accessed sequentially using ELT. Examination of your copy of the LOOP source will even show the ELEMENTS path being defined, but conditionalized only for NIL: the last source split for LOOP predates the finalization of common lisp sequence functions, if not the existence of any generic sequence accessor, in your lisp -- otherwise it would already be defined. Secondly, the use of the preposition USING by this iteration path, while not technically incorrect, is stylistically poor on two grounds: (a) USING already has a special meaning in iteration paths, with a different syntax (b) there is already a way to do what is trying to be done -- using USING no less. The correct way to do this is to eliminate all support for the USING preposition from the code, and then get the name of the variable to be iterated over by doing (SI:LOOP-NAMED-VARIABLE 'LIST) Then, the syntax for iterating over a list and using "L" as the list variable is (LOOP FOR X BEING THE ELEMENTS OF (COMPUTE) USING (LIST L) ...) Precedent for this does already exist in the Symbolics version of LOOP under the ARRAY-ELEMENTS path [conceptually a specialization of the generic sequence ELEMENTS path to vectors!], in which one can specify the names of the array being iterated over, and the current index, with the keywords SEQUENCE and INDEX respectively: (LOOP FOR X BEING THE ARRAY-ELEMENTS OF (MUMBLE) USING (SEQUENCE A) (INDEX I) ...) ---------------- For the record, I will point out that this is NOT something which is causing us a problem. I simply feel that having the ELEMENTS path available to users with such poor syntax and semantics is a bad idea and should be corrected. And lest someone bring it up, I am aware there are arguments for making loop iteration paths package-sensitive. There are some arguments against also.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Dec 87 02:15:57 EST Received: from LIVE-OAK.LCS.MIT.EDU (CHAOS 30303) by MC.LCS.MIT.EDU 6 Dec 87 02:11:04 EST Received: from JASPER.Palladian.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 70708; 6 Dec 87 02:07:29-EST Received: from DWORKIN.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 15960; 6 Dec 87 01:27:22-EST Date: Sun, 6 Dec 87 01:26 EST From: Glenn S. Burke Subject: definition of ELEMENTS loop iteration path To: Bug-Symbolics-software@JASPER.PALLADIAN.COM cc: bug-loop@mc.lcs.mit.edu, moon@stony-brook.scrc.symbolics.com Message-ID: <871206012648.3.GSB@DWORKIN.PALLADIAN.COM> Reply-To: Glenn S. Burke In Symbolics 3640 Symbolics-software in Genera 7.1, IP-TCP 52.16, 7-1-Patches 1.33, Hu-Kwa 5.1, Advisor Core 71.0, Extended Common Lisp 95.0, Apollo Foreign 65.0, IO 88.0, Advisor Preamble 85.0, Database 94.1, Control 90.0, Graphics 85.0, Help Prelude 59.0, Image 84.0, Presentation Core 66.0, Presentation Objects 66.4, Explanation 84.0, Help 82.0, Corporation 79.0, Reports 79.0, Hardcopy Help 36.0, Advisor Control 81.0, Advisor Goals 82.0, Advisor Presentations 78.0, Advisor Postamble 77.0, Operations Advisor 69.0, Operations Advisor First 83.0, Operations Advisor Data 81.0, Core Graphical Editor 67.0, Operations Advisor Graphical Editor 88.0, Operations Advisor Reports 72.0, Operations Advisor Rules 73.0, Operations Advisor Input 74.1, Operations Advisor Heuristics 72.2, Operations Advisor Analysis 75.1, Operations Advisor Simulator 77.0, Operations Advisor Tours 72.0, Operations Advisor Interpretation 72.0, Operations Advisor Icon editor 83.0, Operations Advisor Postamble 71.0, microcode 3640-MIC 396, FEP 127, FEP0:>v127-lisp.flod(55), FEP0:>v127-loaders.flod(55), FEP0:>v127-debug.flod(34), FEP0:>v127-info.flod(55), FEP0:>v127-tests.flod(55), Machine serial number 5371, fix swelling itching brain (from J:>gsb>glenns-rel7-therapy.lisp.1), on Dworkin: Processes forcibly aborted: ZMACS-WINDOWS aborted with the following warning: Flavor data structures are being updated to define (FLAVOR:METHOD :DIRECTORY-COMMAND TCP-FTP-FILE-ACCESS-PATH). Aborting this could damage the flavor TCP-FTP-FILE-ACCESS-PATH and its dependents. The definition of the ELEMENTS loop iteration path by the compiler (implemented by compiler::elements-path, q.v.) is very poor for a number of reasons. First and foremost, LOOP iteration paths are not package specific. As a consequence of this, the path named ELEMENTS, as implemented, is being imposed upon all users. Besides being a "good" name, it is being assigned semantics contrary to what it should have had, historically. The ELEMENTS iteration path is for iterating over sequences (in the Common Lisp sense) -- objects accessed sequentially using ELT. Examination of your copy of the LOOP source will even show the ELEMENTS path being defined, but conditionalized only for NIL: the last source split for LOOP predates the finalization of common lisp sequence functions, if not the existence of any generic sequence accessor, in your lisp -- otherwise it would already be defined. Secondly, the use of the preposition USING by this iteration path, while not technically incorrect, is stylistically poor on two grounds: (a) USING already has a special meaning in iteration paths, with a different syntax (b) there is already a way to do what is trying to be done -- using USING no less. The correct way to do this is to eliminate all support for the USING preposition from the code, and then get the name of the variable to be iterated over by doing (SI:LOOP-NAMED-VARIABLE 'LIST) Then, the syntax for iterating over a list and using "L" as the list variable is (LOOP FOR X BEING THE ELEMENTS OF (COMPUTE) USING (LIST L) ...) Precedent for this does already exist in the Symbolics version of LOOP under the ARRAY-ELEMENTS path [conceptually a specialization of the generic sequence ELEMENTS path to vectors!], in which one can specify the names of the array being iterated over, and the current index, with the keywords SEQUENCE and INDEX respectively: (LOOP FOR X BEING THE ARRAY-ELEMENTS OF (MUMBLE) USING (SEQUENCE A) (INDEX I) ...) ---------------- For the record, I will point out that this is NOT something which is causing us a problem. I simply feel that having the ELEMENTS path available to users with such poor syntax and semantics is a bad idea and should be corrected. And lest someone bring it up, I am aware there are arguments for making loop iteration paths package-sensitive. There are some arguments against also.  Date: Sun, 5 Jul 87 17:14:42 EDT From: Alan Bawden Subject: Loop Macro (after Zetalisp, Franz, etc.) To: BUG-LOOP@AI.AI.MIT.EDU, AI.BOYER@MCC.COM cc: jeff%JASPER@LIVE-OAK.LCS.MIT.EDU In-reply-to: Msg of Sat 4 Jul 87 16:51:05-CDT from Bob Boyer Message-ID: <223711.870705.ALAN@AI.AI.MIT.EDU> Date: Sat 4 Jul 87 16:51:05-CDT From: Bob Boyer To: jeff at JASPER, info-loop at MC Send bug reports to BUG-LOOP, not INFO-LOOP. The former reaches the maintainers, the latter is supposed to reach the users, and it is the maintainers that you want, right? The file gsb;cloop at ai.ai.mit.edu "CLLOOP" with two "L"s. contains some garbage that prevents it from being readable in several Common Lisps that I have tried. It looks like a comment editing sessions went poorly. Is there another place to get this file? Specifically, it has unbalanced parenthesis near the end of the file (in the definition of DEFINE-LOOP-SEQUENCE-PATH). It does looks like incompetent editing took place. The file was created on March 12 of this year, if that helps any.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Mar 87 14:15:35 EST Received: from ML.AI.MIT.EDU (CHAOS 3133) by MC.LCS.MIT.EDU 19 Mar 87 14:04:50 EST Received: from MC.LCS.MIT.EDU (CHAOS 3131) by ML.AI.MIT.EDU 19 Mar 87 13:16:38 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 19 Mar 87 12:42:12 EST Received: from HNYKUN53(DESMEDT) by MITVMA (Mailer X1.23) id 3950; Thu, 19 Mar 87 05:19:33 EST Date: Thu, 19 Mar 87 11:06 N From: Subject: loop for Common Lisp To: bug-loop@mit-ml.mit.edu X-Original-To: "bug-loop@mit-ml.mit.edu" To: bug-loop@mit-ml.mit.edu Subject: loop for Common Lisp Is there a version of the LOOP macro for Common LISP which is entirely machine-independent? K.  Date: Thu, 12 Mar 87 06:03:44 EST From: "Glenn S. Burke" Subject: common lisp loop To: yduJ@SPAR-20.ARPA cc: BUG-LOOP@AI.AI.MIT.EDU, ALAN@AI.AI.MIT.EDU Message-ID: <167208.870312.GSB@AI.AI.MIT.EDU> I seem to have successfully transferred the Common-lisp loop from Palladian to herre. It may be found in the file GSB;CLLOOP > I have not checked for character translations or transmission errors...  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 MAR 87 20:44:49 EST Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 27559; Tue 10-Mar-87 20:43:30 EST Date: Tue, 10 Mar 87 20:43 EST From: Chris Lindblad Subject: [AKBARI@CS.COLUMBIA.EDU: cl loop macro] To: bug-loop@AI.AI.MIT.EDU Message-ID: <870310204320.7.CJL@OTIS.AI.MIT.EDU> Return-path: <@ZERMATT.LCS.MIT.EDU,@R20.UTEXAS.EDU:CMP.SLUG@R20.UTEXAS.EDU> Received: from ZERMATT.LCS.MIT.EDU (ZERMATT.LCS.MIT.EDU) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 27550; 10 Mar 87 19:34:23 EST Received: from R20.UTEXAS.EDU (R20.UTEXAS.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 35672; 10 Mar 87 19:33:16 EST Return-Path: Received: from CS.COLUMBIA.EDU by R20.UTEXAS.EDU with TCP; Tue 10 Mar 87 13:42:12-CST Date: Tue 10 Mar 87 14:40:56-EST From: John C. Akbari Subject: cl loop macro To: slug@R20.UTEXAS.EDU Message-ID: <12285331398.45.AKBARI@CS.COLUMBIA.EDU> ReSent-Date: Tue 10 Mar 87 16:10:24-CST ReSent-From: CMP.SLUG@R20.UTEXAS.EDU ReSent-To: SLUG: ; ReSent-Message-ID: <12285358607.16.CMP.SLUG@R20.UTEXAS.EDU> anyone have a (relatively) complete implementation of the symbolics common lisp LOOP macro? ad...THANKS...vance! john c akbari ARPANET & Internet akbari@CS.COLUMBIA.EDU BITnet akbari%CS.COLUMBIA.EDU@WISCVM.WISC.EDU uucp & usenet ...!seismo!columbia!cs!akbari DECnet akbari@cs PaperNet 380 riverside drive, no. 7d new york, new york 10025 usa SoundNet 212.662.2476 -------  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 NOV 86 13:33:20 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 11350; Fri 14-Nov-86 13:28:06 EST Date: Fri, 14 Nov 86 13:28 EST From: Alan Bawden Subject: [AI.BOYER@MCC.COM: sloop] To: Bug-LOOP@AI.AI.MIT.EDU Message-ID: <861114132811.6.ALAN@PIGPEN.AI.MIT.EDU> If someone doesn't do something about cleaning up the original LOOP and announcing its availability soon... (The implication that LOOP is under an "MIT or lisp machine company copyright claim" seems to be a common impression that won't be cleared up by anything other than an available LOOP.) Date: Fri, 14 Nov 1986 11:52 CST Message-ID: From: AI.BOYER@MCC.COM To: common-lisp@su-ai Subject: sloop Bill Schelter has produced a lovely Common Lisp substitute for the Maclisp/Zetalisp loop construct called sloop. It is mostly upwards compatible with loop. This note describes where to get it, what's new, etc. Fahlman observes that any detailed discussion of the merits of this package should be directed to the cl-iteration mailing list. Sloop sources may be found in the file sloop.lisp on utexas-20.edu. The code is free. It was written by Schelter from scratch and is hence definitely free of any MIT or lisp machine company copyright claim. Like the original I.S.OPR facility in Interlisp, the sloop construct permits the addition of new "collection" type operators; for example, an averaging operation is defined. A very general facility different from that of loop's has been implemented to provide user extensible iteration paths. One can map over tree fringes, Common Lisp hash tables, or packages, e.g. (sloop for sym in-package 'user when (fboundp sym) collect sym). A "cross-product" concept has been added. Instead of writing something like: (loop for x in (l1) nconc (loop for y in (l2) collect (fn x y))) one may write: (sloop for x in (l1) sloop (for y in (l2) collect (fn x y))) Only one "collection site" is created and used during these two nested iterations. Like the original loop, sloop takes advantage of locatives to do collection more efficiently when they are available, e.g., on MIT type lisp machines. Sloop has been run in at least four dialects of Common Lisp on three different kinds of machines. I believe Schelter is definitely interested in reports of bugs and suggestions for improvements. Mail will reach him at atp.schelter@utexas-20.edu or at the Mathematics Department, University of Texas at Austin, Austin, Texas 78712.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 OCT 86 16:54:31 EDT Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 OCT 86 16:52:53 EDT Received: from MC.LCS.MIT.EDU by ML.AI.MIT.EDU via Chaosnet; 25 OCT 86 16:52:20 EDT Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 OCT 86 16:52:37 EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 14326; 25 Oct 86 16:49:48-EDT Received: from DWORKIN.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 17201; 25 Oct 86 16:16:35-EDT Date: Sat, 25 Oct 86 16:15 EDT From: Glenn S. Burke Subject: why do i have to enter a subject field? To: ALAN%ML.AI.MIT.EDU@MC.LCS.MIT.EDU, BUG-LOOP%ML.AI.MIT.EDU@MC.LCS.MIT.EDU cc: gsb@JASPER.Palladian.COM In-Reply-To: <[ML.AI.MIT.EDU].1629.861025.ALAN> Message-ID: <861025161520.2.GSB@DWORKIN.Palladian.COM> Reply-To: Glenn S. Burke Date: Sat, 25 Oct 86 15:58:04 EDT From: Alan Bawden It would be nice if there was a loop cliche like THEREIS that didn't go to the trouble to preserve the non-nil value that causes the loop to terminate (but did return -something- non-nil, unlike UNTIL). Trivial to implement, painful to name...  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 OCT 86 16:00:10 EDT Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 OCT 86 15:58:35 EDT Date: Sat, 25 Oct 86 15:58:04 EDT From: Alan Bawden To: BUG-LOOP%ML.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[ML.AI.MIT.EDU].1629.861025.ALAN> It would be nice if there was a loop cliche like THEREIS that didn't go to the trouble to preserve the non-nil value that causes the loop to terminate (but did return -something- non-nil, unlike UNTIL).  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 AUG 86 01:59:24 EDT Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 AUG 86 01:58:51 EDT Received: from AI.AI.MIT.EDU by ML.AI.MIT.EDU via Chaosnet; 10 AUG 86 01:58:35 EDT Date: Sun, 10 Aug 86 01:59:11 EDT From: Alan Bawden Subject: idea To: BUG-LOOP@ML.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].81602.860810.ALAN> There should be an iteration path for the successive macroexpansions of a form.  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 19 Dec 85 20:33:29 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 379086; Thu 19-Dec-85 20:31:13-EST Date: Thu, 19 Dec 85 20:25 EST From: David A. Moon Subject: Is loop public domain? To: Don Cohen cc: bug-loop@MIT-MC.ARPA, vrotney@ISI-VAXA.ARPA In-Reply-To: <8512192340.AA10848@isi-vaxa.ARPA> Message-ID: <851219202520.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 19 Dec 1985 1540-PST (Thursday) From: donc@isi-vaxa.ARPA (Don Cohen) Is the loop macro (and its source) public domain? Yes. You can copy it from MIT-MC: LSB1; LOOP >. What you get is, of course, unsupported, taken "as is", and not guaranteed to do the same thing as anything anybody else has that they call "loop".  Received: from isi-vaxa.ARPA by MC.LCS.MIT.EDU 19 Dec 85 18:41:44 EST Received: by isi-vaxa.ARPA (4.12/4.7) id AA10848; Thu, 19 Dec 85 15:40:38 pst From: donc@isi-vaxa.ARPA (Don Cohen) Message-Id: <8512192340.AA10848@isi-vaxa.ARPA> Date: 19 Dec 1985 1540-PST (Thursday) To: bug-loop@mit-mc.ARPA Cc: vrotney@isi-vaxa.ARPA Subject: Is loop public domain? Is the loop macro (and its source) public domain? If not, what do I have to do to (legally) use it on some machine that does not yet have it?  Received: from MIT-CORWIN by MIT-MC.ARPA via Chaosnet; 17 OCT 85 00:16:35 EDT Date: Thu, 17 Oct 85 00:19:06 EDT From: Glenn S. Burke To: bug-loop@mit-mc Subject: USING again Reply-to: gsb@mit-mc Maybe USING should take multiple pairs only if joined by AND. (This to get around the business of it screwing the implicit DO.) Any opinions?  Date: Fri, 4 Oct 85 23:05:42 EDT From: Alan Bawden Subject: book 2, page 222 (whatever that is --gsb) To: RSL@SCRC-STONY-BROOK.ARPA cc: BUG-LOOP@MIT-MC.ARPA, GSB@MIT-MC.ARPA, Bug-Documentation@SCRC-STONY-BROOK.ARPA, Lisp-Designers@SCRC-STONY-BROOK.ARPA, Margulies@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Fri 4 Oct 85 14:51 PDT from Richard Lamson Message-ID: <[MIT-MC.ARPA].669136.851004.ALAN> Date: Fri, 4 Oct 85 14:51 PDT From: Richard Lamson Date: Fri, 4 Oct 85 16:07:59 EDT From: Alan Bawden ... For example: (loop for a being the array-elements of q using (index ai) collecting (lambda (x) (when (> x a) (aset x q ai)))) In my opinion this should work as the writer clearly intended it to.... It's conceivable that you might want to write such a loop which didn't re-bind the variables, but rather created closures all of which shared the variable. If you want the effect you require, you can say (loop for a being the array-elements of q using (index ai) collecting (let ((a a) (ai ai)) #'(lambda (x) (when (> x a) (aset x q ai))))) If you require that the description above work the way you want, there is no way to write a loop which does what I (might) want, namely that all the closures use the same variable. [An example of a fragment of code you might want to do this with: (loop for a being the array-elements of q using (index free-element) while a collecting #'(lambda (x) (push x (aref q free-element)))) I don't claim this is completely clear, just that it has useful semantics.] First off, as Moon points out, there is nothing that prevents you from binding a variable outside the loop. Secondly, I don't understand your example. Is that really supposed to be a plausible fragment of code? It seems to me to be nonsense to produce a list of identically behaving closures. But perhaps it isn't importatnt that your example be plausible. Thirdly, in deciding what it means to close over a variable of iteration, isn't the -clarity- of the code precisely the issue? I claim that in my example it is completely and straightforwardly clear how those closures should behave. In your example I haven't the slightest idea what the value of FREE-ELEMENT is in the resulting closure(s). Is it one less than the length of the array? Or is it the length of the array? Again, on a painful case-by-case basis you have to decide what the value of the variable is -after- the loop has exited.  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 4 Oct 85 18:14:27 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 327076; Fri 4-Oct-85 18:12:15-EDT Date: Fri, 4 Oct 85 18:11 EDT From: David A. Moon Subject: book 2, page 222 (whatever that is --gsb) To: RSL@SCRC-STONY-BROOK.ARPA cc: Alan Bawden , GSB@MIT-MC.ARPA, BUG-LOOP@MIT-MC.ARPA, Bug-Documentation@SCRC-STONY-BROOK.ARPA, Lisp-Designers@SCRC-STONY-BROOK.ARPA, Margulies@SCRC-STONY-BROOK.ARPA In-Reply-To: <851004145136.6.RSL@STHENO.SSF.Symbolics.COM> Message-ID: <851004181129.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 4 Oct 85 14:51 PDT From: Richard Lamson It's conceivable that you might want to write such a loop which didn't re-bind the variables, but rather created closures all of which shared the variable. If you want the effect you require, you can say (loop for a being the array-elements of q using (index ai) collecting (let ((a a) (ai ai)) #'(lambda (x) (when (> x a) (aset x q ai))))) If you require that the description above work the way you want, there is no way to write a loop which does what I (might) want, namely that all the closures use the same variable. [An example of a fragment of code you might want to do this with: (loop for a being the array-elements of q using (index free-element) while a collecting #'(lambda (x) (push x (aref q free-element)))) I don't claim this is completely clear, just that it has useful semantics.] No way? If the trick of introducing a let works to turn case 1 into case 2, the trick of introducing a setq must work to turn case 2 into case 1. Thus: (let (free-element) (loop for a being the array-elements of q using (index i) while a do (setq free-element i) collecting #'(lambda (x) (push x (aref q free-element)))))  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 4 Oct 85 17:57:37 EDT Received: from CERRIDWYN.SSF.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 327056; Fri 4-Oct-85 17:52:23-EDT Received: from STHENO.SSF.Symbolics.COM by CERRIDWYN.SSF.Symbolics.COM via CHAOS with CHAOS-MAIL id 48970; Fri 4-Oct-85 14:51:56-PDT Date: Fri, 4 Oct 85 14:51 PDT From: Richard Lamson Subject: book 2, page 222 (whatever that is --gsb) To: Alan Bawden , GSB@MIT-MC.ARPA cc: BUG-LOOP@MIT-MC.ARPA, Bug-Documentation@SCRC-STONY-BROOK.ARPA, Lisp-Designers@SCRC-STONY-BROOK.ARPA, Margulies@SCRC-STONY-BROOK.ARPA In-Reply-To: <[MIT-MC.ARPA].668707.851004.ALAN> Message-ID: <851004145136.6.RSL@STHENO.SSF.Symbolics.COM> Reply-To: RSL@SCRC-STONY-BROOK.ARPA Date: Fri, 4 Oct 85 16:07:59 EDT From: Alan Bawden Date: Fri, 4 Oct 85 03:31:07 EDT From: Glenn S. Burke Date: Wed, 18 Sep 85 15:04 EDT From: Benson I. Margulies ... Is it legitimate to setq a USING variable of a path? Particularly the INDEX variable of the sequence paths. The answer to this question should be in the documentation. For that matter, I'm pretty curious myself. In general, it should not be legal to modify a USING variable in a LOOP iteration. I could imagine that the legality of this could be well-defined for the particular USING variables of particular iteration paths, but that's getting pretty heavily specified and maybe too restricting to any given implementation. [What did everyone else say? This *IS* a topic for bug-loop you know.] A related issue that I remember coming up in the context of DOLIST and DOTIMES is what to do about closures created on one turn of a loop that make free reference to iteration driving and driven variables. For example: (loop for a being the array-elements of q using (index ai) collecting (lambda (x) (when (> x a) (aset x q ai)))) In my opinion this should work as the writer clearly intended it to. The result should be a list of closures, each of which has accesses a different element of the array. Each time around the loop A and AI should be "fresh" variables bound to the fresh values. It's conceivable that you might want to write such a loop which didn't re-bind the variables, but rather created closures all of which shared the variable. If you want the effect you require, you can say (loop for a being the array-elements of q using (index ai) collecting (let ((a a) (ai ai)) #'(lambda (x) (when (> x a) (aset x q ai))))) If you require that the description above work the way you want, there is no way to write a loop which does what I (might) want, namely that all the closures use the same variable. [An example of a fragment of code you might want to do this with: (loop for a being the array-elements of q using (index free-element) while a collecting #'(lambda (x) (push x (aref q free-element)))) I don't claim this is completely clear, just that it has useful semantics.]  Date: Fri, 4 Oct 85 16:07:59 EDT From: Alan Bawden Subject: book 2, page 222 (whatever that is --gsb) To: GSB@MIT-MC.ARPA cc: BUG-LOOP@MIT-MC.ARPA, Bug-Documentation@SCRC-STONY-BROOK.ARPA, Lisp-Designers@SCRC-STONY-BROOK.ARPA, Margulies@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Fri 4 Oct 85 03:31:07 EDT from Glenn S. Burke Message-ID: <[MIT-MC.ARPA].668707.851004.ALAN> Date: Fri, 4 Oct 85 03:31:07 EDT From: Glenn S. Burke Date: Wed, 18 Sep 85 15:04 EDT From: Benson I. Margulies ... Is it legitimate to setq a USING variable of a path? Particularly the INDEX variable of the sequence paths. The answer to this question should be in the documentation. For that matter, I'm pretty curious myself. In general, it should not be legal to modify a USING variable in a LOOP iteration. I could imagine that the legality of this could be well-defined for the particular USING variables of particular iteration paths, but that's getting pretty heavily specified and maybe too restricting to any given implementation. [What did everyone else say? This *IS* a topic for bug-loop you know.] A related issue that I remember coming up in the context of DOLIST and DOTIMES is what to do about closures created on one turn of a loop that make free reference to iteration driving and driven variables. For example: (loop for a being the array-elements of q using (index ai) collecting (lambda (x) (when (> x a) (aset x q ai)))) In my opinion this should work as the writer clearly intended it to. The result should be a list of closures, each of which has accesses a different element of the array. Each time around the loop A and AI should be "fresh" variables bound to the fresh values. Why do I bring this up in the current context? Because if you agree with me about how this should work, it follows that a SETQ of the variables in question -must not- effect the course of the iteration. To clarify my position further: There are -four- positions you can take about Benson's original question: 1. It is an error to SETQ a variable of iteration. The compiler should issue a warning if you do so. 2. It is undefined what happens when you SETQ a variable of iteration. The behavior is subject to change without notice. 3. It is legitimate to SETQ a variable of iteration. However, to do so will not effect the course of the iteration in any way. 4. It is legitimate to SETQ a variable of iteration. To do so will cause the course of the iteration to change "accordingly". I hold position 3. GSB was arguing against position 4, by correctly noting that the implementation of "accordingly" has to be done on a painful case-by-case basis. I would argue that position 2 is just a cop-out, I only mentioned it in an attempt at completeness. If an implementation cannot support position 3, then it should adopt position 1. (Note that it is an upward-compatible change to go anywhere from position 1.)  Date: Fri, 4 Oct 85 03:31:07 EDT From: Glenn S. Burke Subject: book 2, page 222 (whatever that is --gsb) To: Margulies@SCRC-YUKON.ARPA cc: BUG-LOOP@MIT-MC.ARPA, Bug-Documentation@SCRC-YUKON.ARPA, Lisp-Designers@SCRC-YUKON.ARPA Message-ID: <[MIT-MC.ARPA].668430.851004.GSB> Date: Wed, 18 Sep 85 15:04 EDT From: Benson I. Margulies Resent-To: gsb@MIT-MC.ARPA Resent-From: Moon@SCRC-STONY-BROOK.ARPA Resent-Date: Wed, 18 Sep 85 19:52 EDT Resent-Message-ID: <850918195204.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Resent-Comments: Any comments on this? . . . Is it legitimate to setq a USING variable of a path? Particularly the INDEX variable of the sequence paths. The answer to this question should be in the documentation. For that matter, I'm pretty curious myself. The interesting case is this: (loop for a being the array-elements of q using (index ai) do (if (skip-predicate a) (incf ai) ..operate on a..)) ---- In general, it should not be legal to modify a USING variable in a LOOP iteration. I could imagine that the legality of this could be well-defined for the particular USING variables of particular iteration paths, but that's getting pretty heavily specified and maybe too restricting to any given implementation. [What did everyone else say? This *IS* a topic for bug-loop you know.]  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 1 SEP 85 14:29:41 EDT Received: from MIT-MOON by MIT-OZ via Chaosnet; 1 Sep 85 14:29-EDT Date: Sun, 1 Sep 85 14:31 EDT From: Alan Bawden Subject: Yuck To: Bug-LOOP@MIT-MC.ARPA Message-ID: <850901143120.1.ALAN@MOON> While randomly perusing the Symbolics documentation I happened to read a section about tools for showing the results of macroexpansion. Guess what the example they use is. Right. Here we find enshrined forever the wisdom that "the only way you can debug code written with LOOP is to macroexpand it first". Foo.  Date: 6 February 1985 15:17-EST From: Alan Bawden Subject: LOOP has fans in the Common Lisp community To: BUG-LOOP @ MIT-MC Date: 05 Feb 85 14:00:37 PST (Tue) From: Steve Smith To: AIList Re: LOOP macro under CommonLisp Has anybody hacked up the old MIT Loop macro to work under vanilla CommonLisp (eg. DEC's CommonLisp)? --Steve Smith (ssmith%nrtc@usc-ecl)  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 149615; Thu 27-Dec-84 13:27:54-EST Date: Thu, 27 Dec 84 13:27 EST From: "David A. Moon" Subject: implicit DO To: GSB@MIT-MC.ARPA cc: BUG-LOOP@MIT-MC.ARPA In-Reply-To: The message of 16 Dec 84 02:08-EST from Grandiose S. Building Message-ID: <841227132722.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 16 Dec 84 02:08:29 EST From: Grandiose S. Building Implying "do" when a non-atomic form appears screws the USING kludge, which needs a keyword to terminate... I.e., (loop for x being the elements of a using (index i) (when ...)) gets upset about the WHEN form. I didn't know USING swallowed multiple lists. That's disgusting. It should swallow a single list with multiple pairs in it. Actually I think USING is poor syntax and instead one should be able to write (loop for x being the elements of a index i ...)  Date: Sun, 16 Dec 84 02:08:29 EST Sent-By: GSB To: BUG-LOOP@MIT-MC Subject: implicit DO Reply-To: GSB @ MIT-MC From: Grandiose S. Building Implying "do" when a non-atomic form appears screws the USING kludge, which needs a keyword to terminate... I.e., (loop for x being the elements of a using (index i) (when ...)) gets upset about the WHEN form. Just thought i'd point this out for future reference.  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 112144; Sat 20-Oct-84 23:05:09-EDT Date: Saturday, 20 October 1984, 23:02-EDT From: David A. Moon Subject: [rwg: LOOP again] To: Alan Bawden , Bug-LOOP at MIT-MC In-Reply-To: The message of 15 Oct 84 23:14-EDT from Alan Bawden Message-ID: <841020230255.3.MOON@EUPHRATES.SCRC.Symbolics> Date: Monday, 15 October 1984 23:14-EDT From: Alan Bawden I think this is yet another example of the screw I complained about in my previous messages to Bug-LOOP two or three years ago. I know this isn't news to anybody on Bug-LOOP, but its probably usefull to have a few of these screws in the archives so that they can be used as test examples for the "New LOOP System". Date: Saturday, 13 October 1984, 00:30-PDT From: Bill Gosper To: lisp-designers at SPA-NIMBUS cc: ddyer at SPA-NIMBUS Re: LOOP again I was fooling around trying to bum DDYER's (defmethod (graphics-mixin :triangulate-simple-polygon) (message alu &rest points) (loop with p = points and x1 and y1 and x2 and y2 and x3 and y3 initially (pop p x1) (pop p y1) (pop p x3) (pop p y3) while p do (setq x2 x3 y2 y3 ) (pop p x3) (pop p y3) (send self message x1 y1 x2 y2 x3 y3 alu))) into (defmethod (graphics-mixin :triangulate-simple-polygon) (message alu &rest points) (loop with (x1 y1 . p) = points for (x2 y2 . p) = p while p for (x3 y3 . NIL) = p do (send self message x1 y1 x2 y2 x3 y3 alu))) which loses because (x2 y2 . p) destructures NIL instead of (CDDR points). Can someone tell me why this is not a bug? Every time you use a FOR or a WITH to create a new variable, you create a new variable, even if it happens to have the same name as another variable you created. There are two variables named P in your program. I think what this really shows is that you should program in LISP rather than in LOOP, except when using the particular cliches for which LOOP is good. The LISP language makes variable scoping clearer. The LOOP language is a little too general. Anyway, I bletched it into (defmethod (graphics-mixin :triangulate-simple-polygon) (message alu &rest points) (loop with (x1 y1 . pOINTS) = points for (x2 y2 . p) = pOINTS THEN P while p for (x3 y3 . NIL) = p do (send self message x1 y1 x2 y2 x3 y3 alu))) which works, but shouldn't, if I understand the documentation, which seems to require (x2 y2 . p) FIRST points then p, which, in fact, loses! The documentation is not very clear. I suspect that in the description of "FOR ... FIRST" you read "other iteration variables set before it" to mean "all LOOP-defined variables, but actually "iteration variables" means only variables-of-iteration, set by iteration-driving clauses. Anyway, assuming someone straightens out either me or LOOP, there is one more issue. DDYER's code compiles into 56 instructions, and mine compiles into 73. Maybe in the wonderful future, LOOP could recognize opportunities to POP in such circumstances? Looks like LOOP destructuring isn't smart at all. DESTRUCTURING-BIND destructuring, which is the same as DEFMACRO destructuring, is much smarter (in the latest Symbolics system, not yet released). Perhaps an interface should be defined? I'm not sure what all this says about what should be done when LOOP is redesigned.  Date: Monday, 15 October 1984 23:14-EDT From: Alan Bawden To: Bug-LOOP at MC Subject: [rwg: LOOP again] I think this is yet another example of the screw I complained about in my previous messages to Bug-LOOP two or three years ago. I know this isn't news to anybody on Bug-LOOP, but its probably usefull to have a few of these screws in the archives so that they can be used as test examples for the "New LOOP System". Date: Saturday, 13 October 1984, 00:30-PDT From: Bill Gosper To: lisp-designers at SPA-NIMBUS cc: ddyer at SPA-NIMBUS Re: LOOP again I was fooling around trying to bum DDYER's (defmethod (graphics-mixin :triangulate-simple-polygon) (message alu &rest points) (loop with p = points and x1 and y1 and x2 and y2 and x3 and y3 initially (pop p x1) (pop p y1) (pop p x3) (pop p y3) while p do (setq x2 x3 y2 y3 ) (pop p x3) (pop p y3) (send self message x1 y1 x2 y2 x3 y3 alu))) into (defmethod (graphics-mixin :triangulate-simple-polygon) (message alu &rest points) (loop with (x1 y1 . p) = points for (x2 y2 . p) = p while p for (x3 y3 . NIL) = p do (send self message x1 y1 x2 y2 x3 y3 alu))) which loses because (x2 y2 . p) destructures NIL instead of (CDDR points). Can someone tell me why this is not a bug? Anyway, I bletched it into (defmethod (graphics-mixin :triangulate-simple-polygon) (message alu &rest points) (loop with (x1 y1 . pOINTS) = points for (x2 y2 . p) = pOINTS THEN P while p for (x3 y3 . NIL) = p do (send self message x1 y1 x2 y2 x3 y3 alu))) which works, but shouldn't, if I understand the documentation, which seems to require (x2 y2 . p) FIRST points then p, which, in fact, loses! Anyway, assuming someone straightens out either me or LOOP, there is one more issue. DDYER's code compiles into 56 instructions, and mine compiles into 73. Maybe in the wonderful future, LOOP could recognize opportunities to POP in such circumstances?  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60118; Wed 11-Jul-84 22:22:57-EDT Date: Wed, 11 Jul 84 22:19 EDT From: "David A. Moon" Subject: Request for documentation To: Michal Young cc: bug-loop@MIT-MC.ARPA In-Reply-To: The message of 2 Jul 84 17:34-EDT from Michal Young Message-ID: <840711221939.5.MOON@EUPHRATES.SCRC.Symbolics> Date: 02 Jul 84 14:34:59 PDT (Mon) From: Michal Young I would like to obtain documentation for the loop macro. Machine readable would be best; we can print from TeX, troff, or Scribe files. Franz is the lisp we are using, if that matters. Thank you, Michal Young, Artificial Intelligence Project, UC Irvine young@uci-750a.arpa The documentation is MIT Laboratory for Computer Science memo TM-169. It is also incorporated into the Lisp Machine Manual, available from MIT, Symbolics, or LMI. You do not have software that would be capable of printing the machine-readable form.  Date: 02 Jul 84 14:34:59 PDT (Mon) To: bug-loop@Mit-Ml cc: young@UCI-750b Subject: Request for documentation From: Michal Young I would like to obtain documentation for the loop macro. Machine readable would be best; we can print from TeX, troff, or Scribe files. Franz is the lisp we are using, if that matters. Thank you, Michal Young, Artificial Intelligence Project, UC Irvine young@uci-750a.arpa  Received: from SCRC-QUABBIN by MIT-OZ via Chaosnet; 29 Jan 84 22:04-EST Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Sun 29-Jan-84 22:05:53-EST Date: Sunday, 29 January 1984, 21:54-EST From: David A. Moon Subject: collecting into a not-initially-null variable To: Philip E. Agre Cc: bug-loop at MIT-OZ In-reply-to: The message of 29 Jan 84 01:36-EST from Philip E. Agre Date: Sunday, 29 January 1984, 01:36-EST From: Philip E. Agre I wanted to write the macro do-collect: (do-collect (x '(1 2 3)) (+ x 10)) => (11 12 13) with the extra feature of being able to specify the rest of the collected list: (do-collect (x '(1 2 3) '(r e s t)) (+ x 10)) => (11 12 13 r e s t) So I did this: (defmacro do-collect ((variable list . **rest) &body body) (unless **rest (setq **rest '(nil))) ; kludge `(loop with **result = ,@**rest for ,variable in ,list collect (progn ,@body) into **result finally (return **result))) The latter do-collect call expands into: (loop with **result = '(r e s t) for x in '(1 2 3) collect (progn (+ x 10)) into **result finally (return **result)) Alas, this returns (11 12 13) instead of (11 12 13 r e s t), the variable being collected into automatically being initialized to nil. If you macroexpand that loop, you'll see that you're binding two distinct variables both named **result. Is this a bug or a feature? Well, it probably should be regarded as a bug that LOOP didn't warn you that you were binding two variables with the same name. If LOOP could produce parallel bindings (LET-style) it would be up to the compiler to warn you, but since it can't it ought to. I added this to my list of things that the next generation LOOP ought to do. That list already included a way to do what you're asking for (specify an initial value for the collection accumulator). Some day....  Received: from MIT-MORRISON by MIT-OZ via Chaosnet; 29 Jan 84 01:36-EST Date: Sunday, 29 January 1984, 01:36-EST From: Philip E. Agre Subject: collecting into a not-initially-null variable To: bug-loop at MIT-OZ I wanted to write the macro do-collect: (do-collect (x '(1 2 3)) (+ x 10)) => (11 12 13) with the extra feature of being able to specify the rest of the collected list: (do-collect (x '(1 2 3) '(r e s t)) (+ x 10)) => (11 12 13 r e s t) So I did this: (defmacro do-collect ((variable list . **rest) &body body) (unless **rest (setq **rest '(nil))) ; kludge `(loop with **result = ,@**rest for ,variable in ,list collect (progn ,@body) into **result finally (return **result))) The latter do-collect call expands into: (loop with **result = '(r e s t) for x in '(1 2 3) collect (progn (+ x 10)) into **result finally (return **result)) Alas, this returns (11 12 13) instead of (11 12 13 r e s t), the variable being collected into automatically being initialized to nil. Is this a bug or a feature? /phil  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 30-Dec-83 14:53:30-EST Date: Fri, 30 Dec 83 14:51 EST From: "David A. Moon" Subject: LOOP feature suggestion To: "Bernard S. Greenberg" Cc: bug-lispm%SCRC-TENEX@MIT-MC.ARPA, bug-loop@MIT-ML.ARPA In-reply-to: The message of 30 Dec 83 11:52-EST from Bernard S. Greenberg Date: Friday, 30 December 1983, 11:52-EST From: Bernard S. Greenberg How about (loop for (pathname) and plist in (fs:directory-list ...) ...? The semantics of "and" conjoining iteration patterns or variables would be simultaneous assignment/destructuring from a real, gensym, iteration variable. This particular case is easily handled as (loop for plist in (fs:directory-list ... ) as (pathname) = plist ...) In general your suggestion could be useful; really this is a syntactic deficiency of this style of destructuring. Date: Friday, 30 December 1983, 14:10-EST From: David C. Plummer How does this affect (loop with foo and bar = baz with (quux q2) and mumble = frotz with (blot b2) = glorp) which I think gives most of the cases? Indeed it would not be possible to make WITH treat AND consistently with FOR if Bernie's suggestion were adopted, since WITH already has its own entirely different meaning for AND. I think this shoots down the proposal, since we don't want to make LOOP even more inconsistent and hard to understand.  Received: from SCRC-CONCORD by SCRC-QUABBIN with CHAOS; Fri 30-Dec-83 15:09:31-EST Date: Fri, 30 Dec 83 15:08 EST From: "Bernard S. Greenberg" Subject: LOOP feature suggestion To: Moon%SCRC-TENEX@MIT-MC.ARPA Cc: bug-lispm%SCRC-TENEX@MIT-MC.ARPA, bug-loop@MIT-ML.ARPA In-reply-to: The message of 30 Dec 83 14:51-EST from David A. Moon Date: Friday, 30 December 1983, 14:51-EST From: David A. Moon Date: Friday, 30 December 1983, 11:52-EST From: Bernard S. Greenberg How about (loop for (pathname) and plist in (fs:directory-list ...) ...? This particular case is easily handled as (loop for plist in (fs:directory-list ... ) as (pathname) = plist ...) I say exactly that in every program; it is precisely that bsilly locution I was trying to improve upon.  Date: 29 November 1983 23:34 EST From: Glenn S. Burke Subject: gratuities To: BUG-LOOP @ MIT-MC Changed loop so that (loop-gentemp &optional prefix) gets used instead of (gensym). This turns into gentemp in NIL, gensym (ignoring the prefix) elsewhere. Most occurences specify some mnemonic prefix, all of which (and the default prefix too) start with "LOOP-". This prompted by my fixing NIL's gentemp.  GSB@MIT-ML 11/28/83 05:20:20 Re: implicit progns To: (BUG LOOP) at MIT-ML In the latest source, only initially, finally, and do will accept any number of forms without complaint. All the other things which gobble a form will issue a warning if more than one is there.  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 24-Oct-83 13:26:26-EDT Date: Monday, 24 October 1983, 13:25-EDT From: David A. Moon Subject: Can it be done? To: ROB@MIT-OZ Cc: bug-loop@MIT-ML In-reply-to: Date: Sat, 22 Oct 1983 20:04 EDT From: ROB%MIT-OZ@MIT-MC.ARPA I'd like to define my own collection type to work on a particular data structure I'm using. In particular it should look something like this: (loop ..... adding foo-element to foo-universe ...) There isn't an official way to do this (yet; this was one of the things planned for the second generation LOOP that hasn't happened yet). If you want to look at the code, you can add something to loop-keyword-alist and imitate some of the code in loop-do-collect. You may find it difficult to understand what loop-do-collect is doing, since it doesn't seem to have been meant to be easy to read; it's main purpose is to generate efficient code.  Date: Sat, 22 Oct 1983 20:04 EDT Message-ID: From: ROB%MIT-OZ@MIT-MC.ARPA To: bug-loop%MIT-OZ@MIT-MC.ARPA Subject: Can it be done? I'd like to define my own collection type to work on a particular data structure I'm using. In particular it should look something like this: (loop ..... . . . adding foo-element to foo-universe . . .) Is there and way to do this directly and not use do (add foo element foo-universe) I am running in Zetalisp. ROB  Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sat 23-Jul-83 17:26:31-EDT Date: Saturday, 23 July 1983, 17:25-EDT From: David A. Moon Subject: minor updates To: Glenn S. Burke Cc: BUG-LOOP@MIT-MC In-reply-to: The message of 21 Jul 83 20:28-EDT from Glenn S. Burke Date: 21 July 1983 20:28 EDT From: Glenn S. Burke Virtuous souls might want to take loop 790 from MC in an idle moment and verify that i haven't broken anything. Major addition: interned-symbols iteration path split symbolics/lmi. I didn't bother copying it since the only change was under the (or mit lmi) conditional, and that code had obviously not been fully tested yet, so it will obviously change again. After it stabilizes let me know and I'll merge source versions.  Date: 21 July 1983 20:28 EDT From: Glenn S. Burke Subject: minor updates To: BUG-LOOP @ MIT-MC Virtuous souls might want to take loop 790 from MC in an idle moment and verify that i haven't broken anything. Major addition: interned-symbols iteration path split symbolics/lmi.  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 31-May-83 21:06:32-EDT Date: Tuesday, 31 May 1983, 21:05-EDT From: David A. Moon Subject: New loop keyword? To: Allan Wechsler Cc: BUG-LISPM@SCRC-TENEX, bug-loop@MIT-ML, BUG-ZMAIL@SCRC-tenex In-reply-to: The message of 31 May 83 19:20-EDT from Allan Wechsler Date: Tuesday, 31 May 1983, 19:20-EDT From: Allan Wechsler In Release 4.2, System 222.211, Hardcopy 11.15, Zmail 74.45, LMFS 30.27, site configuration 62, on Terrier: While grovelling about in Zmail source trying to learn how to unwedge a mail sequence lock, I encountered this: (DEFUN LOCK-BOTH-BUFFERS (ME) (DECLARE (VALUES OLD-ME OLD-HIM)) (LOOP WITH INHIBIT-SCHEDULING-FLAG =T ... Bug-ZMAIL: I think the =T at the end of the third line is a typo. Bug-LISPM: Why didn't LOOP scold the author at macroexpand time? Fixed in the source on P and MC. This was caused by LOOP-DO-WITH not calling the proper entry into the data-type stuff, so it thought =T was the name of a data type and then ignored it since the Lisp machine doesn't have data types. The effect ended up being that INHIBIT-SCHEDULING-FLAG was bound to NIL instead of to T.  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 23-May-83 23:31:04-EDT Date: Monday, 23 May 1983, 23:28-EDT From: David A. Moon Subject: Crumby error message from LOOP To: Clark M. Baker Cc: BUG-LISPM@SCRC-TENEX, bug-loop@MIT-ML In-reply-to: The message of 20 May 83 14:32-EDT from Clark M. Baker Date: Friday, 20 May 1983, 14:32-EDT From: Clark M. Baker In Release 4.3 (Beta test), System 222.232, Hardcopy 11.16, LMFS 30.36, Experimental LIL 20.22, Obsolete MICROCODE 161.0, Experimental LMACH 10.33, microcode 981, site configuration 54, L Machine Console (TMC5), on Collie: I got the following error with this piece of code. I expected a better error message. (loop for r 1 to (// hw 2) >>Trap: The argument to the GET-PNAME instruction, 1, was of the wrong type. The instruction expected a symbol. While in the function SI:LOOP-OPTIONAL-TYPE  SI:LOOP-DO-FOR  SI:LOOP-HACK-ITERATION Fixed when LOOP doesn't try to run in 5 different Lisp dialects (no exaggeration). This one was introduced by conditionalization for NIL, where the empty list isn't a symbol. Except that that design bug in NIL was fixed some time ago. Fixed in the source (on P and MC both).  Date: Thursday, 14 April 1983 17:27-EST From: MOON at SCRC-TENEX To: Webster Dove cc: bug-loop at ml Subject: Is there a way to skip to the next iteration In-reply-to: The message of 14 Apr 1983 10:14-EST from Webster Dove Date: Thursday, 14 April 1983, 10:14-EST From: Webster Dove To: info-LISPM at MIT-OZ Is there a way in (loop ...) to say "go directly to the next iteration. Do not execute the remaining clauses of the body" Such statements typically are called "continue" or "next" There isn't now. Normally one encloses the body in a conditional (unfortunately, it can be painful to do this currently if the body includes COLLECT statements). The main problem with having a continue statement is that it may be unclear just what is regarded as "the body" and what is regarded as "the iteration framework": If there is a WHILE statement later in the LOOP than the CONTINUE, should it be skipped or should it still be executed? And is the answer to this affected by whether there is a DO after the WHILE?  Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Sun 10-Apr-83 21:45:36-EST Date: Sunday, 10 April 1983, 21:48-EST From: David A. Moon Subject: Loop problem? To: Bernard S. Greenberg Cc: BUG-lispm@SCRC-TENEX, bug-loop@MIT-ML In-reply-to: The message of 8 Apr 83 13:00-EST from Bernard S. Greenberg Date: Friday, 8 April 1983, 13:00-EST From: Bernard S. Greenberg In Release 4.2, System 222.211, Hardcopy 11.15, Zmail 74.45, LMFS 30.27, microcode 990, site configuration 62, on Borzoi: (loop repeat start1 for l = sequence1 then (cdr l) finally (return l)) Why is it gratuitously SUB1'ing my repeat count? ((LAMBDA (G3255) ((LAMBDA (L) (PROG NIL (AND (NOT (PLUSP G3255)) (GO ZL:SYSTEM:SYSTEM-INTERNALS:END-LOOP)) (SETQ G3255 (ZL:SUB1 G3255)) ZL:SYSTEM:SYSTEM-INTERNALS:NEXT-LOOP (AND (NOT (PLUSP G3255)) (GO ZL:SYSTEM:SYSTEM-INTERNALS:END-LOOP)) (SETQ G3255 (ZL:SUB1 G3255)) (SETQ L (CDR L)) (GO ZL:SYSTEM:SYSTEM-INTERNALS:NEXT-LOOP) ZL:SYSTEM:SYSTEM-INTERNALS:END-LOOP (RETURN L))) SEQUENCE1)) START1) It isn't. If you look on page 237 of the Chine Nual, "for l = sequence1 then (cdr l)" means "bind l to sequence1 before the loop; then set l to its cdr on ALL BUT THE FIRST iteration". Thus it takes one less cdr than the repeat count. Indeed it would be unreasonable for it not to mean this, if you think about. You should probably just write SETQ in the body of the loop; there isn't any iteration driving clause now that both does a setq and allows an initial binding. It's been proposed that there should be one, but I'm not sure of a non-confusing syntax for it.  Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 6-Apr-83 01:11:38-EST Date: Wednesday, 6 April 1983, 01:07-EST From: David C. Plummer Subject: LOOP macro expansions To: BUG-lisp@MIT-MC, bug-Lispm@SCRC-TENEX, BUG-LOOP@MIT-ML Cc: BSG@SCRC-TENEX, GSB@MIT-ML In-reply-to: The message of 5 Apr 83 19:23-EST from DCP at SCRC-TENEX Small warning to those who put my suggestion in their private versions of LOOP: Be sure to also get the EVAL-WHEN at the beginning of the file that sets up all the features/non-features. Failure to do this will, among other things, cause collection to fail on the LispM. I just found this out the hard way...  Date: 5 April 1983 22:05 EST From: George J. Carrette Subject: LOOP macro expansions into LET To: DCP @ SCRC-TENEX cc: BUG-LISP @ MIT-MC, BUG-LOOP @ MIT-ML, GSB @ MIT-ML, BSG @ SCRC-TENEX, bug-Lispm @ SCRC-TENEX In-reply-to: Msg of 5 Apr 1983 19:23-EST from DCP at SCRC-TENEX In PDP-10 maclisp, if you wanted to take up GSB's suggestion, you could have LET and LET* in the interpreter autoload "LIBLSP;LETFEX FASL" which is an implementation of LET optimized for the interpreter, it defines 'em as FEXPRs. Not only is it fast and cons no extra storage, it is about 1/6 the size of the macro let implementation, and comes with a money-back guarantee..  Date: Tuesday, 5 April 1983 19:23-EST From: DCP at SCRC-TENEX To: Glenn S. Burke Cc: BSG at SCRC-TENEX, BUG-lisp at MIT-MC, bug-Lispm at SCRC-TENEX, BUG-LOOP at MIT-ML Subject: LOOP macro expansions In-reply-to: The message of 5 Apr 1983 16:07 EST from Glenn S. Burke I see your point about memoizing. *sigh*. So perhaps there is a need for #+/-LOOP-uses-LET feature. I tried to be careful about when LETs where merged into LET*s. I think I got it right... I, for sure, won't make the "official" change, since I have no idea where the correct source is and how it must propigate. (For now I've just put it into my LispM environment.)  Date: 5 April 1983 16:07 EST From: Glenn S. Burke Subject: LOOP macro expansions To: BUG-LOOP @ MIT-ML, BSG @ SCRC-TENEX, DCP @ SCRC-TENEX cc: BUG-lisp @ MIT-MC, bug-Lispm @ SCRC-TENEX There is a good reason why the variables are collected suitably for let, and that is because they originally were. As i remember it, loop used let even when it was coding its own destructuring (as it does in the multics & lispm implementations). The killer, though, was all those macro expansions in interpreted code (Maclisp in particular). I mean, we were talking about using up 10% of the address space of pdp10 maclisp running an interpreted program, just to memoize those LET macro expansions! (That was Martin's parser, when it ran (mostly) interpreted.) Because of that kind of lossage, loop (and LSB and various other things i've written) generally try to expand into the simplest possible forms. It's been worth it from the point of view of those running out of address space. Otherwise, i really don't care. A special-form let makes this much more attractive. Just don't break the pdp10 version. (Remember that not all the lets can be merged into let*s too.) If no one else gets to it, i'll look at this in a day or two when i'm done with some documentation and bolio hacking.  Date: 5 April 1983 07:07 EST From: Alan Bawden Subject: [DCP: LOOP macro expansions] To: BUG-loop @ MIT-ML Date: Tuesday, 5 April 1983, 05:41-EST From: David C. Plummer To: DCP at SCRC-TENEX, bug-Lispm at SCRC-TENEX, bug-lisp Re: LOOP macro expansions While we're at it, we could combine multiple single LETs into LET*s. I don't suggest you take this verbatim, since I am making a few assumptions on the internal data structures as the macro gets built. ('t #+Lispm (setq tem (if (and (= (length vars) 1) (listp tem) (listp (car tem)) (or (eq (caar tem) 'let*) (and (eq (caar tem) 'let) (= (length (cadar tem)) 1)))) `(let* (,(car vars) ,.(cadar tem)) ,.(cddar tem)) `(let ,(reverse vars) ,.tem))) #-Lispm (let ((lambda-vars ()) (lambda-vals ())) (do ((l vars (cdr l)) (v)) ((null l)) (cond ((atom (setq v (car l))) (push v lambda-vars) (push () lambda-vals)) ('t (push (car v) lambda-vars) (push (cadr v) lambda-vals)))) (setq tem `((lambda ,lambda-vars ,.tem) ,.lambda-vals))))  Date: 5 April 1983 07:07 EST From: Alan Bawden Subject: [DCP: LOOP macro expansions] To: BUG-loop @ MIT-ML Date: Tuesday, 5 April 1983, 04:18-EST From: David C. Plummer To: bug-Lispm at SCRC-TENEX, bug-lisp Re: LOOP macro expansions [Please forward this to the correct mailing lists; I'm not quite sure what the correct audience is.] I would like to change LOOP-TRANSLATE-1 to use LET for the local variables it creates instead of using LAMBDA. This is for expansion readability. The relevent code fragment is below. You will notice that internally loop collects the variables in a manner nearly directly suited for LET. Perhaps #+/-Lispm is not the correct crition. Perhaps a new FEATURE status is needed which determines if the target has the LET macro or special form. I have not changed any sources. ('t #+Lispm (setq tem `(let ,(reverse vars) ,.tem)) #-Lispm (let ((lambda-vars ()) (lambda-vals ())) (do ((l vars (cdr l)) (v)) ((null l)) (cond ((atom (setq v (car l))) (push v lambda-vars) (push () lambda-vals)) ('t (push (car v) lambda-vars) (push (cadr v) lambda-vals)))) (setq tem `((lambda ,lambda-vars ,.tem) ,.lambda-vals))))  Date: 9 March 1983 03:18 EST From: Alan Bawden Subject: )( To: BUG-LOOP @ MIT-ML I have identified a reason to prefer a LOOP macro with parenthesized clauses over a LOOP macro with keyword introduced clauses (as now). It makes clauses easier to manipulate with text editors as logical entities. (That is, I can use C-M-T to twiddle clauses, rather than diddling around with the region or whatever.) Make of this what you will.  Date: Saturday, 15 January 1983 04:05-EST From: MOON at SCRC-TENEX To: David L. Andre Cc: BUG-LISPM at SCRC-TENEX, BUG-LLC at SCRC-TENEX, GSB at ML Subject: Horrible code In-reply-to: The message of 9 Jan 1983 16:53-EST from David L. Andre Date: Sunday, 9 January 1983, 16:53-EST From: David L. Andre Subject: Horrible code To: BUG-LISPM at SCRC-TENEX, BUG-LLC at SCRC-TENEX The code generated on the L-machine for LOOP COLLECT (which turns into RPLACD for value) is atrocious. Although I admire the totally general way which no-value subprimitives are handled, I think that (1) the "return first argument" case could be made to simply copy the first argument after it is computed, and (2) LOOP could be fixed to produce (RPLACD G0001 (NCONS FOO)) (SETQ G0001 (CDR G0001)) Or maybe (RPLACD G0001 (SETQ G0001 (NCONS FOO))) instead of (SETQ G0001 (CDR (RPLACD G0001 (NCONS FOO)))) As I understand it the latter code is the only thing that gets anything at all reasonable out of the pdp10 Maclisp compiler. I amused myself by improving Loop's machine-dependent knowledge. It now generates the second of your three forms, where possible, on Lisp machines, which is much better on the L machine and even saves about two microseconds on the A machine. Loop will still prefer RPLACD for value over generating a temporary variable [this happens when it is going to take more than one CDR of the RPLACD, which you can get it to do by using "NCONC (LIST a b c)" and the like], which is the right choice for all machines except the 3600. We should fix the 3600 compiler some time to effectively generate the variable itself (i.e. copy the value). Even better would be if it did like Maclisp and realized that taking CDR of the result of RPLACD means that you really wanted the second arg, not the first arg.  Date: Sunday, 24 October 1982, 17:54-EDT From: Mike McMahon Subject: ':FLONUM To: bug-loop at SCRC-TENEX Ignore previous message. The original bug was elsewhere and a bug in the debugger hid that fact from me.  Date: Sunday, 24 October 1982, 15:16-EDT From: Mike McMahon To: BUG-LOOP at SCRC-TENEX In something like 219 on Mystic: LOOP thinks :FLONUM is a TYPEP. It's :FLOAT only on the L machine.  Date: Monday, 18 October 1982, 23:31-EDT From: David A. Moon To: David L. Andre Cc: BUG-LISPM at SCRC-TENEX, BUG-LOOP at MIT-ML In-reply-to: The message of 18 Oct 82 21:34-EDT from David L. Andre Date: Monday, 18 October 1982, 21:34-EDT From: David L. Andre To: BUG-LISPM at SCRC-TENEX, BUG-LOOP at MIT-OZ The HASH-ELEMENTS loop iteration path in PTR:>SYS>SYS2>LOOP.LISP needs to wrap itself in (SI:INHIBIT-GC-FLIPS ...), or its results are not predictable. There doesn't seem to be a way to do this with LOOP... Fixed and patched. I merged the F: and ML: sources back together. Glenn, you might want to look at how I did it (I just put in a variable without any special interfacing to it: it wasn't convenient to add another return value from paths).  Date: Monday, 18 October 1982, 21:34-EDT From: David L. Andre To: BUG-LISPM at SCRC-TENEX, BUG-LOOP at MIT-OZ The HASH-ELEMENTS loop iteration path in PTR:>SYS>SYS2>LOOP.LISP needs to wrap itself in (SI:INHIBIT-GC-FLIPS ...), or its results are not predictable. There doesn't seem to be a way to do this with LOOP...  Date: Tuesday, 28 September 1982 05:42-EDT From: MOON at SCRC-TENEX To: bug-loop at ml Subject:Laws@sri coments on loop doc in 4th ed Chine Nual (p. 236, par. 5) The definition of "as" in this paragraph is rather hidden. It was quite difficult to discover what "as" meant when it was used later in the examples (e.g., p. 239). Keywords for iteration (as, for, on, by, etc.) and for other macros should be added to the keyword index. (p. 242, par. 5) "while clause" should be "until clause". The entire example is rather confusing and raises questions of portability and of good programming style. (p. 244, l. 8) "memoize" should be "memorize". (p. 249, middle) The sentence "Thus, we can hypothesize ..." has too many commas, or commas in the wrong places.  Date: 21 September 1982 17:10-EDT From: Glenn S. Burke To: BUG-LOOP at MIT-ML I wonder how much code would "break" if i "broke" the implicit-progn feature for forms gathered within iteration clauses, conditional clauses, and WITH bindings; i.e., everything except initially, finally, and body clauses. People keep losing with this over and over and over...  Date: 8 September 1982 01:29-EDT From: Alan Bawden Subject: LOOP: = vs. FIRST To: MOON at SCRC-TENEX cc: DLW at SCRC-TENEX, BUG-LOOP at MIT-ML Date: Tuesday, 7 September 1982 16:58-EDT From: MOON at SCRC-TENEX You are quite right. The current draft of the new LOOP proposal tries to address this, but probably just makes it worse. I will definitely make sure this is fixed. Fixed how? Does fixed mean that all my code will break? Or do you propose to fix it so that FIRST is no longer necessary? I don't see how you can do the former without new total hair, because (for example) in "for x in l" you cannot initialize X until you have performed an endtest... Hmm... I'll bet this means that "for x from 0 below -1" runs some of the initialization code in the later clauses before it performs the associated endtest and realizes that the loop is over before it began... [I just tried it, it does.] Damn. Why did I start worring about this? I'm convincing myself that we should put off adding LOOP in Common Lisp until 1984... I suspect (but am not sure right now) that the = vs FIRST distinction is really only an efficiency hack and therefore should not be visible to the user, but should be handled automatically by the macrology. I think I believe this too. I think this is related to my complaint before about a strict semantics for LOOP. If we had one from the beginning, then it would have been designed to meet that strict spec. Of course nobody knew what that spec should say until you try to write a LOOP in the first place... I'm convinced, BTW, that such a strict semantics can (and should) be worked out. I suspect that it will do a lot to improve LOOP's image and reputation. The fact that none of LOOP's detractors has zeroed in on anything this specific as a problem with it (ignoring the anti-"syntax" flamers) probably indicates that none of them has ever REALLY taken the trouble to try and learn about using LOOP. We should beat then to the punch by cleaning it up first.  Date: Tuesday, 7 September 1982 16:58-EDT From: MOON at SCRC-TENEX To: Alan Bawden , dlw at SCRC-TENEX Cc: BUG-loop at MIT-ML Subject: LOOP: = vs. FIRST You are quite right. The current draft of the new LOOP proposal tries to address this, but probably just makes it worse. I will definitely make sure this is fixed. I suspect (but am not sure right now) that the = vs FIRST distinction is really only an efficiency hack and therefore should not be visible to the user, but should be handled automatically by the macrology. Is Macrology the opposite of Smalltalk?  Date: Tuesday, 7 September 1982, 12:04-EDT From: Daniel L. Weinreb Subject: LOOP: = vs. FIRST To: BUG-loop at MIT-ML Cc: ALAN at MIT-MC, jlk at SCRC-TENEX In-reply-to: The message of 7 Sep 82 04:45-EDT from Alan Bawden Without intending to start a flame, I would like to construtively criticize LOOP by saying that it is exactly this sort of complexity that makes people suspicious and afraid of LOOP. If you have to think THAT hard to get a simple two-variables-in-sequence loop to work, then it's just not worth LOOP; a PROG would be easier to write and easier to understand. How I am supposed to remember which code is generated by "first" versus "=" is also unclear. This is hardly what I call mnemonic names. Of course, if the names were mnemonic, they would be ugly, because the very syntax for doing iteration would be talking about these hairy issues of what gets evaluated in which environment, which is presumably why you chose the pretty-but-useless pair of names you did. But, the whole point is, you DO have to think about these issues when you use LOOP; it's cheating to pretend that you don't. Either change LOOP to make these issues more apparent, perhaps by using uglier but more mnemonic names, or else change LOOP so that you don't have to worry about these things. If neither of these can be done, then something is wrong with the whole idea of LOOP.  Date: 7 September 1982 04:45-EDT From: Alan Bawden Subject: LOOP: = vs. FIRST To: BUG-loop at MIT-ML cc: dlw at SCRC-TENEX I have finally groked what I think is the biggest ambiguity in loop's definition. Consider this function intended to add up the numbers from 1 to N: (defun sum1 (n) (loop for x from 1 upto n for sum = x then (+ sum x) finally (return sum))) This happens to work. Now consider the following closely analogous function for adding up the elements of a list: (defun sum2 (l) (loop for x in l for sum = x then (+ sum x) finally (return sum))) This doesn't work because X happens to be bound to NIL at the time the X in "for sum = x" gets evaluated. In light of this I went back and looked at SUM1 and carefull read the documentation. Sure enough, by the documentation, SUM1 should not work. According to the documentation I should be using for/first/then rather than for/=/then because otherwise "it cannot reference other iteration variables set before it". Now in reality this is an overstatement, since in fact there are many iteration variables that CAN be referenced (any variable bound using an "=" or using "on" or a numeric iteration variable, for example). Going back and looking at many of my uses of loop, I find that I violate this rule ALL THE TIME! Now my question is this: Am I in any danger here? Do we all use loop this way and the documentation is merely lacking in its explanation of matters? Or are the rest of you carefully adhering to a strict interpretation of the contract?  Date: 2 Sep 1982 13:32 PDT From: JonL at PARC-MAXC Subject: Re: 2nd generation LOOP macro In-reply-to: Fahlman's message of Thursday, 26 August 1982 20:43-EDT To: Scott E. Fahlman cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI Let me proffer a reason why LOOP should be even *white* pages. Despite the best efforts of some functional programming people (especially PROLOG?) iterative constructs won't go away; e.g. too often the translation of a somewhat simple loop into functional equations leads to indecipherable code. Thus it would be well to standardize on some loop facility, if in fact a standard can be found. InterLisp's iterative statement facility *does not* share all the crocks of CLISP (and was no doubt put there rather than being a macro due to the primitive treatment of macros). Furthermore, it's years of existence as a standard within InterLisp, and its easy extensibility, speak well for it. Both the past and current LOOP proposals are very very much like the InterLisp iterative constructs, and should be viewed as having years of support behind their basic ideas. Another winning idea from the InterLisp iterative statement is that the prettyprinter treats them specially, and tries to do a "good" job of formatting so that the constituent parts stand out 2-dimensionally. A real defect of DO loops is that almost all minor exceptions to the simple case have to appear in the code in some place that obscures their nature (e.g., in the code body, or actually *before* the DO loop, or in the return clause); I realize that doing a "good" job will cause months of seemingly endless discussion, but fruitage of this idea has got to be worth the effort.  Date: Tuesday, 31 August 1982, 11:06-EDT From: Daniel L. Weinreb Subject: 2nd generation LOOP macro To: Fahlman at Cmu-20c, BUG-LOOP at MIT-ML, Common-Lisp at SU-AI In-reply-to: The message of 27 Aug 82 21:11-EDT from Scott E. Fahlman Date: Friday, 27 August 1982 21:11-EDT From: Scott E. Fahlman Well, it is OK to write a portable package that explicitly requires something from the yellow pages, so we could still use your portable code and include the LOOP package with it. The main problem with this is that it introduces a new phenomenon. "I thought that I'd use Moon's nifty new code-walker to improve my hairy language extension, but unfortunately it uses the Moon/Burke/Bawden/whomever LOOP package and so when I load it into my environment it smashes my own LOOP package, so I can't use it." This is a fundamental problem with the whole idea of the yellow pages; I don't think there is any solution, so we should just live with it in general. I think that it is important that LOOP go into the white pages, so that our language has some reasonable way to get the same power in iteration that other languages have, but obviously we need a real solid proposal before this can be discussed. If it is necessary to leave LOOP in the yellow pages for a while before it is adopted, that is unfortunate but acceptable. However, I'd like it to be made clear that LOOP is being seriously proposed for eventual inclusion in the white pages even if it is only going into the yellow pages for now, so that people will be encouraged to try it, suggest improvements, and use it instead of ignoring it and writing their own equivalent but gratuitously incompatible LOOP macros. (Conceptually-different and non-gratuitously incompatible keyword-oriented iterators are perfectly OK, of course.)  Date: 28 August 1982 21:21-EDT (Saturday) From: FEINBERG at CMU-20C To: Scott E. Fahlman Cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI Subject: 2nd generation LOOP macro I suspect many people have not seen the complete proposal for the Common Lisp loop macro yet, and therefore it is premature to include it in the White Pages until everyone has a chance to examine the proposal in depth. I too wonder whether adding additional syntax to Common Lisp is a good idea for Common Lisp, but would like to at least see what is being proposed.  Date: Saturday, 28 August 1982 11:44-EDT From: MOON at SCRC-TENEX To: Scott E. Fahlman Cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI Subject: Yellow pages I guess I misunderstood the philosophy then. If the "yellow pages" things work in every implementation, just like the "white pages" things, then I'm happy with LOOP being in the yellow pages. I don't mind LOOP not being in the part that we say we will never (well, hardly ever) change, as long as writers of portable code are not discouraged from learning about it and using it.  Date: Friday, 27 August 1982 21:11-EDT From: Scott E. Fahlman To: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI Subject: 2nd generation LOOP macro One reason (for putting LOOP in the white pages) is that it is unlikely that any portable code I write will do its iteration with PROG or DO. -- Moon Well, it is OK to write a portable package that explicitly requires something from the yellow pages, so we could still use your portable code and include the LOOP package with it. If the white pages are to include everything that any individual wants to use in his code then we would have to include CGOL, Interlisp Compatibility Package, Flavors, three kinds of Smalltalk, Actors, Dick Waters' pseudo-Fortran macros, etc. My philosophy on this, such as it is, is that when a package is not essential and when there is a substantial portion of the community that has some doubts about the package's merits, it should go into the yellow pages. There it can compete in the marketplace of ideas. Perhaps it will come to be used by most of us, and we can promote it to the white pages at that time. Perhaps something better will come along to fill the same niche, and in that case we will not be burdened with the original package forever. Perhaps users will decide that it is easier just to do whatever the package does by hand than to remember its complexities, and in that case we will have spared the readers of the white pages from dealing with a lot of needless complexity. I could be wrong, but I think that the proposed LOOP package only appeals to a few of us. If so, I think a probationary period in the yellow pages is appropriate. If I'm wrong and I'm the last holdout for the old Lispy syntax, then LOOP should go directly into the white pages; in that case, I hope it can be documented very clearly, since new users are going to have to absorb it all. -- Scott  Date: Friday, 27 August 1982 21:25-EDT From: JLK at SCRC-TENEX To: MOON at SCRC-TENEX Cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI, Scott E. Fahlman Subject: 2nd generation LOOP macro I don't feel like arguing yet again why DO is fundamentally inadequate and causes you to write unmodular, unreadable code when you use it for advanced parallel/serial binding and flexibly-sequenced initial, end-test, and exit clauses, but maybe someone who is more energetic should undertake this. I believe it is worth the cost of the keyword syntax.  Date: Friday, 27 August 1982 13:28-EDT From: MOON at SCRC-TENEX To: Scott E. Fahlman Cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI Subject: 2nd generation LOOP macro Date: Thursday, 26 August 1982 20:43-EDT From: Scott E. Fahlman Is there any reason why LOOP should not be a yellow-pages package for those who like this sort of syntax? One reason is that it is unlikely that any portable code I write will do its iteration with PROG or DO.  Date: Thursday, 26 August 1982 20:43-EDT From: Scott E. Fahlman To: BUG-LOOP at MIT-ML Cc: Common-Lisp at SU-AI Subject: 2nd generation LOOP macro Moon's description of LOOP is reasonably clear. To me, LOOP looks like a lot of hairy syntax for no reason. The equivalent DO constructs look simpler and clearer to me in almost all cases, but then I'm a conservative -- I don't like CLISP or CGOL either. People keep coming up with these things, so there must be a need felt in some quarters to which I am insensitive. I would have said that this sort of thing is a training/transition aid for those not comfortable with Lisp, but considering the source of this proposal that can't be the true story. Is there any reason why LOOP should not be a yellow-pages package for those who like this sort of syntax? -- Scott  Date: 1 August 1982 00:44-EDT From: Glenn S. Burke Subject: BFS and DFS searching To: BUG-LOOP at MIT-ML PSZ@MIT-ML 08/01/82 00:34:05 Re: BFS and DFS searching You might consider adopting something like the BFS and DFS search paths extension to LOOP in PSZ;BDFS. Comments?  Date: Friday, 2 July 1982 18:59-EDT From: MOON at SCRC-TENEX To: David L. Andre Subject: Your LOOP complaint Cc: BUG-LISPM at SCRC-TENEX, BUG-LOOP at MIT-AI ELSE matches the innermost unmatched WHEN, as in all other languages I know of with dangling-else ambiguity. This is in the manual. Since you didn't say what was wrong, and the nearest Lisp machine is about 50 miles away, I don't know whether you expected it to do something else or whether it didn't do what it is documented to do. This is fixed in the new loop system by discouraging people from using WHEN and ELSE (and making it unnecessary to use them).  Date: Friday, 2 July 1982, 02:50-EDT From: David L. Andre To: BUG-LISPM at SCRC-TENEX, BUG-LOOP at MIT-AI In System 210.104, ZMail 45.3, LMFS 27.19, Tape 10.7, Canon 14.2, microcode 908, site configuration 22, on Setter: Either my understanding of loop is incorrect, or this generates incorrect code: (LOOP FOR X IN (CDR ELEM) WHEN (AND (LISTP X) (= (LENGTH X) 2) (OR (NULL (CADR X)) (AND (NUMBERP (CADR X)) (FIXP (CADR X)) (PLUSP (CADR X)) (NOT (BIGP (CADR X)))))) WHEN (AND (SYMBOLP (CAR X)) (OR (GET (CAR X) 'SI:SYSTEM-TYPE-FLAVOR) (EQ (CAR X) 'OTHERWISE))) COLLECT (LIST (CAR X) (CADR X)) ELSE WHEN (STRINGP (CAR X)) COLLECT (LIST (SI:PARSE-HOST (CAR X)) (CADR X)) ELSE DO (FERROR NIL "~S must be a host name, system type, or OTHERWISE" (CAR X)) ELSE DO (FERROR NIL "~S is an invalid site entry for :FILE-CONTROL-LIFE-TABLE" X)) In any case, this is an example of loop's syntactic ambiguity.  Date: 1 June 1982 16:39-EDT From: Glenn S. Burke Subject: LOOP producing a call to VALUE-CELL-LOCATION To: Gregor at MIT-AI cc: BUG-LOOP at MIT-ML, BUG-LISPM at MIT-AI This is ironic, because LOOP was hacked to call VARIABLE-LOCATION when it first became available. It does it under an FBOUNDP check with a comment saying that that check can be flushed when VARIABLE-LOCATION is supported everywhere. This change was effected in LOOP 767 over a month ago, and i believe that version of loop is what is in use in symbolics' systems. That is the version which should be in use now. The macro LOOP-COLLECT-INIT could be taken out of context and made into a patch.  Date: 1 June 1982 14:08-EDT From: Gregor J. Kiczales To: BUG-LISPM at MIT-AI In Experimental Remote-File 10.0, Experimental LMFILE-Remote 17.1, Experimental MIT-Specific 9.0, Experimental System 86.18, Experimental ZMail 45.0, microcode 123, Exp 83.18, GC@18, on Lisp Machine Six: Compiling the following function: (DEFUN LOCIFY-LIST (LIST) (LOOP FOR L ON LIST COLLECT (LOCF (CAR L)))) Produces the following warning: << While compiling LOCIFY-LIST >> Warning: VALUE-CELL-LOCATION of a quoted variable is obsolete; use VARIABLE-LOCATION  Date: 29 April 1982 18:07-EDT From: Carl W. Hoffman To: BUG-loop at MIT-ML Sorry. In my last message, (IF (= I-RANDOM N-RANDOM) (SETQ N-RANDOM 0)) should have been (IF (= I-RANDOM N-RANDOM) (SETQ I-RANDOM 0))  Date: 29 April 1982 18:01-EDT From: Carl W. Hoffman To: BUG-loop at MIT-ML This (LOOP FOR I-POINTS FROM 0 MOD N-POINTS FOR I-RANDOM FROM 0 MOD N-RANDOM FOR I-TOTAL FROM 0 BELOW N-TOTAL DO ...) might be a nice way of expressing this (LOOP FOR I-POINTS FROM 0 FOR I-RANDOM FROM 0 FOR I-TOTAL FROM 0 BELOW N-TOTAL DO (IF (= I-POINTS N-POINTS) (SETQ I-POINTS 0)) (IF (= I-RANDOM N-RANDOM) (SETQ N-RANDOM 0)) ...)  Date: Wednesday, 28 April 1982 18:30-EDT From: MMCM at SCRC-TENEX To: Glenn S. Burke Cc: bug-loop at SCRC-TENEX Subject: variable-location in LOOP Date: 28 April 1982 18:10-EDT From: Glenn S. Burke Fixed, upwards-compatibly, in the source (v 766). Oops. Guess my message wasn't explicit enough if you didn't see the original suggestions for it. VARIABLE-LOCATION is a special form, not a regular function. So you want (VARIABLE-LOCATION VAR) rather than 'VAR. I'd suggest using LOCF as a compatible way to win for systems without VARIABLE-LOCATION. What version is being run currently? 765. Also: is the mapatoms (interned-symbols path) code still valid for 3600? Yes, packages are the same on the L machine.  Date: 28 April 1982 18:10-EDT From: Glenn S. Burke Subject: variable-location in LOOP To: MMcM at SCRC-TENEX cc: bug-loop at SCRC-TENEX Fixed, upwards-compatibly, in the source (v 766). What version is being run currently? Also: is the mapatoms (interned-symbols path) code still valid for 3600?  Date: Tuesday, 27 April 1982, 22:02-EDT From: Mike McMahon Subject: variable-location To: bug-lispm-scrc at SCRC-TENEX Cc: doc-changes at SCRC-TENEX Remailed-date: 28 Apr 1982 1613-EDT Remailed-from: Mike McMahon Remailed-to: bug-loop at SCRC-TENEX I put in VARIABLE-LOCATION and made LOCF turn into it. VALUE-CELL-LOCATION on a local or instance variable still works, but prints an obsolete warning. At some point we can flush this, since i assume most bad uses are i the system itself.  Date: 8 April 1982 12:04-EST From: Glenn S. Burke Subject: spastic sequencing To: BUG-LOOP at MIT-ML Date: Wednesday, 7 April 1982, 16:17-EST From: David A. Moon In loop in System 204.56, ZMail 42.10, LMFS 24.7, Tape 8.0, Canon 12.3, Symbolics 10.1, microcode 869, on Spaniel: (loop for x from top downto bottom ...) works but (loop for x downfrom top to bottom ...) says conflicting directions Fixed in LOOP 765 and tested under Maclisp. Found two spazzes: one was that TO implied rather than defaulted direction, the other that UPTO was accepted (to mean the same thing except forcing the direction) by the preposition accumulator but not the sequence hacker.  Date: Wednesday, 7 April 1982, 16:17-EST From: David A. Moon To: BUG-loop at SCRC-TENEX In loop in System 204.56, ZMail 42.10, LMFS 24.7, Tape 8.0, Canon 12.3, Symbolics 10.1, microcode 869, on Spaniel: (loop for x from top downto bottom ...) works but (loop for x downfrom top to bottom ...) says conflicting directions  Date: 1 April 1982 19:04-EST From: Patrick G. Sobalvarro Subject: LOOP To: ALR at MIT-ML cc: BUG-LISPM at MIT-AI Syntactic sugar leads to cancerous semicolons. -- Alan J. Perlis  Date: 30 March 1982 17:25-EST From: Glenn S. Burke To: BUG-LOOP at MIT-ML pdp10 maclisp loop does not declare si:loop-named-variable to the poor compiler which likes to keep its declaration and definition environments completely separate except when it confuses the two and f***s both. Whatever it is it does with SI:LOOP-TMEMBER which is declared properly.  GSB@MIT-ML 03/25/82 16:21:52 Re: good god To: (BUG LOOP) at MIT-ML the installed pdp10 version can't possibly work. The conditionalization was broken.  Date: Thursday, 25 March 1982, 15:11-EST From: To: bug-loop at SCRC-POINTER The several instances of SMALL-FLOAT need to be conditionalized out for the l machine in some way.  GSB@MIT-ML 03/21/82 22:37:25 To: (BUG LOOP) at MIT-ML alan points out that AS is inadequately described. GSB knows what to do with it but is too brain-damaged to do it at the moment so is sending this to himself as a reminder.  GSB@MIT-ML 03/13/82 16:51:40 Re: vector destructuring To: (BUG LOOP) at MIT-ML CC: (BUG NIL) at MIT-ML was actually not working in the Real NIL because it dumbly used ATOM to decide to optimize into SETQ rather than DESETQ. This has been fixed in (what i hope is) the only place this occurs in the source, in version 751 on ML and MC. needs to be compiled and installed...  Date: Thursday, 11 March 1982, 15:56-EST From: Bernard S Greenberg Subject: multiple values To: MOON at SCRC-TENEX Cc: bug-loop at SCRC-TENEX Date: Thursday, 11 March 1982 13:17-EST From: MOON at SCRC-TENEX Date: Thursday, 11 March 1982, 09:57-EST From: Bernard S Greenberg I think LOOP needs WITH-MULTIPLE-VALUE (var var var var) = (form) This is no different than wrapping a MULTIPLE-VALUE-BIND around the loop, so I don't think it is worth introducing a new construct for this. The only reason I would want this in addition to the FOR is consistency. and FOR/AS-MULTIPLE-VALUE, similar. Of course, the var's can be destructure patterns. Perhaps maybe regular WITH/FOR/AS should be used, and MULTIPLE-VALUE-= used to tell that this is the case (this would actually fit in better with AND's....). Disallow multiple-value iteration driving if need be. ...... I'm not sure exactly what you're suggesting; I guess: FOR (v1 v2 v3) MULTIPLE-VALUE = FOR (v1 v2 v3) MULTIPLE-VALUE = THEN FOR (v1 v2 v3) MULTIPLE-VALUE FIRST THEN (but none of the other FOR/AS forms) These seem to do it quite fine. Destructuring v's would be nice, but I will refrain from wanting them until I grok GSB's remarks. This can be put in if there aren't any objections or better suggestions.  Date: 11 March 1982 15:04-EST From: Glenn S. Burke Subject: multiple values To: MOON at SCRC-TENEX cc: bsg at SCRC-TENEX, bug-loop at SCRC-TENEX The problem with any kludge here is that the "fix" is to have or allow (by some more general kludge) the active kind of destructuring. i.e., (loop for (values a b c) = (mumble frotz) ...). About the only way in which this could be added upwards-compatibly is to allow a trailing keyword the way a data-type spec is allowed; e.g., (loop for (values a b c) [] [] = (mumble frotz) ...). The other problem, of course, is that LOOP needs to know about the things inside this SETF spec, in order that it may bind them (in this case, the variables A, B, and C -- they may not be variables either!). This means it must be able to interact with these setf specifications. You can imagine what this means; it's bad enough getting "compatible" DEFMACROs to have the same semantics. (P.s. It's possible. I've done it. But it would be either (a) nasty (b) difficult or (c) impossible to add to loop without cooperation at that level from the lisps involved.)  Date: Thursday, 11 March 1982 13:17-EST From: MOON at SCRC-TENEX To: bsg at SCRC-TENEX cc: bug-loop at SCRC-TENEX Subject:multiple values Date: Thursday, 11 March 1982, 09:57-EST From: Bernard S Greenberg Subject: Loop not featureful enough To: Moon at SCRC-TENEX, GSB at MIT-ML, MMcM at SCRC-TENEX, RWK at SCRC-TENEX I think LOOP needs WITH-MULTIPLE-VALUE (var var var var) = (form) This is no different than wrapping a MULTIPLE-VALUE-BIND around the loop, so I don't think it is worth introducing a new construct for this. and FOR/AS-MULTIPLE-VALUE, similar. Of course, the var's can be destructure patterns. Perhaps maybe regular WITH/FOR/AS should be used, and MULTIPLE-VALUE-= used to tell that this is the case (this would actually fit in better with AND's....). Disallow multiple-value iteration driving if need be. I guess there isn't a convenient other way to do this (receive multiple values each time around the loop without needing a separate declaration of locality of variables, and without wrapping a form around the rest of the body thus eliminating the ability to use additional loop clauses). I'm not sure exactly what you're suggesting; I guess: FOR (v1 v2 v3) MULTIPLE-VALUE = FOR (v1 v2 v3) MULTIPLE-VALUE = THEN FOR (v1 v2 v3) MULTIPLE-VALUE FIRST THEN (but none of the other FOR/AS forms) This can be put in if there aren't any objections or better suggestions.  Date: Thursday, 11 March 1982, 09:57-EST From: Bernard S Greenberg Subject: Loop not featureful enough To: Moon at SCRC-TENEX, GSB at MIT-ML, MMcM at SCRC-TENEX, RWK at SCRC-TENEX I think LOOP needs WITH-MULTIPLE-VALUE (var var var var) = (form) and FOR/AS-MULTIPLE-VALUE, similar. Of course, the var's can be destructure patterns. Perhaps maybe regular WITH/FOR/AS should be used, and MULTIPLE-VALUE-= used to tell that this is the case (this would actually fit in better with AND's....). Disallow multiple-value iteration driving if need be. 1. Do any of you like this, or have better syntactic suggestions/names? 2. A skilled loop-internals-meister could probably whip this off in a lot less time than I would spend trying to figure out what the _ is going on.  Date: 2 February 1982 23:58-EST From: Glenn S. Burke To: WGD at MIT-MC cc: BUG-LOOP at MIT-MC, BUG-MACLISP at MIT-MC Date: 2 February 1982 10:03-EST From: William G. Dubuque Sender: BIL at MIT-MC (loop for (ignore x) in pairs ...) doesn't ignore; however using () instead of ignore works. Is this the defined behavior for loop? Yes. [I realize that the ignore conventions aren't standardized across Lisps; perhaps the MacLisp compiler could be made to recognize ignore also.] It does. The problem here is that IGNORE is only specially recognized when used in a variable-binding position. As i remember it, it isn't recognized in such things as (multiple-value (ignore foo) ...) (i'm talking lispm here--maybe this has been "fixed" but i don't think so). What you are saying is that (SETQ IGNORE (CAR L)) should do something special, like not bother. (I could say something nasty like "it's bad enough that the symbols T and NIL are treated specially, you want IGNORE to be also?", but i won't.)  ALAN@MIT-MC 02/02/82 21:01:43 Re: Fowarded without comment To: GSB at MIT-MC Date: 2 February 1982 17:52-EST From: David Chapman Subject: DO& iteration macro To: DLW at MIT-AI, BEE at MIT-AI, ALAN at MIT-AI, MOON at MIT-AI cc: LEVITT at MIT-AI This is about DO&, which might be an alternative to LOOP for Common Lisp. It has similar functionality and a much better syntax. The syntax is based on ``DO*'': (DO& (({var} {&keyword} arg1 arg2 ... {&only-if condition} {&noreturn} {&return return}) ...) form1 form2 ...) &keywords, one per varspec clause, generate code for initialization, repeat forms, end tests, etc. If there is no &keyword, a varspec is treated like DO*. The action of main keywords may be modified by three auxiliary keywords within the same variable specification. The keyword &RETURN, valid only as a modifier, specifies a form to be evaluated and returned when the variable in question reaches the end of its sequence of values. Unlike LOOP, DO& guarantees the value of iteration variables at return time. (There is a trade-off between this and implementing BELOW and so forth. A different implementation of DO& than mine might make the opposite design decision.) Similarly, the auxilliary keyword &NORETURN can be used to suppress unwanted end-tests that would otherwise be generated automatically. The auxilliary keyword &ONLY-IF specifies that the repeat form is evaluated only if the form following &ONLY-IF evaluates to non-NIL on that iteration -- otherwise that do variable retains the same value. If a keyword is the car of a variable specification list, a dummy variable is produced. This is useful mainly for the automatic production of end tests: (DO& ((&COUNT1 10)) do-something) does something 10 times. The programs below, equivalent to common LISP functions, give a feel for DO& style: (defun length (list) (do& ((i &count0) (a &pop list &return i)))) (defun reverse (list) (do& ((a &pop list &return b) (b &push a)))) (defun listarray (array) (do& ((&maparray array elt &return (reverse list)) (list &push elt)))) (defun remq (item list) (do& ((a &pop list &return (reverse out)) (out &push a &only-if (neq a item))))) DO& supports user-definable iteration paths. Most of LOOP's iterators have equivalents, and there are a number of useful DO& keywords that have no LOOP equivalent. My implementation of DO& is in AI:ZVONA;DO& >. I wrote this two years ago and have not changed it because it is very reliable. It needs a complete rewrite to incorporate some functionality that it should have and doesn't. However, I am mainly arguing for the syntax of DO&, and not my implementation. DO& syntax makes minimal, clean use of keywords has independent keywords, one per varspec indents reasonably I think that all the functionality of LOOP could be incorporated in this syntax.  Date: 2 February 1982 10:03-EST From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LOOP at MIT-MC cc: BUG-MACLISP at MIT-MC (loop for (ignore x) in pairs ...) doesn't ignore; however using () instead of ignore works. Is this the defined behavior for loop? [I realize that the ignore conventions aren't standardized across Lisps; perhaps the MacLisp compiler could be made to recognize ignore also.]  Date: 2 February 1982 10:03-EST From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LOOP at MIT-MC cc: BUG-MACLISP at MIT-MC (loop for (ignore x) in pairs ...) doesn't ignore; however using () instead of ignore works. Is this the defined behavior for loop? [I realize that the ignore conventions aren't standardized across Lisps; perhaps the MacLisp compiler could be made to recognize ignore also.]  Date: 27 January 1982 04:28-EST From: William G. Dubuque Sender: BIL at MIT-MC Subject: thereis weak To: MOON at MIT-MC, GSB at MIT-ML Date: 27 JAN 1982 0410-EST From: MOON (David A. Moon) To: WGD Re: thereis weak WGD@MIT-MC (Sent by BIL@MIT-MC) 01/26/82 06:18:44 Re: thereis weak To: (BUG loop) at MIT-ML Extending the "thereis" test to allow an "is predicate" would greatly increase its applicability. Please clarify. Sorry, thought it was obvious. Here's an example: (defun non-zero-random (bound) (loop until thereis (random bound) by #'non-zerop)) Grantedthis is a simple case and would be still quGrantquite simple without such functionality but in more complex cases it really improves readability.  WGD@MIT-MC (Sent by BIL@MIT-MC) 01/26/82 06:18:44 Re: thereis weak To: (BUG loop) at MIT-ML Extending the "thereis" test to allow an "is predicate" would greatly increase its applicability.  MOON@MIT-MC 12/15/81 15:36:23 Re: LIST turning into NCONS To: DLA at MIT-AI CC: GSB at MIT-AI, (BUG LISPM) at MIT-AI, (BUG LOOP) at MIT-AI Oops, sorry, I forgot that had been fixed.  Date: 15 December 1981 14:53-EST From: David L. Andre Subject: LOOP and CDR-codes To: DLA at MIT-AI, MOON at MIT-MC cc: GSB at MIT-AI, BUG-LISPM at MIT-AI, BUG-LOOP at MIT-AI MOON@MIT-MC 12/15/81 14:43:36 Re: LOOP and CDR-codes To: DLA at MIT-AI CC: GSB at MIT-AI, (BUG LISPM) at MIT-AI, (BUG LOOP) at MIT-AI Note that for some reason the compiler turns (LIST x) into (NCONS x). Not for me it don't.  MOON@MIT-MC 12/15/81 14:43:36 Re: LOOP and CDR-codes To: DLA at MIT-AI CC: GSB at MIT-AI, (BUG LISPM) at MIT-AI, (BUG LOOP) at MIT-AI Note that for some reason the compiler turns (LIST x) into (NCONS x). A new primitive for appending to a list in a cdr-coded fashion could be added. I don't know that it is worth it. I originally put in mechanisms by which list space could be allocated at decreasing addresses and CONS itself could do this, but never finished it (and flushed the underlying mechanisms, which complicated the microcode) when I decided that it was essentially useless.  Date: 15 December 1981 13:45-EST From: David L. Andre Subject: LOOP and CDR-codes To: GSB at MIT-AI, BUG-LISPM at MIT-AI, DLA at MIT-AI cc: BUG-LOOP at MIT-AI Actually there seems to me to be a much better alternative to this. I may be missing some basic implementational issue. If I am, tell me and I'll shut up. How about a new operation %RPLACD-NCONS , which does almost exactly what (CDR (RPLACD (NCONS ))) does now. The cdr is included free of charge to facilitate looping. The difference occurs when the cons being RPLACDed is the last one in the area. In such a case I see no reason why the CDR-codes couldn't just be twiddled around and the result be CDR-coded. It shouldn't make a difference whether had been CDR-coded or not, and it shouldn't affect the garbage collector at all because of the non-existence of CDR-LOCATION. The implementation need not be restricted to a new function. However, if RPLACD were made to check for this situation, it could only work when had CDR-NIL. This itself may be a win, because LIST could be used to explicitly CDR-code lists, and NCONS could be used when that's not the behavior you want. The advantage to %RPLACD-NCONS is that it would (presumably) always leave the last cons CDR-NEXT. Maybe the right thing is to have both. On the other hand, changing RPLACD's character to do this might cause inefficiencies in some programs which will now create many more invisible pointers.  Date: 12 December 1981 02:22-EST From: Glenn S. Burke Subject: LOOP and CDR-codes To: DLA at MIT-AI cc: BUG-LOOP at MIT-ML This idea has crossed various peoples minds at various times already. The problem with attempting to implement it is sort of twofold, involving both the way loop works, and the way it is implemented. The extreme dissociation of the "data sources" and "data sinks" in loop means that only in some intersection of simple special cases could this be done at all. This is, in my mind, not necessarily a good idea, because it means that not only will the code generation be different for "random" reasons, but it can also be annoying when one knows it can do this but it doesn't succeed in the optimization in some case where the user thinks it should. Not to mention the a priori assumption that cdr-next is preferred. [e.g.: i have seem certain system code bypass using COLLECT exactly because it did not produce cdr-coded lists and that was deemed necessary for efficiency reason. It's sort of gross for the loop to have to be kept deliberately simple in order for that to remain the same.] The implementation problem is simply that the manner in which code is generated in loop is, although done at a higher-level than it used to be, essentially just "instant code generation". Things are further complicated by the ability to do multiple collects into the same place... collects into the same place, for instance, means that you can't really tell until everything is over, and by then most the information has been lost. Actually, though, i still myself think the feature is worthwhile. If we were willing to get hairy, what could be done is this: the "collecting" is done into an art-q-list array with fill pointer, which is something maintained as a resource. Returning the collected frobozz means that the g-l-p simply gets copied. This unfortunately violates the general principle that if one collects "into var", that "var" has in it something interesting and meaningful during the entire iteration, even as it is being performed. I've certainly used this feature, but i must admit that it has haired up the implementation on occasion. Ah well, for a rainy day...  Date: 11 December 1981 07:55-EST From: David L. Andre Subject: LOOP and CDR-codes To: GSB at MIT-AI cc: BUG-LISPM at MIT-AI It would be nice if (LOOP FOR X IN L COLLECTING (F X)) and similar variations would hack CDR-codes. I realize that there are cases where this would be impossible, but the above form, for example, could expand into: (LET ((G0001 (MAKE-LIST (LENGTH L)))) (DO ((G0002 G0001 (CDR G0002)) (G0003 L (CDR G0003))) ((NULL G0002) G0001) (SETQ X (CAR G0003)) (RPLACA G0002 (F X)))) This would be more efficient than the current scheme, would work in any LISP which supports MAKE-LIST (I assume that's all of them with LOOP), and affords a real savings in consing when the list is long.  GSB@MIT-ML 12/09/81 22:17:44 To: (BUG LOOP) at MIT-ML One of the things i often find i want to do is to "overlay" several variables down a sequence; in the same way as (loop for (a b) on l by 'cddr), only for random sequences, like the array-elements path. The reason, of course, is that i'm trying to hide the implementation- dependence of something in LOOP (where in many cases it belongs), and it seems wasteful of time (mine and the computer's) to use two (or more) iterations to do this. Something to consider for the great iteration-redesign in the sky, i suppose.  GSB@MIT-ML 11/17/81 15:20:30 To: (BUG LOOP) at MIT-ML WJL@MIT-ML 11/17/81 10:03:47 Re: Loop How hard would it be to include a pseudo append kind of construct in loop? Say (loop for x in lst1 followed-by lst2 and lst3 do (foo x)) to accomplish (loop for x in (append lst1 lst2 lst3) do (foo x)). Perhaps one could even intermix lists and generating functions... -Bill  GSB@MIT-ML 10/29/81 22:59:01 Re: hack of the week To: (BUG LOOP) at MIT-ML Since i was too fried to do anything constructive yesterday, i spent the day fixing LOOP to run in Franz. Actually wasn't difficult at all; more a matter of causing the conditionalization in places to realize that the set {Maclisp NIL Lispm} didn't account for everything. The conditionalization should be a bit neater in a few places as a result; a couple generalizations.  MOON@MIT-MC 10/26/81 14:24:29 Re: Collection as a Lisp function To: DLW at MIT-MC CC: (BUG LOOP) at MIT-MC The reason you can't collect from Lisp code is not that Maclisp doesn't have COMPILER-LET; I was mistaken when I said that. The real reason is that Loop can't generate the code until it knows whether you are collecting and what sorts of collections you are doing. Thus any collection has to be lexically apparent. When there is a tool for walking through code doing macro expansion Loop could be made to use it, and insert translations of any collect statements it came across (some syntax for them would have to be invented); then after passing through all the code it would know what bindings, prelude, and epilogue to wrap around it.  Date: 25 October 1981 16:27-EDT From: Daniel L. Weinreb To: BUG-LOOP at MIT-AI cc: ALAN at MIT-AI, ACW at MIT-AI I just had a hard time with LOOP for a little while because ELSE takes a clause as an argument while FINALLY takes a form as an argument, and it is hard to keep track of which one you are supposed to use for which keyword in general. I continue to feel that the big problem with LOOP is that it is trying too much to be a programming language, and there are some things that you do in LOOP-language and others that you do in Lisp. I was only using ELSE because of the usual reason, namely that I can't do COLLECT in Lisp, which continues to bother me a lot.  GSB@MIT-ML 09/23/81 17:27:34 Re: iteration path featurefulness To: (BUG LOOP) at MIT-ML There should be a documented function which a user path-function can call, which produces an iteration down a list as if it were a sequence (with all the associated bells and whistles). In the simpler cases it could be as efficient as "for x in l". The reason for this would be so that one could use path functions for producing iterations over some datastructure which might be a list in one implementation, and an array or vector in another. e.g., (loop for arg being the &rest-arg-elements of rest ...). This should complement the documented (?) function which does performs the normal sequence iteration; i.e., itself be a path function (in terms of args and value).  GSB@MIT-ML 09/17/81 14:54:47 To: (BUG LOOP) at MIT-ML KWC@MIT-ML 09/17/81 14:12:23 It would be nice if there were a way of specifying to COUNT (in LOOP) what value to start from. (loop for x from 1 to 10 count x from 4) This might also be useful for COLLECT, APPEND, NCONC, MINIMIZE and so forth. (loop for x in lsb minimize x from 1000000) would return 1000000 if 1000000 is less than all the x's (or if there were no x's) This would provide a way of thresholding for free.  MOON@MIT-MC 09/09/81 02:21:55 Re: unending proliferation of featurettes To: GSB at MIT-ML CC: (BUG loop) at MIT-ML Well, this is all gross. I guess what's gross about it is that the user is controlling whether a step goes in the steps or the body (i.e. at the beginning or the end of the loop) without being allowed to say so explicitly. Blech. Syntax.  GSB@MIT-ML 09/08/81 13:39:09 Re: unending proliferation of featurettes To: (BUG LOOP) at MIT-ML Well, for a totally user-controlled iteration, we have essentially two major things: (1) where the user-supplied stepping code is the same for the first iteration as for all others (2) and where they are different. We may additionally modify these by allowing (a) the user to specify the initial value explicitly (b) the user to NOT specify the form for the first iteration (only for (2) however) The construct "for var = expr" is (1). "for var = this then that" is 2ab. "For var first this then that" is 2. For what you propose, for a minimal compatible extension, i would suggest not using THEN, because what you want is 1a. i.e., perhaps "initially expr" could be optionally used after the var, giving us 2 more hacks: for var initially init = expr [what you want] for var initially init first this then that and for gratuitous elegance (hahaha) for var initially init then expr which is equivalent to "for var = init then expr" ---- Comment? The documentation should be reorganized so as to present all of these as a block rather then just mixed in with the other FOR dispatches the way it is now. I guess these really aren't that gratuitous, since they are needed for user-coded "accumulations" etc.  MOON5@MIT-MC 09/07/81 16:55:31 Re: Feature? To: (BUG loop) at MIT-ML (loop ... as ch = ... unless (<= #/0 ch #/9) do (error ...) as result = 0 then (+ (* result 10.) (- ch #/0)) finally (return result)) ignores CH the first time around the loop rather than adding it into result. Parallel iteration doesn't work when that unless test needs to be in there. The only way that works now is to declare the initial value for result using WITH, and put the setting of result on a separate line. Suppose this were written (loop ... as ch = ... unless (<= #/0 ch #/9) do (error ...) as result initially 0 then (+ (* result 10.) (- ch #/0)) finally (return result)) where INITIALLY meant that it was initialized to that value and stepped every time around the loop, whereas FIRST means that it gets that value the first time and is stepped every time around the loop except for the first time. INITIALLY would be essentially an abbreviation for WITH. Is this worth it or just an unending proliferation of featurettes?  GSB@MIT-ML 09/01/81 02:43:15 Re: dtdcl etc. lossage To: (BUG LOOP) at MIT-ML CC: (BUG LSB) at MIT-ML Moon@MIT-AI 08/27/81 03:43:50 Would get better code if in the Lisp machine it used NIL rather than 0 as the throwaway value for variables which are lambda-bound and then immediately setq'ed to a number. In pdp-10 Maclisp it has to use 0 to avoid a compiler warning, as I recall. ---- The confusion which causes them to not be bound to NIL in the first place is really that it always uses the conceptual default-initial-value of the type rather than the default-initial-value of the primitive-type of the type. For an uninitialized value it should use the latter; for a to-be-seen-by-the-user default it should use the former (example of this being what LSB binds a typed user aux variable to, or what loop initializes an index variable to (the addition identity of that type)). I can fix all of this when i get psyched up to get my hands dirty.  GSB@MIT-ML 08/30/81 18:51:43 To: KWC at MIT-ML CC: (BUG LOOP) at MIT-ML KWC@MIT-ML 08/28/81 17:04:32 (loop for i in nil minimize i) returns 0. I really wish it would return the largest possible integer or error. There is no largest possible integer. I don't think it is reasonable to put in an error check for this automatically. Maybe however we should have some way to insert user exception code for when some collector which requires at least one use, didn't get it.  Moon@MIT-AI 08/27/81 03:43:50 To: (BUG LOOP) at MIT-AI Would get better code if in the Lisp machine it used NIL rather than 0 as the throwaway value for variables which are lambda-bound and then immediately setq'ed to a number. In pdp-10 Maclisp it has to use 0 to avoid a compiler warning, as I recall.  GSB@MIT-ML 08/12/81 16:25:25 Re: minor perturbation To: (BUG LOOP) at MIT-ML I macroified the (status feature) stuff, and added explicit feature removals, so that it will work in NIL. It compiles properly in ordinary maclisp so there shouldn't be any lispm or multics problems unless i managed to blow the features it sets up somehow.  GSB@MIT-ML 07/28/81 19:09:06 Re: multiple-value returns To: (BUG LOOP) at MIT-ML The documentation should be changed to say that to return multiple values you can do "return (values ...)" rather than "do (return ...)". I'll fix when i can get enough core to page in a teco buffer.  GSB@MIT-ML 07/25/81 23:54:17 Re: forwarded request for kludge To: (BUG LOOP) at MIT-ML CC: CWH at MIT-ML MOON@MIT-MC 07/25/81 02:20:19 Re: forwarded request for kludge GSB@MIT-ML 07/24/81 23:52:00 Re: forwarded request for kludge To: (BUG LOOP) at MIT-ML Date: 24 July 1981 02:20-EDT From: Carl W. Hoffman How about letting (LOOP FOR I BELOW N ...) be the same as (LOOP FOR I FROM 0 BELOW N ...) This should be put in, several other people have wanted it, including me. It seems to be intuitive. Apparently it was not only intuitive to humans, but to the code as well. (LOOP FOR I BELOW ...) and (LOOP FOR I TO ...) will work in some upcoming LOOP; all that was needed was the appropriate subdispatch entries for FOR. This will not work in the downward direction, although i can add the subdispatches so that the ABOVE or DOWNTO kwds can come first, in which case the error would be a "no starting point given" rather than a failing FOR subdispatch.  MOON@MIT-MC 07/25/81 02:20:19 Re: forwarded request for kludge To: GSB at MIT-ML GSB@MIT-ML 07/24/81 23:52:00 Re: forwarded request for kludge To: (BUG LOOP) at MIT-ML Date: 24 July 1981 02:20-EDT From: Carl W. Hoffman How about letting (LOOP FOR I BELOW N ...) be the same as (LOOP FOR I FROM 0 BELOW N ...) This should be put in, several other people have wanted it, including me. It seems to be intuitive.  GSB@MIT-ML 07/24/81 23:52:00 Re: forwarded request for kludge To: (BUG LOOP) at MIT-ML Date: 24 July 1981 02:20-EDT From: Carl W. Hoffman How about letting (LOOP FOR I BELOW N ...) be the same as (LOOP FOR I FROM 0 BELOW N ...)  GSB@MIT-ML 07/03/81 04:07:20 To: (BUG LOOP) at MIT-ML Date: 1 July 1981 20:47-EDT From: Alan Bawden Sender: DANNY at MIT-AI Subject: LOOP To: GSB at MIT-AI Having been burned several time writing things like this: (loop for x in l for n = 0 then (+ x n) finally (return n)) When I meant this: (loop for n = 0 then (+ x n) for x in l finally (return n)) (Note that it is the end-test that screws you, not the binding order.) I have come to the conclusion that this: (loop for x in l summing x) Does something that I cannot do easily. It seems that collection (summing, counting, maximizing, etc.) could be generalized to allow me to collect in some more general way. This do loop: (do ((l (mumble) (cdr l)) (n (init) (f (car l) n))) ((null l) n)) should easily translate into something like: (loop for x in (mumble) spazz n = (init) then (f x n)) Spazz would do two things for me: 1) Allow me to avoid the end-test screw noted above without having to write the clauses in a non-intuitive order. 2) Arrange to return the final value of n without a "finally (return ...)". Is this a good idea? Or am I wedged and there really is a better way of writing that DO in LOOP?  GSB@MIT-ML 06/26/81 16:02:46 Re: User definable generators To: (BUG LOOP) at MIT-ML Date: 26 Jun 1981 1341-EDT From: MARKT at MIT-XX Subject: User definable generators To: LH at MIT-ML, GSB at MIT-ML What do you think of "BUILD" as the keyword for a user defined 'accumulator'. For example, factorial could be LOOP FOR X FROM .A TO .B BUILD PRODUCT FROM .X {INTO ...}. Or, ...BUILD BINARY-TREE FROM .Y TESTING G?. I don't think the definitions would be as hairy as they are for defining generators. Maybe COLLECT .Z AS-A (VECTOR) could turn into BUILD VECTOR FROM .Z . -Mark -------  MOON@MIT-MC 06/25/81 15:37:21 Re: I doubt it, but... To: gsb at MIT-ML RWG@MIT-MC 06/25/81 04:44:32 To: (BUG LMMAN) at MIT-MC Perhaps it should be noted that (LOOP ... APPENDING L INTO LS ...) is really just NCONCING (COPYLIST L) INTO LS, thus avoiding n^2 conses, but screwing ... IF (= 3 (LENGTH LS)) DO (SETQ FOO LS) ... .  GSB@MIT-ML 06/18/81 15:14:39 Re: forwarded request-for-kludge To: (BUG LOOP) at MIT-ML Date: 18 June 1981 13:58-EDT From: Lowell B. Hawkinson How about having ONCE be just like LOOP except that it never loops. Specifically, (ONCE ...) is equivalent to (LOOP ... UNTIL T).  gsb@MIT-MC (Sent by JONL@MIT-MC) 06/15/81 18:54:11 Re: USING hack in sequence iteration To: (BUG LOOP) at MIT-MC (actually, in general) If the "variable" is null the using pair should be treated as if it isn't there. This will make it easier to use it in macros which just produce a LOOP template.  GSB@MIT-ML 06/13/81 17:05:41 Re: request for kludge To: WGD at MIT-MC CC: (BUG LOOP) at MIT-ML WGD@MIT-MC (Sent by BIL@MIT-MC) 06/13/81 00:17:37 Would it be ambiguous or undesirable for (loop ) => (loop do ) assuming doesn't begin with a loop keyword? It wouldn't really be ambiguous, but i don't think it is sufficiently useful to be worth having a special case. Part of the reason is that a more common case is (loop for this in that expr) where a "do" was meant to precede "expr". But "expr" gets parsed with "that" as a progn. (You are aware what the trivial case of (loop) gives? I find loop do a bit distasteful in such circumstances.) I believe (loop) is a fairly concise abbreviation for (do () (())), which is itself a good way to get a lisp to do a JRST . I suppose if you don't like this, you could refrain from using it, especially since it is not polite on a timesharing system.  WJL@MIT-ML 06/11/81 13:49:53 To: (BUG LOOP) at MIT-ML Perhaps the following should work: (loop for x in xx when (f x) when (g x) do (fg x) else else do (not-f x)) Currently, loop complains about the doubled elses.  Date: 10 Jun 1981 07:08:57-PDT From: CSVAX.jkf at Berkeley To: jane@cca-unix Subject: loop package Cc: CSVAX.fateman@Berkeley, gsb@mit-ml The LOOP package was copied from MIT and incorporated in our system because some random Macsyma implementor at MIT felt that a few functions were better written using it. We thus needed it for Vaxima. Version 120 of LOOP was copied over here on August 20, 1980 along with the latest document. I franzified it by making a quick pass over it, replacing strings by symbols (so eq tests would work), removing obscenities and useless code. The converstion was done in a hasty manner because we needed the code right away to complile a vaxima file. The conversion could be redone using conditional coding in such a way that the same file could be run on Franz lisp as well as Maclisp, lisp machine lisp, multics, etc, etc. We also converted the FOR package to work in Franz in order to run an Interlisp program. As I read the loop document, the designers of LOOP decided that rather than bridge the gap between Interlisp and the various MIT lisps, they would widen the chasm even more by doing the LOOP macro 'right'. In case your version of the LOOP macro document does not have the chapter on comptability with the FOR, I have included it below. I would be willing to send you a copy of the loop document associated with the code you have, as well as the unfranzified version 124 of the LOOP code so you can see what changes were necessary. - john foderaro  GSB@MIT-ML 06/05/81 16:49:52 Re: missing documentation To: DLW at MIT-AI CC: (BUG LOOP) at MIT-AI DLW5@MIT-AI 06/05/81 14:47:21 I was not able to figure out fromthe documentation how, if you are writing your own path of the "being expr and its path" variety, how you get at the "expr" from the path-functin. I was going to reply with a quote from the manual, but indeed the explanation was lost in the rewrite. I will fix this. The prep-phrases arg to the path function will be ((OF expr) ...).  DLW5@MIT-AI 06/05/81 14:47:21 To: (BUG LOOP) at MIT-AI I was not able to figure out fromthe documentation how, if you are writing your own path of the "being expr and its path" variety, how you get at the "expr" from the path-functin.  Date: 24 May 1981 12:33-EDT From: Daniel L. Weinreb Subject: looptm To: GSB at MIT-MC Well, it is a little weird for an example in the Lisp Machine Manual to be written in NIL, with a note telling you how you would change it were you writing for the Lisp Machine. I understand that you are writing the T.M. for all the dialects, but it does look a little funny in the Lisp Machine manual. I don't really mind it that much the way you've just edited it, but it would be even nicer if there were some way to conditionalize the source of LOOPTM so that it could generate the example in different dialects depending on whether the LMMAN or the stand-alone LOOPTM were being generated. If you feel like working on it, it would be nice to do that, but I'm satisfied enough with the way it is now. Thanks very much.  dlw@MIT-AI 05/24/81 13:11:56 Re: Feature LOOP To: (BUG LOOP) at MIT-AI OK, Loop fans, here is a new clause that would actually be useful in many cases. (loop for x from 0 below 10 cycle y from 3 to 5 do (print y)) => 3 4 5 3 4 5 3 4 You could have an optional "by" keyword too. Furthermore, (loop for x from 0 below 10 cycle y in '(foo bar baz) do (print y)) => foo bar baz foo bar baz foo bar  Date: 24 May 1981 02:01-EDT From: Daniel L. Weinreb Subject: LOOPTM To: GSB at MIT-AI There are two things I would like to see improved about the Loop T.M. before we run off the next Lisp Machine manual. The first thing is that the examples that appear on p 205 of the LMMAN are not so great, because they are Maclispy. The use of arraydims, funcall (instead of aref), error (instead of ferror), and vertical bars (instead of streams), are not really in accordance with what the rest of the manual tells you to do. The other things is that in the description of for var = expr1 then expr2 after "set to expr2", it should say "(re-evaluated)" just as it does in the description of for var first expr1 then expr2 because when RWG first noticed this discrepancy between the two descriptions, he assumed that THAT is what was different about the two. I would just edit this in myself except that I don't understand where the canonical source is (Moon told me that there would be a comment explaining that at the front of AI:LMMAN;LOOPTM >, but there wasn't one). I'd really appreciate if you could take care of this in the next few days, as we want to get a new revision of the manual out pretty soon. Thanks very much.  Date: 20 May 1981 03:46-EDT From: Bill Gosper To: BUG-LISPM at MIT-AI In System 68.18, ZMail 26.6, microcode 752, on Lisp Machine Two: loop needs push & pushing.  GSB@MIT-ML 05/14/81 17:56:24 To: (BUG LOOP) at MIT-ML I twiddled some modularization internally, if we want to make ALWAYS/NEVER (THEREIS?) work between iteration clauses they need only call LOOP-PSEUDO-BODY instead of LOOP-EMIT-BODY. RETURN already does this.  GSB@MIT-ML 05/14/81 16:43:54 Re: terminations To: (BUG LOOP) at MIT-ML CC: MMCM at MIT-ML perhaps the "aggregated boolean tests" should be allowed to be intermixed with iteration clauses. The following barfs (loop for i from 1 always (f i) for j from 3 ...) because the ALWAYS counts as being "body".  CWH@MIT-MC 05/12/81 17:07:01 To: (BUG loop) at MIT-ML How about letting (LOOP FOR I BELOW N ...) be the same as (LOOP FOR I FROM 0 BELOW N ...) This would make it almost as convenient as DOTIMES.  MOON@MIT-MC 05/12/81 01:48:55 Re: Your (BUG LOOP) To: MMCM at MIT-MC CC: (BUG LOOP) at MIT-MC MMCM@MIT-MC 05/11/81 23:05:15 To: (BUG LOOP) at MIT-MC (1) There should be a version of WHILE/UNTIL that does not execute the FINALLY clause, i.e. is just like WHEN DO (RETURN). ALWAYS and NEVER do this. They also make it return T instead of NIL if your FINALLY clause doesn't do a RETURN, which doesn't seem too important. (2) WHEN should ignore AS or WITH when computing its scope. E.g. (loop for x in l when (pred x) with tem do something) The way WHEN and AS interact now is more useful. It isn't documented but WHEN AS = conditionalizes the setting of . An iterating FOR/AS is not allowed in this context and signals an error. It already does what you request with WITH (as I was surprised to discover; this isn't documented). I'll remember to improve the documentation when I feel like writing unless Glenn does so first.  MMCM@MIT-MC 05/11/81 23:05:15 To: (BUG LOOP) at MIT-MC (1) There should be a version of WHILE/UNTIL that does not execute the FINALLY clause, i.e. is just like WHEN DO (RETURN). (2) WHEN should ignore AS or WITH when computing its scope. E.g. (loop for x in l when (pred x) with tem do something)  Moon@MIT-AI 04/07/81 17:59:09 Re: Moon grosses out! To: (BUG LOOP) at MIT-AI AI:LISPM2;LOOP 693 and AI:LMMAN;LOOPTM 301 provide if-then-else clauses, e.g. (LOOP FOR I FROM 1 TO 100 WHEN (ODDP I) COLLECT I INTO ODD-NUMBERS ELSE COLLECT I INTO EVEN-NUMBERS)  Moon@MIT-AI 04/04/81 02:55:08 To: (BUG LOOP) at MIT-AI Needs an if-then-else form of conditional keyword.  Date: 17 November 1980 1938-EST (Monday) From: Guy.Steele at CMU-10A To: gsb at MIT-ML, moon at MIT-MC Subject: LOOP Macro a Winner CC: lisp-forum at MIT-MC Message-Id: <17Nov80 193848 GS70@CMU-10A> I haven't much liked LOOP macros in the past, but I think I endorse this one (for whatever that is worth). A few points: (a) There is a "dangling AND" problem, similar to the "dangling ELSE" problem with IF-THEN-ELSE. Suppose I write: (LOOP FOR I IN LIST-OF-INTEGERS WHEN (ODDP I) DO (FORMAT T "~%~D is odd" I) AND WHEN (ZEROP (REMAINDER I 3)) DO (FORMAT T " and divisible by 3") AND (FORMAT T ".")) That is, I want to print a message if I is odd, and add something to the message if also divisible by 3. The message should always end in a period. However, the above evidently gets parsed as: (LOOP FOR I IN LIST-OF-INTEGERS WHEN (ODDP I) DO (FORMAT T "~%~D is odd" I) AND WHEN (ZEROP (REMAINDER I 3)) DO (FORMAT T " and divisible by 3") AND (FORMAT T ".")) That is, it resolves the ambiguity the same way dangling ELSEs usually are: the AND is attached to the *innermost* eligible construct. Unfortunately, LOOP doesn't provide BEGIN-END blocks or FI for resolving the other way. Would it be hard to let a FI or NEHW or SSELNU or ENDIF or something terminate the innermost conditional? Then I could write: (LOOP FOR I IN LIST-OF-INTEGERS WHEN (ODDP I) DO (FORMAT T "~%~D is odd" I) AND WHEN (ZEROP (REMAINDER I 3)) DO (FORMAT T " and divisible by 3") NEHW AND (FORMAT T ".")) and expect it to work as desired. (Actually, would it be hard to add an ELSE as well? (LOOP ... IF x ... ELSE ...) would be about the same as (LOOP ... IF x ... UNLESS x ...) except for not evaluating x twice. You could allow THEN to be a gratuitous buzzword. But I won't be disappointed if you turn this down: that way lies madness (or at least PL/I).) (b) I propose that a form NAMED be added for naming the loop for use with RETURN-FROM: (LOOP NAMED SUE FOR HORRIBLE-THING IN CAVE ... (LOOP ... (RETURN-FROM SUE ...) ...) ...) (c) How about an easy way to declare new kinds of collecting LOOP forms? (That way I don't have to bug you to add my favorites.) Examples: (DEFINE-LOOP-COLLECTOR (NRECONC NRECONCING) NRECONC () T) (DEFINE-LOOP-COLLECTOR (MULTIPLY MULTIPLYING) TIMES 1 T) (DEFINE-LOOP-COLLECTOR (MAXIMIZE MAXIMIZING MAXING) MAX 0 ()) (DEFINE-LOOP-COLLECTOR (COLLECT-UNIQUE COLLECTING-UNIQUE) CONS-UNIQUE () T) where (DEFUN CONS-UNIQUE (X Y) (IF (MEMQ X Y) Y (CONS X Y))) Here we have the general form (DEFINE-LOOP-COLLECTOR ) where and are obvious, is the value if zero things are collected, and is a truth value: non-() means the value after collecting one thing is the result of applying to the thing and the , while () means the value after collecting just one thing is the thing itself. Maybe this isn't general enough, but you get the idea of what I want. CONSING would be like COLLECTING but would produce a reversed list. UNIONING and INTERSECTING would also be useful. (I realize that one can get those by writing some parentheses, but...)  Date: 15 December 1980 20:27-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI Subject: brain rot (loop) To: GSB at MIT-ML, MOON at MIT-ML, PSZ at MIT-ML I think it is impossible to win completely in this case. Suppose you have two FOR clauses, both of which step with side effects, and both of which have an end test. LOOP cannot know which will terminate first, and so in half the cases it will have to step one of them where the other one's stepping ends the loop. Some kinds of iteration are simply *defined* to do the end-test after stepping; you can't really get around this. These cases mostly seem to obscure to worry about anyway.  LH@MIT-ML 01/08/81 09:45:19 Synonyms for prepositions sounds useful. Checking for duplication is perhaps overly thorough and does impose limitations, as you point out, though I have no personal need for duplication.... Lowell  Moon@MIT-AI 01/09/81 02:50:16 Re: dlw's bug-loop To: gsb at MIT-ML Here's a random idea: if loop makes a progn with more than one form, and the first form is an atom, it should issue a "probably missing keyword" warning. GSB@MIT-ML 03/14/81 21:22:51 To: BYRON at MIT-ML CC: (BUG LOOP) at MIT-ML, WAM at MIT-ML, PSZ at MIT-ML BYRON@MIT-ML 03/14/81 14:40:59 Did you know that LOOP has been converted to Franz Lisp? No... Interesting...  Moon@MIT-AI 03/14/81 03:33:08 Re: new versions of your files To: gsb at MIT-ML AI:LMMAN;LOOPTM 297, LOOPTM LISPM  Date: 8 March 1981 0225-est From: Carl Hoffman Subject: loop To: GSB at MIT-ML Just looking through the copy of the loop source on Multics. Most of the hair you have at the head of the file for the conditionalization on Multics is no longer necessary. You can get by with (eval-when (eval compile) (or (status feature Multics) (read))) (%include lisp_prelude) and everything should work correctly. You can even flush these lines if you don't mind using nlcp instead of lcp to compile the file. lisp_prelude pulls in backquote, sharpsign, defmacro, and most of the commonly used stuff. Granted this takes a little longer than loading only what you need, but its simpler. lisp_dcls isn't needed since you don't reference any exprs. All features used by loop are read-time or compile-time. I believe that (declare (read)) now works on the Lisp Machine. This is lucky, too, since it is going to be a long time before # is on by default in Multics Lisp. I was somewhat grossed out by the quantity of #+ #- hair in the source. Isn't it possible to isolate all that stuff into one section which deals with interfacing to each different system? Although I am certainly aware of the vast number of incompatibilities. Perhaps it simply wasn't worth the effort? I can sympathize with that, too, looking back on the quick and dirty job I did on Macsyma. I haven't installed the new loop yet since I didn't understand the pointer to lisp_dtdcl_ in the object segment. Dlos loop to see what I'm referring to. moon@MIT-AI (Sent by dlw@MIT-AI) 02/19/81 02:00:53 To: (BUG LOOP) at MIT-AI Please merge back in the change in AI:LISPM2;LOOP 691, which causes (LOOP FOR X FROM 0 BY (JHSHJGSHJG)) not to expand incorrectly.  GSB@MIT-ML 02/13/81 05:28:32 Re: #+Lispm interned-symbols To: (BUG LOOP) at MIT-ML Moon@MIT-AI 02/13/81 04:19:22 In LOOP 690 (loop for x being the interned-symbols of "si" collect x) expands into amazing shit with an unexpanded backquote in it, which should have generated a multiple-value of the appropriate stepping function. ---- should be fixed in version 691.  Moon@MIT-AI 02/13/81 04:19:22 To: (BUG LOOP) at MIT-AI In LOOP 690 (loop for x being the interned-symbols of "si" collect x) expands into amazing shit with an unexpanded backquote in it, which should have generated a multiple-value of the appropriate stepping function. the using clause works  GSB@MIT-ML 02/02/81 18:12:11 Re: declaration hack To: BMT at MIT-ML CC: (BUG LOOP) at MIT-ML The next loop (when the loop cataclysm occurs, which is either when the TM comes out [it's "in press"] or when Martin starts to define iteration paths, whichever comes first) will have a NODECLARE clause to cause declaration inhibition: (loop nodeclare (k) as k fixnum = (f) ...) It takes a single "form" only which MUST be a list of variable names. It will NOT be complicated by hairy syntax checking; it exists solely to compensate for various compiler lossages wrt local declarations. p.s. There have been many changes since a loop has been brought up on multics, so it may be a while. But i don't really anticipate any lossages, since there is very little multics-only code: this loop will do its own destructuring if necessary (this is working on the lispm), and the "dumb" collect code has been pretty well tested in the pdp-10 -> nil version.  MOON@MIT-MC 01/28/81 15:47:36 Re: type names in LOOP To: GSB at MIT-ML GSB@MIT-ML 01/26/81 11:11:36 To: (BUG LOOP) at MIT-ML is it reasonable to accept any type name as a data-type keyword? Driven off of (status spcnames) in maclisp, the typep alist or whatever in lispm? [it happens that (eq (status spcnames) (status spcnames)) => T] [This is suprising?] That would be the best basis for dummy data-types, like (loop for x array in l do ...) Seems random to me. There is no way in the Lisp machine to get a list of all types, since there can be arbitrary user-defined types. (I suppose you could mapatoms and check for half a dozen different properties...) If it isn't going to do anything useful with the type name there it seems kind of useless to have it.  Date: 28 January 1981 14:16-EST From: Mike McMahon Subject: USING To: GSB at MIT-ML cc: Moon at MIT-MC Maybe paths could be allowed to return (variable expression data-type what-it-is) and then USING (what-it-is known-variable) would SUBST known-variable for variable. So, ARRAY-ELEMENTS would return (G0001 expression FIXNUM INDEX) and you could write: (LOOP FOR ELEM BEING THE ARRAY-ELEMENTS OF ARRAY USING (INDEX I) DO (FORMAT T "~&Elem #~D = ~S~%" INDEX ELEM)) or something like that.  GSB@MIT-ML 01/26/81 11:11:36 To: (BUG LOOP) at MIT-ML is it reasonable to accept any type name as a data-type keyword? Driven off of (status spcnames) in maclisp, the typep alist or whatever in lispm? [it happens that (eq (status spcnames) (status spcnames)) => T] That would be the best basis for dummy data-types, like (loop for x array in l do ...)  GSB@MIT-ML 01/26/81 02:45:21 Re: documentation To: (BUG LOOP) at MIT-ML RETURN should explain the proper alternative for returning values from the epilogue  CARLF@MIT-AI 01/25/81 21:13:26 To: (BUG LOOP) at MIT-AI Loop seems to be working again. Thank you for your help, and also for devising the marvelously useful and clear loop function.I use it often, and it is nifty.  GSB@MIT-ML 01/23/81 16:35:13 To: CARLF at MIT-AI CC: (BUG LOOP) at MIT-AI CARLF@MIT-AI 01/23/81 15:48:27 Yesterday loop worked. Now it dosen't. The example of destructuring given at the bottom of section 5 of lsbdoc; looptm causes an error. I am on cadr-1 with system 55.15. -- carl That system contains an old loop which does not properly support destructuring. System 56 seems to fix it. I guess if you are running an old one reload in LISPM2;LOOP, i don't know if this is in a patch or not.  CARLF@MIT-AI 01/23/81 15:48:27 To: (BUG LOOP) at MIT-AI Yesterday loop worked. Now it dosen't. The example of destructuring given at the bottom of section 5 of lsbdoc; looptm causes an error. I was using precisely such a "for (... ...) on ... by 'cddr" construction in a function which fouled up today, although it worked fine yesterday. The function is (make) in setnet; prop >. For your convenience, the example in the documentation is kept in setnet; loop screwd. Please destroy that file when you are done, or if you do not need it. I am on cadr-1 with system 55.15. -- carl  Moon@MIT-AI 01/22/81 01:52:31 Re: WITH loses To: GSB at MIT-ML CC: (BUG LOOP) at MIT-ML, JLK at MIT-MC GSB@MIT-ML 01/21/81 11:16:52 Re: WITH loses To: JLK at MIT-MC CC: (BUG LOOP) at MIT-ML JLK@MIT-MC 01/20/81 23:16:12 In the version of loop in System 56.12, ZMail 14.0, microcode 720, on Lisp Machine Six: Is it a feature that (LOOP WITH FOO FOR ...) no longer works (i.e. an explicit = is required)? Bug. I put an interim fix in the loop source on AI:LISPM2;, in the function LOOP-DO-FOR. Needs to be recompiled or made into a patch. You mean LOOP-DO-WITH. Patched in 56.18.  GSB@MIT-ML 01/21/81 11:16:52 Re: WITH loses To: JLK at MIT-MC CC: (BUG LOOP) at MIT-ML JLK@MIT-MC 01/20/81 23:16:12 In the version of loop in System 56.12, ZMail 14.0, microcode 720, on Lisp Machine Six: Is it a feature that (LOOP WITH FOO FOR ...) no longer works (i.e. an explicit = is required)? Bug. I put an interim fix in the loop source on AI:LISPM2;, in the function LOOP-DO-FOR. Needs to be recompiled or made into a patch.  JLK@MIT-MC (Sent by HIC@MIT-MC) 01/20/81 23:16:57 To: (BUG LOOP) at MIT-MC Sorry, that last message was from JLK not HIC  HIC@MIT-MC 01/20/81 23:16:12 To: (BUG LOOP) at MIT-MC In the version of loop in System 56.12, ZMail 14.0, microcode 720, on Lisp Machine Six: Is it a feature that (LOOP WITH FOO FOR ...) no longer works (i.e. an explicit = is required)?  Moon@MIT-MC 01/14/81 23:15:04 To: (BUG LOOP) at MIT-MC In the version of LOOP in System 56.3, microcode 720, on Lisp Machine Six: Uses the undefined functions INITIAL-VALUE and VARIABLE-DECLARATIONS. I guess it checks whether they are fbound? Are these part of the optional type declaration mechanism?  MMCM@MIT-AI 01/09/81 20:18:19 Re: howzzat? To: (BUG LOOP) at MIT-AI #-FM (globalize "LOOP" ; Major macro "LOOP-FINISH" ; Handy macro "DEFINE-LOOP-PATH" ; for users to define paths "DEFINE-LOOP-SEQUENCE-PATH" ; this too ) Lisp Machines don't have FM, just a little beeper. That isn't the way our globalize function works.  GSB@MIT-ML 01/09/81 16:19:27 To: MMcM at MIT-AI CC: (BUG LOOP) at MIT-AI MMcM@MIT-AI 01/09/81 14:55:27 AI: LISPM2; LOOP QFASL created 01/09/81 01:43:30, compiled from AI: LISPM2; LOOP 576. Gets an error message for (LOOP FOR A IN L AS I UPFROM 1 ...) "illegal prep in sequence path". fixed, needs to be recompiled.  MMcM@MIT-AI 01/09/81 14:55:27 To: (BUG LOOP) at MIT-AI In the version of loop in System 55.12, ZMail 10.0, microcode 715, on Lisp Machine Six: AI: LISPM2; LOOP QFASL created 01/09/81 01:43:30, compiled from AI: LISPM2; LOOP 576. Gets an error message for (LOOP FOR A IN L AS I UPFROM 1 ...) "illegal prep in sequence path".  dlw@MIT-AI 01/08/81 22:05:55 To: (BUG LOOP) at MIT-AI If you try to evaluate the following mistake: (loop for x from 0 to 5 (loop for y from 0 to 5 do (print (cons x y)))) no error is signalled during the expansion of the loop macro. The 5 followed by the second attempted loop form are taken to be two forms inside a progn! This was pretty confusing when it happened. Is the above actually supposed to be valid code in the syntax of loop? It seems like it ought to be an error.  Date: 6 January 1981 20:15-EST From: Glenn S. Burke To: MMcM at MIT-AI cc: MOON at MIT-MC, BUG-LOOP at MIT-MC Date: 22 December 1980 15:56-EST From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI MOON@MIT-MC 12/22/80 02:50:34 MMcM@MIT-AI 12/21/80 22:58:53 I wrote (LOOP FOR ZOT IN '(A B C) DO (PRINT T) AS FOO = (PRINT ZOT) COLLECT FOO) originally, which gives an error message. You can use (loop for zot in '(a b c) as foo = (print t) (print zot) collect foo) to get side effects into iterations, i.e. wherever one form is allowed you can have many as long as they are non-atomic. Nope. That gives an different error message (which in this case is not spurious), it seems to only allow single forms there. I could use (progn (print t) (print zot)) of course, but it's easier to just ignore the error message and stick with what i had originally if it will be fixed by XLOOP. The FOR/AS parser should be calling LOOP-GET-FORM. This is fixed in the source, can someone change the setq of FIRST-ARG in LOOP-DO-FOR from (POP LOOP-SOURCE-CODE) to be (LOOP-GET-FORM) on the lispm? As for (hohoho) the other stuff, "AS x = expr1 {THEN expr2}" should work in XLOOP after non-iteration stuff.  MMcM@MIT-AI 12/24/80 20:10:08 To: (BUG LOOP) at MIT-AI There should be a keyword NAMED which generated a PROG exit tag.  Date: 22 December 1980 15:56-EST From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI To: MOON at MIT-MC cc: BUG-LOOP at MIT-MC MOON@MIT-MC 12/22/80 02:50:34 MMcM@MIT-AI 12/21/80 22:58:53 I wrote (LOOP FOR ZOT IN '(A B C) DO (PRINT T) AS FOO = (PRINT ZOT) COLLECT FOO) originally, which gives an error message. You can use (loop for zot in '(a b c) as foo = (print t) (print zot) collect foo) to get side effects into iterations, i.e. wherever one form is allowed you can have many as long as they are non-atomic. Nope. That gives an different error message (which in this case is not spurious), it seems to only allow single forms there. I could use (progn (print t) (print zot)) of course, but it's easier to just ignore the error message and stick with what i had originally if it will be fixed by XLOOP.  MOON@MIT-MC 12/22/80 02:50:34 To: MMcM at MIT-AI CC: (BUG LOOP) at MIT-MC MMcM@MIT-AI 12/21/80 22:58:53 To: (BUG LOOP) at MIT-AI I cannot see how to cause a iteration form to be computed after a side-effect. I wrote (LOOP FOR ZOT IN '(A B C) DO (PRINT T) AS FOO = (PRINT ZOT) COLLECT FOO) originally, which gives an error message. The error message is spurious in this case, because as var = form is not really an iteration, but just a combination of a declaration of local variable and a setq to go in the body. Unfortunately there is a bug in the error checking, which I think is fixed in XLOOP, which is not yet quite ready to be installed. If the thing after the do had been a real iteration, proceeding from the error would not have done what you would have expected, which is why the error check is there. You can use (loop for zot in '(a b c) as foo = (print t) (print zot) collect foo) to get side effects into iterations, i.e. wherever one form is allowed you can have many as long as they are non-atomic.  MMcM@MIT-AI 12/21/80 22:58:53 To: (BUG LOOP) at MIT-AI I cannot see how to cause a iteration form to be computed after a side-effect. I wrote (LOOP FOR ZOT IN '(A B C) DO (PRINT T) AS FOO = (PRINT ZOT) COLLECT FOO) originally, which gives an error message. However, if i proceed the error, i get T A T B T C => (A B C). This is exactly what i wanted. Perhaps the error message is entirely spurious?  Moon@MIT-AI 12/16/80 02:27:37 Re: XLOOP on the Lisp machine To: (BUG LOOP) at MIT-AI It works somewhat, but you need the latest version of STATUS in order for the conditionalization to work. I have not made this a system patch (yet). Get it with meta-. if you work on loop again.  Date: 15 December 1980 00:16-EST From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: GSB at MIT-ML cc: BUG-LOOP at MIT-ML GSB@MIT-ML 12/14/80 23:39:47 MMcM@MIT-AI 12/14/80 20:25:42 The function TVBUG in LMDEMO;DLWHAK gets an error expanding some complicated DESETQ. The source seems to be suffering a bit of Brain Damage. I presume you got the error "LOOP can't hack this desetq"? I will fix the place which makes this check, which it is doing totally wrong. In the meantime i guess i'll test out a more recent source (with lots of changes, including doing the destructuring stuff better). Can you recompile and try the one i just wrote out? The one you just wrote gets the same error. LOOP-TRANSLATE is called with (LOOP FOR (A1 A2) ON *TVBUG-ARRAYS* AS XOR = (MAKE-ARRAY NIL 'ART-1B '(40 41)) DO (BITBLT TV:ALU-SETA 40 40 A1 0 0 XOR 0 1) (BITBLT TV:ALU-XOR 40 40 (OR A2 (CAR *TVBUG-ARRAYS*)) 0 0 XOR 0 0) COLLECT XOR) This calls LOOP-TRANSLATE-1 with (LOOP FOR (A1 A2) ON ...) Which calls LOOP-DO-FOR, which calls LOOP-MAKE-PSETQ with ((A1 A2) G1192) This calls LOOP-MAKE-SETQ with (A1 A2) and G1192. Which tries to call LOOP-MAKE-DESETQ with too many arguments, namely (A1 A2) and G1192.  MOON@MIT-MC 12/14/80 23:42:40 To: MMcM at MIT-AI CC: (BUG LOOP) at MIT-AI MMcM@MIT-AI 12/14/80 20:25:42 To: (BUG LOOP) at MIT-AI The function TVBUG in LMDEMO;DLWHAK gets an error expanding some complicated DESETQ. This is probably because a new experimental source that somehow got onto the LISPM2 directory was compiled. It should be set back to the old version until Glenn is done changing it.  GSB@MIT-ML 12/14/80 23:39:47 To: MMcM at MIT-AI CC: (BUG LOOP) at MIT-ML MMcM@MIT-AI 12/14/80 20:25:42 The function TVBUG in LMDEMO;DLWHAK gets an error expanding some complicated DESETQ. The source seems to be suffering a bit of Brain Damage. I presume you got the error "LOOP can't hack this desetq"? I will fix the place which makes this check, which it is doing totally wrong. In the meantime i guess i'll test out a more recent source (with lots of changes, including doing the destructuring stuff better). Can you recompile and try the one i just wrote out?  MMcM@MIT-AI 12/14/80 20:25:42 To: (BUG LOOP) at MIT-AI The function TVBUG in LMDEMO;DLWHAK gets an error expanding some complicated DESETQ.  GSB@MIT-ML 12/13/80 16:17:17 Re: desetq To: (BUG LOOP) at MIT-ML do we want that #Q (or (fboundp 'desetq) (fset 'desetq #'loop-desetq)) ? It won't come out in the "right" package anyway if DESETQ isn't defined, and it isn't used in loop either.  BMT@MIT-MC 12/10/80 14:53:49 To: (BUG LOOP) at MIT-MC The file mc:rat;loop > contains a usage of loop which compiled correctly on Dec. 4, but now gives the error message for/as not allowed in body. I understand the potential ambiguity of other types of for clauses mixed in the body, but I need a suggestion about what to do in this case. jpg wants to recreate a macsyma now, but can't until either loop is changed, or this application is changed.  GSB@MIT-ML 12/10/80 01:10:26 To: BMT at MIT-MC CC: (BUG LOOP) at MIT-MC BMT@MIT-MC 12/09/80 22:57:53 (loop if (f) return (g) for k = (h)) gives an error about for clauses after the body, but this construct used to work, I think, since the file rat;loop > contains an example which has previously compiled but will no longer. Although this example probably behaved the way it looks like it should, more general cases of FOR following any other "significant" body code generally fail in obscure ways. Once upon a time this was detected and diagnosed, but the diagnosis got lost somewhere along the way with the addition of other features. If that is the ordering you desire you can use (loop for k = then (h) if ...), but stepping in the middle is more difficult unless specially hacked. Perhaps since it seems to be meaningful to both place this particular clause in all sorts of places (including inside conditionals) there should be a non-FOR clause which does this which is allowed to be put in the exact place where the stepping is desired.  BMT@MIT-MC 12/09/80 22:57:53 To: (BUG LOOP) at MIT-MC (loop if (f) return (g) for k = (h)) gives an error about for clauses after the body, but this construct used to work, I think, since the file rat;loop > contains an example which has previously compiled but will no longer.  GSB@MIT-ML 12/08/80 16:29:25 Re: brain damage on my part To: (BUG LOOP) at MIT-ML This maximize/minimize business.... What happens now is essentially (SETQ VAL ) (SETQ MAX (COND (FLAG (MAX VAL MAX)) (T VAL))) As to the business about maybe-open-coding-it-if-we-are-in-a-lisp-which- loses-badly-and-the-user-declares-it-to-be-a-fixnum-or-a-flonum, is there any reason to not simply code it as (SETQ VAL ) (AND (OR (NOT FLAG) (GREATERP VAL MAX)) (SETQ MAX VAL)) and let the compiler handle the hackery? Dave? I'm sure there isn't any reason in Maclisp. (What about GREATERP vs > on lispm? Any b.s. like we had with ADD1?)  Date: 6 December 1980 23:08-EST From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI To: BUG-LOOP at MIT-ML Sorry if I already sent this; I can't remember if I did or not. I'd like a LOOP keyword that would circulate around a list, so that if you gave it the list (1 2 3) then a varible could assume the values 1, 2, 3, 1, 2, 3, 1....  GSB@MIT-ML 12/06/80 08:26:37 To: (BUG LOOP) at MIT-ML should check for multiple clauses attempting to make the loop return a value  GSB@MIT-ML 12/06/80 07:45:56 Re: You may remember this "bug" To: BMT at MIT-ML, DLW at MIT-ML CC: (BUG LOOP) at MIT-ML I have implemented the FIRST variant of FOR. It allows one to do (loop for term in poly for ans first (car term) then (gcd ans (car term)) finally (return ans)) I decided that this was worthwhile to have, since it allows one to do this kind of sequencing nicely. The overhead on the 10 i would guess to be 1 extra instruction and two words for binding the flag, a test and an out-of-line jump to set the variable on each iteration, and one instruction to clear the flag. There is at most one such flag in each LOOP, so adding more of these clauses only adds that check for stepping the variable. I will install this eventually, leaving enough time for me to get jumped on for it. I'm revising the documentation, and this will be appropriately juxtaposed with the doc of "for v = x1 then x2", which itself will have its shortcomings more clearly delineated...  GSB@MIT-ML 12/06/80 07:12:53 To: (BUG LOOP) at MIT-ML Don't forget to implement FOR var FIRST expr1 THEN expr2 glenn...  Date: 2 December 1980 15:41-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-LOOP at MIT-ML In the version of LOOP in System 50.17, ZMail 5.6, microcode 701, on LISP Machine Six: (1) I'd really like a kind of clause that is like for x in '(1 2 3) except that when it gets to the end of the list, it starts all over again, so that x takes on the values 1, 2, 3, 1, 2, 3, 1, etc. (2) The section in the documentation about how to define your own path is very hairy; I think that as it stands it is not too helpful, but with a few examples it would be a whole lot better.  CWH@MIT-MC 12/02/80 09:50:04 Re: More on random thoughts about LOOP To: (BUG LOOP) at MIT-ML MOON@MIT-MC 12/01/80 00:24:28 Re: Your random thoughts about LOOP Well the following moderate piece of grossness works: (loop for x in l1 as sw = t for x in l2 do (setq sw nil) ... finally (return sw)) Returns T if l2 is shorter, NIL if l1 is shorter or they are the same. Perhaps this could be improved slightly. Thanks for the suggestions. They happen to satisfy my immediate need. What I had in mind, though, was an "exit-form" clause for "for", as the "end-test" clause is already taken care of, i.e. something like (loop for x in l1 exit-form 'l1-ran-out for y in l2 exit-form 'l2-ran-out for i from 1 to n exit-form 'more-than-n-elements collect (cons x y)) where some sufficiently English-sounding keyword would be substituted for "exit-form".  GSB@MIT-ML 12/01/80 17:43:48 Re: bleagh! To: (BUG LOOP) at MIT-ML Ramesh just got a PURPG because he has some macro code which contained the expression "(LOOP-FINISH)", which when evaluated interpreted attempted to displace itself. I guess i'll just redefine LOOP-FINISH to not displace, since it is so simple (ie, bypass DEFMACRO).  MOON@MIT-MC 12/01/80 00:24:28 Re: Your random thoughts about LOOP To: CWH at MIT-MC CC: (BUG loop) at MIT-ML CWH@MIT-MC 11/30/80 18:41:20 Re: Some random thoughts ... * I'd like some way of making the return value conditional on how the loop terminated, i.e. if iterating down two lists at a time, I want to return one value if the first list runs out, and a different value if the second list runs out. Well the following moderate piece of grossness works: (loop for x in l1 as sw = t for x in l2 do (setq sw nil) ... finally (return sw)) Returns T if l2 is shorter, NIL if l1 is shorter or they are the same. Perhaps this could be improved slightly.  CWH@MIT-MC 11/30/80 18:41:20 Re: Some random thoughts To: (BUG loop) at MIT-ML * How about a "times" keyword, for performing an iteration n times without explicitly naming an index variable, i.e. (DEFUN TERPRI-N (N) (LOOP TIMES N DO (TERPRI))) * I'd like some way of making the return value conditional on how the loop terminated, i.e. if iterating down two lists at a time, I want to return one value if the first list runs out, and a different value if the second list runs out.  MOON@MIT-MC 11/19/80 15:48:58 Re: KMP loses To: (BUG LOOP) at MIT-MC I don't find any of his criticisms particularly cogent. However, LOOP should check for two variables with the same name. It used to rely on the Lisp system to do so, but then it was changed so that it no longer declared all of the local variables as PROG variables of a single PROG, and we forgot that it now needs to do the check itself. This is simply a bug, and KMP's many examples that cause strange things to happen by exploiting the bug aren't significant.  Date: 17 November 1980 1938-EST (Monday) From: Guy.Steele at CMU-10A To: gsb at MIT-ML, moon at MIT-MC Subject: LOOP Macro a Winner CC: lisp-forum at MIT-MC Message-Id: <17Nov80 193848 GS70@CMU-10A> I haven't much liked LOOP macros in the past, but I think I endorse this one (for whatever that is worth). A few points: (a) There is a "dangling AND" problem, similar to the "dangling ELSE" problem with IF-THEN-ELSE. Suppose I write: (LOOP FOR I IN LIST-OF-INTEGERS WHEN (ODDP I) DO (FORMAT T "~%~D is odd" I) AND WHEN (ZEROP (REMAINDER I 3)) DO (FORMAT T " and divisible by 3") AND (FORMAT T ".")) That is, I want to print a message if I is odd, and add something to the message if also divisible by 3. The message should always end in a period. However, the above evidently gets parsed as: (LOOP FOR I IN LIST-OF-INTEGERS WHEN (ODDP I) DO (FORMAT T "~%~D is odd" I) AND WHEN (ZEROP (REMAINDER I 3)) DO (FORMAT T " and divisible by 3") AND (FORMAT T ".")) That is, it resolves the ambiguity the same way dangling ELSEs usually are: the AND is attached to the *innermost* eligible construct. Unfortunately, LOOP doesn't provide BEGIN-END blocks or FI for resolving the other way. Would it be hard to let a FI or NEHW or SSELNU or ENDIF or something terminate the innermost conditional? Then I could write: (LOOP FOR I IN LIST-OF-INTEGERS WHEN (ODDP I) DO (FORMAT T "~%~D is odd" I) AND WHEN (ZEROP (REMAINDER I 3)) DO (FORMAT T " and divisible by 3") NEHW AND (FORMAT T ".")) and expect it to work as desired. (Actually, would it be hard to add an ELSE as well? (LOOP ... IF x ... ELSE ...) would be about the same as (LOOP ... IF x ... UNLESS x ...) except for not evaluating x twice. You could allow THEN to be a gratuitous buzzword. But I won't be disappointed if you turn this down: that way lies madness (or at least PL/I).) (b) I propose that a form NAMED be added for naming the loop for use with RETURN-FROM: (LOOP NAMED SUE FOR HORRIBLE-THING IN CAVE ... (LOOP ... (RETURN-FROM SUE ...) ...) ...) (c) How about an easy way to declare new kinds of collecting LOOP forms? (That way I don't have to bug you to add my favorites.) Examples: (DEFINE-LOOP-COLLECTOR (NRECONC NRECONCING) NRECONC () T) (DEFINE-LOOP-COLLECTOR (MULTIPLY MULTIPLYING) TIMES 1 T) (DEFINE-LOOP-COLLECTOR (MAXIMIZE MAXIMIZING MAXING) MAX 0 ()) (DEFINE-LOOP-COLLECTOR (COLLECT-UNIQUE COLLECTING-UNIQUE) CONS-UNIQUE () T) where (DEFUN CONS-UNIQUE (X Y) (IF (MEMQ X Y) Y (CONS X Y))) Here we have the general form (DEFINE-LOOP-COLLECTOR ) where and are obvious, is the value if zero things are collected, and is a truth value: non-() means the value after collecting one thing is the result of applying to the thing and the , while () means the value after collecting just one thing is the thing itself. Maybe this isn't general enough, but you get the idea of what I want. CONSING would be like COLLECTING but would produce a reversed list. UNIONING and INTERSECTING would also be useful. (I realize that one can get those by writing some parentheses, but...)  GSB@MIT-ML 10/27/80 02:16:19 Re: IF To: BMT at MIT-ML CC: (BUG LOOP) at MIT-ML Looks like an oversight, IF appears to not be defined as a loop keyword. I'll fix and install tomorrow afternoon, i'm excruciatingly busy for hte next 10 hours  BMT@MIT-MC 10/27/80 02:10:54 To: (BUG LOOP) at MIT-MC according to my loop doc. if and when should be synonimous, but (loop if a do b) gives an error about macros not permitted during expansion, while (loop when a do b) is fine.  GSB@MIT-ML 10/09/80 04:50:12 Re: FOR v = x1 THEN x2 To: DLW at MIT-AI CC: (BUG LOOP) at MIT-AI I see the problem. (Synchronization... Now that i think of it i'm surprised it didn't come up before.) I believe i have a solution to this, which will also fix certain other misunderstandings which have cropped up with this construct. I want to discuss it with dave, but not until i have time to. I'm not sure if changing it to what it should have been in the first place will break things or not...  DLW@MIT-AI (Sent by DLW5@MIT-AI) 10/09/80 02:27:43 To: (BUG LOOP) at MIT-AI In the following piece of code: (LOOP FOR J FROM 1 TO N-2 AS L0 := (AREF L 0) THEN L1 AS L1 := (AREF L 1) THEN (AREF L J) AS PX0 := (AREF PX 0) THEN PX1 AS PX1 := (AREF PX 1) THEN PX2 AS PX2 := (AREF PX 2) THEN (AREF PX (1+ J)) AS PY0 := (AREF PY 0) THEN PY1 AS PY1 := (AREF PY 1) THEN PY2 AS PY2 := (AREF PY 2) THEN (AREF PY (1+ J)) DO (ASET L1 N1 J) (ASET (* 2 (+ L0 L1)) N2 J) (ASET L0 N3 J) (IF N4 (ASET 0.0s0 N4 J)) (ASET (// (* 3.0s0 (+ (* (^ L0 2) (- PX2 PX1)) (* (^ L1 2) (- PX1 PX0)))) (* L0 L1)) BX J) (ASET (// (* 3.0s0 (+ (* (^ L0 2) (- PY2 PY1)) (* (^ L1 2) (- PY1 PY0)))) (* L0 L1)) BY J)) the THEN clauses get executed after J is set to (1+ J) but before the end-test on J is done. As a result, the PX2 line tries to evaluate (AREF PX (1+ J)) where J is one greater than N-2. This is not what I thought would happen, and I think most people would expect that those THEN clauses would only get evaluated for values of J between 1 and N-2, inclusive. Now, either there is a bug here, or you have chosen a confusing syntax. Dave could not figure out which from the documentation, because it seems the documentation simply does not tell you enough about what order things get moved to that you can possibly tell what this code ought to do!  Date: 2 Sep 1980 08:54:37-PDT From: CSVAX.jkf at Berkeley To: bug-loop@mit-mc Subject: documentation request Could you send me documentation on the loop package in a form I could print on a line printer. I have a copy of your documentation source but since I can't run your text processor here, I would prefer a copy where the text processing has been done. Thank you.  BMT@MIT-MC 08/23/80 18:53:40 To: (BUG LOOP) at MIT-MC when using loop with collects why isn't the result initialized to (ncons nil) instead of having special case code which checks whether the list is empty or not? If there are several collects in the body much of this special case code is duplicated. In particular I would like an efficient way to walk down an alternating list like a property list, and reconstruct a new one from some of the entries. when foo collect bar and collect baz expands into pretty ugly code.  GSB@MIT-ML 08/16/80 19:45:11 To: BMT at MIT-MC CC: (BUG LOOP) at MIT-ML BMT@MIT-MC 08/16/80 16:23:00 the following loop construct expands incorrectly (loop for term in poly for ans = (car term) then (gcd ans (car term)) finally (return ans)) initially term is lambda bound to nil, and then ans is lambda bound to (car term) which is also nil. poly is a list of pairs of integers. If term needs to be lambda bound to nil, then ans must also be, after term is properly initialized, ans should be set to (car term) This is not expanding incorrectly. The definition of "for v = f1 then f2" says that v is bound to f1 before the iteration starts. Term, on the other hand, is set during iteration. It is in general not possible nor reasonable to initialize iteration variables (eg term) before the start of the iteration. The "for v = f1 then f2" construct is essentially just a binding with stepping after the iteration body. The construction you are making is similar to many produced implicitly in loop which have to depend on a "first-iteration" flag to work (eg, MAX, MIN). Maybe LOOP should offer such a construct (maybe "for v first f1 then f2"? Dave?) In the meantime, might i suggest (loop for ans = (caar poly) then (gcd ans (car term)) for term in (cdr poly) finally (return ans)) If "poly" is an arbitrary form it can be bound with WITH.  BMT@MIT-MC 08/16/80 16:23:00 To: (BUG LOOP) at MIT-MC the following loop construct expands incorrectly (loop for term in poly for ans = (car term) then (gcd ans (car term)) finally (return ans)) initially term is lambda bound to nil, and then ans is lambda bound to (car term) which is also nil. poly is a list of pairs of integers. If term needs to be lambda bound to nil, then ans must also be, after term is properly initialized, ans should be set to (car term)  DLW@MIT-AI 08/02/80 19:28:08 Re: LOOP document To: GSB at MIT-ML CC: (BUG LOOP) at MIT-ML In the "Loop Synonyms" section, please explain the I answered this already. Yeah, well, don't just answer it, put it in the (next version of) the document... There should be more text to explain the "Aggregate Boolean" keywords, explaining why they are named what they are. Because they tend to return a boolean result which is some functional aggregation of the boolean results of the values of the clauses. No, no, not why the are called "Aggregate Boolean", but why they are called what they are, namely, "always", "never", and "thereis". It is the individial names I would like to see documented, to give the user a mnemonic aid. Anyway, it is a winning frob, and a nice example of the thesis I ahve been pushing to the effect that Lisp is the best and maybe only extensible language around.  GSB@MIT-ML 08/02/80 11:11:31 Re: LOOP document To: DLW at MIT-AI CC: (BUG LOOP) at MIT-ML DLW@MIT-AI 08/02/80 02:12:38 Re: LOOP document In the "Loop Synonyms" section, please explain the philosophy here. Why would anyone want this? Conversely, why aren't they all already defined? Well there isn't any philosophy, some people want that or are used to it from FOR or CLISP. You definitely should say this explicitly. Give SOME excuse for its existence. If you don't think it is a winner, discourage it and plead that it is only for compatibility. I answered this already. Essentially it was originally suspected that this would be needed for "acceptance" of LOOP. We didn't want them predefined for two reasons: without them, LOOP and psz's FOR can and do reside compatibly in the same lisp. Besides that would be a lot of keywords cluttering up the environment as macro definitions (not to mention the package problems they might cause). There should be more text to explain the "Aggregate Boolean" keywords, explaining why they are named what they are. Because Warren Teitelman (or someone in that crew) decided to call them that. Come now, that is no reason. There are reasonable reasons for calling them that, and you should show some examples. It's YOUR macro, not Teitelman's; you ought to take responsibility. Because they tend to return a boolean result which is some functional aggregation of the boolean results of the values of the clauses. (Now if that didn't make sense, i guess i should write instructions for tax returns.) Actually, i find "aggregated boolean" to be humorously pretentious. But yes, there is a bit of unclarity in this section, but i hadn't thought it to be from this but from the other problem of termination of the loop -- implicit (the epilogue [finally] code gets run) or explicit (via return, or some of the a.b. kwds -- the epilogue code does not get run). At the beginning of the paper it talks about being inspired by the Interlisp FOR.... Actually the Interlisp FOR and the Maclisp FOR are the same (almost). I.e. the latter was written to emulate the former when PSZ was seduced by the light side of the Force and switched allegiances. I know, but that doesn't affect what I said. The typical reader probably doesn't know (at least a lot of them won't). True. Mention explicitly that you cannot use GO inside LOOP, even though it turns into a PROG. Why not? Oh, you can? It looked like it would complain at any GO tag, telling you that it is an invalid keyword. How would you get a label in? You can use go, but we don't document the tags you can go to and don't intend to. You can't make your own tags. In effect then, you can't use GO. BTW, is it in the world load of the LM these days? Good question. ---------------- As i may have said before, these comments are well taken. Dan, when you send stuff in the future send it to bug-loop so it gets archived away for me.  GSB@MIT-ML 08/01/80 22:29:32 Re: comments spurred by moon's To: DLW at MIT-ML CC: (BUG LOOP) at MIT-ML I filed your comments away for future reference. Just for the peanut gallery, the lack of data-type in "for ... on" is probably partly oversight, partly not knowing what to do without forward- referencing destructuring. I believe ALL of the FOR things go through the same thing which will gobble up an optional type. (All the COLLECT variants do also.) The define-loop-macro bs was put in in the original design in the eventuality that (for example) anyone converting from FOR could keep things looking the same if they wanted to. I have encountered no usage. As to macro memoizing.... Well, i obviously misjudged the audience. (My typical proofreading audience is WJL, dave, and whoever else i can scrounge up on the third floor. Sort of a limited environment.) In reference to dave's comment on this, if he did much work in an environment where you couldn't trivially compile things to test them (both because it wasn't trivial and doing so would flush lots of error checking), then you would appreciate macro displacement which was undoable automagically upon redefinition. The only complaint i have about this mechanism is that the most common case, LET, is a macro because of that damned destructuring hair, and these things do trap list storage in interpreted code. You mean i didn't make up "aggregated boolean tests"? Actually, i've always wanted a PUSH type frob. As to the .chapter stuff, well, when i went to make it a tm, i upgraded all the sectioning by one level (simply because i didn't want the whole thing coming out as a single chapter), and then appropriately redefined .chapter so it paginated more like .section. I think it came out ok for a document that size. I think next version (sigh) i'm going to hack the index to be more like the one i hacked for the LSB manual -- in general there are n indices (for large n), and each indexing goes and adds something plus an italicised string to one final index. I should mail you the TM, what it has is this before i cleaned it up some.  DLW@MIT-AI 08/01/80 03:53:49 Re: LOOP document To: MOON at MIT-AI, GSB at MIT-AI I just read the LOOP document in ML: LSBDOC;, and here are some random comments. In the "Loop Synonyms" section, please explain the philosophy here. Why would anyone want this? Conversely, why aren't they all already defined? There should be more text to explain the "Aggregate Boolean" keywords, explaining why they are named what they are. You start mentioning data types near the front (in giving the syntaxes), but don't explain them until much later. Put in a note saying "data types are explained below". Can you give a data type in "for ... on"? The syntax doesn't say you can. Also, you only sometimes tell what the data type defaults to; say so for all of them or give a set of rules. Do you really want to use .chapter? They are very small chapters! In the "destructuring" section it is implied that "with (a) fixnum" will set a to zero rather than nil; if declarations are used to figure out initialization, this should be mentioned before the destructuring section. At the beginning of the paper it talks about being inspired by the Interlisp FOR. Then, much later, you start talking about compatibility with Maclisp FOR. *I* know what is going on here, but I promise you anyone not familiar with the history would think you had your dialect wrong in one place or the other from the way it is written. You use "hopefully" in the canonical wrong way; change it to ", we hope," or something. I certainly do not understand what you mean by "macro memoizing is done using displace in the Lisp Machine". What is macro memoizing, anyway? Mention explicitly that you cannot use GO inside LOOP, even though it turns into a PROG. How about a version of collect that works backwards (that is, that builds up the list with CONS and doesn't reverse it)? Probably too obscure to be worth it...  GSB@MIT-ML 07/15/80 11:21:42 Re: multix To: (BUG LOOP) at MIT-ML eliminate eval-when loadtime dependency  GSB@MIT-ML 07/08/80 02:07:06 Re: closed compilation To: WJL at MIT-ML CC: (BUG LOOP) at MIT-ML LOOP now tries to put a value-type wrapper around the form being SUMmed, MAXed, or MINed. This will cause error checking in the interpreter and open coding in the compiler, for such cases as (loop for x in l sum x flonum) which in the past got close-compiled. (This is by default only effective in pdp-10 maclisp.)  GSB@MIT-ML 06/17/80 17:41:43 Re: token-equal To: (BUG LOOP) at MIT-ML LOOP-TEQUAL should be not just a compile-time macro and should be globalized, for the sake of lusers who write paths.  GSB@MIT-ML 06/08/80 05:13:13 Re: loop To: (BUG LOOP) at MIT-ML Cackle, cackle! We have a multics loop user community! For the interim period until format gets defined, i have conditionalized all ferror's in it to call error directly for multics. I also defined loop-displace; when loop gets loaded on multics, it will copy that subr property to displace's if displace is not defined. I do expect to bring format up there in finite time so maybe the conditionalization can be removed eventually. I also flushed the macro definitions for if, defvar, and selectq from loop; these are now in maclisp (and have been in the multics compilation environment loop sets up for itself). Macro def for lexpr-funcall in pdp-10 maclisp cannot be removed until old lisps go away. (lexpr-funcall is part of the current lisp.)  GSB@MIT-ML 06/08/80 03:56:18 Re: multics loop To: (BUG LOOP) at MIT-ML requires DISPLACE which ain't defined... Maybe it should do it itself on multics? Or displace it conditionally upon the value of nouuo? Dave?  GSB@MIT-ML 05/25/80 00:48:21 To: PSZ at MIT-ML, LH at MIT-ML CC: (FILE [LSB1;LOOP BUGS]) at MIT-ML When an "attachment" spec is encountered, if the value of LOOP-ATTACHMENT-TRANSFORMER is not NIL, that is called with a single argument of the expression to make a new expression to use instead; if LOOP-ATTACHMENT-TRANSFORMER is NIL, then a QUOTE is listed around the expression. Everything else proceeds as before. LOOP-ATTACHMENT-TRANSFORMER defaults to NIL except when (STATUS FEATURE LMS), in which case it defaults to PROGN (ie a no-op). ---------------- I don't much like the way in which this is handled. I doesn't fit in with the remainder of LOOP too well; i think what might be better would be an UNDEFINED-LOOP-PATH hook of some type. But even that is non-modular, so i will probably just leave well enough alone. ---- pete: check out XI;ATTS I will test & compile it shortly. ---- Lowell: i leave it to you to decide how to handle this for XLMS. Probably the best thing is for you to make sure LOOP-ATTACHMENT-TRANSFORMER is initialized in both XLMS and the compiler environment setup, so i can remove the LMS defaulting from the LOOP source, then you can change it if, as, and when you see fit.  GSB@MIT-ML 05/03/80 13:35:44 To: JLK at MIT-MC CC: (BUG LOOP) at MIT-ML JLK@MIT-MC 05/03/80 11:08:04 I think it would be nice to have a REPEAT feature in loop (or does this exist?) I found my self wanting to do something n times where I wanted some UNLESS and additional FOR clauses (so that DOTIMES and friends were not convenient). And it seemed a bit of a crock to need a gensym counting variable (explicitly). I presume this would be trivial to put in... It might be non-trivial to put in and have it fit in with the parallel/ sequential iteration groupings which FOR/AS support - the "obvious" syntax is (LOOP REPEAT ...). I think we considered this at one time but punted because it was non-trivial (dave?). I might modularize the innards at some point which should make it easier. JLK@MIT-MC 05/03/80 11:56:45 Re: LOOP To: GSB at MIT-MC (loop for i from 1 to 10. collecting i (1+ i)) collects (1+ i) and ignores i. Would it be better for it to be doing (push (1+ i) (push i ...)) ? Probably not, to maintain consistency with the definition. eg, you can do things like (loop for i from 1 to 10 as n = (f i) collect (maybe-have-some-side-effects-on-n) (f-prime n)) I don't really think we should have special-cases in the implicit progns after keywords. Comments?  GSB@MIT-AI 03/28/80 18:27:36 Re: destructuring stuff To: (BUG LOOP) at MIT-AI i'm going to have to change psetq into loop-psetq so it can interface to the desctruting setq  Date: 5 March 1980 10:07-EST From: Glenn S. Burke Subject: On a rainy day, when bkph isn't losing with the xgp To: BUG-LOOP at MIT-ML There should be qualification about destructuring and paths, specifically that not all paths may support destructuring of the iteration variable. (But enforcement could make it work, at the slight cost of an extra binding and setq in the simple case, and/or contortions on the part of the path-function writer...) Possibly there should be a (appendix like?) section which gives a brief discussion on the macros LET, PSETQ, and DESETQ. All except DESETQ are currently introduced without comment, and DESETQ itself is only mentioned for the benefit of those who use the already-existing- in-maclisp cruft. test out .group-ing some of the tablified cruft. should have flushed some of the qualifications about lack of features in lispm version, is random noise to most users. Appropriate qualifications either exist or can go with the more detailed explanation of the features.  GSB@MIT-ML 03/05/80 08:29:39 Re: numeric iteration To: (BUG LOOP) at MIT-ML one thing i have had pointed out as missing is the ability to step through some range of values where the direction is determined only by the start and end points at run time. Then, of course, one gets into the additional hair of inclusive/exclusive boundary values, at both ends... My feeling is pretty much that this could be done as a path, since it's too late to allow the general case ("for i from a to b") to handle that, and any modifications of "for ... from" will only cause confusion. comments?  GSB@MIT-ML 03/05/80 08:26:57 To: (BUG LOOP) at MIT-ML In case i haven't mentioned this, i think it is possible and reasonable to handle cases like (loop ... when t1 do e1 and when t2 collect e2 ...) that is, the general case where something wants to be done (or "collected") under one predicate, and something else wants to be done under both that and another predicate. A user-written COND won't do it because of the collection code generated.