YN-!  ZZDZ ZD ZZDZZDZ$ZDZ,ZDZ4ZDZZ|ZDCp fZ  ZZZ@HZ  ]ZZLJt` HICip(000s,,Xx0HPb@ hc NC` f` f` Rece fromby pw(3.2/.2) A0145u, 1990 175 PDTe: Th Apr :24 Prom: r Ham Sender: BITNIC IBM-NETS List Comments: Warning -- original Sender: tag was hank%bitnic.BITNET@LILAC.BERKELEY.EDU From: Bob Pasker Subject: Re: TCP/IP Versus LU 6.2 For Building Client-Server To: "Robert L. Plouffe" Message-ID: <9004192032.aa19454@mintaka.lcs.mit.edu> walasek@hpcc01.UUCP (Arthur Walasek) writes: >Wayne Clark writes: >> HERE IS THE CATCH: The family jewels (i.e. DB2, CICS, DISOSS, ...) are >>accessible only through SNA. Now, I imagine your client-server application >>might want to get to a mainframe database at some point. If this is the case, >>look real hard at LU 6.2 and ask tough questions to IBM regarding their TCP/IP >>for MVS and VM. >LU6.2 also uses, I believe, a dedicated line - that is, you need one >physical line from the IBM to each PC wanting a connection. can you say "multi-dropped SDLC?" >There are many variables here, and Wayne was correct when he stated that >IBM's real advantage is in using the SNA protocol. Hopefully they will >improve on their TCP/IP implementation in the future. promises and hope are not very helpful when building real applications for NOW. you can sit around for years waiting for stuff be released and, uh, "field debugged." -- - bob ;----------------------------------------------------------------- ; Bob Pasker, San Francisco, CA | rbp@well.sf.ca.us ; +1 415-695-8741 | {apple|pacbell}!well!rbp FAILNET-ORIGIN<723136.900419@AI.AI.MIT.EDU>YN-! fh fh fh fh#fh+fh3fh;fh!Cfh%Kfh)Sfh-[fh1cfh5kfh9sfh={fh   8 @H  Og"g HI H0P` /X@@  M0 `**BB_To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AIBABYLCZRFC733CZcz@LSDThis is a test <722976.900419.CZ@AI.AI.MIT.EDU>FAILDate: Thu, 19 Apr 90 14:39:08 EDT From: "Christopher R. Zach" To: cz@LSD.AI.MIT.EDU Message-ID: <722976.900419.CZ@AI.AI.MIT.EDU> YN-!  M%MK M%MKM% MKM% MK"M%MK*M%MK2M%MK:M%MKBM%!MKJM%%MKRM%)MKZM%-MKbM%1MKjM%5MKrM%9MKzM%=MKCp gM%  MEM%M%@H3  SH3H3` HI%pY( 0s,,8 , % , P[,X0 )H(S@tUFQx]88l_Pe8 `g`g`5@MC.LCS.MIT.EDU,@PHOTON.lcs.mit.edu:macmod@sumex-aim.stanford.eduSTEVEH@AI.AI.MIT.EDURG@AI.AI.MIT.EDUJON-O@AI.AI.MIT.EDULSP@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 17 Apr 90 23:20:05 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 23:17:40 EDT Received: from PHOTON.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa10833; 17 Apr 90 23:13 EDT Received: from PM-PRJ.LCS.MIT.EDU by photon.LCS.MIT.EDU via TCP with SMTP id AA18268; Tue, 17 Apr 90 23:12:36 EDT Received: from SUMEX-AIM.Stanford.EDU by pm-prj via TCP with SMTP id AA17318; Tue, 17 Apr 90 23:12:09 EDT Received: by sumex-aim.stanford.edu (4.0/inc-1.0) id AA06888; Tue, 17 Apr 90 20:05:55 PDT Message-Id: <9004180305.AA06888@sumex-aim.stanford.edu> Date: Tue, 17 Apr 90 20:05:22 PDT From: The Moderators Reply-To: Info-Mac@sumex-aim.stanford.edu Subject: Info-Mac Digest V8 #77 To: info-mac-list@sumex-aim.stanford.edu Info-Mac Digest Tue, 17 Apr 90 Volume 8 : Issue 77 Today's Topics: 6.0.5 bug with Mac Plus? 68882 emulation Administrative software needed. Bison for THINK C (part 1 of 4) BUNDLE & FREF Problem EtherTalk-ing Macs with strange setup... Flex for THINK C FOREIGN LANGUAGE SOFTWARE Imagewriter II and Multifinder Importing Postscript into Word 4.0 internal drives List Manager in Hypercard. looking for flush.snd Looking for SORT program Mac/Sun Spoolers Mac Fax Modems? Macintosh and Psychology MWII & ZhongwenTalk? NewFolder XCMD SMTP VirusDetective 4.0a VT100 emulation. Weird Mac Behaviour Your Info-Mac Moderators are Bill Lipa, Lance Nakata, and Jon Pugh. The Info-Mac archives are available (by using FTP, account anonymous, any password) in the info-mac directory on sumex-aim.stanford.edu [36.44.0.6]. Help files are in /info-mac/help. Indices are in /info-mac/help/recent-files.txt and /info-mac/help/all-files.txt. Please send articles and binaries to info-mac@sumex-aim.stanford.edu. Send administrative mail to info-mac-request@sumex-aim.stanford.edu. ---------------------------------------------------------------------- Date: Tue, 10 Apr 90 09:49:08 -0500 From: Kurt Hirchert Subject: In Info-Mac Digest V8 #72 Garrett Fitzgerald writes: >I've got a question about NCSA Telnet that the documentation doesn't seem to >address. How do you connect to a specific port at a machine, using this? The >version of Telnet on the mainframe allows you to say "belch.berkeley.edu 2323," >but typing this in the "Open Connection" dialog doesn't work. You need to upgrade to version 2.3 of NCSA Telnet. The early versions could connect only to the standard Telnet port of a host, but the current version (2.3) allows you to type the port number after the host identification in the Open Connection... dialog. (In other words, what you tried should work in version 2.3.) -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications ------------------------------ Date: Mon, 9 Apr 90 17:59:21 EDT From: hal@cs.cornell.edu (Hal Perkins) Subject: 6.0.5 bug with Mac Plus? >Hello. If I boot my Mac Plus off the 6.0.5 System Tools floppy, bring >up the control panel, and set the speaker volume to 0, it crashes! >It's repeatable and I'm not using *any* INITs or CDEVs or etc. as I'm >booting off _Apple's_ locked disk! This problem wasn't in 6.0.4 and it >makes me wonder what else doesn't work. This is reminiscent of trouble I had with 6.0.5 on my Mac Plus. I upgraded from 6.0.4 to 6.0.5 with the installer and got a system that crashed just after installing Macsbug while rebooting. After a fair amount of experimenting, I deleted the system folder and created a new, vanilla, one with the 6.0.5 installer. That worked fine, but when I dragged the map and closeview cdevs to the new system folder I wound up with a system that wouldn't reboot. It just hung up after displaying "welcome to macintosh" but before "macsbug installed" appeared. At that point, I restored my 6.0.4 system folder from a backup and it's been running fine ever since. 6.0.5 was flaky enough that it wasn't worth it to me to take chances. Your mileage may vary. Waiting for 6.0.6. (Disclaimer: I have no idea if there is a 6.0.6.) Hal Perkins hal@cs.cornell.edu Cornell CS ------------------------------ Date: TUE APR 10, 1990 07.26.39 EST From: "Macintosh Conference System Opperator" <#MAK%LEHIGH.BITNET@ibm1.cc.lehigh.edu> Subject: 68882 emulation From: Macintosh Conference System Opperator (RobPlatt) .. Can anyone tell me, is there a INIT or CDEV, either PD/SW or commercially available, that will emulate the 68882 Math coprocessor that is in a MacII but not in a MacPlus? In other words, I have a few programs that depend on a 68882 (Notably, PSPICE) and I would like to run them on a MacPlus. I know it would go slow, but it would be nice to be able to do... Thanks, Rob Platt . . . . . . . . . . . . . . . . . . . . . . . . . . ------------------------------ Date: Tue, 10 Apr 90 10:52 GMT From: Big Nose Subject: Administrative software needed. Dear all, Firstly, thanks to everyone who replied to my Cricket Graph problem, I've thrown it away as suggested!! Secondly, a group of scientists at our Institute run a journal and are looking for software (free, share or expensiveware) to keep track of details. Requirements are:- tracking referees who are late replying, producing reports as to submitted paper contents, filing correspondence, and other general journal monitoring duties. Does anyone know of or have any such software which may be of use? Please mail me direct. I'll summarize. Thanks, Andy Law. ------------------------------ Date: Wed, 28 Mar 90 15:23:45 -0500 From: rsfinn@neutron.lcs.mit.edu Subject: Bison for THINK C (part 1 of 4) This file contains Bison, the GNU replacement for "yacc", adapted to run on the Macintosh as a stand-along application (i.e., MPW is not required). Also included is a THINK C 4.0 project file and complete source code. Send comments to rsfinn@athena.mit.edu. One note left out of the documentation: the text files "bison.simple" and "bison.hairy" must be present in the same directory as the Bison application. [Archived as /info-mac/source/c/think-c-bison.hqx; 254K] ------------------------------ Date: Tue, 10 Apr 90 00:32 CST From: MJW Subject: BUNDLE & FREF Problem I am working on an application. I have two icons for the two different files it creates. Each file has it's own unique file type. My application has its own icon and creator signature. I got the APPL icon to work okay by going by an example. But I am having problems getting it to set and give the output files the icons I want. I am confused about how to design the BNDL & FREF resources so that it will work. If someone can give me an example they have of a program which has specific file icons for their output files I would appreciate it, or if someone could send me a description of how to set up the resources and their fields, or simply give me a reference. I am using RMaker to compile the resources. I have the inside macintosh manuals 1-3 2nd ed., any help would be greatly appreciated. -- I can be reached at the following addresses: -- MJWOLF@UIAMVS WOLF@MEL.CIPL.UIOWA.EDU -- Thanks all.... ------------------------------ Date: Mon, 09 Apr 90 23:45:19 -0500 From: fgodfrey@rodan.acs.syr.edu (Francis N. Godfrey) Subject: EtherTalk-ing Macs with strange setup... The subject line said it. What we are about to do is to have some of our Mac clusters on EtherNet and to fix the EtherNet-ted Macs and the remaining Mac clusters so that they will boot from a "fixed" disk (by this I mean a disk that is a floppy but will not eject). Since that will contain System, this will assure that all Macs will be running the appropriate setup for EtherNet or AppleTalk. The problem is that if the need to update the "fixed" System disk that there will be slight problems with hardware. Also there will be some students that want to boot from their own System disks. The big question is: is there an alternate such as using an chip to tell the Mac to boot from a server if there is no disk drive or anything less painful than what is to be implemented? Send replies to my addresses and also to: rskeg@suvm.acs.syr.edu (Keith E. Gatling) this is the guy who will relay the replies to all concerned parties at our end. Thanx for the help people!!!! ------------------------------------------------------------------------------ Francis N. Godfrey |Computing and Network Services|"It was the server Syracuse University|Micro Cluster Support | that did it"-Mystery fgodfrey@SUVM.BITNET |fgodfrey@rodan.acs.syr.edu ------------------------------ Date: Wed, 28 Mar 90 15:27:20 -0500 From: rsfinn@neutron.lcs.mit.edu Subject: Flex for THINK C This file contains Flex, the GNU replacement for "lex", adapted to run on the Macintosh as a stand-along application (i.e., MPW is not required). Also included is a THINK C 4.0 project file and complete source code. Send comments to rsfinn@athena.mit.edu. One note left out of the documentation: the text file "flex.skel" must be present in the same directory as the Flex application. [Archived as /info-mac/source/c/think-c-flex-part1.hqx; 194K /info-mac/source/c/think-c-flex-part2.hqx; 174K] ------------------------------ Date: Tue, 10 Apr 90 15:55:46 EDT From: ZAK@cu.nih.gov Subject: FOREIGN LANGUAGE SOFTWARE >From: Pieter Stouten > 1) Does anyone know of Macintosh programs to learn basic grammer > (English and German) ? They should be on a exercises and answers > basis. PD, Shareware or commercial. All information is welcome, > preferrably adresses. For $25 you can put MacFlash Cards on your Macintosh and learn French, Spanish, German, Russian, and Latin. It comes with a 43-page manual and needs HyperCard 1.2 to work. The address/phone number for the distributor is The Language Quest Software Co. 101 First Street, Suite 428 Los Altos, CA 94022 (415) 941-2879 [information] (800) 283-4080 ext. 850 [orders] The German and French versions come in beginner and advanced. I don't know a thing about this personally; I'm just forwarding the info! ------------------------------ Date: Tue, 10 Apr 90 12:47:20 PDT From: Gregg Kasten Subject: Imagewriter II and Multifinder I have an SE w/ 2.5 MB, system 6.0.3, finder 6.0.3, running multifinder 6.0.3. I have a RAM cache set for 256K. My problem: When I print either from Red Ryder or from Microsoft Word 4.0, the print job takes an unusually long time, even in draft mode. Any suggestions or people with the same problem? Thanks in advance. Gregg L. Kasten proteus@portia.stanford.edu ------------------------------ Date: Mon, 9 Apr 90 13:58 EDT From: The Blue Adept Subject: Importing Postscript into Word 4.0 Is there a way to import an image created in, e.g. FreeHand, into Word in a WYSIWYG manner? I've read in the manual about the Postscript style, and making the text hidden. But, is there a way to import the picture in a manner similar to the way it's done in PageMaker? I'd like to be able to SEE the picture as I'm placing it, but then have the printer access the applicable Postscript code. Is this possible? Or, am I destined to use PageMaker for such an enterprise? (It seems odd that you can easily place PICT files into Word, but not EPSF files...) Kevin Bolduan '91 Amherst College KSBOLDUAN@AMHERST Bitnet Address ------------------------------ Date: Tue, 10 Apr 90 02:27 EDT From: Down & Out Subject: internal drives once again..Hello netters, As I promised I would be posting more than one message it is just under another topic. We are looking for a beast that we have been told by some ddoes not exist. What is out there as far as internal drives for the Mac. We are looking for some different options. I deal mostly with the software end of it here on campus but a friend asked me If I could post this request for him. I believe he is looking for a third party dealer. If you have any information about this at all please let me know. As the saying goes "send to me I will post to the net" As always, Thanks in advance, ***************************************************************** /\ * Kip Ferguson *GENERAL DISCLAIMER: * / \ * Student * "The downfall of society may come when * /----\ * Albion College * man feels he has to make excuses" * / \ * Kip@albion.bitnet * In other words "I said it, no one else!" * ***************************************************************** ------------------------------ Date: Tue, 10 Apr 90 10:53 GMT From: Big Nose Subject: List Manager in Hypercard. Dear All, Are there any XCMD/XFCNs floating about out there which allow the use of the list manager in hypercard? Please mail me direct. I'll summarize. Cheers, Andy Law. ------------------------------ Date: Tue, 10 Apr 90 13:14:58 -0400 From: grant@itd.nrl.navy.mil (Liam Grant) Subject: looking for flush.snd I'm looking for the sound of a toilet flushing, or a close equivalent. I've checked the archives at info-mac, and SIMTEL, and haven't found what I need. If any one can find such a beastie, or point me towards other archives, I'd appreciate it. [I was told of an archive on sally.utexas.edu, but I can't find that machine any more. Thanks ====================================================================== William (Leprechaun Liam) Grant Grant@itd.nrl.navy.mil Code 5541 (202) 767-2392 Naval Research Laboratory Washington, D.C. 20375-5000 ------------------------------ Date: Tue, 10 Apr 90 16:28 MET From: "Adam van Gaalen (PA2AGA/PI8MAC) DGV-TNO (31)15697283" Subject: Looking for SORT program Hello MacUsers, A few weeks ago I bought a dutch word-list of about 450.000 words... Last week I wrote a little program that searches for words and anagrams, so that finally there may be a way to find the always missing last one or two words of crossword puzzles. To speed up the process of going through the unsorted word-list I am looking for a program that is capable of sorting these half a million words. Any suggestions? Kind regards, Adam van Gaalen. +----------------------------------------------------------------------+ | Please send your reply to: | Where | Mac | Software | |-------------------------------------------+--------+------+----------| | EARN/BITNET: gaalen@hdetno51.bitnet | office | SE | DynaComm | | or: gaalen@tno.nl | same | same | same | | Packet-radio: pa2aga@pa2aga (44.137.32.9) | at home| Plus | NET/Mac | | or: pa2aga@pi8mac (44.137.32.22)| at home| SE/30| NET/Mac | +----------------------------------------------------------------------+ ------------------------------ Date: Tue, 10 Apr 90 15:12:29 EDT From: Glenn Smith Subject: Mac/Sun Spoolers Hello world; I am in search of a spooler for our workstations. It needs to be able to print files from both our Sun Workstations and our Macintosh IIx's. Currently I can print on one or the other with configuration changes, but this has become very troublesome. I beleive it is possible, but I can't remember where I had read it. Can anyone help me in my search for a quality spooler?? Does one exist? If so do I need any special hardware ? Crossing my fingers for a spooler!! Please mail me direct @ Smith@akronvm.bitnet Thank you in advance for your help The University Of Akron Glenn Smith System Administrator Molecular Spectroscopy Lab U U U U U A U A A UU AAAAA A A A A ------------------------------ Date: Sun, 8 Apr 90 21:36:49 EDT From: rlm%dawn.hampshire.edu@cunyvm.cuny.edu Subject: Mac Fax Modems? Anyone have experience with the new combination data/fax modems? The new Dove unit at $279 is tempting ... Richard Muller Hampshire College Amherst MA USA 01002 rmuller@hampvms.bitnet rmuller%hampvms.bitnet@cunyvm.cuny.edu rlm@dawn.hampshire.edu ------------------------------ Date: Tue, 10 Apr 90 02:23 EDT From: Down & Out Subject: Macintosh and Psychology Hello netters, I have been reading this list for a long time and just recently came up with several questions to post. I will post them according to topic to make it easier reading. If you see my name several time within the next couple of weeks it is due to the fact that my lack of knowledge is starting to show through. Anyway on with my questions. I am interested in using the macintosh more in our Psychology department here on campus and had some major questions about some software and hardware. First what statisical programs are out there right now for the mac (ANOVA, T-stat etc.). What programs are out there as far as just dealing with psychological matters. I know of Spinning Brain but are tehre others. One final specific question under this topic...What is out there for say a mac se that would time intervals between voice activation. ex. I show "dog" on the screen and someone repeats it. Is there a program/hardware that will do this? If you have any information regarding these topics could you please reply to me. I will probably not post a summary to the net since this is so specific but if there is enough respons i will post it in the archives, Thanks in advance, ***************************************************************** /\ * Kip Ferguson *GENERAL DISCLAIMER: * / \ * Student * "The downfall of society may come when * /----\ * Albion College * man feels he has to make excuses" * / \ * Kip@albion.bitnet * In other words "I said it, no one else!" * ***************************************************************** ------------------------------ Date: Mon, 9 Apr 90 18:11:44 PDT From: khaw@parcplace.com (Mike Khaw) Subject: MWII & ZhongwenTalk? There was some discussion here a while ago about Apple's Chinese Script Manager, but I can't find the hardcopy I saved. Anyone know whether MacWrite II works with Zhongwen Talk (the Taiwan version of Apple's Chinese Script Manager)? I called Claris tech. support twice: the first time the person on the other end said "Script Manager? What's that?" (or something like that); the second time, the person on the line said he wasn't sure, but didn't think it would work. Alternatively, I'd appreciate a list of word-processors/text-editors normally used in the US for English that work with Zhongwen Talk. -- Mike Khaw ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043 Domain=khaw@parcplace.com, UUCP=...!{uunet,sun,decwrl}!parcplace!khaw ------------------------------ Date: Wed, 04 Apr 90 14:27:29 +1000 From: David Elliott Subject: NewFolder XCMD Executed with a list of one or more folder pathnames, NewFolder creates the folders (including any nonexistent parents). The XCMD was created because I needed a way to create an entire tree with node-specific names on the fly from HyperCard. [Archived as /info-mac/card/xcmd/new-folder.hqx; 83K] ------------------------------ Date: Mon, 09 Apr 90 14:43:43 EDT From: Evan Stark Subject: SMTP Does anyone know of any mail programs running on the Mac side that use SMTP? Reply to me directly and I will summarize to the net. Bitnet: EXSGC@CUNYVM Internet: exsgc@cunyvm.cuny.edu evan@eleni.gc.cuny.edu ------------------------------ Date: Sun, 1 Apr 90 13:28:24 CDT From: shulman@sdrvx2.sinet.slb.com (Jeffrey Shulman) Subject: VirusDetective 4.0a VirusDetective is a DA for tracking down viruses (or any resources) in files. You specify the resource type and various attributes. Once the offending resource is found it can optionally be removed from the file (use this feature with caution) or file deleted. The user can update the search list at any time. Shareware. VirusDetective update notices were mailed on 3/24/90 to all registered users. If you are not a registered user, you are missing out on one of the most fully-supported shareware programs out there! Register today! Version 4.0a features: - Wild card "Data" searches. You can now specify that an unspecified number of bytes exist between each "Data" sub-pattern. - New "WData" and "LData" keywords to start data searches on word and long word boundaries. - Password protection. You can now set a password preventing any options or search strings from being modified without it. - Ignore errors option. No longer stops scans due to resource fork errors. - No Cmd-. VirusBlockade II Cancel option. When VD is called from VB II you won't be able to interrupt scanning via Cmd-period. - International keyboard recognition of Cmd-period. - Eject button. When a scan matches can now directly eject the matched floppy. - Copy/Pasting search strings from other files now better supported (i.e. it works now ;->) - File name and matching string now reported in background scanning alert dialog. - Can now scan all mounted volumes with a single mouse click. - Progress indicator added during full volume scans. - New scanning cursor. - New keyword "dataFork." You can now scan the data forks of files! - New keyword "Executables." This keyword "matches" the over 2 dozen executable resource types. No need to worry about other WDEF-like Desktop infections sneaking into your Desktop! - Stylized help text. You now have bold, italic, etc. It even copies to the clipboard that way! Note: Only word processors (like MacWrite II) that recognize the Apple standard 'styl' resource will show the text as seen. - ZUC Virus search string - Change to Mosaic/FontFinder search string to not also, accidently, match MacInTax Fed Converter 1989. Jeff Shulman Shulman@SDR.SLB.COM [Archived as /info-mac/virus/virus-detective-40a.hqx; 122K] ------------------------------ Date: Mon, 9 Apr 90 16:02 EST From: HENRY YEE Subject: VT100 emulation. Around here there is a communications program called Z-TERM, which has VT-100 emulation. It supports the ZMODEM file transfer protocol, and is pre immediately following the "Welcome to Macintosh" box, saying "Unable to load a needed resource"--only option: restart. After one or two times it will frequently boot successfully. Booting from floppy and switch- launching works fine but of course the suitcase stuff doesn't come up that way. Once it's running, it occasionally bombs with id 2, 10, or 28. Most frequently this is associated with a menu operation: when I click on the menu it bombs. Less frequently it waits until I've pulled down a selection on the menu (e.g. save as...). It has now taken to bombing when I select particular DAs, but not ALL das, just some of them like Character Map, MSMail, and Find File. Control Panel, SciCalc, and Tetris all open up fine, however. Fixes: I have replaced all combinations of system and finder with copies from locked original disks. I have replaced Suitcase with a copy from original disk. I have zapped pram, rebuilt desktop, cursed, threatened, begged, and pleaded. To no avail. Also, I've checked with Disinfectant 1.6; nothing indicated. Any ideas? Post to net or email directly; this perhaps shouldn't take up any more valuable bandwidth than it already has. Josh Hayes, Zoology Department, Miami University, Oxford OH 45056 voice: 513-529-1679 fax: 513-529-6900 miamiu.bitnet (good) / jahayes@-miamiu.acs.muohio.edu (also good) ^ miavx1.acs.muohio.edu (not so good) ------------------------------ End of Info-Mac Digest ****************************** FAILNET-ORIGIN<722375.900417@AI.AI.MIT.EDU>APPENDRFC733levine@eniac.seas.upenn.eduNOSHOWto get your mail on OZ, you should be added there. ;; remaining OZ names added 25dec88 (TWENEX-HATERS (EQV-LIST A2DEH AGRE ALAN ATTY Bagley.PA@XEROX.COM BATALI BJN CENT CSTACY DANNY DCP Devon DMS@HERMES DPH FVE Foner GREGOR GRUPP Gumby HAL HENRY IAN@SRI-NIC.ARPA JNC JRLK JTW KLH KLOTZ KWH MAEDA MAP Mly MROSE@PREP PGS RAY RMS RS SAJ@PREP SWA TATAR TK zvona [CENTI;HATE TWENEX])) (ULTRAGEN (EQV-LIST BROWN@SUMEX-AIM.STANFORD.EDU Delagi@SUMEX-AIM.STANFORD.EDU BillD@WHEATIES Hewitt Pullen@vax.darpa.mil Scherlis@VAX.DARPA.MIL chuck@vlsi.caltech.edu squires@vax.darpa.mil)) ;; Completely unrelated to unix-haters@amt, which doesn't exist anymore. (UNIX-HATERS (EQV-LIST (@FILE [GREGOR;WEENIX TEXT]))) (WEENIX-HATERS (EQV-LIST UNIX-HATERS)) ;; Redistribution of unix-haters@amt. Unrelated to above list ;; -- unix-hater@amt has been nuked. straz 27-mar-89 ;(MAC-UNIX-HATERS (EQV-LIST ; Alan CENT DEVON-JUNK DLW HAL JAR JNC KWH MAEDA MAP Mly ; PGS RS SWA TK DANIEL ; [CENTI;HATE UNIX])) (USER (R-OPTION SHOWLIST) ; This is to prevent mail to "USER" from (EQV-LIST USER-ACCOUNTS)) ; going astray (USER- (R-OPTION SHOWLIST) ; Some pinhead sent mail here recently (EQV-LIST USER-ACCOUNTS)) ; -- ZvoYN-!  ` ` ` `"`*`2`:`!B`%J`)R`-Z`1b`5j`9r`=z` W  @HT 4 tTs HI?H xxX @H0 %`  5(P '8 )`) TodairthdTo: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AIBDAYDRAGONRFC733NSINGHappy Birthday!Happy birthday to you, Happy birthday to you, Happy birthday dear Neil, Happy birthday to you. <722392.900418.DRAGON@AI.AI.MIT.EDU>FAILnsingNOSHOWDate: Wed, 18 Apr 90 00:10:18 EDT From: Puff the Magic Dragon Subject: Happy Birthday! To: NSING%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <722392.900418.DRAGON@AI.AI.MIT.EDU> YN-!  jjZj jZ jjZ jjZj"jZj*jZj2jZj:jZ!jBjZ%jJjZ)jRjZ-jZjZ1jbjZ5jjjZ9jrjZ=jzjZ Nj , jjj@HGJu ć:CqG|f H/#jH0P(h8  4 x PH `>gX ,'@(џ0W,`,o su an iable oine e botf the so tyou cock p by gdown ole, BABYLZVONARFC733ZVONARWEINER%eagle.wesleyan.EDU@XXSHAVA%src.org@RELAY.CS.NETR-OPTIONCCReply-to: paganism-request@mc.lcs.mit.edu Welcome to PAGANISM@MC.LCS.MIT.EDU [form letter][Sorry this is so delayed -- I've been away for a week.] The list is for discussion of NeoPaganism, witchcraft, and like that. Most of us on the list are Pagans of some stripe. Some of us know each other face-to-face and practice together. However, you should be aware that not everyone on the list is Pagan. You need not fear being attacked for saying outrageous things, but if you are not yet out of broom closet, keep in mind that this is a somewhat public forum. It is an optional but friendly practice to send a letter of self-introduction to the list. Due to the volume of this list, PAGANISM is a digest. That means each day's messages are collected and mailed out by a program in one big message shortly after midnight. The big message is in "standard" digest format. That means that if your mail reader has an Undigestify command you can unpack the digest at the other end into individual messages. This is known to work with at least Babyl, Gnu EMACS Rmail, Zmail, and mh (using the `burst' command). If you want to get off the list, or you have a mail problem, please write to PAGANISM-REQUEST@MC.LCS.MIT.EDU, rather than to the whole list. If your friends want to get onto the list, please ask them to mail to the -REQUEST list rather than to everybody. Messages you do intend everyone to see (that is, messages that are part of the conversation) should go to PAGANISM@MC.LCS.MIT.EDU. Blessed Be! David/Zvona <623714.890720.ZVONA@AI.AI.MIT.EDU>FAILDate: Thu, 20 Jul 89 14:45:33 EDT From: David Chapman Subject: Welcome to PAGANISM@MC.LCS.MIT.EDU [form letter] To: RWEINER%eagle.wesleyan.EDU@MINTAKA.LCS.MIT.EDU cc: SHAVA%src.org@RELAY.CS.NET Reply-to: paganism-request@mc.lcs.mit.edu Message-ID: <623714.890720.ZVONA@AI.AI.MIT.EDU> YN-%  a aa a a aa aa &aa .aa 6aa >a#a Fa'a Na+a Va/a ^a3a fa7a na;a va?a ~a "(|a +@ cKa a @H^ 2 a _^oa Hpose: Address: Affiliation: .AI.MpaLph ((p0q(8#h&0P  (X4 0 ]H,4 tx_@tdP 0fq80g5P0h`$8,hiP0k8l` l( 0l`p%h (`&) 1/19* + Ver,2 by -on 2/. /Versi0by Pi1 5/232per c3ts by4 Sta5 6 Inte7Discu8 T9imiti:reams; beenripti? CLt@uiresA *STAB-INPUCSTANDDUTPUTEERRORFUT*, GE-OUTH *QUEI*, anJBUG-IKe inLly boMo synNstreaO *TERP-IO*.Qs reqRent Srs thTegratUf ComVisp wWany eXng anYtentiZerati[viron\. ]xampl^Unix _menta`is cualy unbto lec supdUnix eard efoutpugn thohommoni defij*ERROkPUT* lse *EmOUTPUn requoto stput boqto thre strss *STtD-OUTu A wvationwronnmxwhichyides zm acc{o win|as an}nsion~urrenorbito maace o appe a see winy def becaTRACEUT* i uired tart  ound  e samream TANDATPUT*PropoSTANDNPUT-AL-BI:DEFIONTRA Aon Liplemeon isired ovidefollo inittreamach i l str!as a "fic p#e as $ed i%L. &*STAN'INPUT( Th)ream *und t+ prim,efaul-ut of.Lisp/tem (0stand1nput 2ix, S3PUT o4). W5 thi6l pro7 be a8eract9ermin: wind;ring may ?be a @file A noBeractCpplicD. EANDARFPUT*G ThisHam isId to JrimarKault Lt of Misp Nem (eOtandaPtput Qix, SRTPUT SS). T thUll prVy be WteracXtermiYr winZuring[ogram\lopme]t may^ be a_ file`a nateracbapplicn. dUERY-e* fenevegsiblehs stris bouj an ikctivelput sm. Thny be oame apitialqt* inrdevelst envtent, u may vseparwindowx tery. IfzLisp {m is |ng un}n ope~g ssuchegis  prova sep errout e, thream d pro be b to th urce. a no eractnviro for  no ictivet iilablading strell alresulEOF.*ERROPUT* If *al-qunput*ound  inteve inourceX3J13-mailer@sail.stanford.eduJAR-CL@ai.ai.mit.eduRSG%OZ@ai.ai.mit.eduCSTACY@ai.ai.mit.eduReceived: from life.ai.mit.edu (TCP 20015020120) by AI.AI.MIT.EDU 30 Sep 88 03:28:13 EDT Received: from ai.ai.mit.edu by life.ai.mit.edu; Thu, 29 Sep 88 22:13:36 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88 18:25:06 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 SEP 88 18:16:24 PDT Date: 29 Sep 88 18:16 PDT From: masinter.pa@xerox.com Subject: Re: Fairfax Updated Agenda DRAFT In-Reply-To: Jan Zubkoff 's message of Thu, 29 Sep 88 15:40:06 PDT To: Jan Zubkoff Cc: x3j13@sail.stanford.edu Message-Id: <880929-181624-1531@Xerox> The two other topics I wanted to discuss -- registry for packages, modules, features, and public-ftp access for public Common Lisp programs, I thought would only take about 30 minutes, mainly just to organize something. FAILmasinter.pa Re: Fairfax Updated Agenda DRAFT<453286.880930@AI.AI.MIT.EDU>NOQCNO-CLICSTACYNOSHOW[JAR;CL MAIL]FILENOSHOWRecipient name apparently rejected. Last reply was: {550 ... User unknown}YN-%  JWʯ JWʯJW ʯJW ʯ#JWʯ+JWʯ3JWʯ;JWʯCJW!ʯKJW%ʯSJW)ʯ[JW-ʯcJW1ʯkJW5ʯsJW9ʯ{JW=ʯ %zJW+< LwJWJW@HLw  OHLwHLwt` Hpose: Address: Affiliation: .AI.Mpa<ph (( 7($   7(X<0 H Pi@ hjb/8!@m 7P0n` Y@oP0p88,hqP0s8t`t`(Pt"h (`#&MAY 8'02:52( Date)May 8*02 PD+om: m,er.pa-x.COM.ject:/New i0 STEP1RONME2n-rep3: Eri4son <5!eb@l6.Stan7EDU>'8sage 9n, 14: 88 ;:06 Ptanfo?U cc@n@stoAook.sBymbolCom, CDanup@EstanfFdu MGe-ID:H523-1I-5606Jx> Ke I bLe it M sensN TIMEOe a mP it mQless R forS to dT Utes sVat "MWill sXte thYt intZP-ENV[ENT a\IME-E]NMENT^t it _ like`-workae. I bthe pcal bdlly ie formf Davigmitteh i wantjdd tokCurrelacticmu mignnt tooion tpoth qand Trre masin Lutommonu (altv the w defixn foryP bafzme), {hat i|ox Co}Lisp,~ is aal fnd TIs a m eceivrom StanfoU (TC00000y AI. T.EDU ay 88 8:36  Receifrom max.Ay SAInfordwith 23 Ma 16:1PDT ved: ultimPA (55-eefd AA0 Mon,ay 882:05 Receifrom host  st.UU!.2/4."id AA#; Mon$May 8%15:06& Mess'd: <8(2315.)61@mi*CP> +l-cle,sail.-ord.e.ltima/bject0ue: S1RD-IN2NITIA3DING 4ion 35te: M63 May79:15:8T Fr9an L.:son <;on%mi >e: ? STAN@INPUTAIAL-BBG ReCces: DandarEeams F327-3GCategH IE EdJstoryKrsionL PierMnd HaN 1/19O P VerQ2 by Ron 2/S TVersiUby PiV 5/23Wper cXts byY StaZ [ Inte\Discu] T^imiti_reams` beenaved.boblemcriptid CLteuiresf *STAg-INPUhSTANDiUTPUTjERRORkUT*, lE-OUTm *QUEn*, anoBUG-Ipe inqly boro synsstreat *TERu-IO*.vs reqwent xrs thyegratzf Com{isp w|any e}ng an~tentirativiron. xamplUnix mentais culy unto le sup Unix  ard e outpu n thoommon defi*ERROPUT* se *EOUTPU requto stut boto the strs *STD-OUT A wationronnmwhichides m acco winCL-Cleanup-mailer@sail.stanford.eduJAR-CL@ai.ai.mit.eduMLY-LISPM@ai.ai.mit.eduReceived: from life.ai.mit.edu (TCP 20015020120) by AI.AI.MIT.EDU 30 Sep 88 03:27:56 EDT Received: from ai.ai.mit.edu by life.ai.mit.edu; Thu, 29 Sep 88 22:13:12 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 17:33:13 PDT Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00392g; Thu, 29 Sep 88 16:31:09 PST Received: by bhopal id AA14046g; Thu, 29 Sep 88 17:30:42 PDT Date: Thu, 29 Sep 88 17:30:42 PDT From: Jon L White Message-Id: <8809300030.AA14046@bhopal> To: vanMelle.pa@xerox.com Cc: cl-cleanup@sail.stanford.edu In-Reply-To: Jon L White's message of Thu, 29 Sep 88 16:29:48 PDT <8809292329.AA13827@bhopal> Subject: Issue: DEFPACKAGE (version 2) Foo, whereever my message said "(version 2)", I meant to say "(version 3)". Version 3 is the one I sent out on Date: Tue, 27 Sep 88 22:41:16 PDT correcting most of the problems you brought up in yesterday's note. -- JonL -- FAILNET-ORIGIN<453285.880930@AI.AI.MIT.EDU>MLY-LISPNOSHOWmly-lisp@mNOSHOW[JAR;CL MAIL]FILENOSHOWHost appears to be permanently down or not accepting mail.YN-!  [[[ [&[.[6[>[F[#N['V[+^[/f[3n[7v[;~[?  M[ : {[[@H < f# HlVp (p0q(X`0 H(?@ tA ` ,4G %PK8 M`M`bjectrfax deesus fa   X3J1endeermati X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Sep 88 19:11:18 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:44:29 PDT Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00252g; Thu, 29 Sep 88 14:42:24 PST Received: by challenger id AA00808g; Thu, 29 Sep 88 15:40:06 PDT Date: Thu, 29 Sep 88 15:40:06 PDT From: Jan Zubkoff Message-Id: <8809292240.AA00808@challenger> To: x3j13@sail.stanford.edu Subject: Fairfax Updated Agenda DRAFT **************DRAFT************** X3J13 Committee Meeting Agenda October 11 - 12, 1988 1 Call to Order, October 11, 9:00am 2 Opening Remarks and Introductions - Opening Remarks, Bob Mathis (10 minutes) - Introduction of attendees - Future meetings, Jan Zubkoff (5 minutes) 3 Approval of Agenda 4 Approval of Minutes 5 Character Subcommittee Report and Vote, Thom Linden (3 hrs) 6 Lunch, 12:00pm - 1:00pm 7 CLOS Workshop Report, Danny Bobrow (20 minutes) 8 CLOS Chapter 3, Gregor Kiczales (20 minutes) 9 Compiler Subcommittee Report and Vote, Sandra Loosemore (2 hrs) 10 Editorial Subcommittee Report, Kathy Chapman (30 minutes) 11 Recess, 5:00pm 12 Call to Order, October 12, 9:00am 13 Clean-up, Larry Masinter 14 Lunch, 12:00pm - 1:00pm 15 Error Terminology, Dan Pierson (30 minutes) 16 Registry for Packages, Modules, Features, Larry Masinter 17 Public-ftp access, Larry Masinter 18 Other committee reports 19 Adjournment, 5:00pm FAILNET-ORIGIN<453133.880929@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  [[[ [&[.[6[>[F[#N['V[+^[/f[3n[7v[;~[?  [ : {[[@Hv_ < xwv5 HlSp (p0q(X.0 OH(@ t ` ,4 UP8 ``bjectrfax deesus fa   X3J1endeermati X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Sep 88 19:11:16 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:46:06 PDT Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00255g; Thu, 29 Sep 88 14:44:00 PST Received: by challenger id AA00811g; Thu, 29 Sep 88 15:41:40 PDT Date: Thu, 29 Sep 88 15:41:40 PDT From: Jan Zubkoff Message-Id: <8809292241.AA00811@challenger> To: x3j13@sail.stanford.edu Subject: Fairfax Subcommittee Meetings Update Subcommittee meetings October 10, 1988 9:30 - 5:00 Characters (4-5) 9:30 - 12:30 Cleanup (?) 12:30 - 4:30 Editorial 2:00 - 5:00 Compiler (12) 2:30 - 5:00 Iteration (4) FAILNET-ORIGIN<453131.880929@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  [[[ [&[.[6[>[F[#N['V[+^[/f[3n[7v[;~[?  2[+< {[[@HL 0 lvK Hlp (p04(X7(0UHP+@ h, c` ,h/aP018 2`2`bjectrfax deesus fa   X3J1endeermati X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Sep 88 19:10:15 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:43:19 PDT Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00246g; Thu, 29 Sep 88 14:41:12 PST Received: by challenger id AA00805g; Thu, 29 Sep 88 15:38:54 PDT Date: Thu, 29 Sep 88 15:38:54 PDT From: Jan Zubkoff Message-Id: <8809292238.AA00805@challenger> To: x3j13@sail.stanford.edu Subject: Fairfax attendees Thus far: X3J13 Attendee Information 09/23/88 Name Institute Paid L1 L2 Jim Antonisse The MITRE Corporation - y - Kim Barrett USC - - - David Bartley TI y y y Paul Beiser HP - y y Danny Bobrow Xerox y y y Skona Brittian MSC y y y Kathy Chapman Digital Equipment Corporation - - - Jeff Dalton University of Edinburgh - y y Jerry Duggan HP - y y Dick Gabriel Lucid, Inc. - y y David Gray TI y y y George Hadden Honeywell Systems \& Research - y y Gregor Kiczales Xerox PARC - y y Timothy Koschmann Southern Illinois University y y y Aaron Larson Honeywell - y y Thom Linden IBM y y y David Loeffler MCC - y y Sandra Loosemore Evans & Sutherland - y y Barry Margolin Thinking Machines - y y Larry Masinter Xerox PARC y y y Bob Mathis Contel - y y Crispin Perdue Sun Microsystems - y y Dan Pierson Encore - y y Kent Pitman Symbolics - y y Rick Tucker Mitre Corporation - y y David Unietis Lucid, Inc. - y y Mary Van Deusen IBM Research y y y Walter van Roggen Digital Equipment Corporation - y - Ellen Waldrum TI - y y JonL White Lucid, Inc. - y y Jan Zubkoff Lucid, Inc. - y y FAILNET-ORIGIN<453124.880929@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  P PP P "P*P2P:PBP!JP%RP)ZP-bP1jP5rP9zP=  P+8 pPP@Hb * 5h HjWFp (v/(X 0 KH, 4 tx M@ t X`,4 UP8``XXt(t&t&t*Yt*qh&Dh(BCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Sep 88 12:12:54 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88 07:27:46 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 23:42:19 PDT Date: 28 Sep 88 23:42 PDT From: masinter.pa@Xerox.COM Subject: Re: Issue: DEFPACKAGE (version 3) In-reply-to: vanMelle.pa's message of 28 Sep 88 17:41 PDT To: cl-cleanup@Sail.stanford.edu cc: vanmelle.pa@Xerox.COM Message-ID: <880928-234219-233@Xerox> I think we're very close on this one. As for Bill's questions: DEFPACKAGE should in fact do an in-package? In fact, isn't it simply written portably? I like removing features. FAILmasinter.pa Re: Issue: DEFPACKAGE (version 3)<452861.880929@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  %% %% %% %% %&% %.% %6% %>% #%F% '%N% +%V% /%^% 3%f% 7%n% ;%v% ?%~%  /% , %U%%@H( 2 -+( HjMHp (JA(X= 0 H(!@ t# M` ,4) P-8 /`/`t)+0t(t&t&t*Yt*qh&Dh(BCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Sep 88 11:51:36 EDT Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 07:05:45 PDT Received: by decwrl.dec.com (5.54.5/4.7.34) id AA06406; Thu, 29 Sep 88 07:49:36 PDT Date: Thu, 29 Sep 88 07:49:36 PDT Message-Id: <8809291449.AA06406@decwrl.dec.com> From: vanroggen%aitg.DEC@decwrl.dec.com To: cl-cleanup@sail.stanford.edu Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (formerly FUNCTION-DECLARATION) Issue: DECLARE-FUNCTION-AMBIGUITY References: CLtL pp 43 (Table 4-1), 158-159 Category: CHANGE Edit history: #1, 21 Sept 1988, Walter van Roggen #2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity) Problem description: CLtL permits confusing and ambiguous FUNCTION declarations. One can say (DECLARE (FUNCTION F (VECTOR INTEGER) T)) to indicate that the function binding for F is of a certain type. Yet one can also say (DECLARE (FUNCTION X Y Z)) to indicate that the variables X, Y, and Z have values which are functions. The former is an abbreviation for (DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F)) The latter is an abbreviation for (DECLARE (TYPE FUNCTION X Y Z)) The ambiguity arises in a case like (DECLARE (FUNCTION F NIL STRING)) However, it would be an error to declare the type of the constant NIL to be a FUNCTION, so technically there is no ambiguity--there is just a peculiar special case. The most important problem, though, is that using the same declaration for two completely different purposes can lead to confusion among people writing or reading such code. Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE) The declaration (FUNCTION name argtypes valtypes) is no longer permitted to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name). The declaration (FUNCTION var1 var2) would just be an abbreviation for (TYPE FUNCTION var1 var2). Rationale: Continuing to allow all the predefined atomic type specifiers as declaration abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand. In other words, all the normal type declarations describe variable bindings; only the FTYPE declaration describes function bindings. This is a more uniform solution than making an exception to table 4-1. Since the old use of the FUNCTION declaration for function bindings was just an abbreviation for the FTYPE declaration, no expressivity is lost. Furthermore one is able to say that a variable's value is of type FUNCTION, something that hadn't been clearly possible without using the TYPE declaration. Current Practice: VAX LISP treats FUNCTION declarations only as abbreviations for FTYPE declarations. Cost to Implementors: Likely to be small to those implementations that heed these kinds of declarations; none for those that don't. Cost to Users: Existing uses of the FUNCTION declaration for function bindings will need to be changed to FTYPE declarations. Cost of Non-Adoption: People will continue to be confused by function declarations. Benefits: A simpler language. Esthetics: Discussion: Making it clear that only FTYPE declarations describe function bindings will make it easier to add new kinds of declarations that support incremental or additional descriptions, as is needed for describing methods (MTYPE?). Since all cases can be disambiguated after all (the original proposal didn't realize that one couldn't declare the type of the constant NIL to be a FUNCTION), compatibility considerations might deem this proposal to be unnecessary. However, van Roggen believes that making declarations simpler and less confusing is more important than compatibility in this case. The proposal was renamed from FUNCTION-DECLARATION after Masinter pointed out that this issue had already been considered and named. FAILNET-ORIGIN<452856.880929@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ~>~} ~>~}~> ~}~> ~}"~>~}*~>~}2~>~}:~>~}B~>!~}J~>%~}R~>)~}Z~>-~}b~>1~}j~>5~}r~>9~}z~>=~}  ~> < ~^~>~>@Hw }= Hegp ((X 0 XH, 4 tx Z@ t o`,4 bP8``ee,0 z(CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 22:49:11 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 19:39:04 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 19:31:36 PDT Date: 28 Sep 88 19:31 PDT From: masinter.pa@Xerox.COM Subject: on Splitting and Merging issues To: CL-Cleanup@Sail.stanford.edu Message-ID: <880928-193136-2162@Xerox> Merging issues is time-consuming and risky. On these tightly intertwined issues (e.g., DEFPACKAGE and IN-PACKAGE-FUNCTIONALITY, PACKAGE-CLUTTER and LISP-SYMBOL-REDEFINITION), I thought I might present them both to X3J13 before any discussion of either of them. Its almost as good as merging them, but does allow us to agree on one and continue to discuss the other without the additional confusion. FAILmasinter.pa on Splitting and Merging issues<452650.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  bt+B tt@H+  kt7}; Hpose: Address: Affiliation: .AI.Mdi2p ((X!D 0HP[@ h\ i` ,h_P0a8 b`b`MIT.Edph@AMIT.EDAM@AMIT.EDanieAI.MIbatalAIL-FCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 21:57:06 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 18:46:33 PDT Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01414g; Wed, 28 Sep 88 17:43:59 PST Received: by bhopal id AA10743g; Wed, 28 Sep 88 18:43:33 PDT Date: Wed, 28 Sep 88 18:43:33 PDT From: Jon L White Message-Id: <8809290143.AA10743@bhopal> To: Gregor.pa@Xerox.COM Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu In-Reply-To: Gregor.pa@Xerox.COM's message of Wed, 28 Sep 88 16:47 PDT <19880928234749.5.GREGOR@PORTNOY.parc.xerox.com> Subject: Issue: DEFPACKAGE (version 3) re: I should have said "the way a symbol is printed". In a programming environment in which the users program passes through READ and PRINT this is an issue. Given that package is bound to some package FOO which only uses LISP, this form: (import 'pcl::class-direct-slots) Once I read this form, it will print out as: (IMPORT 'CLASS-DIRECT-SLOTS) So that when I load it again in a fresh world, I won't get the result I got the first time. This is precisely one of the situations that I've been referring to when I argue for the removal of the :IMPORT option. Note however, that the revised proposal does *not* have this misfeature even if you use _symbols_ in the :IMPORT-FROM option. That's the whole point of it. [Yes, your structure editor might package-qualify one such symbol differently, if PRINTed at the "wrong" times, but that will be completely irrelevant.] You did mention before that you found the documentation about the symbols-vs-strings as arguments somewhat unclear, so maybe this point didn't get through. Wanna suggest some re-wordings? -- JonL -- P.S. By the bye, are you aware of the existence of the Decency in Packaging League, which will slap you with a citation for writing code like: (import 'pcl::class-direct-slots) rather than: (import (intern "CLASS-DIRECT-SLOTS" "PCL")) FAILNET-ORIGIN<452623.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWiYN-% At tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  9t+8 tt@HL+6AeRz] Hpose: Address: Affiliation: .AI.Md5Mp (V(X 0#HH 4 tx @ t- 6`,43 P789`9`h&Dh(Bt) h'2h)Ut*SCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 20:06:37 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 16:56:14 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 16:48:00 PDT Date: Wed, 28 Sep 88 16:47 PDT From: Gregor.pa@Xerox.COM Subject: Re: Issue: DEFPACKAGE (version 3) To: Jon L White cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8809282019.AA09354@bhopal> Message-ID: <19880928234749.5.GREGOR@PORTNOY.parc.xerox.com> Line-fold: no Date: Wed, 28 Sep 88 13:19:55 PDT From: Jon L White There is no common-lisp capability to "change the print-name" of symbols. This DEFPACKAGE proposal doesn't suggest that, so if you think it implied it somehow, maybe you could point out the confusing phrases. I should have said "the way a symbol is printed". In a programming environment in which the users program passes through READ and PRINT this is an issue. Given that package is bound to some package FOO which only uses LISP, this form: (import 'pcl::class-direct-slots) Once I read this form, it will print out as: (IMPORT 'CLASS-DIRECT-SLOTS) So that when I load it again in a fresh world, I won't get the result I got the first time. ------- FAILGregor.pa Re: Issue: DEFPACKAGE (version 3)<452559.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  Jt+B tt@H|+8 wC Hpose: Address: Affiliation: .AI.Mcp (?|(X L 0 AH, 4 tx HC@ hD `,hGP0I8J`J`CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 18:11:13 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 14:58:48 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 14:50:52 PDT Date: 28 Sep 88 14:49 PDT From: masinter.pa@Xerox.COM Subject: back.... To: cl-cleanup@sail.stanford.edu Message-ID: <880928-145052-1699@Xerox> I forgot to send out a message that I'm actually back... I'm still swamped by cleanup mail, and really would still like new revised, clean, agreeable proposals from you asap. Thanks, Larry FAILmasinter.pa back....<452510.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWiYN-% At tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  Wt+8 tt@H+>A ɇ{( Hpose: Address: Affiliation: .AI.Mc|Op ((X 0 $H(I@ tK ` ,4Q *PU8 W`W`--<q :uwwCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 18:05:03 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 14:53:02 PDT Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01076g; Wed, 28 Sep 88 13:50:55 PST Received: by bhopal id AA09835g; Wed, 28 Sep 88 14:50:29 PDT Date: Wed, 28 Sep 88 14:50:29 PDT From: Jon L White Message-Id: <8809282150.AA09835@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM Cc: CL-Cleanup@SAIL.Stanford.EDU Subject: Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE In Kent's note of Tue, 27 Sep 88 12:25 EDT, he points out the action of MAKE-PACKAGE, for an existing package, is to "break" (in most implementations.) It occurs to me that the DEFPACKAGE proposal is silent (hence, subject to varying interpretations) about how to handle the case of defining a package on a name that already exists. I see three possibilities: (1) "break", just like MAKE-PACKGE (2) Simply do the new definition (as DEFUN and DEFCLASS do), possibly issuing a warning message based upon vendor-specific facilities. (3) Quietly do the new definition, providing that it is essentially compatible with the old one; signal an error if not compatible. I think I'd prefer (3), since it allows you to re-load a file that is under development, without getting spurious breaks or warning messages; yet it provides some assurance that you aren't about to break your whold world. Comments? -- JonL -- FAILNET-ORIGIN<452503.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!    \  \  \  \ & \ . \ 6 \ > \# F \' N \+ V \/ ^ \3 f \7 n \; v \? ~ \  y  8    @HT+8 tZ HcM-p ((X 0cH2 ")Hx e@ tm `,4s ;Pw8y`y`>> CLIEDS   ======ill tCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 16:24:14 EDT Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 13:11:47 PDT Received: from GRYPHON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 323211; Wed 28-Sep-88 16:09:17 EDT Date: Wed, 28 Sep 88 16:09 EDT From: Kent M Pitman Subject: Issue: PACKAGE-CLUTTER (Version 2) To: jonl@lucid.com cc: Scott.Fahlman@B.GP.CS.CMU.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: <8809282004.AA09299@bhopal> Message-ID: <880928160917.3.KMP@GRYPHON.SCRC.Symbolics.COM> Date: Wed, 28 Sep 88 13:04:19 PDT To: Scott.Fahlman@B.GP.CS.CMU.EDU Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Wed, 28 Sep 88 14:53:08 EDT <8809281858.AA00875@lucid.com> Subject: Issue: PACKAGE-CLUTTER (Version 2) Say, you guys have been discussing the LISP-SYMBOL-REDEFINITION issue under the banner of "Issue: PACKAGE-CLUTTER". Wanna switch? -- JonL -- I guess I accidentally broadened the issue when I changed some sentence that said "the system can't provide..." to say "no one can..." or some such thing. It's just as dangerous for the user to do it as the system, so the issues are related. Would it make sense to merge the issues as a single new issue LISP-SYMBOL-DEFINITION? I'd prefer to do that rather than ask people to talk about only half the subject at a time. If after more discussion we needed to break it back out into two topics, we could still do so... FAILKMP Issue: PACKAGE-CLUTTER (Version 2) <452439.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  x>x} x>x}x> x}x> x}"x>x}*x>x}2x>x}:x>x}Bx>!x}Jx>%x}Rx>)x}Zx>-x}bx>1x}jx>5x}rx>9x}zx>=x}  x> : x^x>x>@Hz+< ||zY Hc?p (PR(XP 0 ;Hw ")Hx <@ t `,4 DP8`` I/A0%4 &/AM<OCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 14:14:23 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 11:01:30 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467081; Wed 28-Sep-88 14:00:01 EDT Date: Wed, 28 Sep 88 13:59 EDT From: David A. Moon Subject: Issue: TYPE-OF-UNDERCONSTRAINED To: masinter.pa@Xerox.COM cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880921-024739-5696@Xerox> Message-ID: <19880928175947.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: 21 Sep 88 02:47 PDT From: masinter.pa@Xerox.COM This is in response to mail under COERCE-FROM-TYPE and TYPE-OF. I would prefer to constrain TYPE-OF to be at least as specific as (CLASS-NAME (CLASS-OF x)). That seems like a reasonable idea. I'm less sure what to do about instances of unnamed classes; the Medley way would be to return the class itself for an otherwise nameless class. TYPE-OF could return NIL in that case, which is a subtype of everything (ha ha). Since CLOS says class objects are acceptable wherever type specifiers are, I think the Medley way is okay. This would disallow what is otherwise "legal" now: namely to have TYPE-OF return T for everything but structure instances. I think it probably is reasonable also to constrain TYPE-OF to be something that SUBTYPEP can deal with. (cf SUBTYPEP-TOO-VAGUE). I'm less sure of this, since I can't figure out if there are any ramifications. It's not worth putting a lot of effort into TYPE-OF, since if you want something well-defined you definitely use CLASS-OF rather than TYPE-OF. FAILMoon Issue: TYPE-OF-UNDERCONSTRAINED<452359.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  Ut < tt@Hg , 8s|z Hpose: Address: Affiliation: .AI.Mc rp (a%(X 0 JH$ 4 tx @ hO `,hRP0T8U`U`070  =CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 14:00:18 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 10:47:30 PDT Received: from Semillon.ms by ArpaGateway.ms ; 28 SEP 88 09:23:05 PDT Date: Wed, 28 Sep 88 09:21 PDT From: Gregor.pa@Xerox.COM Subject: Re: Issue: DEFPACKAGE (version 3) To: Jon L White cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8809280541.AA06405@bhopal> Message-ID: <19880928162127.8.GREGOR@PORTNOY.parc.xerox.com> Line-fold: no Date: Tue, 27 Sep 88 22:41:16 PDT From: Jon L White Add a DEFPACKAGE macro to the language. It encourages putting the entire definition of a package in a single place. It also encourages putting all the package definitions of a program in a single file, which can be loaded before loading or compiling anything that depends on those packages. This file can be read in the USER package, avoiding any package bootstrapping issues. I think that at least IN-PACKAGE should not accept these options, and should be used for selection only. The reason is the same as the one for adding DEFPACKAGE. If you do this to IN-PACKAGE, people will end up making the same mistake of using in-package with different arguments in different files of their program. Also, wherever it currently takes a symbol or a symbol-name (string), it should just take a string. There are two reasons for this. The first is simplicity, the current description of what happens with symbols is confusing. More importantly is current practice. In systems which use a "structure" editor, forms which take symbols as their argument, and then change the print-name of those symbols, cause all sorts of problems. So, at least the import options will cause problems for this system. ------- FAILGregor.pa Re: Issue: DEFPACKAGE (version 3)<452350.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  t * tt@HH  hOI Hpose: Address: Affiliation: .AI.Mb]rp (P !%(X) 0H  ")Hx @ h ``,h-P08``h&Dh(Bt) h'2t&t CL-Error-Handling-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 12:26:26 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 09:04:28 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466997; Wed 28-Sep-88 12:03:11 EDT Date: Wed, 28 Sep 88 12:03 EDT From: David A. Moon Subject: Issue: CLOS-CONDITIONS (Version 1) To: Kent M Pitman cc: CL-ERROR-HANDLING@SAIL.Stanford.EDU, Gregor.PA@Xerox.COM In-Reply-To: <880927180538.1.KMP@GRYPHON.SCRC.Symbolics.COM> Message-ID: <19880928160300.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Tue, 27 Sep 88 18:05 EDT From: Kent M Pitman .... Define that CLOS condition types are CLOS classes. Define that CLOS condition objects are CLOS instances. Is the first occurrence of CLOS on each line a typo? If not, I don't know what a "CLOS condition" is. Define that condition reporting is mediated through the PRINT-OBJECT method for the condition type (class) in question, with *PRINT-ESCAPE* always being NIL. Specifying (:REPORT fn) in the definition of a condition type C is equivalent to doing (DEFMETHOD PRINT-OBJECT ((X c) STREAM) (IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X C))) (fn X C) should be (fn X STREAM). Also, use upper or lower case C consistently. Clarify that DEFINE-CONDITION automatically adds :INITARG and :READER slot-options. Specify what happens if the user writes these slot-options herself; do they override the default ones, or do both sets of slot-options apply? * Daniels still thinks there should be a way to access and modify report functions for conditions without going through DEFINE-CONDITION again. [This has been blocked waiting for CLOS to settle down.] I'm not sure whether you regard this issue as settled now, or need to do something more. Some functions like SIGNAL take an argument that can be among other things a condition-type. Is it valid to use a class object as a condition type, in addition to a class name being valid? CLOS itself signals some new errors and standardized condition names for those signals could be added. There are also a lot of editorial changes to be made to the rev-18 document, to reflect the existence of CLOS. They're pretty obvious, like take out all the complaints that there is no standardized object system. FAILMoon Issue: CLOS-CONDITIONS (Version 1)<452302.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! Ax>x} x>x}x> x}x> x}"x>x}*x>x}2x>x}:x>x}Bx>!x}Jx>%x}Rx>)x}Zx>-x}bx>1x}jx>5x}rx>9x}zx>=x}  x>  x^x>x>@H{+@A ~{xw HbZsp ('u(X7, 0 gH(@ t [A` ,4 mP8 ``pp(h&,0 z(CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 12:20:03 EDT Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 28 Sep 88 09:05:13 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa04769; 28 Sep 88 16:11 BST Date: Wed, 28 Sep 88 16:51:09 BST Message-Id: <28871.8809281551@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: Issue: PROCLAIM-LEXICAL (Version 7) To: Jon L White <@NSS.Cs.Ucl.AC.UK,@edu.stanford.edu:jonl@lucid.com>, Moon@scrc-stony-brook.arpa In-Reply-To: Jon L White's message of Tue, 27 Sep 88 23:56:21 PDT Cc: KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu, JAR@ai.ai.mit.edu > his might be something we shouldn't even think about standardizing > until some implementor/vendor takes the plunge in a trial balloon, > Yes, I remember, I was mildly in favor of the original proposal; but that > was a year and a half ago, and I expected a GLOBAL declaration to mean that > it would be illegal to special-bind that name (hence you could depend on > that name *not* being in the D environment). Had somebody implemented > something like it for their Lisp back then, we might have had results to > talk about now. I think the semantic implications of adding a declaration that prevents dynamic binding are sufficiently straightforward that we should not rule it out just because no one implemented it a year ago. The strangeness in the current proposal is because the dynamic and lexical environments meet in a separate global environment. So a shallow bound implementation can't just change the global cell when it pushes a new binding. The shallow binding cell has to be a separate cell, making symbols (effectively) larger. KMP and JAR suggested the use of a single cell combined with search for the global value if both it and the dynamic are needed. This is a new machanism, so we might want to think twice about it. An alternative is to say that a given global variable can be either lexical or special but not (as they can be in the current proposal) both. That's not all that strange, because it's what we get with LET. It lets us use a single cell and simply rules out the case when both are needed. I believe this alternative (which is more or less what was proposed before minus all the stuff about CONSTANT proclamations, etc.) solves the main problems (an easily referenced global for deep bound implementations and a way to establish a global variable without proclaiming it special and without some implementations thinking it's a spelling error or an omitted proclamation) and is fairly noncontroversial. We can fight about whether the proclamation for this should be called GLOBAL or LEXICAL. I think it is better to think of the new kind of global variable as a kind of lexical variable rather than as a special1 variable that can't be bound, but that may be a matter of taste. We might also fight, I suppose, about whether there should be a corresponding declaration (to override special proclamations). [It occurs to me that people might think of two different declarations. 1. (set-global x 10) (let ((x 20)) (locally (declare (lexical x)) x)) => 20 2. (set-global x 10) (let ((x 20)) (locally (declare (global x)) x)) => 10 The one I have in mind is the 1st.] In any case, I think there is a fallback better than "do nothing". FAILNET-ORIGIN<452294.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! Ax>x} x>x}x> x}x> x}"x>x}*x>x}2x>x}:x>x}Bx>!x}Jx>%x}Rx>)x}Zx>-x}bx>1x}jx>5x}rx>9x}zx>=x}  ?x>+: x^x>x>@H{ <A}s}5{l HbSp (v(X*L 0)H  ")Hx +@ t3 S`,49 P=8?`?`!!,0 z(CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 88 12:03:15 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 08:52:30 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466976; Wed 28-Sep-88 11:22:12 EDT Date: Wed, 28 Sep 88 11:22 EDT From: David A. Moon Subject: Issue: PROCLAIM-LEXICAL (Version 7) To: Kent M Pitman cc: CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: <880924193252.5.KMP@GRYPHON.SCRC.Symbolics.COM> Message-ID: <19880928152208.0.MOON@EUPHRATES.SCRC.Symbolics.COM> In fact I have been unable to think of any way to implement this proposal in a fully shallow-bound system. The problem is that the proposal requires that SPECIAL global references and LEXICAL global references share the same value when there has been no SPECIAL binding, but do not share when there has been a SPECIAL binding. In a fully shallow-bound system (i.e. no environment search in SPECIAL references and none in LEXICAL global references), this means that the first SPECIAL binding has to do something unusual to separate the SPECIAL value from the LEXICAL value, and the last SPECIAL unbinding has to undo that. Having turned my brain back on, I have now thought of an efficient way to do this on Lisp machines, using invisible pointers, and another efficient way to do it on stock hardware, using one extra instruction on every global reference of one or the other sort, plus a few extra instructions in SPECIAL binding and unbinding. Given that, I no longer object to the proposal as unimplementable. However, I still think you need to be more forthcoming about the cost to the implementor: it doesn't just require a few compiler changes, it requires some reimplementation of the representation of global variables, with concomitant changes to the compiler, the loader, the interpreter, and probably the debugger. Every symbol now potentially has two values accessible from the interpreter (the current SPECIAL and the global LEXICAL) and you need the corresponding new data structure to keep track of that. A more cogent objection is that the proposal is incomplete. Common Lisp includes a bunch of mechanisms related to global SPECIAL variables (DEFVAR, SYMBOL-VALUE, MAKUNBOUND, etc.) and some or all of this needs to be replicated for LEXICAL variables. I suspect not all of it needs to be replicated, but you've got to discuss and decide. I still think it would be good to do something resembling this. FAILMoon Issue: PROCLAIM-LEXICAL (Version 7)<452288.880928@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  4 44 4 #4+434;4C4!K4%S4)[4-c41k45s49{4= A4  4"44@HT+8 W3V-T Hpose: Address: Affiliation: .AI.M\|`p (S(X\ 0 x+H (3@ t5 ` ,4; P?8A`A`"".eduL@ai.t.eduY@ai.t.edui.ai.duved: CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Sep 88 22:38:24 EDT Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 19:28:35 PDT Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 27 Sep 88 22:24:27 EDT To: Kent M Pitman cc: CL-Cleanup@SAIL.Stanford.EDU Subject: Re: Issue: PACKAGE-CLUTTER (Version 2) In-reply-to: Your message of Tue, 27 Sep 88 13:04:00 -0400. <880927130442.2.KMP@GRYPHON.SCRC.Symbolics.COM> Date: Tue, 27 Sep 88 22:23:54 EDT From: Scott.Fahlman@B.GP.CS.CMU.EDU Symbols on the LISP package may have function or macro definitions, variable definitions or SPECIAL proclamations, or type definitions only if explicitly permitted in the specification. Neither users nor implementors are permitted to add new kinds of definitions for these symbols. I don't know what "variable definitions" means. Does this mean that I, as a user, am not allowed to use symbols such as LIST, MEMBER, or SYMBOL as a lexical variable in my own protable code? If so, I am very strongly opposed to this. The conversion cost would be very high, and I don't see any safety issue that would force us to restrict the user in this way. If that is not the intended meaning, perhaps some clearer wording is needed. I'd go along with the other cases. -- Scott FAIL Re: Issue: PACKAGE-CLUTTER (Version 2) NET-ORIGIN<452052.880927@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  } }} }$},}4}<}D}"L}&T}*\}.d}2l}6t}:|}>  |}+6 }}@Hq    1}~= HX>1p (_(XMX 0HPu@ hv >` ,hyP0{8 |`|`08t@0H'  CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Sep 88 02:13:05 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 23:02:07 PDT Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00238g; Mon, 26 Sep 88 22:00:09 PST Received: by bhopal id AA03266g; Mon, 26 Sep 88 22:59:40 PDT Date: Mon, 26 Sep 88 22:59:40 PDT From: Jon L White Message-Id: <8809270559.AA03266@bhopal> To: cl-cleanup@sail.stanford.edu Subject: Issue HASH-TABLE-TESTS Issue: HASH-TABLE-TESTS References: CLtL, p382 (third paragraph), and p383 Issue EQUAL-STRUCTURE Issue: CONTAGION-ON-NUMERICAL-COMPARISONS Category: Addition Edit history: 26-Sep-88 Version 1 by JonL Problem Description: A great many users try to coalesce two equivalent defstruct instances, or two equivalent pointer arrays, using hash tables; but they are rudely awakened when they find out that EQUAL is not an appropriate test for this case, and that there is no :test argument to MAKE-HASH-TABLE which will "hash on non-tree structures". Proposal: HASH-TABLE-TESTS:ADD-EQUALP With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we can expect EQUALP to be a true equivalence function, and thus a suitable candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will come in four kinds, the difference being whether the keys are compared with EQ, EQL, EQUAL, or EQUALP. Examples: > (defstruct foo a b c) FOO > (setq x (make-foo :a 1 :b 'b :c '(1 . 2)) x-copy (make-foo :a 1 :b 'b :c '(1 . 2))) #S(FOO A 1 B B C (1 . 2)) > (setq y #(1 B (1 . 2)) y-copy (copy-seq y)) #(1 B (1 . 2)) > (setq ht-equal (make-hash-table :test 'equal) ht-equalp (make-hash-table :test 'equalp)) # > (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t) (setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t)) T > (gethash x-copy ht-equal) NIL NIL > (gethash x-copy ht-equalp) T T > (gethash y-copy ht-equal) NIL NIL > (gethash (copy-seq y) ht-equalp) T T > Rationale: Implementing hash-tables efficiently is not an easy task; it makes more sense for this to be standardly available (implemented by the wizards at the Lisp vendor companies) than for individual programmers to keep trying to re-invent this obscure part of technology. Current Practice: Lucid's release 3.0 implements this proposal [some 2.1-level release supported it "provisionally"]. Symbolics implementation is reputed to be robust enough to implement this proposal trivially. Cost to Implementors: Moderate. Implementors have already dealt with EQUAL; the only tricky part will be ensuring the implication: "If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the same collision chain in any given EQUALP hash table" It has been suggested that merely linear searching a table is an acceptable implementation technique for CL's hash-tables [although no serious implementation limits itself thus] and that such tables have no "collision chains"; but in fact, this is the degenerate case wherein all entries are in the same collision chain, so the implication is trivially satisfied. Some persons prefer to say that the "reprobe sequence will be the same for the two items", rather than using the term "collision chain"; the meaning is the same. Cost to Users: None. This is an entirely upwards-compatible addition. Cost of non-adoption: Continuing bug reports from CL vendors' customers about why "hashing doesn't work" when said customer tries entering pointer-containing objects other than cons cells into hash tables. Continuing delay in same customers work until they figure out a new strategy for identifying equivalent structures. More difficulty in debugging their alternatives. Benefits: Addresses one aspect of the difficult equivalence problem. Makes hash tables usable with the major, remaining equivalence predicate of CL. Also as a "side effect", permits case-insensitive hashing on strings [tables of type EQUAL are case-sensitive on strings]; another "side effect" is the abililty to use the CL numeric comparison "=" for numbers [tables of type EQUAL use EQL on numbers]. Aesthetics: Reduces the discontinuity between basic equivalence functions and those usable as equivalence relations in hash-tables. Discussion: With the rejection of all the issues related to EQUAL-STRUCTURE, there is little or no hope that EQUAL will be "beefed up" to meet the expectations of so many of the user community on compound structures. If one wants a hash-table with a :test function that has fewer equivalence classes (i.e., does more "coalescing"), then there is no alternative now except to use the function EQUALP. FAILNET-ORIGIN<451511.880927@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  ct 8 tt@H'  gs3x@ Hpose: Address: Affiliation: .AI.MXwp (G(X 0H Y ")Hx |@ h] `,h`P0b8c`c` p0r sCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Sep 88 00:48:55 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 21:38:51 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466144; Tue 27-Sep-88 00:37:24 EDT Date: Tue, 27 Sep 88 00:37 EDT From: David A. Moon Subject: Issue: STREAM-INFO (Version 5) To: Richard C. Waters , CL-Cleanup@sail.stanford.edu In-Reply-To: <8809231612.AA00588@rice-chex.ai.mit.edu> Message-ID: <19880927043729.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I approve STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS in version 5. Your property 9 appears to have been garbled by an editing error. FAILMoon Issue: STREAM-INFO (Version 5)<451466.880927@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWiYN-% At tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=   t & tt@H8 A{> Hpose: Address: Affiliation: .AI.MU\p (2(X 0H ~ ")Hx @ h `,hP08 ` `Y[[CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Sep 88 23:53:00 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 20:42:52 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466117; Mon 26-Sep-88 23:41:34 EDT Date: Mon, 26 Sep 88 23:41 EDT From: David A. Moon Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1) To: CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: <880707161211.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880927034132.3.MOON@EUPHRATES.SCRC.Symbolics.COM> I approve IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY even though I rarely favor incompatible changes. As JonL pointed out in a recent message, the fact that Common Lisp encourages users to replicate their package definitions in several places (several calls to IN-PACKAGE) leads to errors that are difficult to diagnose and correct. Even if DEFPACKAGE is not adopted, I still favor IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY, in spite of the proposal's claim to depend on DEFPACKAGE; MAKE-PACKAGE could be used instead. FAILMoon Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)<451427.880926@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  t , tt@H6  V5< Hpose: Address: Affiliation: .AI.MTp (#(XX 0 {H(@ t ` ,4 P8 ``YCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Sep 88 22:44:18 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 19:33:54 PDT Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA09696g; Mon, 26 Sep 88 18:30:59 PST Received: by bhopal id AA02793g; Mon, 26 Sep 88 19:30:32 PDT Date: Mon, 26 Sep 88 19:30:32 PDT From: Jon L White Message-Id: <8809270230.AA02793@bhopal> To: KMP@STONY-BROOK.SCRC.Symbolics.COM Cc: Gray@DSG.CSC.TI.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: Kent M Pitman's message of Sat, 24 Sep 88 20:29 EDT <880924202915.2.KMP@GRYPHON.SCRC.Symbolics.COM> Subject: Issue: DECLARE-TYPE-FREE (Version 1) re: Fyi, I didn't mean to suggest that that program was good style. I was just trying to answer Moon's "Is it necessary to be explicit?" query by demonstrating that it was necessary. Understood. I liked Gray's phraseology re "specialized storage". Some commentary alluding to that ought to be in the proposal; that would help justify the restriction against this "explicit" style. -- JonL -- FAILNET-ORIGIN<451398.880926@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  krkkrkkr kkrk&krk.krk6krk>krkFkr#kNkr'kVkr+k^kr/kfkr3knkr7kvkr;k~kr?k  }kr  lkrkr@Hm+@ poOm HT p ((X, 0gH4 ")Hx i@ tq M`,4w =P{8}`}`n-Rep: (ArE. Ogmessa 26 S 19:2GMT <@agatKELEYCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Sep 88 18:34:00 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 15:23:12 PDT Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465961; Mon 26-Sep-88 18:21:32 EDT Date: Mon, 26 Sep 88 18:21 EDT From: Kent M Pitman Subject: Issue: PROCLAIM-LEXICAL (Version 7) To: eb@lucid.com cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: <8809262150.AA00173@blacksox> Message-ID: <880926182124.4.KMP@GRYPHON.SCRC.Symbolics.COM> Date: Mon, 26 Sep 88 14:50:10 pdt From: Eric Benson ... Do you want to make LEXICAL the default for otherwise unspecified references? It still might be a good idea to warn about the absence of any declaration. This proposal doesn't suggest it. I thought hard about it and decided there was really no reason to. After all, you still need to initialize the variable you'll be closing over, so you can do the proclamation at the same time. The missing component which does need to be followed up on if this gets approved is how we declare these variables. People will want lexical analogs of DEFVAR and DEFPARAMETER or perhaps some extended syntax to these which allows you to designate that the proclamation should be LEXICAL instead of DYNAMIC. I suspect that this issue will be a subject of much controversy as well, so I wanted to make sure it was fully separated in order to stave off the multiplicative effects of doing too many controversial things at once. FAILKMP Issue: PROCLAIM-LEXICAL (Version 7)<451244.880926@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!       # + 3 ; !C %K )S -[ 1c 5k 9s ={  h+6 S@H?  zK}Y HSt0p (l(X! 0 ]H  ")Hx  ^@ hb `,heP0g8h`h`A C gCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Sep 88 17:47:29 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 14:36:46 PDT Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465907; Mon 26-Sep-88 17:35:17 EDT Date: Mon, 26 Sep 88 17:35 EDT From: Kent M Pitman Subject: Issue: PROCLAIM-LEXICAL (Version 7) To: eb@lucid.com cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: <8809262107.AA00152@blacksox> Message-ID: <880926173510.0.KMP@GRYPHON.SCRC.Symbolics.COM> Date: Mon, 26 Sep 88 14:07:48 pdt From: Eric Benson Date: Mon, 26 Sep 88 15:44 EDT From: Kent M Pitman Does the following look ok to you? #1: (proclaim '(lexical x)) (proclaim '(special y)) (setq x 1 y 2) (defun tst () (let ((x 3) (y 4)) (locally (declare (special x) (lexical y)) (list x y (funcall (let ((x 5) (y 6)) #'(lambda () (list x y)))))))) (tst) => (1 2 (5 4)) I think that's (1 2 (5 6)). No, I'm not as tired this time, and I think I'm right ... X gets bound lexically to 3 because X is [pervasively] proclaimed LEXICAL. Y gets bound specially to 4 because Y is [pervasively] proclaimed SPECIAL. Reference style for name X is changed to SPECIAL, making lexical X=3 invisible. Reference style for name Y is changed to LEXICAL, making dynamic Y=4 invisible. Global X=1 and global Y=2 are first two elements of list. X gets bound lexically to 5 because X is [pervasively] proclaimed LEXICAL. Y gets bound specially to 6 because Y is [pervasively] proclaimed SPECIAL. Closure is returned, capturing [lexical] X=5 but not [special] Y=6. Dynamic binding of Y to 6 disappears, dynamic binding of Y to 4 reverts. Closure is funcalled, returning captured X=5 and dynamically active Y=4 in a list which becomes third list element. Make sense? FAILKMP Issue: PROCLAIM-LEXICAL (Version 7)<451193.880926@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWiYN-% AUGU$UG U$ UGU$ UGU$UG"U$UG*U$UG2U$UG:U$!UGBU$%UGJU$)UGRU$-UGZU$1UGbU$5UGjU$9UGrU$=UGzU$  UG+@ UUGUG@HVj+BAYWnVpyt Hpose: Address: Affiliation: .AI.MShNp (;(X 0 H(@ t ` ,4  P 8 ``   0U  WXXXCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Sep 88 17:22:22 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 14:12:27 PDT Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA09428g; Mon, 26 Sep 88 13:10:21 PST Received: by blacksox id AA00152g; Mon, 26 Sep 88 14:07:48 pdt Date: Mon, 26 Sep 88 14:07:48 pdt From: Eric Benson Message-Id: <8809262107.AA00152@blacksox> To: KMP@STONY-BROOK.SCRC.Symbolics.COM Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: Kent M Pitman's message of Mon, 26 Sep 88 15:44 EDT <880926154450.4.KMP@GRYPHON.SCRC.Symbolics.COM> Subject: Issue: PROCLAIM-LEXICAL (Version 7) Date: Mon, 26 Sep 88 15:44 EDT From: Kent M Pitman Does the following look ok to you? #1: (proclaim '(lexical x)) (proclaim '(special y)) (setq x 1 y 2) (defun tst () (let ((x 3) (y 4)) (locally (declare (special x) (lexical y)) (list x y (funcall (let ((x 5) (y 6)) #'(lambda () (list x y)))))))) (tst) => (1 2 (5 4)) I think that's (1 2 (5 6)). FAILNET-ORIGIN<451172.880926@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  t  tt@H  _O Hpose: Address: Affiliation: .AI.MS.p ([(X 0 =H({@ t} 鮋` ,4 CP8 ``FFCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Sep 88 15:17:24 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 12:06:47 PDT Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA09287g; Mon, 26 Sep 88 11:04:43 PST Received: by blacksox id AA00135g; Mon, 26 Sep 88 12:02:11 pdt Date: Mon, 26 Sep 88 12:02:11 pdt From: Eric Benson Message-Id: <8809261902.AA00135@blacksox> To: KMP@STONY-BROOK.SCRC.Symbolics.COM Cc: CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: Kent M Pitman's message of Sat, 24 Sep 88 19:32 EDT <880924193252.5.KMP@GRYPHON.SCRC.Symbolics.COM> Subject: Issue: PROCLAIM-LEXICAL (Version 7) Date: Sat, 24 Sep 88 19:32 EDT From: Kent M Pitman Test Case: #1: (proclaim '(lexical x)) (proclaim '(special y)) (setq x 1 y 2) (defun tst () (let ((x 3) (y 4)) (locally (declare (special x) (lexical y)) (list x y (funcall (let ((x 5) (y 4)) #'(lambda () (list x y)))))))) (tst) => (1 4 (5 4)) Maybe I'm confused, but I thought this should be (1 2 (5 4)), since the first reference to y is a lexical reference (LG). The setq of y to 2 is global, but the binding of y to 4 is dynamic, and therefore invisible to a lexical reference. This is an example of the case where you stated "some searching may be necessary to find the global cell in shallow bound implementations [unless dynamic binding has been forbidden for that variable]" which is also illustrated in the second example. Or did you intend that a lexically apparent dynamic binding is also a lexical binding? That seems strange to me. It would imply that a special binding is not equivalent to a corresponding PROGV, for example. FAILNET-ORIGIN<451094.880926@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ` `` ` ` `` `` $`` ,`` 4`` <`"` D`&` L`*` T`.` \`2` d`6` l`:` t`>` |`  `  < `M` ` @Hd  h%gCd1 HRtVp,a(p0(XH0oH8 ")Hx xq@ tw t`,4} @P8``ct: iEVAL-NON-TVEL andran@cs.edu 3j13@stanfX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 26 Sep 88 13:15:02 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:16 PDT Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465233; Sun 25-Sep-88 15:09:13 EDT Date: Sun, 25 Sep 88 15:08 EDT From: Kent M Pitman Subject: issue EVAL-WHEN-NON-TOP-LEVEL To: sandra%defun@cs.utah.edu cc: x3j13@sail.stanford.edu In-Reply-To: <8809231753.AA02502@defun.utah.edu> Message-ID: <880925150859.4.KMP@GRYPHON.SCRC.Symbolics.COM> I'm sorry. At the last meeting, I stated that I had reservations about this proposal and said I would send some mail and I never did. I did say at that time, though, that the root of my problem was that there were insufficient examples and that this made me nervous because this is a hard issue to reason about and (I think) an easy one to get wrong. -- Specific Remarks -- Your use of phrases like "the interpreter" in the proposal make me nervous because I work with at least one compiled-only implementation (Cloe). Your remarks about (let ((x (some-hairy-computation))) (eval-when (eval compile load) (print x))) treating X as special in the compile situation are not supported by any part of CLtL that I know of. X is treated as "free", but that situation is not defined by CLtL as far as I know. Btw, I don't see why the term "hairy" needs to be in that example. The issue would be the same for a trivial computation. Your references to EVAL being like "normal processing of the interpreter" and LOAD being like "normal processing of the compiler" are too obscure for me to figure out. Perhaps you mean "normal execution of interpreted code" and "normal execution of compiled code"? If so, I might begin to see what you mean, but since the presence of compiled-only and interpreted-only implementations makes these phrases vague, I'd want to see this clarified. I am also unconvinced that LOAD really corresponds to "normal execution". In my code, it often addresses things that really only want to be done once and never again because at top-level, things can't happen more than once. I'm not at all clear that if I had a DEFFOO macro which expanded into (EVAL-WHEN (LOAD) ...) and someone put the DEFFOO in the body of (DEFUN BAR ...) -- a thing you're apparently advocating -- that I would want the thing in the LOAD clause executing every time they called BAR. Also, you don't offer enough info for me to figure out what happens when both EVAL and LOAD are specified in the interpreter. In general, the absence of examples makes this just hard to follow. -- General Remarks -- I believe that the real problem with EVAL-WHEN is that its keywords do not map straightforwardly onto the things we really need to say. For example, when we really want to do something abstract like "provide macro support at semantic analysis time" we are instead forced to designate times (EVAL COMPILE) because we happen to know that that is when semantic analysis takes place and we must cover our bets. I think there is no fix for EVAL-WHEN other than to identify keywords which are equally meaningful to interpreter-only and compiled-only implementations. I would rename COMPILE to something meaning ``semantic analysis time,'' LOAD to something meaning ``first occurrence in execution environment'' and EVAL to mean something like ``execution time.'' But then I would also want to require interpreted-only implementations to do a semantic-prepass so that ``semantic analysis time'' where all macros were expanded at once and all EVAL-WHEN's figured out at a definite time rather than being permitted to occur lazily. Since I don't really feel convinced about what you're proposing and since I think what I might propose is a ``research'' project too ambitious to get into at this point, I would prefer that EVAL-WHEN continue to be illegal except at toplevel and that we just pin down a status-quo description of what EVAL-WHEN already does, asking Kathy to acknowledge in the manual that we know its design is less than pretty and that the design of a better primitive is a research topic. FAILKMP issue EVAL-WHEN-NON-TOP-LEVEL<450993.880926@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWiYN-% At tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  t  tt@H <A.'x" Hpose: Address: Affiliation: .AI.M=p ((X  0 SH 4 x xT@ t ޅ/`,4 \P8``__ 0 {_0 :CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 22:56:17 EDT Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 19:45:07 PDT Received: by rice-chex.ai.mit.edu; Fri, 23 Sep 88 22:44:51 EDT Date: Fri, 23 Sep 88 22:44:51 EDT From: dick@wheaties.ai.mit.edu (Richard C. Waters) Message-Id: <8809240244.AA03833@rice-chex.ai.mit.edu> To: masinter.pa@xerox.com In-Reply-To: masinter.pa@xerox.com's message of 23 Sep 88 13:47 PDT <880923-134724-1961@Xerox> Subject: Issue: STREAM-INFO (Version 4) Cc: gls@think.com, CL-Cleanup@sail.stanford.edu Re letting the functions return rationals. That is fine with me. I was just trying to think of efficiency in the programs that call these functions. Dick FAILdick Issue: STREAM-INFO (Version 4)<449999.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  uj ujuj uj #uj+uj3uj;ujCuj!Kuj%Suj)[uj-cuj1kuj5suj9{uj= 8uj v ujuj@H+: Cy6{i H;y}p (=*(X 0 1H c (@ h2 U` ,h5mP0788`8`ss@4rO@.CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 17:59:25 EDT Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 14:47:38 PDT Return-Path: Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 23 Sep 88 17:35:56 EDT Received: by joplin.think.com; Fri, 23 Sep 88 17:33:46 EDT Date: Fri, 23 Sep 88 17:33:46 EDT From: gls@Think.COM Message-Id: <8809232133.AA03205@joplin.think.com> To: jonl@lucid.com Cc: Moon@stony-brook.scrc.symbolics.com, GLS@Think.COM, CL-Cleanup@sail.stanford.edu In-Reply-To: Jon L White's message of Thu, 22 Sep 88 19:20:19 PDT <8809230220.AA07675@bhopal> Subject: Issue: DECLARE-TYPE-FREE (Version 1) Date: Thu, 22 Sep 88 19:20:19 PDT From: Jon L White I raised this issue at the Fort Collins meeting last November, suggesting that it was an unintended aberration in CLtL. But Guy Steele quickly defended it, and promised to write down his objection to the "ALLOW" interpretation and mail them out (this was in a plenary session, and was only partially relevant to the item under discussion.) To date, I don't recall seeing his objections, but he should cough them up now or forever hold his peace. Having pondered the matter, I have concluded that the me of September 1988 is considerably less wedged than the me of November 1987 (this follows from the more general theorem that the me of now always judges itself less wedged than me's of other times, past or future), and therefore I will hold my peace. In other words, I see the utility of the proposal, and have no overriding objections that hold water. --Guy FAILgls<449677.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ? ? ? ?"?*?2?:?B!?J%?R)?Z-?b1?j5?r9?z=?  +: ?@HZl 8 ] [rZr H;t!p (i(X 0H (x @ t S`,4  P8``plin..com> jonld.com cl-cp@sainford In-RTo: JCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 17:47:13 EDT Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 14:32:19 PDT Return-Path: Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 23 Sep 88 17:31:27 EDT Received: by joplin.think.com; Fri, 23 Sep 88 17:29:25 EDT Date: Fri, 23 Sep 88 17:29:25 EDT From: gls@Think.COM Message-Id: <8809232129.AA02644@joplin.think.com> To: jonl@lucid.com Cc: cl-cleanup@sail.stanford.edu In-Reply-To: Jon L White's message of Thu, 22 Sep 88 17:24:43 PDT <8809230024.AA07353@bhopal> Subject: Issue: TAGBODY-CONTENTS (version 1) Date: Thu, 22 Sep 88 17:24:43 PDT From: Jon L White I'm happy with the restrictions proposed. For the record, I believe the reason pdp10 MacLisp allowed numbers, including flonums, as tags was that Ira Goldstein's LLOGO (a LOGO system written entirely in Lisp) just used READ for the statement numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc. There may be more to it, but I distinctly remember an event like this in the distant past. That is exactly what I recall. --Guy FAILgls Issue: TAGBODY-CONTENTS (version 1)<449668.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  uz uz uz uz#uz+uz3uz;uz!Cuz%Kuz)Suz-[uz1cuz5kuz9suz={uz  m  3@H}&  FWxr H;lp (p0'=(X 0HPf@ hg ݣ` ,hjP0l8 m`m`AI.AIEDU>97.88AI.AIEDU>76.88AI.AIEDU>55.88AI.AIEDU>X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 14:36:28 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:57:54 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA29038; Fri, 23 Sep 88 11:56:26 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02532; Fri, 23 Sep 88 11:56:23 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231756.AA02532@defun.utah.edu> Date: Fri, 23 Sep 88 11:56:22 MDT Subject: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY To: x3j13@sail.stanford.edu Issue: COMPILE-ENVIRONMENT-CONSISTENCY References: CLtL p. 68-69, 143, 321 RAM's "Compiler Cleanup Proposal #3" Category: CLARIFICATION Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft) V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions) Status: **DRAFT** Problem Description: CLtL does not clearly specify what aspects of the compiletime environment the compiler (or other preprocessor) may "wire in" to code being compiled. Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY: Common Lisp deliberately leaves unspecified the time at which certain transformations, such as macro expansion, are performed within a program. While some implementations perform such transformations concurrently with evaluation, it is also legitimate to perform transformations during a preprocessing phase. For example, an implementation might choose to apply transformations at "function promotion time" (i.e., transformations are applied once during evaluation of a surrounding FUNCTION special form), or to completely transform each top-level form and all of its subforms before performing any evaluation. User programs cannot portably depend upon either the time of such transformations, or the number of times the transformations are applied. In all cases, however, compiling a program (with COMPILE or COMPILE-FILE) provides a mechanism for forcing these transformations to be applied and a guarantee that, once compiled, no further transformations will be applied to that program. In the discussion that follows, the term "compiler" is to be understood to include other preprocessors as well. Likewise, the "compiletime environment" refers to the environment in which program transformations occur, while "runtime" refers to the time the program is executed. (1) The following information *must* be present in the compiletime environment for the preprocessor to apply the correct transformations. This information need not also be present in the runtime environment. (a) Macro definitions must be available in the compiletime environment. The compiler may assume that forms that are lists beginning with a symbol that does not name a macro or special form is a function call. (This implies that SETF methods must also be available at compiletime.) (b) Special variables must be declared as such before they are bound. The compiler must treat any undeclared variable binding as a lexical binding. (2) The compiler *may* "wire in" the following kinds of information into the code it produces, if the information is present in the compiletime environment. However, since implementations are not required to do this, user code must ensure that the information is also defined consistently in the runtime environment. Except as noted, the behavior of user programs is unspecified in situations where the information is defined differently at runtime than at compiletime, since the user cannot depend upon which will take precedence in a particular implementation. In all cases, the absence of the information at compiletime is not an error, but its presence may enable the compiler to do a better job. (a) The compiler may assume that functions that are defined and declared INLINE in the compiletime environment will retain the same definitions at runtime. (b) The compiler may assume that, within a named function, a recursive call to a function of the same name refers to the same function, unless that function has been declared NOTINLINE. (c) COMPILE-FILE may assume that, in the absence of NOTINLINE declarations, a call within the file being compiled to a named function which is defined in that file refers to that function. (This permits "block compilation" of files.) The behavior of the program is unspecified if functions are redefined individually at runtime. (d) The compiler may assume that the signature (or "contract") of all built-in Common Lisp functions will not change. In addition, the compiler may treat all built-in Common Lisp functions as if they had been proclaimed INLINE. (e) The compiler may "wire in" the values of symbolic constants that have been defined with DEFCONSTANT in the compiletime environment. (f) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to retain the same definition in the runtime environment as in the compiletime environment. (Note that it is not an error for an unknown type to appear in a declaration at compiletime, although it is reasonable for the compiler to emit a warning in such a case.) (g) The compiler may assume that a class name defined by DEFCLASS that is present in the compiletime environment will also be a class name at runtime, and that class will be an instance of the same metaclass. There may be additional conformance requirements imposed by the metaclass, but there are none for STANDARD-CLASS. (h) The compiler may assume that if type declarations are present in the compiletime environment, the corresponding variables and functions present in the runtime environment will actually be of those types; otherwise, the behavior of the program is undefined. (3) The compiler *must not* make any additional assumptions about consistency between the compiletime and runtime environments. In particular: (a) The compiler may not assume that functions that are defined in the compiletime environment will retain the either the same definition or the same signature at runtime, except in situations (2a) through (2d) above. It is, however, reasonable for the compiler to emit warning messages about calls to functions that are defined at compiletime, but where the wrong number or type of arguments are supplied. (b) The compiler may not signal an error if it sees a call to a function that is not defined at compiletime, since that function may be provided at runtime. Again, it is permissible to emit a warning in these situations. Rationale: This proposal generally reflects current practice. Current Practice: I know of no compiler that does not implement the provisions of item (1). For item (2), most compilers (including Lucid) optimize self-recursive calls by default. Most compilers also opencode data structure accessors (such as CAR) at some level of optimization, and some code much more complicated built-in functions inline as well. VaxLisp, for example, normally compiles MEMBER inline. The Lucid compiler makes use of type declarations to perform generic-to-specific transformations on many arithmetic and sequence functions, which is also a form of inlining. KCL performs block compilation by default, and Lucid does so under certain conditions. Cost to implementors: Unknown, but probably minor. Cost to users: Since most implementations appear to be largely in conformance with the proposal, users should notice little difference. Benefits: The presence of a definite specification of what may happen when will help users structure their programs so they will compile correctly in all Common Lisp implementations. Discussion: Most of the discussion on this issue has been centered on the terminology describing error situations for item (2). In most cases where there is an inconsistency between compile-time and run-time, the results will be unpredictable but harmless. The major exception is violation of type declarations, which is a "crash-and-burn" error in many implementations. There has also been some concern raised that item (3) would prohibit such things as a cross-compiler that produces standalone programs in an environment that disallows redefinition of functions. The intent of this proposal is not to prohibit a compiler from having a magic switch that imposes additional restrictions on the programs it compiles, but such a compiler would not be a compiler for Common Lisp. ------- FAILNET-ORIGIN<449521.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  33  333$3,343<"3D&3L*3T.3\23d63l:3t>3|  3+6 s33@Hf < nm}fa H;[p (p0(X0 _H(@ t ݡ` ,4 eP8 ``h+ ({_0} X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 14:36:11 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:04 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA28914; Fri, 23 Sep 88 11:52:40 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02497; Fri, 23 Sep 88 11:52:36 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231752.AA02497@defun.utah.edu> Date: Fri, 23 Sep 88 11:52:35 MDT Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS To: x3j13@sail.stanford.edu Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS References: CLtL pages 66-70, 143 Category: CLARIFICATION Edit history: V1, 07 Oct 1987 Sandra Loosemore V2, 15 Oct 1987 Sandra Loosemore V3, 15 Jan 1988 Sandra Loosemore V4, 06 May 1988 Sandra Loosemore V5, 20 May 1988 Sandra Loosemore V6, 09 Jun 1988 Sandra Loosemore Problem Description: Standard programming practices assume that, when calls to defining macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE, certain side-effects occur that affect how subsequent forms in the file are compiled. However, these side-effects are not mentioned in CLtL, except for a passing mention that macro definitions must be ``seen'' by the compiler before it can compile calls to those macros correctly. In order to write portable programs, users must know exactly which defining macros have compile-time side-effects and what those side-effects are. Inter-file compilation dependencies are distinct from, and not addressed by, this issue. Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY (1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing within a file being processed by COMPILE-FILE, normally have compile-time side effects which affect how subsequent forms in the same file are compiled. A convenient model for explaining how these side effects happen is that the defining macro expands into one or more EVAL-WHEN forms, and that the calls which cause the compile-time side effects to happen appear in the body of an (EVAL-WHEN (COMPILE) ...) form. This is also the recommended implementation technique. (2) The affected defining macros and their specific side effects are as follows: DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time. If the expansion of a DEFTYPE'd type specifier is also a valid type specifier at compile time, then the DEFTYPE'd type specifier is also considered to be fully defined at compile time and must be recognized within subsequent type declarations. DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile time, so that occurences of the macro later on in the file will be expanded correctly. The body of the macro (but not necesarily its expansion) must be evaluable at compile time. DEFUN: An implementation may choose to store information about the function for the purposes of compile-time error-checking (such as checking the number of arguments on calls), or to enable the function to be expanded inline. Portable code should not rely on DEFUN making the function definition available at compile time. DEFVAR, DEFPARAMETER: The compiler must recognize that the variables named by these forms have been proclaimed special. The initial value form must not be evaluated at compile time. DEFCONSTANT: The compiler must recognize the symbol as being constant (for example, to suppress warnings about references to the symbolic constant as an unbound variable or to enable warnings about binding or SETQ'ing the constant in the code being compiled). Neither evaluation of the value-form or SETQ'ing of the symbol may occur at compile-time. However, if the (unevaluated) value-form is CONSTANTP, the compiler is allowed to build assumptions about the value of the constant into programs being compiled, as described on p. 68-69 of CLtL. DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the expansion of calls to SETF later on in the file. The body of DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable at compile time, although the expansions need not be. DEFSTRUCT: The structure type name must be recognized as a valid type name in declarations, as for DEFTYPE. The structure slot accessors must be made known to SETF. In addition, further DEFSTRUCT definitions should be able to :INCLUDE a structure type defined earlier in the file being compiled. The functions which DEFSTRUCT generates, and the #S reader syntax, may or may not be available at compile time. (3) The compile-time side effects may cause information about the definition to be stored differently than if the defining macro had been processed in the "normal" way (either interpretively or by loading the compiled file). In particular, the information stored by the defining macros at compile time may or may not be available to the interpreter (either during or after compilation), or during subsequent calls to COMPILE or COMPILE-FILE. For example, the following code is nonportable because it assumes that the compiler stores the macro definition of FOO where it is available to the interpreter: (defmacro foo (x) `(car ,x)) (eval-when (eval compile load) (print (foo '(a b c)))) A portable way to do the same thing would be to include the macro definition inside the EVAL-WHEN: (eval-when (eval compile load) (defmacro foo (x) `(car ,x)) (print (foo '(a b c)))) Rationale: The proposal reflects standard programming practices. The primary purpose of the proposal is to make an explicit statement that CL supports the behavior that most programmers expect and many implementations already provide. Current Practice: Many (probably most) Common Lisp implementations, including VaxLisp and Lucid Lisp, are already largely in conformance. In VaxLisp, macro definitions that occur as a side effect of compiling a DEFMACRO form are available to the compiler (even on subsequent calls to COMPILE or COMPILE-FILE), but are not available to the interpreter (even within the file being compiled). Kyoto Common Lisp is a notable offender. By default, KCL evaluates *all* top level forms as they are compiled, which is clearly in violation of the behavior specified on p 69-70 of CLtL. There is a flag to disable the compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do not make their definitions available at compile-time either. Cost to implementors: Making the defining macros expand into EVAL-WHENs to store the required information is a simple and recommended implementation technique. The intent of the proposal is specifically not to require the compiler to have special knowledge about each of these macros. Cost to users: Since CLtL does not specify whether and what compile-time side-effects happen, any user code which relies on them is, strictly speaking, nonportable. In practice, however, most programmers already expect the behavior described in this proposal and will not find it to be an incompatible change. Benefits: Adoption of the proposal will provide more definite guidelines on how to write programs that will compile correctly under all CL implementations. Discussion: Reaction to an earlier version of this proposal on the CL mailing list was overwhelmingly positive. It has been suggested that this proposal should also include PROCLAIM. However, since PROCLAIM is not a macro, its compile-time side effects cannot be handled using the EVAL-WHEN mechanism. A separate proposal seems more appropriate. There has also been a suggestion that DEFCONSTANT should always evaluate the value provided. The behavior specified in this proposal makes DEFCONSTANT similar to DEFVAR and DEFPARAMETER, while allowing the user to explicitly ask for compile-time evaluation using the #. read macro. Item (3) allows for significant deviations between implementations. While there is some sentiment to the effect that the compiler should store definitions in a manner identical to that of the interpreter, other people believe strongly that compiler side-effects should be completely invisible to the interpreter. The author is of the opinion that since this is a controversial issue, further attempts to restrict this behavior should be considered as separate proposals. ------- FAILNET-ORIGIN<449520.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  33  333$3,343<"3D&3L*3T.3\23d63l:3t>3|  %3  s33@Hk  & $z[ H;Lp (p0'=(XH0  H(@ t ݡ` ,4 P#8 %`%`h+ ({_0} X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 14:35:56 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:13 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA28959; Fri, 23 Sep 88 11:53:47 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02507; Fri, 23 Sep 88 11:53:43 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231753.AA02507@defun.utah.edu> Date: Fri, 23 Sep 88 11:53:41 MDT Subject: issue DEFINING-MACROS-NON-TOP-LEVEL To: x3j13@sail.stanford.edu Issue: DEFINING-MACROS-NON-TOP-LEVEL References: CLtL p. 66-70, 143 Issue EVAL-WHEN-NON-TOP-LEVEL Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS Category: CLARIFICATION, ENHANCEMENT Edit History: 6-May-88, V1 by Sandra Loosemore 9-Jun-88, V2 by Sandra Loosemore 12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4) 21-Sep-88, V4 by Sandra Loosemore (clarify section 5) Problem Description: CLtL leaves the interpretation of defining forms such as DEFMACRO and DEFVAR that appear in other than top-level locations unspecified. Resolution of other issues (EVAL-WHEN-NON-TOP-LEVEL and COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS) now allows reasonable semantics to be assigned to defining forms which appear at non-top-level. Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW (1) Clarify that while defining macros normally appear at top level, it is meaningful to place them in non-top-level contexts and that the compiler must handle them properly in all situations. Remove the language on p. 66 of CLtL which states that the compiler is not required to recognize defining macros at other than top-level. (2) The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY defines a model for specifying how defining macros work. To summarize, the expansion of the macro (rather than its expander function) is responsible for storing information about the definition. Compile-time side effects are typically handled by including one or more EVAL-WHEN forms in the expansion. A compiler may choose some other implementation, such as treating defining macros as implementation-specific special forms, provided that the semantics are compatible. (3) Defining macros which define functional objects (such as DEFUN and DEFMACRO) must ensure that the functions are defined in the lexical environment in which the defining macro appears. In the model referred to above, this would normally be implemented by producing a FUNCTION special form in the macro expansion. For example, the following code causes the function BAR to be closed over the variable X: (let ((x (some-hairy-computation))) (defun bar (y) (+ x y))) (4) The language on p. 145 of CLtL, which states that macro functions are always defined in the null lexical environment, should be removed. Instead, the defining forms DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of DEFSETF, which make functional definitions available at compile time, use the environment which is apparent at the time of evaluation. When calls to these macros appear in a non-null lexical environment, an explicit (EVAL-WHEN (COMPILE) ...) must normally be wrapped around the entire containing top-level form to ensure that the correct lexical environment is seen at both compile time and load time. An example may help clarify why this is necessary. The code fragment (let ((x (some-hairy-computation))) (defmacro bar-macro (y) `(+ ,x ,y))) would macroexpand into something similar to (let ((x (some-hairy-computation))) (eval-when (eval compile load) (setf (macro-function 'bar-macro) #'(lambda (form env) (let ((y (second form))) `(+ ,x ,y)))) 'bar-macro)) Since the rules for (EVAL-WHEN (COMPILE) ...) state that evaluation takes place in the null lexical environment, in this situation X would be treated as a special variable within the macro function. However, in the EVAL or LOAD situations, the lexical value of X would be used. To ensure consistency, the correct definition would be: (eval-when (eval compile load) (let ((x (some-hairy-computation))) (defmacro bar (y) `(+ ,x ,y)))) (5) Clarify that ``top-level forms'' are evaluable data objects read in from an input source (such as a keyboard or disk file) by successive calls to the function READ; these forms would be evaluated by the interpreter in a null lexical environment. As special cases, forms within a top-level PROGN or COMPILER-LET are also considered to be top-level forms, as is the expansion of a macro call appearing at top-level. Specify that top-level forms in a file being compiled are guaranteed to be processed sequentially, but the order in which subforms of a top-level form are processed by the compiler is explicitly left unspecified. It is an error for user code to depend upon the compile-time side-effects of a defining macro within the same top-level form in which the defining macro appears. Rationale: The notion of a ``top-level form'' is rather confused, since the term is used in CLtL to refer both to a place where a form may appear (what this proposal continues to call ``top-level''), and to instances of forms which traditionally appear there (what this proposal calls ``defining macros''). There has been a suggestion that the notion of a top-level form should be extended to include forms in the body of a top-level LET, to allow forms such as DEFUN to be meaningful there. However, we feel that a cleaner solution is to remove the restrictions on the placement of defining macros altogether. Current Practice: CLtL mentions only that forms within a top-level PROGN, and not COMPILER-LET, are treated as top-level. However, COMPILER-LET is also treated specially in implementations derived from the MIT Lisp Machine (TI and Symbolics), as well as Lucid and Coral (but not VaxLisp). Cost to implementors: Cost to users: None. This is a compatible extension. Benefits: The notion of defining macros as being somehow special is removed from the language. Allowing defining macros to appear anywhere instead of restricting them to certain positions results in a cleaner language design. Discussion: ------- FAILNET-ORIGIN<449517.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Ak Ak Ak Ak#Ak+Ak3Ak;Ak!CAk%KAk)SAk-[Ak1cAk5kAk9sAk={Ak  +< @H0 * !P k H;*p (p0'=(XxP0 `H(@ t ݞ` ,4 fP8 ``99(@7 6(mtoՃuX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 14:35:23 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:58:36 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA29064; Fri, 23 Sep 88 11:57:04 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02537; Fri, 23 Sep 88 11:57:00 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231757.AA02537@defun.utah.edu> Date: Fri, 23 Sep 88 11:56:59 MDT Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE To: x3j13@sail.stanford.edu Issue: PROCLAIM-ETC-IN-COMPILE-FILE References: CLtL p. 182 [package functions], p. 156 [PROCLAIM], P. 188 [REQUIRE], p. 439 [COMPILE-FILE]; Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS Category: CLARIFICATION Edit History: 15 Sept. 88, V1 by David Gray 23 Sep 88, V2 by Sandra Loosemore (summarize discussion) Status: **DRAFT** Problem Description: Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls to the following package functions as though they were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...): EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE There are other things that need special handling by the compiler that are not explicitly specified by CLtL. The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY addresses the part of the problem pertaining to macros that define things. The following proposal adds PROCLAIM and REQUIRE to the list of functions needing special handling. Proposal PROCLAIM-ETC-IN-COMPILE-FILE:CLARIFY: Clarify that when COMPILE-FILE encounters a call to one of the following functions at top level in a file, the form will be evaluated at compile time as well as at load time: EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE PROCLAIM REQUIRE SHADOW SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE Note that the compile-time evaluation of these package functions can affect the way that the remaining top-level forms in the file are read. In the case of PROCLAIM, it is implementation-dependent whether the evaluation affects the global environment or is only recorded in data structures used by the compiler, and whether the effect of the evaluation remains in the global environment after COMPILE-FILE returns. (PROCLAIM '(OPTIMIZE ...)) is a special case that is evaluated only at compile-time and not at load time, and that affects only the current file being compiled. Note that the behavior specified here can still be altered by the user by wrapping an explicit EVAL-WHEN around the form. Rationale: Experience seems to have shown that this behavior best matches what people expect to have happen. The examples on pages 189 and 191 of CLtL won't work right unless REQUIRE takes effect at compile-time. Since most of the things that PROCLAIM can be used for only affect the compiler, it doesn't make much sense for the compiler to not take notice during compilation. Optimization control is something that one usually wants to control locally, rather that having a proclamation in one file affect other unrelated files compiled later. Current Practice: This proposal follows what the Explorer does, except that (EVAL-WHEN (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything. The Symbolics compiler has special top-level handling for all of these functions, although the details are not clear. The Lucid documentation indicates that certain functions at top-level are treated as though within an (EVAL-WHEN (EVAL COMPILE LOAD) ...): REQUIRE, all of the package functions listed above, INTERN, and UNINTERN; it is not clear what happens with PROCLAIM. Cost to implementors: Since implementations are already required to have a mechanism for compile-time handling of the package functions, it should only require minor adjustments to add handling for PROVIDE and REQUIRE if they aren't handled already. The main thing that most implementations would need to do is to make OPTIMIZE proclamations local to the file, but that should be fairly simple. Cost to users: If someone has a use of REQUIRE that they want to only be a load-time dependency and their implementation did not previously do REQUIRE at compile-time, they may want to wrap (EVAL-WHEN (EVAL LOAD) ...) around it. If someone has a use of (PROCLAIM '(OPTIMIZE ...)) that they really want to be global, they would need to wrap (EVAL-WHEN (EVAL COMPILE LOAD) ...) around it. Benefits: Users will know what to expect when they use PROCLAIM and REQUIRE. Costs of Non-Adoption: In order to write programs that would be sure to be portable, the user would have to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around each use of PROCLAIM or REQUIRE in order to be sure of what will happen. Aesthetics: Programs look cleaner if EVAL-WHEN is only needed for unusual cases instead of being required for the normal cases. Discussion: Cleanup proposal PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE wanted to add an option to PROCLAIM to control whether the effect is local to the current file. That may be better handled by an extension to EVAL-WHEN since that kind of control might be wanted for definitions as well as proclamations. If the handling of OPTIMIZE specified here is taken as a default, that issue can be pursued separately from this one. There have been objections raised to treating (PROCLAIM '(OPTIMIZE...)) specially. If DEFPACKAGE is accepted, we may wish to remove the "magical" behavior of the package functions entirely, and propose a macro (DEFPROCLAIM?) to deal with PROCLAIM. How do people feel about making this kind of incompatible change to the language? ------- FAILNET-ORIGIN<449514.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Ak Ak Ak Ak#Ak+Ak3Ak;Ak!CAk%KAk)SAk-[Ak1cAk5kAk9sAk={Ak   @HS 2 /5 H;|p (p0'=(X0 TH(@ t ݜ` ,4 ZP8 ``99(@7 6(mtoՃuX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 14:34:38 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:38 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA28938; Fri, 23 Sep 88 11:53:11 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02502; Fri, 23 Sep 88 11:53:08 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231753.AA02502@defun.utah.edu> Date: Fri, 23 Sep 88 11:53:07 MDT Subject: issue EVAL-WHEN-NON-TOP-LEVEL To: x3j13@sail.stanford.edu Issue: EVAL-WHEN-NON-TOP-LEVEL References: CLtL p. 69-70 Issue DEFINING-MACROS-NON-TOP-LEVEL Category: CLARIFICATION, ENHANCEMENT Edit History: 6-May-88, V1 by Sandra Loosemore Problem Description: The current description of how the compiler should handle EVAL-WHEN only makes sense when it appears as a top-level form in the file being compiled. Other proposals being considered by the compiler cleanup committee require that we clarify how the compiler should process EVAL-WHENs appearing at non-top-level, such as within LET or FUNCTION special forms. Proposal: EVAL-WHEN-NON-TOP-LEVEL:CLARIFY In this proposal, we view EVAL-WHEN as a macro which expands into a PROGN containing the body of the EVAL-WHEN when the context in which it is expanded matches one of the situations listed, or NIL otherwise. However, it is explicitly *not* proposed that EVAL-WHEN's status as a special form be changed. The EVAL situation corresponds to the normal processing of the interpreter. If EVAL is specified, the interpreter evaluates each form in the body of the EVAL-WHEN as an implicit PROGN, using the current lexical environment. If the EVAL situation is not specified, then the interpreter must return NIL as the value of the EVAL-WHEN form, without evaluating the body. The LOAD situation corresponds to the normal processing of the compiler. If LOAD is specified, the compiler treats the EVAL-WHEN as a PROGN and compiles the body in the normal way in the appropriate lexical environment. Otherwise, the form is equivalent to specifying a constant value of NIL. (The name LOAD is something of a misnomer, because ``evaluation'' of the body happens not at LOAD time, but when the EVAL-WHEN form would normally be ``evaluated''. For example, if an EVAL-WHEN form appears in the body of a DEFUN, it is ``evaluated'' when that function is called.) The COMPILE situation is a special case; it indicates that the compiler itself should evaluate the body of the EVAL-WHEN form as an implicit PROGN in the null lexical environment. During the evaluation, if a nested EVAL-WHEN appears in the body, the interpreter follows its usual rule of checking only whether or not the EVAL situation is specified to decide whether or not the body of the nested EVAL-WHEN should be processed. If both the COMPILE and LOAD situations are specified, the compiler first performs the evaluation for the COMPILE situation. Then, the normal processing for the LOAD situation takes place, except that the compile-time evaluation of nested (EVAL-WHEN (COMPILE) ...) forms in the body is suppressed, preventing repeated evaluations of subforms. (EVAL-WHEN (COMPILE) ...) should be used with caution in non-top-level situations. For example, if the following appears as a top level form in a file being compiled (let ((x (some-hairy-computation))) (eval-when (eval compile load) (print x))) the variable X will be treated as special during the compile-time evaluation, and the value printed will be its symbol-value. To guarantee consistency between compile-time evaluation and the normal processing, one should wrap the entire top-level form in an EVAL-WHEN, as follows: (eval-when (eval-compile load) (let ((x (some-hairy-computation))) (print x))) Rationale: The behavior of top-level EVAL-WHENs as specified in this proposal remains almost identical to that specified in CLtL. The major addition is specifying the lexical environment in which non-top-level EVAL-WHENs are processed. It is clear that the COMPILE situation must always be processed in the null lexical environment, since the actual lexical environment is not available at compile time. Having the EVAL and LOAD situations evaluate in the proper environment leads to differing semantics, but it appears to be the behavior that most people expect, and it is also the easiest to implement. Suppression of COMPILE evaluations in nested EVAL-WHENs is necessary to achieve certain desirable behaviors, such as the macro example in section 4 of the DEFINING-MACROS-NON-TOP-LEVEL proposal. Although viewing EVAL-WHEN as a macro is useful for purposes of explanation, user code is likely to want to continue to treat EVAL-WHEN as a special form. For example, a preprocessor that performs a code walk should leave EVAL-WHENs intact, since the context in which the preprocessor runs may not be the same as the context in which the code it produces runs. Current Practice: Cost to implementors: Probably fairly minor in most implementations. As an implementation technique, we suggest implementing EVAL-WHEN as a macro which uses a state variable to keep track of the current context. A sample implementation might look something like: (defvar *compiling-p* nil "Are we compiling or interpreting?") (defmacro eval-when (situations &body body) (cond ;; If the COMPILE situation applies, evaluate the body now ;; and also see if we need to do the LOAD situation too. ;; If so, shadow the definition of EVAL-WHEN to make it ;; ignore nested compile-time evaluation requests, and ;; return the body. ((and *compiling-p* (member 'compile situations)) (eval `(progn ,@body)) (if (member 'load situations) `(macrolet ((eval-when (situations &body body) (if (member 'load situations) `(progn ,@body) 'nil))) ,@body) 'nil)) ;; If either the EVAL or LOAD situation applies, return a PROGN. ((if *compiling-p* (member 'load situations) (member 'eval situations)) `(progn ,@body)) ;; Otherwise no situation applies, so just return NIL. (t 'nil))) ;;; Eval must bind *compiling-p* to NIL. (defun eval (form) (let ((*compiling-p* nil)) : )) ;;; Compile and Compile-file must bind *compiling-p* to a non-nil value. (defun compile (name &optional definition) (let ((*compiling-p* t)) : )) (defun compile-file (input-pathname &key output-file) (let ((*compiling-p* t)) : )) Cost to users: Since CLtL does not currently specify what the meaning of EVAL-WHEN forms at non-top-level is, existing code which depends on their use is already nonportable. Preventing repeated evaluations of subforms when EVAL-WHENs are nested is unlikely to cause any serious compatibility problems, since the current model would already result in only a single evaluation in the case when the code is processed interpretively. There are also some situations concerning nested top-level occurences of EVAL-WHEN that CLtL does not completely specify, to which this proposal does assign a specific interpretation. For example, CLtL is unclear on whether or not (FOO) would ever be called, while in the current proposal it would definitely not be called: (eval-when (compile) (eval-when (compile) (foo))) Benefits: Clarifying the meaning of EVAL-WHEN allows the behavior of defining macros such as DEFMACRO to be specified in terms of EVAL-WHEN. As a side effect, it would then become meaningful for defining macros to appear at other than top-level. Discussion: This proposal reflects what appears to be the consensus of the compiler cleanup committee on this issue. ------- FAILNET-ORIGIN<449509.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Ak Ak Ak Ak#Ak+Ak3Ak;Ak!CAk%KAk)SAk-[Ak1cAk5kAk9sAk={Ak   @HY 2 2 H;dp (p0(XV(0 \H(@ t ݜ` ,4 bP8 ``99(@7 6(mtoՃuX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 14:34:14 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:37 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA28972; Fri, 23 Sep 88 11:54:12 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02512; Fri, 23 Sep 88 11:54:08 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231754.AA02512@defun.utah.edu> Date: Fri, 23 Sep 88 11:54:07 MDT Subject: issue COMPILE-ARGUMENT-PROBLEMS To: x3j13@sail.stanford.edu Issue: COMPILE-ARGUMENT-PROBLEMS References: CLtL p. 438-439 Issue FUNCTION-TYPE Issue DEFINING-MACROS-NON-TOP-LEVEL Category: CLARIFICATION, CHANGE Edit History: V1, Sandra Loosemore (8 Aug 1988) V2, Sandra Loosemore (21 Sep 1988) Problem Description: The description of what arguments can legitimately be passed to the function COMPILE in CLtL is too vague. There are two specific problems: (1) Acceptance of the FUNCTION-TYPE proposal makes it nonsensical to speak of a lambda-expression being an interpreted function (it is not) or to require a symbol to have a lambda-expression as its definition (the SYMBOL-FUNCTION must be a true FUNCTION object). (2) Many implementations cannot correctly compile functions that are defined interpretively in a non-null lexical environment, because the compiler and interpreter use different representations for closures. Although this problem arose in conjunction with the DEFINING-MACROS-NON-TOP-LEVEL proposal, the situation can also arise if SETF is used to store a lexical closure in the SYMBOL-FUNCTION of the symbol. Proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY: If the optional "definition" argument to COMPILE is supplied, it may be either a lambda expression (which is coerced to a function) or a function to be compiled. Otherwise, the SYMBOL-FUNCTION of the symbol is extracted and compiled. It is an error if the function to be compiled was defined interpretively in a non-null lexical environment, or if it is already compiled. Rationale: Saying "it is an error" to try to compile the wrong kind of function allows implementations that can compile functions defined in a non-null lexical environment to go ahead and do so. Current Practice: Implementations that do not allow sharing of lexical environments between compiled and interpreted functions include VaxLisp, Allegro CL, and Lucid. Lucid and VaxLisp already accept an interpreted function object as the "definition" argument to COMPILE. Cost to implementors: Most of the changes required for this proposal are already necessary to correctly implement the FUNCTION-TYPE proposal. The primary addition is that COMPILE must be extended to accept a FUNCTION object as well as a lambda expression as the "definition" argument. Cost to users: None. This is an upward-compatible change, since a lambda expression can still be passed as an argument to COMPILE. Also, since most existing implementations refuse to compile a function with a non-empty lexical environment, user code which depends on being able to do this is already nonportable. Benefits: An area of ambiguity in the language is resolved. Discussion: An alternative behavior when trying to COMPILE as function that is already compiled would be to do nothing. ------- FAILNET-ORIGIN<449506.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Ak Ak Ak Ak#Ak+Ak3Ak;Ak!CAk%KAk)SAk-[Ak1cAk5kAk9sAk={Ak  O  @H/  oc|\ H;cp (p0|(Xy(0HPH@ hI ݕY` ,hLP0N8 O`O`($(((X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 14:21:23 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:56:00 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA28982; Fri, 23 Sep 88 11:54:35 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02517; Fri, 23 Sep 88 11:54:31 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231754.AA02517@defun.utah.edu> Date: Fri, 23 Sep 88 11:54:30 MDT Subject: issue COMPILE-FILE-PACKAGE To: x3j13@sail.stanford.edu Issue: COMPILE-FILE-PACKAGE References: CLtL p. 182, 183 Category: CHANGE, CLARIFICATION Edit History: 1 Sep 1988, Sandra Loosemore (initial version) 21 Sep 1988, Sandra Loosemore (minor tweak to current practice) Problem Description: The variable *PACKAGE* is rebound by the function LOAD, so that its old value will be restored in spite of any calls to IN-PACKAGE appearing in the file being loaded. Since COMPILE-FILE must evaluate any top-level calls to IN-PACKAGE that it sees, it may also alter the value of *PACKAGE*. It is inconsistent to have COMPILE-FILE and LOAD behave differently regarding the rebinding of this variable. Proposal COMPILE-FILE-PACKAGE:REBIND: Require COMPILE-FILE to rebind *PACKAGE* before processing the file. Rationale: This makes COMPILE-FILE and LOAD more consistent. It is a more compatible solution than either requiring LOAD not to rebind *PACKAGE*, or removing the specialness of IN-PACKAGE and the other package functions. Current Practice: Lucid Common Lisp, the TI Explorer, and VaxLisp already implement this proposal. Cost to implementors: Trivial. Cost to users: I find it hard to believe that users would consider COMPILE-FILE altering the value of *PACKAGE* as a useful side effect. Benefits: The language is made more uniform. Discussion: ------- FAILNET-ORIGIN<449477.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWiYN-% At tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  t  tt@H"? <A0@/"Kx| Hpose: Address: Affiliation: .AI.M:^Ip (a(X 0 eH  4 x x f@ t  ^`,4  nP 8 ` ` q q (0H JCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 12:27:53 EDT Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 09:13:34 PDT Received: by rice-chex.ai.mit.edu; Fri, 23 Sep 88 12:12:45 EDT Date: Fri, 23 Sep 88 12:12:45 EDT From: dick@wheaties.ai.mit.edu (Richard C. Waters) Message-Id: <8809231612.AA00588@rice-chex.ai.mit.edu> To: masinter.pa@xerox.com Cc: gls@think.com, CL-Cleanup@sail.stanford.edu In-Reply-To: masinter.pa@xerox.com's message of 20 Sep 88 11:35 PDT <880920-113534-4339@Xerox> Subject: Issue: STREAM-INFO (Version 4) ---------- Issue: STREAM-INFO References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383) Category: ADDITION Edit history: 22-Jun-88, Version 1 by Pitman (2d model) 23-Jun-88, Version 2 by Waters (1d model, modified 2d model) 24-Jun-88, Version 3 by Pitman (minor reformatting) 24-Jun-88, Version 4 by Pitman (remove 2d model for submission) 23-Sep-88, Version 5 by Waters (cleaned up in response to discussion) Status: For Internal Discussion Problem Description: Currently, there is no portable way to inquire about the line width of an output stream, the current position on a line, or the amount of space that the display of a string will take up. This makes it essentially impossible to write a portable implementation of a pretty printer. Proposal (STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS): Introduce four new functions. These functions are carefully designed with an eye to the way they interact. As a result, they can only be defined fully in terms of each other. The presentation below first gives a very brief definition of each function and then gives detailed specifications of their relationships. LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function] Returns a non-negative integer representing the line width available when printing to OUTPUT-STREAM. If the stream has no meaningful width (or the width cannot be computed) then NIL is returned. LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function] Returns a non-negative integer representing the current horizontal position on the current output line, or NIL if the position cannot be computed. WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function] Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must be a non-negative integer. WRITE-SPACE returns T if the operation is successful and NIL otherwise (e.g., if the operation is not supported by OUTPUT-STREAM). PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) &key (START 0) (END NIL) [Function] Returns an integer representing the horizontal width that would be required to display STRING if it were written at the current moment to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start START :end END), or NIL if this width cannot be computed. The width may be negative (e.g., if STRING contains backspace or newline characters.) PRINTED-WIDTH does not return any indication of the vertical distance required when printing STRING. The START and END parameters delimit a substring of STRING in the usual manner. PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM. The width returned may well depend on the current state of OUTPUT-STREAM (e.g., the width of tabs depends on the line position and the width of characters depends on the font in use.) In all respects the width is computed based on the current state of the stream. However, the width returned always assumes that the total line width is infinite---i.e., does not reflect any wraparound or truncation which might occur. -The difficulties of a full specification: The functions above are intended to solve a specific current problem in CL. To serve this purpose, they must have reasonably precise specifications. However, there are several things which make it desirable to have specifications which allow for significant variability between implementations. First, current implementations of CL differ greatly in the way IO is supported, and overly strict specifications might make things very difficult for certain implementations. Second, CL places no limits on the kinds of idiosyncratic characters which can be supported by particular implementations. Third, while many CL implementations only support the printing of characters in fixed width fonts, it is desirable to allow for output streams that support variable width fonts. Finally, it is desirable to leave room to move for the future. -Operations on standard characters where the line-width has not yet been exceeded. To deal with the problems above, a layered specification is provided. The lowest level specification is given in terms of constraints between the four functions above. In this lowest level specification, two key simplifying assumptions are made. First, it is assumed that at the time the constraint applies, none of the previous operations on the stream S in question have caused output to go beyond the physical horizontal limits of the output device on the output lines relevant to the constraints. I.e., it is assumed that truncation and or wraparound of the output has not occurred on these lines. Second, it is assumed that all of the characters output to the stream on the output lines relevant to the constraints are standard characters as defined in CLTL pp 20-21. The non-standard character #\newline may have been used to end one line and start the next. (Note that standard characters are all simple characters such as A-Z. Particularly, #\tab, #\backspace, #\newline, are NOT standard characters.) It is further assumed that the strings (X and Y) referred to in the constraints consist solely of standard characters. Basic properties of LINE-POSITION: 1- For all S, (not (minusp (line-position S)). 2- For all S, (zerop (line-position (progn (terpri S) S))). 3- For all S, If something is at line position N on one line and something else is at line position N on another line, then the two things are lined up vertically one under the other. Defining property of WRITE-SPACE 4- For all N,S, let M = (+ (line-position S) N) if M <= (line-width S), then (= (line-position (progn (write-space N S) S)) M) Defining property of PRINTED-WIDTH 5- For all X,S, let M = (+ (line-position S) (printed-width X)) if 0 <= M <= (line-width S), then (= (line-position (progn (write-string X S) S)) M) Basic property of LINE-WIDTH 6- For all N,S, let P = (line-position S) If (+ P N) <= (line-width S) then (write-space N S) is guaranteed to output space on the end of the current line without any truncation of wraparound occurring. 7- For all X,S, let P = (line-position S) If 0 <= (+ P (printed-width X)) <= (line-width S) then (write-string X S) is guaranteed to output X on the end of the current line without any truncation of wraparound occurring. Additional properties of PRINTED-WIDTH 8- For all X,Y (= (printed-width (concatenate 'string X Y) S) (+ (printed-width X S) (printed-width Y S))) 9- For all X,Z (= (printed-width X S) (+ (printed-width X (write-string Z S)))) -Support for varying width fonts. A key motivation behind the functions above is dealing with arbitrary kinds of output devices and output streams that support variable width fonts. To provide for this, the properties above place no absolute constraints on the units used for the width values. In fact, the units can vary from stream to stream. The only thing that is required is that for a given stream, the units must be a constant throughout the life of the stream, and the four functions above must all operate in terms of the same units. The units should be chosen to be small enough to represent the minimum possible difference in the length of two strings and large enough that it is possible to perform (write-space 1). (I.e., a single pixel is a logical choice.) If an output stream only supports a single fixed width font, then the logical width unit to choose is the width of a single character. Given this choice, the following is a minimal implementation of the four functions that meets the requirements above. LINE-WIDTH returns the maximum number of characters which can be printed on a single line. LINE-POSITION returns the number of characters output since the last #\newline (or since the creation of the stream if no #\newlines have been output). (WRITE-SPACE N S) outputs N #\space characters. Finally, (PRINTED-LENGTH X S) = (length X). -Support for non-standard characters and situations where line width has been exceeded. In the main, the properties above can be supported even if the line width has been exceeded and even when non-standard charactres are involved. However, characters such as #\tab and #\newline can make it impossible to support properties 7 and 8. In addition, when the line width is exceeded, property 3 may not hold. It is hoped that implementors will make a good faith effort to support the functions in the full range of situations which can be encountered in their CL implementations. However, the simple implementation suggested above will probably provide at least 80% of the benefits intended. As a result, it is important that people not allow the potential difficulties of a full implementation deter them from making a minimal implementation. -Support for derivative streams. Intentionally, very little is said about what the width units should be or exactly what LINE-WIDTH should return. The only key criterion is that LINE-WIDTH should return a result that is pessimistic enough to ensure proper printing. However, it is useful to make some comments about these matters with regard to certain types of derivative streams. If a synonym stream, two way stream, or echo stream is created, it should have the same line-width and width unit as the base output stream. A string output stream should have a line-width of NIL and probably should be treated as supporting a fixed width font and having an output width unit so that each character has a printed-width of 1. If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION, and PRINTED-WIDTH should be be supported by reflecting them through to the FIRST base stream. (There is no guarantee that anything reasonable can be done with the streams as a set. For example, one might support a varying length font while the others don't.) An attempt should be made to send WRITE-SPACE requests to all of the base streams. However, they may not come out right on other than the first base stream. Test Case: Suppose that S is an output stream that supports a single fixed width font which can display 72 characters on a line and that the associated width unit is the width of one character. Evaluating the following will produce the results shown. (line-width S) => 72 (terpri S) => nil (output-position S) => 0 (printed-width "testing: " S) => 9 (write-string "testing: " S) => "testing: " (line-position S) => 9 (write-string "foo" S) => "foo" (terpri S) => nil (write-space 9 S) => T (write-string "bar" S) => "bar" The output produced is testing: foo bar Rationale: Pretty printing requires the function LINE-WIDTH to know how wide the output it produces can be. Pretty printing requires LINE-POSITION to determine where on the line output is when pretty printing starts. Pretty printing requires PRINTED-WIDTH to determine how much space things will take in the output. (If a variable width font is being used, this cannot be determined without a detailed knowledge of the font being used.) (Properties 7 & 8 greatly reduce the number of times PRINTED-WIDTH has to be called.) Pretty printing requires WRITE-SPACE to get proper indentations. (If a variable width font is being used, indentations may be required that cannot be obtained by outputting spaces.) Current Practice: Essentially every implementation of Common Lisp must support the minimal functionality above internally in order to support PPRINT and the FORMAT directives ~T and ~<...~>. However, there is no documented interface to this functionality in CLTL. As a result, while some implementations of Common Lisp make this functionality available to users, some do not. Further, the implementations that do provide this functionality do so in a variety of incompatible ways. Cost to Implementors: This proposal is written in such a way as to allow implementations which do not have the ability to compute difficult values to just return NIL. Very little work is forced. The idea is to offer implementors a common way to provide this useful information to portable programs where possible. Cost to Users: None. This change is upward compatible. Cost of Non-Adoption: Complex output programs such as pretty printers cannot be written portably. Benefits: A wide range of programs can gain better control of the format of output. Aesthetics: No significant aesthetic impact other than a slight increase in the number of functions defined. Discussion: Dick Waters submitted a request for changes along the line of the horizontal aspects of these functions in a letter to X3J13 dated June 14, 1988. Pitman and Waters wrote up the request formally. STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum which is required to support pretty printing into a stream which displays output using a variable width font. We drafted an alternate proposal, STREAM-INFO:TWO-DIMENSIONAL-FUNCTIONS, which goes significantly beyond what is needed merely for pretty printing and provides primitives LINE-DIMENSIONS, LINE-POSITION, PRINTED-DIMENSIONS, and WRITE-SPACE but it is not included here. A key point of contention which would be likely to swamp the 2d proposal is the age old question of how to handle the issue of vertical distance (where is the origin, which way do you count, ...). If anyone would prefer to see larger problem 2d proposal, it could be circulated, but at the last minute Pitman got worried that even the 1d version was going to be controversial enough and decided to keep things focused on that. For his own needs, Waters is strongly interested in having either ONE-DIMENSIONAL-FUNCTIONS or TWO-DIMENSIONAL-FUNCTIONS proposal accepted, but does not care which. Pitman concurs. One variation of the 1d proposal might be useful to consider: PRINTED-WIDTH could return two additional values: the number of newlines that WRITE-STRING of the string would execute and the maximum X position encountered (which might differ from the first value if the number of newlines was non-zero). This feature wasn't necessary for Waters' minimalist proposal, but Pitman would be willing to write it in here if people thought it would be useful enough for other purposes. The 5th version was changed from the 4th by responding to suggestions about better names for the functions, including a discussion of how line-width should apply to various kinds of derivative streams, and most importantly, by including a much more precise specification for what the minimal capabilities of the functions should be. FAILdick Issue: STREAM-INFO (Version 4)<449391.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-%  t tt t "t*t2t:tBt!Jt%Rt)Zt-bt1jt5rt9zt=  t 8 tt@HD > dz& Hpose: Address: Affiliation: .AI.M:Zqp ( 0P(XR0HP @ h  Z` ,hP08 ``%%CL-Compiler-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 12:20:01 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 09:01:08 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA24818; Fri, 23 Sep 88 09:59:42 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02377; Fri, 23 Sep 88 09:59:14 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8809231559.AA02377@defun.utah.edu> Date: Fri, 23 Sep 88 09:59:12 MDT Subject: Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1) To: David A. Moon Cc: cl-cleanup@sail.stanford.edu, Sandra J Loosemore , Gregor.pa@xerox.com, cl-compiler@sail.stanford.edu In-Reply-To: David A. Moon , Wed, 21 Sep 88 14:23 EDT I'd like to put this issue on hold for the time being. Since it appears that CLOS depends on storing some other information in environment objects besides the information about MACROLETs in the surrounding lexical environment (the only thing that CLtL requires), I think a more general proposal to clarify what goes in environment objects is in order. And, I don't think that really falls into the domain of the compiler committee. -Sandra ------- FAILNET-ORIGIN<449388.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  P PP P "P*P2P:PBP!JP%RP)ZP-bP1jP5rP9zP=   P , pPP@H  A/ y~ H:PWp (r(XT 0HP@ h Q-` ,hP08  ` `( #( '(L+CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 11:58:15 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Sep 88 08:47:52 PDT Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA07506g; Fri, 23 Sep 88 07:46:05 PST Received: by rainbow-warrior id AA24733g; Fri, 23 Sep 88 08:44:24 PDT Date: Fri, 23 Sep 88 08:44:24 PDT From: Patrick Dussud Message-Id: <8809231544.AA24733@rainbow-warrior> To: pierson%mist@multimax.ARPA Cc: cl-cleanup@sail.stanford.edu In-Reply-To: Dan L. Pierson's message of Thu, 22 Sep 88 10:29:09 EDT <8809221429.AA13532@mist.UUCP> Subject: Issue: PRINT-PRETTY-HOOK (version 1) Date: Thu, 22 Sep 88 10:29:09 EDT From: Dan L. Pierson Would it help if the pretty print function took an additional optional argument, the current print level (the current print length always starts at 0 when the function is called.) I think it makes it more consistent with the structure print functions. I don't think that you can win all the time, because, if your print function calls a Common Lisp print function (print, princ...), then you lose the depth. Patrick. FAILNET-ORIGIN<449366.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  |}|?|} |? |}|?|}|?|}$|?|},|?|}4|?|}<|?"|}D|?&|}L|?*|}T|?.|}\|?2|}d|?6|}l|?:|}t|?>|}||? 7|} ||}|}@Hw 5- H:"/p (4(X) 0 x!H ()@ t+ "` ,41 P587`7`.  923-0-3968x>  Fri,ep 886:14 From:t.FahCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 10:19:27 EDT Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Sep 88 07:09:29 PDT Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 23 Sep 88 10:06:53 EDT To: masinter.pa@Xerox.COM cc: CL-Cleanup@SAIL.Stanford.EDU Subject: Re: Issue: PACKAGE-CLUTTER (Version 2) In-reply-to: Your message of 23 Sep 88 01:15:00 -0700. <880923-011503-3968@Xerox> Date: Fri, 23 Sep 88 10:06:14 EDT From: Scott.Fahlman@B.GP.CS.CMU.EDU Those symbols with function, variable, macro, setf, constant definitions or uses as properties or tokens may have no other additional definitions other than those specified. ... #2: The symbol VARIABLE is specified to be on the LISP package (because it is a valid second argument to the DOCUMENTATION function). Since it is not defined as a variable, type, or function, however, it may not be bound, defined as a type, or defined as a function, macro or special form. ... As for the additional definitions, there are situations where additional definitions would cause a problem. For example, if a symbol on the Lisp package were declared as a special variable even though that value was not mentioned in the standard, that variable would behave incorrectly when used as a lexical variable. Similarly, if a symbol in the lisp package were defined as an implementation-dependent special form, problems might result if a user redefined or even bound (as by FLET or MACROLET) that name. Where did this come from? I am vehemently opposed to this, if you intend this restriction to apply to users as well as to implementors. We've got a language that, for better or worse, has separate namespaces for functions and variables, and additional namespaces for properties and flags of various kinds. Just because Lisp pre-empts the use of some symbol as a function name does not mean that users should be prevented from using it as a variable name or marker in a property list. If we impose this restriction now, we are creating a very large "cost of adoption". Just as one example, every user program that uses LIST or SYMBOL or MEMBER as a local variable will have to be altered. If we want to say anything along these lines, we should say that *implementors* must not use these exposed symbols in additional, undocumented ways within their implementations, since users can get hold of these symbols and use them in conflicting ways. -- Scott FAIL Re: Issue: PACKAGE-CLUTTER (Version 2) NET-ORIGIN<449296.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ;;  ; ;;";*;2;:!;B%;J);R-;Z1;b5;j9;r=;z  ^; < {;;@H2 0 6>2$x' H9&Ip (8(X4 0HXS 4 tx @ hX ܦ`,h[P0]8^`^`h{0h]CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 88 05:55:22 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 02:42:51 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 02:13:29 PDT Date: 23 Sep 88 02:13 PDT From: masinter.pa@Xerox.COM Subject: Issue: EQUAL-STRUCTURE (Version 3) TO: cl-cleanup@Sail.stanford.edu cc: masinter.pa@Xerox.COM LINE-FOLD: NO Message-ID: <880923-021329-3994@Xerox> Ready for release? ! Issue: EQUAL-STRUCTURE References: EQUAL (p80), EQUALP (p81) Category: CLARIFICATION/CHANGE Edit history: 18-Mar-88, Version 1 by Pitman 8-Jun-88, Version 2 by Masinter (add Benson's proposal) 23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO) Problem Description: The behavior of EQUAL and EQUALP on structures is a subject of controversy. At issue are whether these functions should descend the slots of structures or use simply the structure's primitive identity (i.e., EQ) to test for equivalence. Proposal (EQUAL-STRUCTURE:STATUS-QUO): Clarify that EQUAL and EQUALP do not descend any structures or data types other than the ones explicitly specified in CLtL. (CONSes, bit-vectors, strings, pathnames). EQUAL uses EQL for numbers and EQ for all other types. Rationale: There seem to be as many different equality primitives as there are applications for them. None of the possible ways of changing EQUAL or EQUALP are flawless. Given the inability to "fix" them, it is better to leave them alone. Current Practice: We are unaware of any extensions to CLtL's set of extensions, although frequently users request them. Cost to Implementors: Since this seems to be compatible with the status quo, none. Cost to Users: same Cost of Non-Adoption: Ongoing controversy about whether EQUAL and EQUALP "do the right thing". Benefits: A feeling that EQUAL and EQUALP exist and/or do what they do because serious consideration was given and we consciously decided on a particular resolution to the numerous questions that have come up about them. Aesthetics: There seems to be wide debate about what the proper aesthetics for how equality should work in Common Lisp. While the status quo is not aesthetically more pleasing than the various alternatives. Aesthetic considerations vary widely. Different people model structures differently. Sometimes the same person models structures differently in different situations. The question of which should be descended and which should not is a very personal one, and the aesthetic attractiveness of any of these options will vary from person to person or application to application. Discussion: An earlier version of this issue with various alternatives was distributed at the June 1988 X3J13 meeting. Since this is a frequently raised issue, we thought we should submit it as a clarification although there is no change to CLtL. We considered: removing EQUAL and EQUALP from the standard. changing EQUALP to descend structures. changing EQUALP to be case sensitive. adding a :TEST keyword to EQUAL. making EQUAL a generic function All of these had some serious problems. FAILmasinter.pa Issue: EQUAL-STRUCTURE (Version 3)<449220.880923@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  KwK KwKKw KKwK$KwK,KwK4KwKK  Kw 8 LKwKw@H   G~j H+tp (Gn(X& 0HP~@ h 1` ,hP08 `` Grayy@DSGti.coo: "DA. MoMoon@-BROOC.Syms.COM: cl-ler@SCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 88 17:46:48 EDT Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 14:36:31 PDT Received: by ti.com id AA04913; Wed, 21 Sep 88 16:33:40 CDT Received: from Kelvin by tilde id AA03344; Wed, 21 Sep 88 16:17:59 CDT Message-Id: <2799868740-14879380@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Wed, 21 Sep 88 16:19:00 CDT From: David N Gray To: "David A. Moon" Cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM In-Reply-To: Msg of Wed, 21 Sep 88 13:48 EDT from David A. Moon > No, of course not. I'm saying that #, is a feature of the reader that > needs to cause the loader to do something appropriate with it. #, never > affects the evaluator, EVAL and COMPILE never see anything different when > #, is used than they would see normally. I was forgetting that in the old scenario, in evaluated code, the expression following #, is executed by the reader instead of the evaluator. I guess the basic issue is: if you generate one of these load-time values in a macro expansion within the evaluator, should the expression get evaluated as part of the macro expansion, or should it be done directly by the evaluator? Certainly tying the evaluation to the macro expansion simplifies things greatly since the question of how many times it gets evaluated is the same as the question of how many times the macro gets expanded. Maybe we could get the best of both proposals by saying that LOAD-TIME-VALUE is a macro instead of a special form, and it is defined something like this: (DEFMACRO LOAD-TIME-VALUE (EXP) (IF (compiling-p) `(some-special-thing-only-the-compiler-cares-about ',EXP) `(QUOTE ,(EVAL EXP)))) As for the assumption that a QUOTE form containing a "magic cookie" passes through the compiler just like any other QUOTE form, that unfortunately is not quite true. In our implementation the compiler actually has to scan QUOTE forms looking to see if it contains a "magic cookie" for two reasons: to suppress optimizations based on the value of the constant, and to prevent merging EQUAL forms that use load-time evaluation. That's why I think this approach is ugly -- it uses the syntax of a constant for something that isn't really a constant. FAILNET-ORIGIN<448190.880921@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  C"C " C" C"C""C*"C2"C:"!CB"%CJ")CR"-CZ"1Cb"5Cj"9Cr"=Cz"  tC+B CC@H , )G~ H+U7p ( ZJ(X# 0Hj ")Hx @ hn ץ`,hqP0s8t`t`h]hUth+tCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 88 16:41:30 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:28:54 PDT Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 463467; 21 Sep 88 16:26:11 EDT Date: Wed, 21 Sep 88 16:25 EDT From: Kent M Pitman Subject: Issue: LOAD-TIME-EVAL (Version 6) To: eb@lucid.com cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Gregor.pa@Xerox.COM, dussud@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu In-Reply-To: <8809212016.AA01201@blacksox> Message-ID: <880921162559.7.KMP@GRYPHON.SCRC.Symbolics.COM> Date: Wed, 21 Sep 88 13:16:24 pdt From: Eric Benson Date: Wed, 21 Sep 88 15:58 EDT From: Kent M Pitman Also, I am concerned about how the "right thing" can be done with the env argument in the case of (EVAL-WHEN (EVAL COMPILE LOAD) (DEFUN FOO (X) '(X #,(SQRT 3)))) ... This should work: (EVAL-WHEN (EVAL COMPILE LOAD) (DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV) `(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV))) (DEFUN FOO (X) (LIST-FOR-FOO))) I'm not concerned that there is no way to get the right thing, I'm concerned that the DWIM alluded to in Moon's stripped down proposal is not possible to really guarantee. I'm concerned that if #, is described as just "doing the right thing" environment-wise, then it will lose randomly because that can't always be satisfied. Then people will think of it as something yucky to be avoided rather than something clean and graceful. [Btw, this is a case that was only recently shown to me -- not something I knew when I wrote the predecessor to his proposal.] If instead LOAD-TIME-VALUE were a special form and #, could expand into it (outside of QUOTE), there would be no such yuckiness for people to get burnt by, so #, would not have to become something that people avoided out of paranoia because they didn't understand it. FAILKMP Issue: LOAD-TIME-EVAL (Version 6)<448117.880921@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  C"C " C" C"C""C*"C2"C:"!CB"%CJ")CR"-CZ"1Cb"5Cj"9Cr"=Cz"  _C 0 CC@H  )2']}, H+TFp ( 0'B(XX0HPX@ hY ` ,h\P0^8 _`_`t0h]hUth+tCL-Compiler-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 88 16:39:35 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:21:33 PDT Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05781g; Wed, 21 Sep 88 12:18:41 PST Received: by blacksox id AA01201g; Wed, 21 Sep 88 13:16:24 pdt Date: Wed, 21 Sep 88 13:16:24 pdt From: Eric Benson Message-Id: <8809212016.AA01201@blacksox> To: KMP@STONY-BROOK.SCRC.Symbolics.COM Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM, Gregor.pa@Xerox.COM, dussud@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu In-Reply-To: Kent M Pitman's message of Wed, 21 Sep 88 15:58 EDT <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM> Subject: Issue: LOAD-TIME-EVAL (Version 6) Date: Wed, 21 Sep 88 15:58 EDT From: Kent M Pitman Also, I am concerned about how the "right thing" can be done with the env argument in the case of (EVAL-WHEN (EVAL COMPILE LOAD) (DEFUN FOO (X) '(X #,(SQRT 3)))) In a file compiler, the #, must read in a way that is acceptable to the compiler's runtime environment (compile to core) and the compiler's file environment (compile to file). And this decision must be made at readtime. If instead you wrote: (EVAL-WHEN (EVAL COMPILE LOAD) (DEFUN FOO (X) #,`(X ,(SQRT 3)))) and #, expanded into a LOAD-TIME-VALUE expression, then the compile to core operation could treat the LOAD-TIME-VALUE special form in one way and the file compiler could treat the LOAD-TIME-VALUE special form another way and things would work nicely as a natural result of the accessibility of the lexical environment from the special form. This should work: (EVAL-WHEN (EVAL COMPILE LOAD) (DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV) `(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV))) (DEFUN FOO (X) (LIST-FOR-FOO))) FAILNET-ORIGIN<448115.880921@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  $V $V$V $V #$V+$V3$V;$VC$V!K$V%S$V)[$V-c$V1k$V5s$V9{$V=  H$V > $v$V$V@H+B (|9 H+G,p (4k(X 0{H> ")Hx }@ hB G`,hEP0G8H`H`mit.eJRD@amit.eHGA@amit.eHENRYi.mitCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 88 16:11:24 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:00:38 PDT Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463431; Wed 21-Sep-88 15:58:16 EDT Date: Wed, 21 Sep 88 15:58 EDT From: Kent M Pitman Subject: Issue: LOAD-TIME-EVAL (Version 6) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Gregor.pa@Xerox.COM, dussud@lucid.com, sandra%defun@cs.utah.edu, eb@lucid.com, CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu In-Reply-To: <19880921185047.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM> Well, let me say up front that this description is absolutely unacceptable to me because of the verbiage about destructive modification. Also, I am concerned about how the "right thing" can be done with the env argument in the case of (EVAL-WHEN (EVAL COMPILE LOAD) (DEFUN FOO (X) '(X #,(SQRT 3)))) In a file compiler, the #, must read in a way that is acceptable to the compiler's runtime environment (compile to core) and the compiler's file environment (compile to file). And this decision must be made at readtime. If instead you wrote: (EVAL-WHEN (EVAL COMPILE LOAD) (DEFUN FOO (X) #,`(X ,(SQRT 3)))) and #, expanded into a LOAD-TIME-VALUE expression, then the compile to core operation could treat the LOAD-TIME-VALUE special form in one way and the file compiler could treat the LOAD-TIME-VALUE special form another way and things would work nicely as a natural result of the accessibility of the lexical environment from the special form. FAILKMP Issue: LOAD-TIME-EVAL (Version 6)<448084.880921@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  &A &A &A &A#&A+&A3&A;&A!C&A%K&A)S&A-[&A1c&A5k&A9s&A={&A    @H+r+8 20A+x H+&p ((XZ 0 KH(@ t Ք` ,4 QP8 ``TT(!(%(D)CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 88 14:11:50 EDT Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 10:59:15 PDT Received: by decwrl.dec.com (5.54.5/4.7.34) id AA24142; Wed, 21 Sep 88 10:57:54 PDT Message-Id: <8809211757.AA24142@decwrl.dec.com> From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza) Date: 21 Sep 88 13:55 To: cl-cleanup@sail.stanford.edu Subject: SYMBOL-MACROLET-SEMANTICS (Version 2) Status: For Internal Discussion Issue: SYMBOL-MACROLET-SEMANTICS References: X3J13 document 88-002R, Chapter 2, pp. 2-81f. Category: CHANGE Edit history: 29-July-88, Version 1 by Piazza 21-September-88, Version 2 by Piazza Problem Description: The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document 88-002R, profoundly alters the interpretation of symbols appearing as forms in a Common Lisp program--what previously was necessarily a variable might now be a symbol macro instead. Macros which appear in the body of a SYMBOL-MACROLET form are currently unable to determine whether a symbol form is a variable or a symbol macro, and, if the latter, what the expansion of the symbol macro is. Consequently, complex macros (such as SETF or PUSH) which depend on the form of their argument(s), are unable to produce their desired results in some cases, as in the following example: (let ((a (make-array 5)) (i 0)) (symbol-macrolet ((place (aref a (incf i)))) (push x place)) i) ==> 2 Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM): Change the definition of SYMBOL-MACROLET to specify that it is a special form, which affects the evaluation environment for symbols. Enhance MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro. Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine even symbol subforms. Specify that the expansion of a symbol macro IS subject to further macro expansion, and that ``recursive'' symbol macros are an error. Specify that it is an error to try to SETQ a symbol macro. Rationale: The potential for interaction between macros is exactly why &environment arguments were originally added to macros. Changing SYMBOL-MACROLET to be a special form, which communicates through the &environment arguments to macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF (among others) to work with SYMBOL-MACROLET in the same way they work with MACROLET. This change cannot (reasonably) support the currently specified semantics that the expansion text is "outside" the scope of the symbol macro. For indeed, when the symbol macro is expanded, (a copy of) the expansion is then within the scope of the SYMBOL-MACROLET, and should then be subject to further scrutiny. The issue of "infinite expansion" of symbol macros is no more dangerous than that of normal macros. Finally, the rule that SETQ of a symbol macro must be treated as a SETF of the expansion seems to be a kludge which was introduced only to support a code-walking version of SYMBOL-MACROLET. If SYMBOL-MACROLET were changed to be a special form, this rule would no longer be needed, and should be eliminated in order to make the distinction between symbol macros and variables cleaner. Current Practice: Portable Common Loops provides a code-walking implementation of SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a code-walking version of a SYMBOL-MACROLET macro and compiler support for a SYMBOL-MACROLET special form. Cost to Implementors: If SYMBOL-MACROLET is modified to be a special form, compilers and interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1, PUSH, INCF, DECF, and others. Cost to Users: If SYMBOL-MACROLET is converted to a special form, code-walking programs will have to be modified to handle SYMBOL-MACROLET correctly. Those same programs would have to be modified to handle the other special forms specified in CLOS, anyway. Cost of Non-Adoption: SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when it interacts with complex macros and forms which produce side-effects. Implementations which support ONCE-ONLY will break. For that matter, any mechanism which examines code and assumes that "variables" have no side effects will break. Benefits: SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems surrounding interaction of macros (like SETF) and side effects, and makes SYMBOL-MACROLET consistent with MACROLET. Aesthetics: If SYMBOL-MACROLET is made to be a special form, aesthetics are improved by making symbol macros consistent with normal macros. Discussion: A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal macros: a symbol macro is associated with a single expansion form, rather than an arbitrary function which computes the expansion. For this reason, the augmented MACROEXPAND-1 proposed here can also fill the role of SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be T if and only if sym is a symbol macro, while the first value gives the expansion of sym, if it has one. Also, Pitman points out that, rather than extending the existing MACROEXPAND and MACROEXPAND-1 functions, new functions could be introduced to expand symbol macros. However, there seems to be no particular reason to do this. FAILNET-ORIGIN<447977.880921@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  &%K &%K&%K&% K!&%K)&%K1&%K9&%KA&% KI&%$KQ&%(KY&%,Ka&%0Ki&%4Kq&%8Ky&% Subject: Msg of Friday, 4 March 1988 20:24-EST To: "ZVONA@AI.AI.MIT.EDU"@AI.AI.MIT.EDU Message-ID: <383222.880304@MC.LCS.MIT.EDU> ============ A copy of your message is being returned, because: ============ "MAILER-ERRO-OF-THE-DAY" at MC.LCS.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 4 Mar 88 19:40:49 EST Date: Fri, 4 Mar 88 19:43:38 EST From: David Chapman Subject: [uucp: uuxqt cmd (rmail aloha1!shahriar) status (signal 0, exit 70)] To: mailer-erro-of-the-day@MC.LCS.MIT.EDU Message-ID: <336325.880304.ZVONA@AI.AI.MIT.EDU> Well, this is real helpful. Full text of message follows. Date: Fri, 4 Mar 88 14:06:13-1000 From: UUCP To: %mc.lcs.mit.edu?%nosc%humu.nosc.mil at uhmanoa.ics.hawaii.edu, at OZ.AI.MIT.EDU, @AI.AI.MIT.EDU, Zvona@ai.ai.mit.edu Re: uuxqt cmd (rmail aloha1!shahriar) status (signal 0, exit 70) FAILCOMSAT Msg of Friday, 4 March 1988 20:24-EST<336350.880304@AI.AI.MIT.EDU>SMALL-CLINOQCAPPENDRFC733YN-!  "5"k"5"k"5 "k"5"k&"5"k."5"k6"5"k>"5"kF"5#"kN"5'"kV"5+"k^"5/"kf"53"kn"57"kv"5;"k~"5?"k  O"5 ( "U"5"5@H%C  )c(%Iw\ Hp ( 9(X2@ 0HPH@ hI ~_` ,hLP0N8 O`O`CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Mar 88 09:02:57 EST Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 88 05:53:18 PST Received: by multimax.ARPA (5.51/25-eef) id AA14574; Wed, 2 Mar 88 08:55:06 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA22763; Wed, 2 Mar 88 08:54:44 EST Message-Id: <8803021354.AA22763@mist.UUCP> To: Jon L White Cc: cl-cleanup%sail.Stanford.EDU@multimax Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-Reply-To: Your message of Tue, 01 Mar 88 17:06:53 -0800. <8803020106.AA07266@bhopal.lucid.com> Date: Wed, 02 Mar 88 08:54:41 EST From: Dan L. Pierson Date: Tue, 1 Mar 88 17:06:53 PST From: Jon L White To: pierson@mist Cc: cl-cleanup@sail.Stanford.EDU Subject: Issue: LET-TOP-LEVEL (version 1) As usual, please excuse regrinding. re: Problem description: The main defining forms in CLtL do not support defining (as opposed to creating) closures in lexical environments. . . . Rationale: Common Lisp tries to support lexical closures but this support is really confined to anonymous lambdas within other function definitions. This proposal attempts to move lexical closures closer to first-class status in Common Lisp. I don't believe this problem description. In particular, previous discussions on these mailing lists suggested that DEFUN is merely a macro that turns into something like: (setf (symbol-function 'foo) #'(lambda (x y ...) ...)) so that anything said about "anonymous lambdas" should also be equally applicable to "defun"'s. The relevant sentence is on page 67: "Other implementation-dependent bookkeeping actions may be taken as well by DEFUN." re: Current practice: The above example works in both Ibuki Lisp and Lucid, however only Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. In Lucid Common Lisp, *all* functions are "closures". It doesn't serve any purpose to distinguish one which has some captured lexical environment "inside it" from another that doesn't. [However, I recently adduced reasons why it would be profitable to distinguish those that are merely "trampolines" back into the interpreter from the real "compiled functions".] I sit corrected, however there appears to be no way in Lucid Common Lisp to inspect or debug a function which has some captured lexical environment to see what the captured environment is so I couldn't find this out. re: Current practice: . . . Both Symbolics and TI are reported to leave GET-THING and FREE-THING as named-lambdas instead of compiling them. At least some persons from Symbolics have agreed that this is a flaw in the particular compiler's techniques -- not a flaw in language design. I agree philosophically, but see page 66, second paragraph on Top-Level Forms. -- JonL -- FAILNET-ORIGIN<334876.880302@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! A""+""+" "+""+&""+.""+6""+>""+F"#"+N"'"+V"+"+^"/"+f"3"+n"7"+v";"+~"?"+  $" "5""@H$x :A)1'1$~ Hp ((X+ 09HP@ h zp` ,h!EP0#8 $`$`Hj kU0oCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Mar 88 08:54:36 EST Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 88 05:45:25 PST Received: by multimax.ARPA (5.51/25-eef) id AA14503; Wed, 2 Mar 88 08:47:10 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA22737; Wed, 2 Mar 88 08:46:48 EST Message-Id: <8803021346.AA22737@mist.UUCP> To: Pavel.pa%Xerox.COM@multimax Cc: cl-cleanup%sail.stanford.edu@multimax Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-Reply-To: Your message of Tue, 01 Mar 88 13:24:19 -0800. Date: Wed, 02 Mar 88 08:46:45 EST From: Dan L. Pierson Date: Tue, 1 Mar 88 13:24:19 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: LET-TOP-LEVEL (version 1) To: cl-cleanup@sail.stanford.edu Please excuse my regrinding of your message where the lines didn't fit after being indented. First, I would claim that this is a ``clarification'' as opposed to an ``addition''. I see no language in CLtL to support the belief that DEFUN can only be used in certain scopes. This reminds me of the debate over whether or not the compiler is required to be reentrant; of course it is, for the same reason that MAP is, for example: it's just another function with a particular contract. The CLtL reference is page 66, 5.3 Top-Level Forms: "It is not illegal to use these forms at other than top level, but whether it is meaningful to do so depends on context. Compilers, for example, may not recognize these forms at other than top-level contexts." In any case, I don't oppose the proposal because I think it's important for implementors to support this style. I have some other comments, though. Why does the proposal not cover all of the defining forms? In particular, why not DEFMACRO? It makes just as much sense for the expansion function to be a closure. Of course, the compiler will not be able to expand uses of that macro later in the same file, since it can't provide the proper lexical environment to the expansion function, but that just means that this style would have to be used in a separate file that is loaded before compilation of uses of the macro. The same goes for the defining forms DEFSTRUCT, DEFTYPE, etc. I may have gotten confused here, my thinking was that since MACROLET ignores lexical bindings that DEFMACRO should too. I don't feel strongly about this though. I not particularly happy with the explicit use of the term ``top-level'', but until Rob's compiler proposal gets a fair hearing, I don't see any way around it. It's the current CLtL language, I'd be happy to see it changed. FAILNET-ORIGIN<334872.880302@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  bHb bHbbH bbHb$bHb,bHb4bHbb  |bH  bhbHbH@HdA fedMy= Ha)p (tm(X 0xXrH 0u g@ hv  a``,hyP0{8|`|`7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 21:39:33 EST Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 18:30:00 PST Date: 1 Mar 1988 21:26-EST Sender: MATHIS@A.ISI.EDU Subject: compiler "clean-up" issues From: MATHIS@A.ISI.EDU To: sandra%orion@CS.UTAH.EDU Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU Cc: smh%franz.uucp@UCBARPA.BERKELEY.EDU Cc: bartley%ti-csl@RELAY.CS.NET Cc: cl-cleanup@SAIL.STANFORD.EDU Message-ID: <[A.ISI.EDU] 1-Mar-88 21:26:26.MATHIS> >At the November meeting I volunteered to send a draft >DEFSYSTEM proposal around to the compiler subcommittee for review (and >in fact I have had both documentation and code sitting around for >months), please bring some printed copies to Palo Alto > but in spite of repeated promises from Steve, our mailing list >has never materialized we'll get Jan Zubkoff to take care of it after Palo Alto > and I don't have e-mail addresses for everybody >(where's David Bartley?). Bartley%TI-CSL@CSNET-RELAY FAIL compiler "clean-up" issuesMATHIS<334697.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  0Q0 0Q00Q 00Q0$0Q0,0Q040Q0<0Q0D0Q"0L0Q&0T0Q*0\0Q.0d0Q20l0Q60t0Q:0|0Q>0  }0Q  0q0Q0Q@H3 2 5S53~B HNp (}(X$ 0 rH( $/x @ hw  Qa`,hzP0|8}`}`ooH}0~h DCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 21:00:02 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 17:49:34 PST Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 17:11:13 PST Received: from bhopal.lucid.com by edsel id AA08004g; Tue, 1 Mar 88 17:00:45 PST Received: by bhopal id AA07266g; Tue, 1 Mar 88 17:06:53 PST Date: Tue, 1 Mar 88 17:06:53 PST From: Jon L White Message-Id: <8803020106.AA07266@bhopal.lucid.com> To: pierson@mist Cc: cl-cleanup@sail.Stanford.EDU In-Reply-To: Dan L. Pierson's message of Tue, 01 Mar 88 16:02:35 EST <8803012102.AA21522@mist.UUCP> Subject: Issue: LET-TOP-LEVEL (version 1) re: Problem description: The main defining forms in CLtL do not support defining (as opposed to creating) closures in lexical environments. . . . Rationale: Common Lisp tries to support lexical closures but this support is really confined to anonymous lambdas within other function definitions. This proposal attempts to move lexical closures closer to first-class status in Common Lisp. I don't believe this problem description. In particular, previous discussions on these mailing lists suggested that DEFUN is merely a macro that turns into something like: (setf (symbol-function 'foo) #'(lambda (x y ...) ...)) so that anything said about "anonymous lambdas" should also be equally applicable to "defun"'s. re: Current practice: The above example works in both Ibuki Lisp and Lucid, however only Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. In Lucid Common Lisp, *all* functions are "closures". It doesn't serve any purpose to distinguish one which has some captured lexical environment "inside it" from another that doesn't. [However, I recently adduced reasons why it would be profitable to distinguish those that are merely "trampolines" back into the interpreter from the real "compiled functions".] re: Current practice: . . . Both Symbolics and TI are reported to leave GET-THING and FREE-THING as named-lambdas instead of compiling them. At least some persons from Symbolics have agreed that this is a flaw in the particular compiler's techniques -- not a flaw in language design. -- JonL -- FAILedsel!jonl Issue: LET-TOP-LEVEL (version 1)<334676.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  HHYHHY HHYHHYH&HYH.HYH6HYH>HY#HFHY'HNHY+HVHY/H^HY3HfHY7HnHY;HvHY?H~HY  aH & HHH@HK  M9LK}6 H?p (U(X! 0HPZ@ h[  ?U` ,h^P0`8 a`a` 0 CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 20:27:48 EST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 17:18:14 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA29680; Tue, 1 Mar 88 18:18:51 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA06603; Tue, 1 Mar 88 18:18:47 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8803020118.AA06603@orion.utah.edu> Date: Tue, 1 Mar 88 18:18:44 MST Subject: Re: Compiler cleanup issues, again To: Ram@c.cs.cmu.edu Cc: cl-cleanup@sail.stanford.edu, mike%acorn@live-oak.lcs.mit.edu, smh%franz.uucp@ucbarpa.berkeley.edu In-Reply-To: Ram@C.CS.CMU.EDU, Tue, 1 Mar 1988 18:47 EST > But I think that the value of in-person meeting time is overrated. Actually, I agree. But there hasn't been anything happening via e-mail or over the telephone, either. > What sort of small, well-defined proposals (that have been tabled) do > you have in mind? I submitted two to the cleanup committee before the November meeting. One was an attempt to specify how top-level forms in a file (such as DEFMACRO or DEFSETF) affect how COMPILE-FILE compiles subsequent forms in the file. At that time, the cleanup committee didn't want to consider compiler-related issues at all, although there did seem to be an overwhelming agreement with the actual content of the proposal. The other proposal tried to specify how REQUIRE works in a little more detail so that it would actually be meaningful to use in specifying inter-file compilation dependencies. On this one, there was a general feeling that PROVIDE and REQUIRE were a poor substitute for a DEFSYSTEM utility. At the November meeting I volunteered to send a draft DEFSYSTEM proposal around to the compiler subcommittee for review (and in fact I have had both documentation and code sitting around for months), but in spite of repeated promises from Steve, our mailing list has never materialized and I don't have e-mail addresses for everybody (where's David Bartley?). > Rob -Sandra ------- FAILNET-ORIGIN<334655.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  hkh hkhhk hhkh$hkh,hkh4hkhh hk * i hkhk@HoK 2 qkHoKHoKt` H9p ($ݣ(0 ݣ(XEH0 H x (@t ? 8,4 }P`8Y$P8``5CL-Cleanup-mailer@SAIL.Stanford.EDUMLY-LISPM@AI.AI.MIT.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 20:15:22 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:48:14 PST Received: ID ; Tue 1 Mar 88 18:47:54-EST Date: Tue, 1 Mar 1988 18:47 EST Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: cl-cleanup@SAIL.STANFORD.EDU, mike%acorn@LIVE-OAK.LCS.MIT.EDU, smh%franz.uucp@UCBARPA.BERKELEY.EDU Subject: Compiler cleanup issues, again In-reply-to: Msg of 1 Mar 1988 18:15-EST from sandra%orion at cs.utah.edu (Sandra J Loosemore) Well, currently I haven't been to any X3J13 meeting because CMU won't pay for peons to go flying around the country. Now that Scott Fahlman has ceased to be active in X3J13, he has been pusing to have me made the CMU delegate, so I might make it at some future meeting. But I think that the value of in-person meeting time is overrated. What sort of small, well-defined proposals (that have been tabled) do you have in mind? Rob FAILRam<334649.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWmly-lispm@NOSHOWYN-!  $b$ $b$$b $$b$$$b$,$b$4$b$<$b$D$b"$L$b&$T$b*$\$b.$d$b2$l$b6$t$b:$|$b>$ b$b %$b$b@Hm` : poymч}1 Hp ($(0 (X(0 H PY@ hZ 8,h]P0_`8YH`P0a8b`b`/((CL-Cleanup-mailer@SAIL.Stanford.EDUMLY-LISPM@AI.AI.MIT.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 18:52:28 EST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:15:14 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA24776; Tue, 1 Mar 88 16:15:40 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA06356; Tue, 1 Mar 88 16:15:30 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8803012315.AA06356@orion.utah.edu> Date: Tue, 1 Mar 88 16:15:28 MST Subject: Compiler cleanup issues, again To: smh%franz.uucp@ucbarpa.berkeley.edu, ram@c.cs.cmu.edu, mike%acorn@LIVE-OAK.LCS.MIT.EDU Cc: cl-cleanup@sail.stanford.edu (flame on) If there is not going to be a compiler subcommittee meeting at this month's X3J13 meeting, I think the subcommittee should be officially disbanded. As far as I can tell, we have accomplished nothing at all since November, and nothing has happened lately to convince me that things are going to change. As I have been saying for quite a while now, I think the current trend of tabling small, well-defined proposals while waiting for the Grand Theory of Compilation to be revealed is a mistake -- what ever happened to the divide-and-conquer approach? I don't think any of us have the time to really take charge of the situation, put together a moby proposal that addresses all of the issues, and push it through the full committee. (We've already seen that there is such a diversity among implementations that I find it hard to believe that implementors will be able to agree on *any* Grand Theory.) On the other hand, there does seem to be somewhat more agreement on some of the smaller issues considered individually. (flame off) The cleanup subcommittee seems to be doing a good job of pushing issues through and I think they would be a better chance of getting compiler-related issues resolved than we would, given our track record so far. Perhaps we should try to arrange for an official transfer of responsibilities at the upcoming meeting? -Sandra ------- FAILNET-ORIGIN<334619.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWmly-lispm@NOSHOWYN-!  tt9tt9t t9tt9&tt9.tt96tt9>tt9Ft#t9Nt't9Vt+t9^t/t9ft3t9nt7t9vt;t9~t?t9  nt  t<tt@Hv $ xx1vL}w Hp (p0(X 0 dH$ $/x d@ hh  `,hkP0m8n`n`X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 18:10:02 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:14 PST Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:06:55 PST Received: from sunvalleymall.lucid.com by edsel id AA06854g; Tue, 1 Mar 88 13:56:26 PST Received: by sunvalleymall id AA00420g; Tue, 1 Mar 88 14:02:49 PST Date: Tue, 1 Mar 88 14:02:49 PST From: Jan Zubkoff Message-Id: <8803012202.AA00420@sunvalleymall.lucid.com> To: x3j13@sail.stanford.edu Subject: X3 attendee list to date Please let me know if your name isn't listed below and you are attending the March meeting. I also need to know whether you will be having lunch 3/16 and/or 3/17. ---jan--- Registration Fees 03/01/88 Name Company Paid Masayuki Ida Aoyama Gakuin University - Gregor Kiczales Xerox PARC - Bob Mathis -0- - Daniel Bobrow Xerox PARC y Kathy Chapman Digital Equipment y Steve Haflich Franz, Inc. y Kevin Layer Franz, Inc. y Thom Linden IBM y Jeff Rininger SRI International y Thomas Turba UNISYS Corp y Walter van Roggen Digital Equipment y Paul Beiser HP - Eric Benson Lucid, Inc. - Jeff Dalton University of Edinburgh - Linda DeMichiel Lucid, Inc. - Jerry Duggan HP - Dick Gabriel Lucid, Inc. - David Moon Symbolics, Inc. - Julian Padget University of Bath - Mary Van Deusen IBM Research - JonL White Lucid, Inc. - FAILedsel!jlz X3 attendee list to date<334603.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  7z7z 7z7z7%z7-z75z7=z"7Ez&7Mz*7Uz.7]z27ez67mz:7uz>7}z F7 w77@H/w 2 1(/ׇ|/ Hp (;(X 0}HP? $/@ h@  xq` ,hCP0E8F`F`(h($`0yCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 17:56:51 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:22 PST Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:07:04 PST Received: from bhopal.lucid.com by edsel id AA06877g; Tue, 1 Mar 88 13:59:18 PST Received: by bhopal id AA06724g; Tue, 1 Mar 88 14:05:25 PST Date: Tue, 1 Mar 88 14:05:25 PST From: Jon L White Message-Id: <8803012205.AA06724@bhopal.lucid.com> To: Ram@c.cs.cmu.edu Cc: cl-cleanup@sail.stanford.edu, Moon@scrc-stony-brook.arpa, vanroggen%aitg.decnet@hudson.dec.com In-Reply-To: Ram@C.CS.CMU.EDU's message of Tue, 1 Mar 1988 16:08 EST Subject: function-type-rest-list-element (really array types) re: My idea is that TYPEP automatically "upgrade" its type argument to the corresponding "implementation type", i.e. a type actually supported by the implementation. . . . There are two problems with respect to typep. Consider arrays made by (MAKE-ARRAY :element-type ') then: 1. (TYPEP '(ARRAY )) frequently fails for such arrays 2. (TYPEP (AREF ) ') frequently fails for such arrays These are two separate problems, and as I read your comments about having TYPEP do the "upgrading", I think they apply only to case (1), right? This may be another way of trying to say that `(ARRAY FOO) is type equivalent to `(ARRAY ,(upgrade array-element-type 'foo)) re: I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has is a precisely defined concept within the language: `(integer ,most-negative-fixnum ,most-positive-fixnum) See my comments in the previous note about a "pyrrhic success". -- JonL -- FAILedsel!jonl<334593.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  PMP'PM P' PMP'PMP'PM$P'PM,P'PM4P'PMPM|P'  PM PPMPM@H% $ )#(%y~ HYp ($#(0 #(Xkx0 H P $/@h _W8,hP0`8YH P0 8 ` `+CL-Cleanup-mailer@SAIL.Stanford.EDUMLY-LISPM@AI.AI.MIT.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 16:45:32 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:16:30 PST Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 12:38:16 PST Received: from bhopal.lucid.com by edsel id AA06523g; Tue, 1 Mar 88 13:03:03 PST Received: by bhopal id AA05817g; Tue, 1 Mar 88 13:09:10 PST Date: Tue, 1 Mar 88 13:09:10 PST From: Jon L White Message-Id: <8803012109.AA05817@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu In-Reply-To: David A. Moon's message of Tue, 1 Mar 88 13:07 EST <19880301180711.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem? re: I don't know why the declaration vs discrimination thing was done. . . . Offhand getting rid of this distinction into two kinds of types seems like a good idea. However, I'm a bit leery of changing things in the language when I don't understand why they are there. . . . I share your queasiness here. My first impluse is to ask for a function (which would be "implementation revealing") named UPGRADE-ARRAY-ELEMENT-TYPE whose purpose would be to tell you what the canonical representation for a type name is (when used as an :element-type specifier). E.g., suppose: (setq a (make-array size :element-type 'foo) (setq real-element-type (upgrade-array-element-type 'foo)) then the following two specifiers would be type-equivalent: `(array foo) `(array ,real-element-type) even if "'foo" and "real-element-type" be not type-equivalent. Furthermore, (typep (aref a n) real-element-type) is always true, even though in the face of non-trivial upgrading, (typep (aref a n) 'foo) could be false. I would consider UPGRADE-ARRAY-ELEMENT-TYPE in the same genre of features as MOST-POSITIVE-FIXNUM. Programmers would inevitably choose to use "real-element-type" rather than "'foo", and ocasionally find that their code wasn't so trivially portable to a system that had a fundamentally different kind of upgrading. But if "upgrading" is to remain in CL, I don't see how we can avoid opening it up a bit for inspection. My second impluse is to toss out upgrading altogether, and require every array to remember the type (or, a canonical name therefor) by which it was created. The reason this is second, rather than first, on my list is that to make types absolutely portable this way is a very pyrrhic success. Sure, your program will port to the Y machine -- it will just run two orders of magnitude slower [because you started out on, say, a Multics machine with (MOD 512) arrays optimized, and ported to an implementation for an engineering workstation that prefers (UNSIGNED-BYTE 8) arrays ...]. Finally, as I've said before, I don't think it's an acceptable solution for Lisp to take the same route as C (and others) to achieve portability. The kinds of array types in such languages are limited to a small (albeit very useful) set that seems inspired by one particular hardware architecture. -- JonL -- P.S. Of course UPGRADE-ARRAY-ELEMENT-TYPE can currently be implemented in a "consy" way doing something like: (array-element-type (make-array 0 :element-type 'foo)) But the presence of a "first class" function UPGRADE-ARRAY-ELEMENT-TYPE would be more for the purpose of encouraging cognizance of these problems than for avoiding the consing. Implicitly, such a function lies underneath any implementation of MAKE-ARRAY already. FAILedsel!jonl<334560.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWmly-lispm@NOSHOWYN-!  PMP'PM P' PMP'PMP'PM$P'PM,P'PM4P'PMPM|P'  PM PPMPM@HRl . U T0Rrm HӋp (s(Xx 0 <H y 4 tx {@ t  X`,4 FP8``\$0&\'0) \CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 16:37:25 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:25:17 PST Received: from Salvador.ms by ArpaGateway.ms ; 01 MAR 88 13:24:51 PST Date: Tue, 1 Mar 88 13:24:19 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-reply-to: <8803012102.AA21522@mist.UUCP> To: cl-cleanup@sail.stanford.edu Message-ID: <880301-132451-3075@Xerox> First, I would claim that this is a ``clarification'' as opposed to an ``addition''. I see no language in CLtL to support the belief that DEFUN can only be used in certain scopes. This reminds me of the debate over whether or not the compiler is required to be reentrant; of course it is, for the same reason that MAP is, for example: it's just another function with a particular contract. In any case, I don't oppose the proposal because I think it's important for implementors to support this style. I have some other comments, though. Why does the proposal not cover all of the defining forms? In particular, why not DEFMACRO? It makes just as much sense for the expansion function to be a closure. Of course, the compiler will not be able to expand uses of that macro later in the same file, since it can't provide the proper lexical environment to the expansion function, but that just means that this style would have to be used in a separate file that is loaded before compilation of uses of the macro. The same goes for the defining forms DEFSTRUCT, DEFTYPE, etc. I not particularly happy with the explicit use of the term ``top-level'', but until Rob's compiler proposal gets a fair hearing, I don't see any way around it. For the current practice section, Xerox Lisp also implements the proposed behavior. FAILPavel.pa Re: Issue: LET-TOP-LEVEL (version 1)<334556.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  PMP'PM P' PMP'PMP'PM$P'PM,P'PM4P'PMPM|P' PM PPMPM@HT% . XEWT+u Hˉp (_(X9X 0Hu (@ t  V`` ,4 zP8``\$0&\'0) \CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 16:20:20 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:09:54 PST Received: ID ; Tue 1 Mar 88 16:08:28-EST Date: Tue, 1 Mar 1988 16:08 EST Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Jon L White Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA, vanroggen%aitg.decnet@HUDSON.DEC.COM Subject: function-type-rest-list-element (really array types) In-reply-to: Msg of 29 Feb 1988 22:54-EST from Jon L White Date: Monday, 29 February 1988 22:54-EST From: Jon L White To: Moon at stony-brook.scrc.symbolics.com Re: function-type-rest-list-element re: . . . CLtL isn't sure whether its data types are portable, fairly abstract types or are ways to find out about implementation details. Good point. In that series of messages a couple of months ago (?) on this issue, there were basically two camps of opinions: (1) array types should be completely portable -- hence the exact equivalence class of the :element-type specifier must be "remembered" (2) "Upgrading" is reasonable, albeit a source of non-portability akin to the fixnum/bignum split; to do otherwise isn't worth it. Both Rob and Walter are espousing position (1), and may not have fully noticed that it isn't mandated by CLtL. Actually I'm not proposing 1, at least as I understand what you are saying. My idea is that TYPEP automatically "upgrade" its type argument to the corresponding "implementation type", i.e. a type actually supported by the implementation. This basically amounts to requiring the programmer (as opposed to the array) the remember the array element type, but in the absence of a hard semantics for ARRAY-ELEMENT-TYPE/TYPE-OF, this is the same as requiring that arrays "remember their element-type". I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has is a precisely defined concept within the language: `(integer ,most-negative-fixnum ,most-positive-fixnum) Given this definition, a Common Lisp program can have a portable understanding of what it means to be a FIXNUM. For example, it is clear that (typep most-negative-fixnum 'fixnum) is true in any Common Lisp implementation. With arrays, TYPEP is simply broken. Unless you use one of the special element types, BIT, STRING-CHAR or T, TYPEP doesn't mean anything on arrays. It seems to me that the FIXNUM issue is kind of like a resource restriction: "This program will only run when a fixnum is at least 16 bits." is similar to "This program will only run when you can have 1e6 element bit-vectors." In constrast, there is no way to characterize the set of implementations in which TYPEP will work on arrays. In fact, there probably are no such implementations. [...] almost everyone agreed that the schizophrenia induced by CLtL p45 is a bad idea, and could easily be dropped. This is the part that says "Types can therefore be used for two different purposes: declaration and discrimination. ...", and implies as a consquence that the result of: (make-array :element-type ') will probably not be of typep (array ). Not only is this very counterintuitive, but it really doesn't satisfy any need that I'm aware of. Yes, I agree with this. Rob FAILRam<334548.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  PMP'PM P' PMP'PMP'PM$P'PM,P'PM4P'PMPM|P'  PM PPMPM@H .  ~هzX Hǧp ((X> 0'HP@ h  V)` ,h3P08 ``0#\$0&\'0) \CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 16:12:03 EST Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:01:05 PST Received: by multimax.ARPA (5.51/25-eef) id AA11586; Tue, 1 Mar 88 16:02:47 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA21522; Tue, 1 Mar 88 16:02:38 EST Message-Id: <8803012102.AA21522@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Issue: LET-TOP-LEVEL (version 1) Date: Tue, 01 Mar 88 16:02:35 EST From: Dan L. Pierson Issue: LET-TOP-LEVEL References: Top-Level Forms (p. 66), DEFUN (p. 67), DEFVAR, DEFPARAMETER, DEFCONSTANT (pp. 68-69) Category: ADDITION Edit history: Version 1 by Pierson 3/1/88 Status: For Internal Discussion Problem description: The main defining forms in CLtL do not support defining (as opposed to creating) closures in lexical environments. Proposal (LET-TOP-LEVEL:ALLOW-DEF): Require implementations to support DEFUN, DEFVAR, DEFPARAMETER, and DEFCONSTANT enclosed in a LET at top level as well as a PROGN at top level. Do not require support for DEFMACRO (environment irrelevant) or EVAL-WHEN. Explicitly note that a "top level" let can be included in a top level PROGN. Test Cases/Examples: The following creates a simple resource allocation package for THINGs. It needs to be COMPILE-FILEd to test it. (LET ((THINGS '())) (DEFUN GET-THING () (IF THINGS (PROG1 (CAR THINGS) (SETF THINGS (CDR THINGS))) (MAKE-THING))) (DEFUN FREE-THING (THING) (SETF THINGS (CONS THING THINGS)))) Rationale: Common Lisp tries to support lexical closures but this support is really confined to anonymous lambdas within other function definitions. This proposal attempts to move lexical closures closer to first-class status in Common Lisp. Current practice: The above example works in both Ibuki Lisp and Lucid, however only Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. Both Symbolics and TI are reported to leave GET-THING and FREE-THING as named-lambdas instead of compiling them. Cost to Implementors: While there is obviously some work required, it shouldn't be too hard since all Common Lisp compilers are required to understand functions in lexical closures in other contexts. Cost to Users: None, this is an upward compatible change. Cost of non-Adoption: Common Lisp will continue to leave a major style of lexical closure use unsupported. This is probably most important to people converting from Scheme to Common Lisp. Benefits: Lexical closures will become more useful. The increased information hiding available may make some programs more maintainable by reducing the number of global variables which really should be private to a small group of functions. It will be easier to migrate some Scheme programming styles to Common Lisp. Aesthetics: The aesthetics of the language will be improved by supporting a more uniform view and use of lexical closures. Discussion: It has been pointed out that much of this proposal can be accomplished by layering macros on top of SETF of SYMBOL-FUNCTION. The problem with the macro approach is that it doesn't support whatever additional environmental things the implementation may decide to do with DEFUN (e.g. make an entry in the cross reference database). One disadvantage of this proposal is that it doesn't interact well with Lisp-style incremental development, for example a new top-level defun of GET-THING wouldn't work. Pierson believes that this is an inherent consequence of heavy use of lexical closures and that the best workaround is to use an inspector which can support incremental development within the current lexical scope, however this is all outside the purvue of this committee. Maybe this should be a compiler proposal instead of a cleanup proposal. FAILNET-ORIGIN<334544.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!   A A  A  A $ A , A 4 A < A D A" L A& T A* \ A. d A2 l A6 t A: | A>   A   a A A@H#  (9&$ H_p (Xm(X9T 0H u ")Hx @ t  M`,4 P8``cmu.eccvb-----------------------------------CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 14:33:19 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 88 11:24:14 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 353802; 1 Mar 88 14:23:46 EST Date: Tue, 1 Mar 88 14:23 EST From: David A. Moon Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2) To: Dan L. Pierson , Pierson@MULTIMAX.ARPA cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8802292355.AA19855@mist.UUCP> Message-ID: <19880301192344.0.MOON@EUPHRATES.SCRC.Symbolics.COM> There are actually three parts to this proposal, and perhaps it should be written in a way that makes the distinction even clearer. First, the specification of *STANDARD-INPUT* etc. is changed to specify them in terms of what they do, rather than in terms of how they are implemented. I wholeheartedly support this. I think the proposal needs to go a little farther in this direction. For instance, it seems to apply that the initial binding of *TERMINAL-IO* will be a value returned by the MAKE-TWO-WAY-STREAM function. That's implementation. Instead it should say only that the initial binding of *TERMINAL-IO* behaves in such a way that input comes from, and output goes to, an interactive place, if there is one. If no interactive places exist, I think you say (the wording is a bit confusing) that *TERMINAL-IO* is bound to (MAKE-TWO-WAY-STREAM *STANDARD-INPUT* *STANDARD-OUTPUT*), even though it's not a terminal. I'm not sure, but I think it might be better for *TERMINAL-IO* to be unbound, or a stream that signals an error if used, in this case, since anything that explicitly uses *TERMINAL-IO* is trying to do something that simply can't be done. I suspect that the alignment of the *TERMINAL-IO* interactive place with the *STANDARD-INPUT* and *QUERY-IO* interactive places should be left up to the implementation, rather than trying to say (as you do) it goes here if that's interactive, else it goes there. There is probably a great deal of variation among implementations on this point, and I don't see that a portable program needs to know whether *TERMINAL-IO* is the same as *STANDARD-INPUT*, the same as *QUERY-IO*, or the same as neither of them; a portable program should use whichever stream is the one it really means, not use some different one on the assumption that it's really the same. Second, you propose to add the variable *INITIAL-QUERY-INPUT*, which doesn't quite correspond to *QUERY-IO*. This gives access to a primitive stream that hadn't been identified as primitive before, but that exists in some implementations. Although I don't understand how an application program would use an input-only query stream, I see no harm in making this change. No one is forced to use it if they don't want to. I'd drop the word "initial" from the variable name. Third, you propose to add three new variables that retain the initial values of three of the existing stream variables, in case the existing variables are rebound. I don't see any value in this, except that it helps you describe the meanings of the other streams. A program that wished to portably recover from a stream-binding error on any User Stream could start by saving the values of the existing variables. We don't need to add new variables for this. This sounds a bit critical, but I think this is basically a very good proposal. I hope you find my suggested improvements constructive. FAILMoon Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)<334491.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!   A A  A  A $ A , A 4 A < A D A" L A& T A* \ A. d A2 l A6 t A: | A>  ` A  a A A@H^  a`L^}1 Hp (?/(X 0 PHT Ox S@ hZ  `,h]P0_8````cmu.eccvb-----------------------------------CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 14:10:44 EST Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 88 11:01:53 PST Date: 1 Mar 88 13:45:00 EDT From: "AITG::VANROGGEN" Subject: sequence-functions-exclude-arrays (pardon msg duplication, if any) To: "cl-cleanup" cc: vanroggen Reply-To: "AITG::VANROGGEN" We currently oppose the proposal SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS: GENERALIZE as it stands. There are a number of issues that should be addressed. The proposal merely offers new syntax for functionality already provided by displaced vectors. The argument that users (or at least one user) "dislikes" using displaced vectors has little meaning. The syntax for displaced vectors could be improved with some trivial macros, while efficiency concerns should be handled by the compiler. The availability of ROW-MAJOR-AREF would seem to make this proposal even less necessary than before. It wouldn't change the behavior of FILL, COUNT, etc. but does make such array operations even easier to implement efficiently. There is no description of the meaning of :START and :END keyword arguments for affected functions in the current proposal. Do ARRAYs become a subtype of SEQUENCE? We assume not, but this should be specified. However, the sequence functions won't just be ``sequence'' functions any more. It's confusing to remember which functions work on arrays and which don't. Despite the proposal's claim to the contrary, it strikes us that this is precisely an attempt to make Common Lisp into a kind of half-baked APL. We feel adoption of this proposal will almost certainly result in pressure to extend still more sequence functions. This may or may not be desirable in the long run; but this proposal is only a partial measure. ---Walter van Roggen & Jeff Piazza ------ FAILvanroggen%aitg.decnet sequence-functions-exclude-arrays (pardon msg duplication, if any)<334484.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  p| p| p| p|#p|+p|3p|;p|!Cp|%Kp|)Sp|-[p|1cp|5kp|9sp|={p|  !  7@Hc 0 gekcuv Hvp (!(X* 0-H  ")Hx /@ h  w#`,h?P0 8!`!`7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 13:19:03 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 88 10:07:38 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 353704; Tue 1-Mar-88 13:07:13 EST Date: Tue, 1 Mar 88 13:07 EST From: David A. Moon Subject: function-type-rest-list-element To: Jon L White cc: cl-cleanup@SAIL.STANFORD.EDU, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu In-Reply-To: <8803010354.AA04652@bhopal.lucid.com> Message-ID: <19880301180711.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 29 Feb 88 19:54:18 PST From: Jon L White While there seemed to be no clear consensus on saying that types "must be" portable, almost everyone agreed that the schizophrenia induced by CLtL p45 is a bad idea, and could easily be dropped. This is the part that says "Types can therefore be used for two different purposes: declaration and discrimination. ...", and implies as a consquence that the result of: (make-array :element-type ') will probably not be of typep (array ). Not only is this very counterintuitive, but it really doesn't satisfy any need that I'm aware of. At first blush, it might seem to be a corollary of "upgrading"; but it isn't at all. I don't know why the declaration vs discrimination thing was done. The only thing I can guess at is that the idea was that if (typep a '(array foo)), then it's -guaranteed- that (typep (aref a n) 'foo) is true, because a is implemented with a representation that only holds objects of type foo. Before speculating further I should of course leaf through CLtL to see if it already contains somewhere an explanation of why the declaration vs discrimination distinction was drawn. Offhand getting rid of this distinction into two kinds of types seems like a good idea. However, I'm a bit leery of changing things in the language when I don't understand why they are there. At first thought, removing the distinction seems like an upward-compatible change in the sense that all it does is make some types that currently have no members, in a particular implementation, have some members. However there might be subtle incompatibilities with existing programs, since the subtype rules would be changed, and in a way that depends on what array representations a particular implementation has. I don't claim to understand the implications right now. FAILMoon function-type-rest-list-element<334451.880301@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  `y` `y``y ``y`$`y`,`y`4`y`<`y`D`y"`L`y&`T`y*`\`y.`d`y2`l`y6`t`y:`|`y>` `y 0 a`y`y@Hcuw eesc Hvp ( /(X&P 0 {H( $/@ t m` ,4 P8``8Mv 7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 23:10:14 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 19:59:55 PST Received: by labrea.Stanford.EDU; Mon, 29 Feb 88 19:21:33 PST Received: from bhopal.lucid.com by edsel id AA04105g; Mon, 29 Feb 88 19:48:13 PST Received: by bhopal id AA04652g; Mon, 29 Feb 88 19:54:18 PST Date: Mon, 29 Feb 88 19:54:18 PST From: Jon L White Message-Id: <8803010354.AA04652@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu In-Reply-To: David A. Moon's message of Mon, 29 Feb 88 16:53 EST <19880229215350.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: function-type-rest-list-element re: . . . CLtL isn't sure whether its data types are portable, fairly abstract types or are ways to find out about implementation details. Good point. In that series of messages a couple of months ago (?) on this issue, there were basically two camps of opinions: (1) array types should be completely portable -- hence the exact equivalence class of the :element-type specifier must be "remembered" (2) "Upgrading" is reasonable, albeit a source of non-portability akin to the fixnum/bignum split; to do otherwise isn't worth it. Both Rob and Walter are espousing position (1), and may not have fully noticed that it isn't mandated by CLtL. I myself forget the horrible intricacies of array types from time to time. Worse yet, I waffle between preferring (1) and (2) depending on the latest "arguments" for one or the other. To me, this indicates that an easy solution isn't at hand. While there seemed to be no clear consensus on saying that types "must be" portable, almost everyone agreed that the schizophrenia induced by CLtL p45 is a bad idea, and could easily be dropped. This is the part that says "Types can therefore be used for two different purposes: declaration and discrimination. ...", and implies as a consquence that the result of: (make-array :element-type ') will probably not be of typep (array ). Not only is this very counterintuitive, but it really doesn't satisfy any need that I'm aware of. At first blush, it might seem to be a corollary of "upgrading"; but it isn't at all. -- JonL -- FAILedsel!jonl<334057.880229@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  UvU UvUUv UUvU$UvU,UvU4UvUU  QUv ( VUvUv@H]  4 eMcT]wf Hvop (3U(X 0HPJ@ hK lW` ,hNP0P8 Q`Q`$B=0B=0YZh&CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 19:02:15 EST Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Feb 88 15:52:45 PST Received: by multimax.ARPA (5.51/25-eef) id AA04746; Mon, 29 Feb 88 18:54:32 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA19855; Mon, 29 Feb 88 18:55:17 EST Message-Id: <8802292355.AA19855@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2) Date: Mon, 29 Feb 88 18:55:14 EST From: Dan L. Pierson Issue: STANDARD-INPUT-INITIAL-BINDING References: Standard streams (pp. 327-329) Category: CHANGE Edit history: Version 1 by Pierson and Haflich 1/19/87 Version 2 by Pierson 2/29/88 Status: For Internal Discussion This is a complete rewrite. I hope the added complexity is worth it, I don't see anyway to both hide the hair and do better than CLtL. Problem description: CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*, *ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are initially bound to synonym streams to *TERMINAL-IO*. This requirement hampers the integration of Common Lisp with many existing and potential operating environments. For example, a Unix implementation is currently unable to legally support Unix standard error output even though Common Lisp defines *ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound to the same stream as *STANDARD-OUTPUT*. A workstation environnment which provides stream access to windows as an extension is currently forbidden to make trace output appear in a separate window by default because *TRACE-OUTPUT* is required to start out bound to the same stream as *STANDARD-OUTPUT*. Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS): A Common Lisp implementation is required to provide two sets of open streams, Primitive Streams, and User Streams. Most user programs should only use the User Streams; each User Stream has a specific purpose as defined in CLtL. [[ If this proposal is accepted I can be persuaded to retype the page and a half of definitions here.]] The Primitive Streams are the initial defined interfaces between Lisp and the non-Lisp world. The primary purpose of the Primitive Streams is to make it possible to portably recover from a stream-binding error on any User Stream, for this reason it is an error to rebind or set any Primitive Stream. Implementations are encouraged, but not required to signal a correctable error if a Primitive Stream is rebound. Primitive Streams: *INITIAL-INPUT* This stream is bound to the primary default input of the Lisp system (e.g. standard input on Unix, SYS$INPUT on VMS). While this will probably be an interactive terminal or window during program development, it may well be a data file for a non-interactive application. *INITIAL-OUTPUT* This stream is bound to the primary default output of the Lisp system (e.g. standard output on Unix, SYS$OUTPUT on VMS). While this will probably be an interactive terminal or window during program development, it may well be a data file for a non-interactive application. *INITIAL-QUERY-INPUT* Whenever possible, this stream is bound to an interactive input source. This may be the same as *initial-input* in a development environment, or it may be a separate window, or terminal. If the Lisp system is running under an operating system such as Aegis which provides a separate error input source, this stream should probably be bound to that source. In a non-interactive environment for which no interactive input is available, reading this stream will always result in EOF. *INITIAL-ERROR-OUTPUT* If *initial-query-input* is bound to an interactive input source, this stream should be bound to the cooresponding interactive output destination such that *query-io* will work in the expected way if bound to a two-way stream between these two streams. If the Lisp system is running under an operating system such as Aegis, Unix, or VMS which provides a separate error output destination, this stream should be bound to that destination. In a non-interactive environment without a separate error destination, this stream should be bound to the same destination as *initial-output*. User Streams: *TERMINAL-IO* The initial binding of *terminal-io* is a two-way stream between *initial-input* and *initial-output* unless these streams can be determined to be non-interactive and *initial-query-input* and *initial-error-output* can both be determined to be real interactive streams (e.g. reading *initial-query-input* does not always result in EOF), in which case *terminal-io* is bound to a two-way stream between them. In a windowing environment, *terminal-io* may refer to a different window than *query-io* (and therefore than any of the *initial-foo* streams) as long as all of these streams refer to windows. *STANDARD-INPUT* The initial binding of *standard-input* is *initial-input*. *STANDARD-OUTPUT* The initial binding of *standard-output* is *initial-output*. *ERROR-OUTPUT* The initial binding of *error-output* is *initial-error-output*. *TRACE-OUTPUT* The initial binding of *trace-output* is *initial-error-output* in a non-windowed environment. In a windowed environment, *trace-output* may start out bound in some other way (e.g. to a non-existant trace output window which will be automagically created when output is first done to *trace-output*). *QUERY-IO* Initially bound to a two way stream between *initial-query-input* and *initial-error-output*. *DEBUG-IO* The initial binding of *debug-io* is *initial-error-output* in a non-windowed environment. In a windowed environment, *debug-io* may start out bound in some other way. Test Cases/Examples: (PROGN (PRINT "Output" *STANDARD-OUTPUT*) (PRINT "Error" *STANDARD-ERROR*)) In current Common Lisp will write: ------ Output Error ------ With proposal *might* write: ------ Output ------ and "Error" appears somewhere else. Rationale: This proposal attempts to provide a balance between over-specifying behavior to the point that Lisp programs can't behave like other programs in conventional operating systems and providing enough specification that Common Lisp programs can perform portable input and output including safe rebinding of the standard streams. Current practice: Lucid binds *TERMINAL-IO* to a special internal stream type. Franz binds *TERMINAL-IO* to a special internal stream type for terminal streams which reads from Unix standard input and writes to Unix standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream with input from Unix standard input and output to Unix standard output. Cost to Implementors: All implementations will have to change to some degree but the changes will probably be simple and localized. Most implementations already include some or all of the initial streams as internal stream types so this is largely a documentation and initialization task. Cost to Users: User code which depends on the strict binding hierarchy in CLtL may have to change. Cost of non-Adoption: It will continue to be difficult or impossible to integrate portable Common Lisp progams in conventional operating system environments. Many implementations will have to continue to choose between conforming to the standard and providing a superior user environment. Benefits: Implementations will be more able to match their IO behavior to their environment and their user's expectations. Aesthetics: The four new streams appear to add complexity but they also separate the previous intermixed concepts of initial bindings and standard purpose streams. Discussion: The repeated mention of windowing environments above seems to be getting dangerously close to the environmental issues this standard is supposed to avoid, but Pierson feels that if we have to do more than leave these areas undefined, we also have to give advanced environments official permission to do their thing. FAILNET-ORIGIN<333934.880229@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  A AA A$A,A4A<ADA"LA&TA*\A.dA2lA6tA:|A>  hA > aAA@H] ee2]}Y Hup (2(X 0H ^ ")Hx @ hb keH`,heP0g8h`h`(9(9 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 17:12:28 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Feb 88 13:57:40 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 353104; Mon 29-Feb-88 16:54:04 EST Date: Mon, 29 Feb 88 16:53 EST From: David A. Moon Subject: function-type-rest-list-element To: "AITG::VANROGGEN" , Jon L White , Ram@C.CS.CMU.EDU cc: cl-cleanup In-Reply-To: The message of 24 Feb 88 09:06 EST from "AITG::VANROGGEN" , <8802242144.AA01988@bhopal.lucid.com>, <8802251719.AA05861@bhopal.lucid.com>, Message-ID: <19880229215350.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 24 Feb 88 10:06:00 EDT From: "AITG::VANROGGEN" From: David A. Moon But the analogy to VECTOR is false! (VECTOR element-type) does not mean a vector all of whose current elements are of type element-type. Nor does it mean a vector constrained such that that all elements that can be stored into it are of type element-type. The ambiguous language on CLtL p.47 might lead you to think that's what it means, but CLtL p.45 makes it clear. For declaration, (VECTOR element-type) [via (ARRAY element-type (*))] means a one-dimensional array of the most specialized type that is capable of holding objects of type element-type. Therefore, unless element-type is STRING-CHAR or BIT, or a subtype of one of them, this guarantees exactly nothing about the types of the elements of the vector. Maybe the element-type argument to these type-specifiers should mean something else, but that's what it means in Common Lisp as currently defined. The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. What would you expect to be the type of the result of the following code: (let ((a ...)) (declare (type (vector foo) a)) (aref a 3)) I don't see anything in CLtL that addresses this question. I believe that in every implementation, the result should be of type FOO, for any type FOO. What is discussed on p.45 says that A might not be of type (VECTOR FOO). But this is unrelated to the question of whether the elements of the array have any particular type. Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. I agree that this is a reasonable approach. I don't think CLtL says this, but I don't think it says anything that contradicts it, either. I think this is not too relevant to my point that the (VECTOR FOO) type-specifier does not mean a vector all of whose elements are of type FOO. As you point out, it means that a portable program "should" (in CLtL "is an error" sense) assume that it can only store elements of type FOO into that vector. But I think your proposed meaning for (LIST FOO) was rather stronger. Perhaps I should make my point a different way: I don't think that Common Lisp's current type system for compound types is well enough specified for this kind of extension to work obviously and naturally without exposing problems. I haven't read any clean-up mail, so if you've talked about this issue and resolved it somehow, please tell me. It's been discussed periodically but I don't think it's ever come close to resolution. It's perhaps too large an issue for the Cleanup committee. The problem here is in trying to use lambda-list syntax for describing function calls. Already there's a slight contortion by having the actual keywords be included in the function type for &KEY arguments. So it isn't quite as simple as just taking the real lambda-list, deleting all the init forms and &AUXen, and replacing parameter names with their types. But I think this way of looking at how function type specifiers are derived is easier than starting with just a positional approach (i.e., the second arg, if supplied, has to be of type X, etc.) and then modifying it to also convey number-of-args and keyword information. Thus one would prefer having the type specifier for the &REST argument be the real type specifier for the &REST argument. I agree with you, up to the last sentence, which I can't understand. There isn't such a thing as an "&REST argument" in Common Lisp, unless you mean the last argument to APPLY. If where you said "argument" you meant "parameter", then I understand what you're saying but don't agree with it. One could equally well conclude from the preceding paragraph that the type specifier for the &REST arguments (note the plural) should be the type specifier for each actual argument. Since there isn't a one to one correspondence of arguments to parameters in this one case, the analogy of function type specifiers to lambda-lists doesn't really give us any guidance. I'm being too long-winded here, since I don't even know what these FUNCTION type specifiers are useful for, anyway. My main reason for jumping in was to point out a possible misconception about how strong the VECTOR type specifier is in current Common Lisp. Date: Thu, 25 Feb 88 09:19:28 PST From: Jon L White re: The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. Well, it's true that CLtL pp45-47 are anything but "clear". But what Dave is saying (I think) is that a number of wizards have groveled over those pages and all agree that there is only one interpretation of them consistent with the rest of CLtL. And that interpretaton is at variance with your comments: Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. Perhaps the clearest indicator that CLtL really isn't saying this is found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how this section really is "clear" that an array made by (make-array 5 :element-type '(mod 5)) may legitimately have an element stored into it that is of type (mod 8) but not necessarily of type (mod 5). Well, this is simply another way of stating the root problem here. CLtL isn't sure whether its data types are portable, fairly abstract types or are ways to find out about implementation details. Date: Sat, 27 Feb 1988 21:17 EST From: Ram@C.CS.CMU.EDU Well, I don't agree with VanRoggen's stand on the &rest type issue, but I think he is pretty close to the mark about array types. This isn't inconsistent, since the desirability or feasilibility of a typed list specifier is pretty unrelated to the &rest issue. Not really, since VanRoggen's proposal was to employ a typed list specifier in the resolution of the &rest issue. By the way, I'm not arguing in favor of the way array types currently are defined, I'm just pointing out the facts. If we're now going to redesign array types, I think that's a good idea, or at least an interesting one, but I'll probably limit my contribution to pointing out that it isn't easy, i.e. the obvious trivial fixes don't completely work. The only rationale under which one could store something not (mod 5) into that array would be that they could make the array, then call ARRAY-ELEMENT-TYPE to find out that element types it can actually hold, and then store randomness into it. I don't believe that this is a reasonable thing to do. But someone else might believe that it is. See my comment above that CLtL isn't sure what the goal of the type system is. This basically amounts to bogotifying the language in order to make ARRAY-ELEMENT-TYPE work. This is a bad idea, since I think that the semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the semantics of TYPE-OF. (which is another flame) It is much easier to give types a clean semantics in Common Lisp if ARRAY-ELEMENT-TYPE and TYPE-OF are ignored. For example, without these functions, there would be no way for users to even know that "array element type upgrading" exists. (Assuming the array TYPEP "feature" mentioned in the manual is fixed.) Yes, the semantics would be cleaner if there weren't compound objects, or if there weren't implementation dependencies. No argument about that. I think removing those primitives from the language may be just sweeping the problem under a rug, not solving it, though. Admittedly that would be in the tradition of Common Lisp. FAILMoon function-type-rest-list-element<333860.880229@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  bb\bb\ bb\bb\b&b\b.b\b6b\b>b\#bFb\'bNb\+bVb\/b^b\3bfb\7bnb\;bvb\?b~b\  b 0 bbb@H  < C Hqp (p0H(X= 0 gxDH  g@ t c*`,4 oP8``(9N($;X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Feb 88 15:08:49 EST Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 11:47:20 PST Date: 28 Feb 1988 14:46-EST Sender: MATHIS@A.ISI.EDU Subject: ISO meeting news From: MATHIS@A.ISI.EDU To: x3j13@SAIL.STANFORD.EDU Message-ID: <[A.ISI.EDU]28-Feb-88 14:46:29.MATHIS> Hot news from the ISO-IEC/JTC 1/SC 22/WG 16 Lisp meeting in Paris February 24-25, 1988. The working group decided "The draft standard to be provided by the Working Group within 18 months will take as starting point COMMON LISP (with X3J13 cleanups) with treatment of major issues and default values to be identified (including issues in the AFNOR list and on the agenda)." They also decided on "ISLISP" as the working name of the standard language. There is considerable hope in both X3J13 and this ISO working group that the results of their work match exactly (this will require close cooperation). FAIL ISO meeting newsMATHIS<333232.880228@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOW YN-! A AA A$A,A4A<ADA"LA&TA*\A.dA2lA6tA:|A>  A aAA@H`: 2 lZl`@ Hq=;p (ed(X 0 EH,  4 tx H G@ t  b?Y`,4  NP 8 ` `7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Feb 88 11:16:45 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Feb 88 08:07:33 PST Received: from Salvador.ms by ArpaGateway.ms ; 28 FEB 88 08:08:05 PST From: masinter.pa@Xerox.COM Date: 28 Feb 88 8:07:18 PST Subject: Issue: COERCE-INCOMPLETE To: cl-cleanup@sail.stanford.edu Message-ID: <880228-080805-2138@Xerox> I'm not really back until next week, but this came in for consideration... ---------- Return-Path: <@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET> Received: from RELAY.CS.NET by Xerox.COM ; 25 FEB 88 23:39:52 PST Received: from relay2.cs.net by RELAY.CS.NET id aa07232; 26 Feb 88 2:16 EST Received: from utokyo-relay by RELAY.CS.NET id aa26262; 26 Feb 88 2:06 EST Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET) id AA19019; Fri, 26 Feb 88 15:54:40 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.3Junet-1.0) id AA12493; Fri, 26 Feb 88 15:55:57+0900 Date: Fri, 26 Feb 88 15:55:57+0900 From: Masayuki Ida Return-Path: Message-Id: <8802260655.AA12493@tansei.cc.u-tokyo.junet> To: ida%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET, masinter.pa Subject: Coercion Dear Larry Masinter, I wrote my opinion on coercion which is attached consulting your suggestion on the format. Please find and use if you think it is valuable to have. Masayuki Ida -------------------------------------------------------------------- Issue: Coerce Reference: coerce (CLtL p50) Category: change Edit history: version 1 by M.Ida, 26-Feb-1988 Problem Description: -------------------- Problem 1: Coerce is not symmetric or not generic among data types. In CLtL, Coerce is defined in page 50 and 51 that, 1) a sequence type may be converted to any other sequence type. 2)Some strings, symbols, and integers may be converted to characters. 2-1) If object is a string of length 1, then the sole element of the string is returned. 2-2) If object is a symbol whose print name is of length 1, then the sole element of the print name is returned. 2-3) If object is an integer n, then (int-char n) is returned. 3) any non-complex number can be converted to a XXX-float. 4) any number can be converted to a complex number. The next table shows that how coerce is not symmetric among character, string, symbol and integer. TABLE 1. Possible Conversions among character, string,symbol, integer type of conversion provided functions coercion under the CLtL character -> string string X character <- string coerce (if the string has only one char.) O character -> symbol (intern (string @i[ch])) X character <- symbol coerce (if pname length is 1) O character -> integer char-code, char-int X character <- integer code-char (zero font-, zero bits- attrib.) O int-char (any font- and any bits-) string -> symbol intern, make-symbol X string <- symbol string, symbol-name X string -> integer (char-code (coerce @i[string] 'character)) X string <- integer (string (code-char @i[integer])) X symbol -> integer (char-code (coerce @i[symbol] 'character)) X symbol <- integer (intern (string (code-char @i[integer]))) X Problem 2: The function of coerce for character is defined to act as char-int/int-char not as char-code/code-char. Proposal: Coerce :replace ------------------------- COERCE should be more generalized for string, symbol, integer, and character data types. The observations show there are no problem if extensions are fully written out in the details. Here is an extension to the current coerce definition using the CLOS. (defmethod coerce ((x character) (y (eql string))) (string x)) (defmethod coerce ((x character) (y (eql symbol))) (intern (string x))) (defmethod coerce ((x character) (y (eql integer))) (char-code x)) (defmethod coerce ((x string) (y (eql symbol))) (intern x)) (defmethod coerce ((x symbol) (y (eql string))) (string x)) (defmethod coerce ((x string) (y (eql integer))) (char-code (coerce x 'character))) (defmethod coerce ((x integer) (y (eql string))) (string (code-char x))) (defmethod coerce ((x symbol) (y (eql integer))) (char-code (coerce x 'character))) (defmethod coerce ((x integer) (y (eql symbol))) (intern (sting (code-char x)))) (defmethod coerce ((x integer) (y (eql character))) (code-char x)) ; redefinition. CLtL defines as int-char The keys are a) ignore char-bits and char-font upon the conversion of characters, assuming font-attribute will be flushed from the language spec. b) ignore the package name upon the conversion of symbols. (package name has no role upon the conversion.) c) the created symbol will be interned to the current package. Rationale: ---------- By extending the definition as this document suggests, the functionality of coerce is symmetric among characters, strings, symbols and integers. Current Practice: Cost to implementors: Cost to users: Benefits: Aesthetics: Discussion: Among the functions in Table 1, we can pick up the role of @t[STRING] function. @T[STRING] has odd definition. It was also the starting point of discussions described in the following. The problems or the awkwards are mainly on the design of the symmetry of the function names. We would start the discussion with the following two observations.@* i) @t[(string @i(x))] is OK. But, @t[(coerce @i(x) 'string)] is illegal.@* While, @t[(character @i(x))] is OK. And @t[(coerce @i(x) 'character)] is OK too..@* ii) To convert from a symbol to a string, use @t[SYMBOL-NAME] or @t[STRING]. While, to convert from a string to a symbol, use @t[MAKE-SYMBOL] to an uninterned symbol, or use @t[INTERN] to an interned symbol.@* @* @* @b[ Discussions on Coercion in Common-Lisp E-mails 1986] The awkward were discussed already in Common-lisp E-mails. The author checked the 10M bytes E-mails on disk. The discussions around @t[coerce] were almost in 1986, and not much in 1985 or before. The sequence of our concern started by a mail of fateman@@dali.berkeley.edu, dated Fri, 16 May 1986 15:40 PDT as follows.@* 1) fateman@@dali.berkeley.edu fri 16 may 1986 15:40 PDT:@* This mail describes the same issue as for STRING function. 2) jeff@@aiva.edinburgh.ac.uk sun 18 may 17:17 GMT@* @t[ ... 'string' applied to a sequence of characters gives an error, typically saying the sequence can't be coerced to a string, but 'coerce' will in fact coerce it...] 3) gls@@think.com, Mon 19 may 1986 12:20 EDT@* @begin[t]Research shows that the Common Lisp archives up to a couple of months ago contains 18 messages that mention @t[COERCE]. None explicitly addresses this issue, but the general tone of the messages is one of conservatism. I now remember that this issue was tied up with the design of the sequence functions. There was real resistance to letting symbols be treated as general sequences, and so the general decision was made that string-specific functions would accept symbols, but general sequence functions would not. ...@end[t] To check his talk, @b[3.3] shows all the early discussions on @t[coerce] the author can find. 4) fahlman@@c.cs.cmu.edu Mon, 19 May 1986 20:44 EDT@* @t[... I would not object to generalizing coerce to handle some of the additional cases that people imagine it ought to handle.] @begin[verbatim] 5) cfry@@oz.ai.mit.edu, Tue, 20 May 1986 03:21 EDT@* ... Coercion is a powerful, easy to remember concept. I think it should be extended as much as possible. ... : (coerce #\a 'string) => "a" (coerce 123 'string) => "123" (coerce #\a 'integer) => (char-code #\a) ; explicitly not provided CLtL p52. It appears that the only reason is that no one could decide on using char-code or char-int for the conversion so they chose not to do it at all. This reasoning is odd. Pick the most frequently used way, document it, and permit it. Same argument for coercion of numeric types. Further out extensions might be: (coerce #'foo 'compiled-function) => returns a compiled function object ... (coerce string-1 'pathname) (coerce bit-vector-1 'integer) ... Undoubtedly there are other coercions which would make sense. ... Users would save a lot of manual searching if coerce was extended. @end[verbatim] 6) Eliot@@umass-cs.csnet, Tue 20 May 1986 15:31 EST@* @t[Coercing symbols to stings is fine, as long as NIL is treated as the empty SEQUENCE, rather than as a symbol.] @begin[verbatim] 7) REM@@IMSSS, 19 May 09:34 PST referring to the mail of gls saying that "@t[COERCE] was limited to ... sequence and numerical coercions". This is one of the bad points of many LISPs, including CL, functions that are miss-named or otherwise don't do what you'd expect from their name. ... I hope the international standards committee will fix this kind of problem so programmers reading somebody else's code can have the meaning apparent in most cases form general programming tradition rather than having to constantly check the manual to see if the function does what it seems to say it would do. 8) DCP@@scrc-quabbin.arpa, Wed, 21 May 1986 16:45 EDT,@* Does (coerce @i(symbol) 'string) return (symbol-name @i(symbol)), or (format nil "~S" @i(symbol)), or (format nil "~A::~A" (package-name (symbol-package @i(symbol))) (symbol-name @i(symbol))) or what ? If this weren't enough, added in with my personal views of style and functionality, for me to want to help veto this coercion, the special casing of NIL certainly would. Programs should reflect their meaning. A string is a sequence, a symbol is not. Why shouldn't @# (coerce :ascii-EOT 'integer) work? The answer is that the requested behavior is not a coercion between compatible types, it is a functional translation between human understandable names for the ascii control characters and the integers that are their corresponding values. @end[verbatim] We found that there is a possibility to extend the semantics of @t[coerce] to cope with more generic types. It should be noted that the two key designers of Common Lisp mentioned their opinions, and they do not always be against to the extension. The discussion was stopped at this point and we cannot find their continuation yet. We find from this story that @* 1) If we don't care about the package, we may extend the coerce to the function from a symbol to a string, @* 2) If we are free to care about the font- and bits- attribute, we may extend the coerce to include the function from a character to other types.@* @* @* @b[ Early discussions on coercion] The following sequence was picked up from the archives. They are almost all the meaningful talk the author can find. They were in 1983, one year before @i(CLtL) was published. @begin(verbatim) 1) Guy Steele, dated 27 May 83 01:23:14 EDT, (in the summary of the discussion with DLW and moon upon the laser edition update) a)No.38: it is noted that DLW said "coercing of characters to integers should probably be allowed too." and this point was marked as {controversial}. b) Moon's comment. "if (string x) <=> (coerce x 'string) exactly, say so. Both of these should coerce a character into a 1-element string; neither says so now. The old argument against this, that people might expect string of a number to give not numbers." and Guy Steele agreed. N.197: {gloss} string is required to signal an error if its argument is not a string and not a symbol. This is wrong; it should convert a character to a one-character string. Also it says that string will not convert a sequence of characters into a string, but coerce will. This might be all right, except under coerce it says that when coercing to a string the implementation is allowed to return a more general type. ... Also the coerce writeup doesn't say anything for or against coercing from a character to a 1-long string. {controversial} {will clarify} 2) Fahlman, dated Sat, 28 May 1983 22:34 EDT; At least, I would like you to consider dropping these. ... Page 38: Coercing of characters to integers is not a very useful operation in portable code if the language spec does not specify the correspondence (and Common Lisp does not). Do you still want to propose that we add this coercion? I'm not particularly opposed, I just worry that users will find it too easy to inadvertently do non-portable things if given this coercion. 3) Moon, date: sat, 28 May 1983, 22:40-EDT I don't think coercion of characters to integers should be allowed, because how do you know whether you want the char-code or what. Dan was probably just stuck in our old mindset from not having character objects on the Lisp machine. Coercion of characters to strings, however, I believe is useful. 4) Daniel L.Weinreb, Date: Tuesday, 31 May 1983, 15:40-EDT ... It's OK with me if COERCE doesn't coerce characters to integers. However, I strongly suggest putting in a clarification note to that effect... Or maybe a Rationale note saying that it doesn't because it wouldn't be clear what to do about the char-code versus whole character, and telling you to use the particularly function instead. This note is for the benefit of users more than of implementors. 5) Scott E. Fahlman, Date: Wed, 1 Jun 1983 01:47 EDT < referring 4)> It's OK with me if COERCE doesn't coerce characters to integers. However, I strongly suggest putting in a clarification note to that ... << I assume Guy will do this. >> @end(verbatim) As far as we can see from this talk, that the process of making a coercion between characters and integers be restricted such that char-to-integer conversion is not provided, while integer-to-char is. The coercions from characters to integers are purposely not provided; @t[char-code] or @t[char-int] may be used explicitly to perform such conversions (See @b[Appendix] for the definitions of @t[char-code] and @t[char-int]). The difference between @t(char-int) and @t(char-code) is on the treatment of @i(font) and @i(bits) attributes. If these two attributes have no significant meaning and are ignored by everyone, we can make the story much simpler. (And @b[4.] describes at least font- is not alive). FAILmasinter.pa Issue: COERCE-INCOMPLETE<333185.880228@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  !C !C! C!C$!C,!C4!C<!CD!"CL!&CT!*C\!.Cd!2Cl!6Ct!:C|!>C ! 2 A!!@HS  s"Y Hn]p ()M(X2 0HL (@ t \]l` ,4 QP8``0%(H0Y 2;%CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Feb 88 21:32:24 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 18:18:33 PST Received: ID ; Sat 27 Feb 88 21:17:29-EST Date: Sat, 27 Feb 1988 21:17 EST Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Jon L White Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA, vanroggen%aitg.decnet@HUDSON.DEC.COM Subject: function-type-rest-list-element In-reply-to: Msg of 25 Feb 1988 12:19-EST from Jon L White Well, I don't agree with VanRoggen's stand on the &rest type issue, but I think he is pretty close to the mark about array types. This isn't inconsistent, since the desirability or feasilibility of a typed list specifier is pretty unrelated to the &rest issue. Date: Thursday, 25 February 1988 12:19-EST From: Jon L White To: vanroggen%aitg.decnet at hudson.dec.com [...] Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. Perhaps the clearest indicator that CLtL really isn't saying this is found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how this section really is "clear" that an array made by (make-array 5 :element-type '(mod 5)) may legitimately have an element stored into it that is of type (mod 8) but not necessarily of type (mod 5). No, this example doesn't make it clear. If you make an array :element-type (mod 5), then it is an error to ever store anything in that array that isn't (mod 5). What the example make clear is that implementation has discretion to upgrade the element type. A corollary is that it has discretion to not upgrade the element type. Since a Common Lisp implementation is free to implement whatever specialized array types it pleases, Common Lisp programs must assume that every type potentially has an exact specialization. The only rationale under which one could store something not (mod 5) into that array would be that they could make the array, then call ARRAY-ELEMENT-TYPE to find out that element types it can actually hold, and then store randomness into it. I don't believe that this is a reasonable thing to do. This basically amounts to bogotifying the language in order to make ARRAY-ELEMENT-TYPE work. This is a bad idea, since I think that the semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the semantics of TYPE-OF. (which is another flame) It is much easier to give types a clean semantics in Common Lisp if ARRAY-ELEMENT-TYPE and TYPE-OF are ignored. For example, without these functions, there would be no way for users to even know that "array element type upgrading" exists. (Assuming the array TYPEP "feature" mentioned in the manual is fixed.) Rob FAILRam<332983.880227@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ))  ) ))#)+)3);!)C%)K))S-)[1)c5)k9)s=){  1) > i))@H 6 Q; Hep (1(X)8 0HP $/x @ t% K 5`,4+ P/81`1`CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Feb 88 13:54:15 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 10:46:56 PST Received: by labrea.Stanford.EDU; Thu, 25 Feb 88 10:08:28 PST Received: from bhopal.lucid.com by edsel id AA26191g; Thu, 25 Feb 88 09:13:40 PST Received: by bhopal id AA05861g; Thu, 25 Feb 88 09:19:28 PST Date: Thu, 25 Feb 88 09:19:28 PST From: Jon L White Message-Id: <8802251719.AA05861@bhopal.lucid.com> To: vanroggen%aitg.decnet@hudson.dec.com Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu In-Reply-To: Walter van Roggen's message of Wed 24 Feb 88 10:06:00 EDT Subject: function-type-rest-list-element re: The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. Well, it's true that CLtL pp45-47 are anything but "clear". But what Dave is saying (I think) is that a number of wizards have groveled over those pages and all agree that there is only one interpretation of them consistent with the rest of CLtL. And that interpretaton is at variance with your comments: Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. Perhaps the clearest indicator that CLtL really isn't saying this is found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how this section really is "clear" that an array made by (make-array 5 :element-type '(mod 5)) may legitimately have an element stored into it that is of type (mod 8) but not necessarily of type (mod 5). There was a rather lengthy interchange on this whole topic (about two months ago?) on the Common-Lisp@SU-AI list. One proposal was to require implementations to conform with your comments quoted above, but it certainly didn't seem to have unanimous approval. Someone pointed out that all current implementations do a form of element-type "upgrading" on at least some :element-type specifiers. Try it in VAXLISP, for example, with (SIGNED-BYTE 5) instead of (MOD 5) and see what you get. If you don't have archives of that mail interchange, I'll can arrange to send you a copy personally. -- JonL -- FAILedsel!jonl function-type-rest-list-element<331842.880225@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  LkL LkLLk LLk L"LkL*LkL2LkL:LkLBLk!LJLk%LRLk)LZLk-LbLk1LjLk5LrLk9LzLk=L  jLk  M LkLk@Hg  s}c Hacp ((l(X! 0 _H( $/x @ hd C}:`,hgP0i8j`j`2LVp 04]0* W6Y-b8MvCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 88 18:06:41 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 14:57:43 PST Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 14:19:23 PST Received: from bhopal.lucid.com by edsel id AA22851g; Wed, 24 Feb 88 13:38:35 PST Received: by bhopal id AA01988g; Wed, 24 Feb 88 13:44:20 PST Date: Wed, 24 Feb 88 13:44:20 PST From: Jon L White Message-Id: <8802242144.AA01988@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: vanroggen%aitg.decnet@hudson.dec.com, cl-cleanup@sail.stanford.edu In-Reply-To: David A. Moon's message of Tue, 23 Feb 88 17:12 EST <19880223221249.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: function-type-rest-list-element re: Here's an interesting thought experiment that might shed some light on what the FUNCTION declaration, and the &REST type specifier nested within in, might be for. Suppose you had an implementation ... [with] lambda-list keyword &REST2, which is just like &REST except that the value to which the parameter variable is bound is a stack-allocated object of some implementation-dependent type, and the only legal operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like the standard functions with similar names except that they take one of these funny objects as an argument where the standard functions take a list). The caller of a function doesn't need to know or care whether the function accepts its arguments with &REST or with &REST2. This "gedanken experiment" isn't hypothetical at all. VAX/NIL, one of the predecessors of Common Lisp, actually had &RESTV and &RESTL in addition to &REST. &RESTV guaranteed a stack-allocated VECTOR and, &RESTL guaranteed a heap-allocated list. &REST was left ambiguous just so that the user couldn't know which of the two kinds of structures was being worked upon, and thus couldn't depend upon any accidental properties. But at "flag day", few other CL participants saw any value to cluttering up &rest *lists*. -- JonL -- FAILedsel!jonl function-type-rest-list-element<331461.880224@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWhYN-# C55 5 55!5)5159 5A$5I(5Q,5Y05a45i85q<5y  35  u55@H 6C,: Hith the AI Lab.ap (p0(XfP0SHH* $/x +@ h- C)r`,h0cP0283`3`tt77X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 88 15:05:54 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:40:23 PST Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:55 PST Received: from sunvalleymall.lucid.com by edsel id AA22000g; Wed, 24 Feb 88 11:07:43 PST Received: by sunvalleymall id AA17093g; Wed, 24 Feb 88 11:12:40 PST Date: Wed, 24 Feb 88 11:12:40 PST From: Jan Zubkoff Message-Id: <8802241912.AA17093@sunvalleymall.lucid.com> To: x3j13@sail.stanford.edu Subject: voting at X3J13 X3J13 VOTING LIST for March 1988 meeting Bob's records indicate these groups were represented at the indicated meetings. If they have paid their X3 service fees, they can vote at the meeting in Palo Alto. Company Name Cambridge Ft. Collins ----------------------------------------------------------- A.I. Architectures x Aerospace x Alliant x Bath U. x x CSC x DEC x x Edinbrugh U. x x Encore x Evans and Sutherland x Franz x x Gensym x Gigamos x x GMD x Goldhill x x Gould x Grumman x x Hewlett Packard x x Honeywell x x IBM x x ILOG S.A. x INRIA x Internat. Lisp Assoc. x Johnson Controls x x Lucid x x Mathis x x MCC x x Micro. Sys. Consultants x MIT x Mitre x x NBS x Prime x Red Shark Software x Schlumberger x Sun x Symbolics x x Tektronics x x Texas Instruments x x Thinking Machines x x Unisys x x USC-ISI x Wang x Xerox x x FAILedsel!jlz voting at X3J13<331380.880224@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-#  55 5 55!5)5159 5A$5I(5Q,5Y05a45i85q<5y  5 u55@Hr $ z] Hith the AI Lab.ap (p0Rc(XW0!HH $/x (@ h C(I`,h5P08``0   H[t`X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 88 15:03:47 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:49 PST Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:24 PST Received: from sunvalleymall.lucid.com by edsel id AA21834g; Wed, 24 Feb 88 10:49:37 PST Received: by sunvalleymall id AA17034g; Wed, 24 Feb 88 10:55:36 PST Date: Wed, 24 Feb 88 10:55:36 PST From: Jan Zubkoff Message-Id: <8802241855.AA17034@sunvalleymall.lucid.com> To: x3j13@sail.stanford.edu Subject: X3J13 committee meeting agenda draft DRAFT X3J13 Committee Meeting Agenda March 16 - 17, 1988 1 Call to Order, March 16, 9:00am 2 Opening Remarks and Introductions - Opening Remarks, Bob Mathis - Introduction of attendees - Report on ISO meeting, Dick Gabriel - Future meetings and mailings, Jan Zubkoff 3 Approval of Agenda 4 Approval of Minutes 5 CLOS (Doc: 88-002, 88-003, 88-004), Dick Gabriel, Danny Bobrow, et.al. 6 Lunch, 12:00pm - 1:00pm 7 CLOS continuation 8 Recess, 5:00pm 9 Call to Order, March 17, 9:00am 10 Clean-up, Larry Masinter 11 Lunch 12 Status of Standard, Kathy Chapman; 1 hour 13 Function Specs, JonL White, Steve Haflich, Bob Kearns; 20 minutes 14 Condition System, Kent Pitman; 1 hour 15 Other committee reports 16 Adjournment, 5:00pm FAILedsel!jlz X3J13 committee meeting agenda draft<331372.880224@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-#  55 5 55!5)5159 5A$5I(5Q,5Y05a45i85q<5y  55  u55@H   ,{#{Z Hith the AI Lab.aMp (p05(XgP0 +H$W $/x XY@ h/ C'U`,h2gP0485`5`0899 H[t`X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 88 15:03:02 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:37 PST Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:07 PST Received: from sunvalleymall.lucid.com by edsel id AA21628g; Wed, 24 Feb 88 10:25:19 PST Received: by sunvalleymall id AA16953g; Wed, 24 Feb 88 10:31:18 PST Date: Wed, 24 Feb 88 10:31:18 PST From: Jan Zubkoff Message-Id: <8802241831.AA16953@sunvalleymall.lucid.com> To: x3j13@sail.stanford.edu Subject: Subcommittee meetings Here are the ones I know about. ---jan--- Monday, 3/14 9:00 - 9:30 - 10:00 - CLOS 10:30 - Gabriel 11:00 - Lucid 11:30 - | 12:00 - | 12:30 - | 1:00 - | Characher 1:30 - | Linden 2:00 - | Hyatt Iteration 2:30 - | Delmonte Room White 3:00 - | | Hyatt 3:30 - | | Regency Room 4:00 - | - | 4:30 - | | 5:00 - - - 5:30 - 6:00 - Tuesday, 3/15 9:00 - Character Clean-up 9:30 - Linden Masinter 10:00 - Hyatt | CLOS 10:30 - Delmonte Room | Gabriel 11:00 - | | Lucid 11:30 - | | | 12:00 - | - | 12:30 - | | 1:00 - | Editorial | 1:30 - | Chapman | 2:00 - | Lucid | 2:30 - | | | 3:00 - | - | 3:30 - | | 4:00 - - | 4:30 - | 5:00 - - 5:30 - 6:00 - Friday, 3/18 9:00 - 9:30 - 10:00 - 10:30 - 11:00 - 11:30 - 12:00 - 12:30 - 1:00 - 1:30 - 2:00 - 2:30 - 3:00 - 3:30 - 4:00 - 4:30 - 5:00 - 5:30 - 6:00 - FAILedsel!jlz Subcommittee meetings<331368.880224@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! AJkJ JkJJk JJk J"JkJ*JkJ2JkJ:JkJBJk!JJJk%JRJk)JZJk-JbJk1JjJk5JrJk9JzJk=J  sJk $ K JkJk@HL_&ANNLe{n HawYp (/(X8 0[HP. $/x X/@ tg BwH`,4m 8Pq8s`s`cmu.eccvb-----------------------------------CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 88 13:20:44 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 10:13:28 PST Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:10 PST Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88 10:03:43 PST Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST Date: Wed, 24 Feb 88 10:09:26 PST From: Jon L White Message-Id: <8802241809.AA26979@bhopal.lucid.com> To: Masinter.pa@xerox.com Cc: sandra%orion@cs.utah.edu, cl-cleanup@sail.stanford.edu In-Reply-To: Masinter.pa@Xerox.COM's message of 19 Feb 88 14:17 PST <880219-141733-9723@Xerox> Subject: FUNCTION-TYPE:STRICT-REDEFINITION proposal re: I intended not to require that it not be a "proper" subtype in the sense that there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP. Lucid Common Lisp distinguishes "compiled" closures which exist for the purpose of supporting entry into the interpreter from functions which are truly compiled. It only takes a bit in a header word. If an implementation really doesn't support an interpreter, then having every function be COMPILED-FUNCTIONP doesn't sound like much of a loss. But most implementations in fact do support an interpreter -- which typically runs code at anywhere from 30 to 600 times slower than when compiled. Thus it seems reasonable to require COMPILED-FUNCTIONP in those implementations to be false on, say, (eval '#'(lambda (x) (list x))) no matter what underlying technique is used to support interpreter closures. -- JonL -- FAILedsel!jonl FUNCTION-TYPE:STRICT-REDEFINITION proposal<331328.880224@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  HkH HkHHk HHk H"HkH*HkH2HkH:HkHBHk!HJHk%HRHk)HZHk-HbHk1HjHk5HrHk9HzHk=H  Hk > I HkHk@H& #T Ha$p ( (XZH 0H(H Ox @ t B%`,4 SP8``(dM($1CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 88 10:24:14 EST Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 88 07:15:01 PST Date: 24 Feb 88 10:06:00 EDT From: "AITG::VANROGGEN" Subject: RE: function-type-rest-list-element To: "cl-cleanup" cc: vanroggen Reply-To: "AITG::VANROGGEN" From: David A. Moon But the analogy to VECTOR is false! (VECTOR element-type) does not mean a vector all of whose current elements are of type element-type. Nor does it mean a vector constrained such that that all elements that can be stored into it are of type element-type. The ambiguous language on CLtL p.47 might lead you to think that's what it means, but CLtL p.45 makes it clear. For declaration, (VECTOR element-type) [via (ARRAY element-type (*))] means a one-dimensional array of the most specialized type that is capable of holding objects of type element-type. Therefore, unless element-type is STRING-CHAR or BIT, or a subtype of one of them, this guarantees exactly nothing about the types of the elements of the vector. Maybe the element-type argument to these type-specifiers should mean something else, but that's what it means in Common Lisp as currently defined. The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. What would you expect to be the type of the result of the following code: (let ((a ...)) (declare (type (vector foo) a)) (aref a 3)) I believe that in every implementation, the result should be of type FOO, for any type FOO. What is discussed on p.45 says that A might not be of type (VECTOR FOO). But this is unrelated to the question of whether the elements of the array have any particular type. Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. I haven't read any clean-up mail, so if you've talked about this issue and resolved it somehow, please tell me. There's no reason why someone might not write a function type specifier with &REST being a supertype of LIST. It just can't conflict with LIST. Yes, but I don't see what that could be useful for. I was just referring to the statement in the first paragraph of the Discussion: "the &REST argument declaration, if any, always be LIST or a subtype of LIST..." Here's an interesting thought experiment that might shed some light on what the FUNCTION declaration, and the &REST type specifier nested within in, might be for. Suppose you had an implementation that thought materializing &REST arguments as lists was too inefficient, especially if you didn't bother to do the (fairly simple) flow analysis needed to figure out that the list has dynamic extent and doesn't have to be consed in the heap. So in your implementation, you made a new lambda-list keyword &REST2, which is just like &REST except that the value to which the parameter variable is bound is a stack-allocated object of some implementation-dependent type, and the only legal operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like the standard functions with similar names except that they take one of these funny objects as an argument where the standard functions take a list). The caller of a function doesn't need to know or care whether the function accepts its arguments with &REST or with &REST2. If the FUNCTION declaration is for the benefit of callers, then the FUNCTION declaration should be independent of whether the callee is written with &REST or with &REST2. From this I conclude that the &REST type specifier nested within a FUNCTION declaration shouldn't say anything about lists. One can't expect people to write function type specifiers in Common Lisp with knowledge about the particular implementation's lambda-list- keywords. So I agree with you there. But it's the only thing one could write. Indeed, there might not be any relationship between the lambda-list in a function type specifier and the real lambda-list. (proclaim '(ftype (function (&key (:key1 integer :key2 string)) ...) f)) (defun f (&optional k1 v1 k2 v2) ...) should be OK if F is always called (F :KEY2 x) and the like. Presumably the reason for having lambda-list-keywords in function type specifiers is to indicate the range of number of arguments permissible. The problem here is in trying to use lambda-list syntax for describing function calls. Already there's a slight contortion by having the actual keywords be included in the function type for &KEY arguments. So it isn't quite as simple as just taking the real lambda-list, deleting all the init forms and &AUXen, and replacing parameter names with their types. But I think this way of looking at how function type specifiers are derived is easier than starting with just a positional approach (i.e., the second arg, if supplied, has to be of type X, etc.) and then modifying it to also convey number-of-args and keyword information. Thus one would prefer having the type specifier for the &REST argument be the real type specifier for the &REST argument. ---Walter ------ FAILvanroggen%aitg.decnet RE: function-type-rest-list-element<331234.880224@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  WF׍ WF׍WF ׍WF ׍#WF׍+WF׍3WF׍;WF׍CWF!׍KWF%׍SWF)׍[WF-׍cWF1׍kWF5׍sWF9׍{WF=׍  WF < WfWFWF@How  v~~ H^%p (p0(X]`0HH $/@ h <'%` ,hP08 ` `%spiccmu.eccvb-----------------------------------X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Feb 88 19:31:22 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:37:54 PST Received: by labrea.Stanford.EDU; Tue, 23 Feb 88 14:57:40 PST Received: from sunvalleymall.lucid.com by edsel id AA17257g; Tue, 23 Feb 88 14:09:49 PST Received: by sunvalleymall id AA15130g; Tue, 23 Feb 88 14:15:41 PST Date: Tue, 23 Feb 88 14:15:41 PST From: Jan Zubkoff Message-Id: <8802232215.AA15130@sunvalleymall.lucid.com> To: jima@mitre.arpa Cc: MATHIS@a.isi.edu, x3j13@sail.stanford.edu, jima@mitre.arpa, edsel!jlz@labrea.Stanford.EDU In-Reply-To: jima@mitre.arpa's message of Tue, 23 Feb 88 15:59:23 EST <8802232059.AA18904@mitre.arpa> Subject: voting I sent the original message on December 14 but it looks like it's time for a reminder. Agenda, subcommitte meeting (that I have arranged) and voting list to follow later this week. ---jan--- X3J13 Meeting and Subcommitte meetings 3/14/88 - 3/18/88 Palo Alto, CA The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16, 1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo Alto, CA. The meeting will be held in the Executive Conference Room. Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and Friday, March 18. Please let me know if and when your subcommittee will be meeting in Palo Alto in March. I need to reserve small rooms now if they're necessary. In the interest of saving money, if you have a subcommittee member who is local perhaps the meeting could be held at their company. For example: the CLOS subcommittee will meet at Lucid Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is yet to be determined. A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a night (plus tax). A limited number of rooms are available for non-smokers. Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive the discounted rate. Be sure to mention "X3J13 Standards Committee". Before I call and get special airline fares I'd like to know if anyone has found this to be useful. If I get no replies I'll assume it's not necessary to set up special fares. Refreshments will be available during the morning (8:00am) and afternoon sessions. Lunch will be available Wednesday, March 16 and Thursday, March 17. If you have dietary restrictions please complete the appropriate section below. The cost per person for food service and conference room rental is $55.00. Please include a check for this amount, payable to Lucid, with the registration form. I will be happy to arrange a group dinner for Wednesday, March 16. Someone has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go hot tubbing afterwards at (combined fee of around $25) If interested, please note this in the appropriate space below. N San Francisco Airport W E | S | | 101 ------------------------------------------92 | | | | | | | | | | 101 Foothills | | San Francisco Bay | | | | |X Hyatt Rickeys | | | |El Camino Real | | | Los Altos ----------------------------------------San Antonio Road | | | | San Jose Airport ! Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to San Antonio Road (about 25 minutes in non-rush hour traffic). Take San Antonio Road exit marked Los Altos, heading toward the hills. Turn right on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-8000. Hertz, Avis and National car rentals are within 1 block. Directions from San Jose airport: Take 101 north to San Antonio Road (about 15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los Altos, heading toward the hills. Turn right on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-8000. A shuttle service is available though Airport Connection for $12.00. Pickup points are located directly outside each terminal baggage claim area at the center traffic island. Shuttle will stop at each blue striped pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys. The schedule from San Francisco Airport to Palo Alto follows: * * LV Menlo Stan- Palo Sunny- San ARR SFO Park ford Alto vale Jose SJC 7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily 8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat 9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily 11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat 12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily 1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat 2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily 3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat 4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily 5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat 6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily 8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat 10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily Shuttle service from Palo Alto to San Francisco Airport: * * LV SJC Sunny- Palo Stan- Menlo AR San Jose vale Alto ford Park SFO 5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily 6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat 7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily 8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat 9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily 10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat 12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily 1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat 2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily 3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat 4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily 6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat 8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily Feel free to contact me if you have any questions. Jan Zubkoff Lucid, Inc. 707 Laurel Street Menlo Park, CA 94025 edsel!jlz@labrea.stanford.edu (415) 329-8400 ! X3J13 March Meeting Registration Form Please include check for $55.00 payable to Lucid mail to: Jan Zubkoff Lucid, Inc. 707 Laurel Street Menlo Park, CA 94025 (415) 329-8400 *Feel free to bring check to meeting but please let me know if you will be attending. ! Name: _____________________________________________________________ Institution: ______________________________________________________ Street Address: ___________________________________________________ City: ________________ State: ___ Phone: ________________________ Net-Address: ______________________________________________________ Lunch 3/18: yes _______ no _______ Lunch 3/17: yes _______ no _______ Dietary Restrictions:_______________________________________________ Sushi Dinner 3/16: yes ______ something else ______ Hot tubbing 3/16: yes ______ something else ______ Set up special airline fares: yes _______ no _______ Subcommittee Name: _________________________________________________ Subcommittee Chair: ________________________________________________ ____ We need a meeting room ____ We will be meeting at _________________________________________ FAILedsel!jlz<330957.880223@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  FKF FKFFK FFK F"FKF*FKF2FKF:FKFBFK!FJFK%FRFK)FZFK-FbFK1FjFK5FrFK9FzFK=F  $FK FkFKFK@H <  :u { H]Qp (9(X? 03H  ")Hx 5@ h ;u'`,h!EP0#8$`$` M")H0O0PCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Feb 88 17:23:52 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Feb 88 14:14:01 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349602; Tue 23-Feb-88 17:13:00 EST Date: Tue, 23 Feb 88 17:12 EST From: David A. Moon Subject: function-type-rest-list-element To: "AITG::VANROGGEN" cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: The message of 23 Feb 88 13:07 EST from "AITG::VANROGGEN" Message-ID: <19880223221249.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 23 Feb 88 14:07:00 EDT From: "AITG::VANROGGEN" We oppose the proposal FUNCTION-TYPE-REST-LIST-ELEMENT: USE-ACTUAL-ARGUMENT-LIST. We feel that although specifying the element type in a function type specifier is slightly more convenient, it is outweighed by its inconsistency and lack of expressiveness. If specifying the element type of lists is an important issue, and we think it is, then we should extend the LIST type to be a list type: (LIST [ []]) just like for VECTOR. In fact, it would also be wise to extend SEQUENCE in the same way. But the analogy to VECTOR is false! (VECTOR element-type) does not mean a vector all of whose current elements are of type element-type. Nor does it mean a vector constrained such that that all elements that can be stored into it are of type element-type. The ambiguous language on CLtL p.47 might lead you to think that's what it means, but CLtL p.45 makes it clear. For declaration, (VECTOR element-type) [via (ARRAY element-type (*))] means a one-dimensional array of the most specialized type that is capable of holding objects of type element-type. Therefore, unless element-type is STRING-CHAR or BIT, or a subtype of one of them, this guarantees exactly nothing about the types of the elements of the vector. Maybe the element-type argument to these type-specifiers should mean something else, but that's what it means in Common Lisp as currently defined. VAX LISP has always made use of FUNCTION type specifiers, although it has ignored the &REST and &KEY type information. There's no reason why someone might not write a function type specifier with &REST being a supertype of LIST. It just can't conflict with LIST. Yes, but I don't see what that could be useful for. Here's an interesting thought experiment that might shed some light on what the FUNCTION declaration, and the &REST type specifier nested within in, might be for. Suppose you had an implementation that thought materializing &REST arguments as lists was too inefficient, especially if you didn't bother to do the (fairly simple) flow analysis needed to figure out that the list has dynamic extent and doesn't have to be consed in the heap. So in your implementation, you made a new lambda-list keyword &REST2, which is just like &REST except that the value to which the parameter variable is bound is a stack-allocated object of some implementation-dependent type, and the only legal operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like the standard functions with similar names except that they take one of these funny objects as an argument where the standard functions take a list). The caller of a function doesn't need to know or care whether the function accepts its arguments with &REST or with &REST2. If the FUNCTION declaration is for the benefit of callers, then the FUNCTION declaration should be independent of whether the callee is written with &REST or with &REST2. From this I conclude that the &REST type specifier nested within a FUNCTION declaration shouldn't say anything about lists. FAILMoon function-type-rest-list-element<330896.880223@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  FkF FkFFk FFk F"FkF*FkF2FkF:FkFBFk!FJFk%FRFk)FZFk-FbFk1FjFk5FrFk9FzFk=F _Fk 4 G FkFk@HH < J(HHx, H]p (p0n(X2P0 Vx0H PX@ hY ;] ` ,h\P0^8_`_`8Mv 7aPP2LVp 04]0* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Feb 88 16:57:12 EST Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 23 Feb 88 13:06:28 PST Full-Name: Jim Antonisse Message-Id: <8802232059.AA18904@mitre.arpa> Organization: The MITRE Corp., Washington, D.C. To: MATHIS@A.ISI.EDU Cc: x3j13@SAIL.STANFORD.EDU, jima@mitre.arpa Subject: Re: voting In-Reply-To: Your message of 26 Jan 88 14:06:00 -0500. <[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS> Date: Tue, 23 Feb 88 15:59:23 EST From: jima@mitre.arpa Bob, Where exactly *is* the March X3j13 meeting? Does anyone have details of location, registration fee, etc., figured out yet? I'll be travelling for the week before it so I'd like to make all arrangements soon. Thanks, Jim Antonisse MITRE FAIL Re: voting NET-ORIGIN<330867.880223@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  DKD DKDDK DDK D"DKD*DKD2DKD:DKDBDK!DJDK%DRDK)DZDK-DbDK1DjDK5DrDK9DzDK=D  >DK 6 DkDKDK@HFc  IH;Fi| H]p ((X 0cH(2 Ox i@ h8 ;u`,h;yP0=8>`>`cmu.eccvb-----------------------------------CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Feb 88 14:25:40 EST Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:14:22 PST Date: 23 Feb 88 14:07:00 EDT From: "AITG::VANROGGEN" Subject: function-type-rest-list-element To: "cl-cleanup" cc: vanroggen Reply-To: "AITG::VANROGGEN" We oppose the proposal FUNCTION-TYPE-REST-LIST-ELEMENT: USE-ACTUAL-ARGUMENT-LIST. We feel that although specifying the element type in a function type specifier is slightly more convenient, it is outweighed by its inconsistency and lack of expressiveness. If specifying the element type of lists is an important issue, and we think it is, then we should extend the LIST type to be a list type: (LIST [ []]) just like for VECTOR. In fact, it would also be wise to extend SEQUENCE in the same way. VAX LISP has always made use of FUNCTION type specifiers, although it has ignored the &REST and &KEY type information. There's no reason why someone might not write a function type specifier with &REST being a supertype of LIST. It just can't conflict with LIST. The statement in the discussion favoring USE-ACTUAL-ARGUMENT-TYPE referring to ``the weight of current practice'' itself doesn't have any weight when previous statements say that function type specifiers are in limited use and that most implementations ignore them--there is no ``current practice''. We agree with Kent Pitman's first two comments (at the end of the Discussion section), but don't understand his last one. ---Walter ------ FAILvanroggen%aitg.decnet function-type-rest-list-element<330772.880223@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  DKD DKDDK DDK D"DKD*DKD2DKD:DKDBDK!DJDK%DRDK)DZDK-DbDK1DjDK5DrDK9DzDK=D  rDK 6 DkDKDK@Hc   i~ H]}p (a(X# 0H(g Ox \@ hl ;N`,hoP0q8r`r`cmu.eccvb-----------------------------------CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Feb 88 14:25:02 EST Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:15:33 PST Date: 23 Feb 88 14:06:00 EDT From: "AITG::VANROGGEN" Subject: compiler-warning-break To: "cl-cleanup" cc: vanroggen Reply-To: "AITG::VANROGGEN" The proposal COMPILER-WARNING-BREAK:YES leaves a lot of issues unresolved. As it stands we must oppose the proposal. The principal problem is that it isn't clear what warnings are. Currently VAX LISP distinguishes between two different kinds of ``error conditions'': ones signalled during compilation with ERROR, CERROR, WARN, and the like, and ones detected by the compiler from examination of the source code being compiled. The former arise in cases like (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A))) or when READ encounters an error while reading a form from the file. However, when this happens during a COMPILE-FILE, we try to continue with the compilation, so as to maximize the usefulness and information generated by the compiler. During COMPILE, the normal error signalling and handling is in effect, so *BREAK-ON-WARNINGS* would indeed control ``breaking'' upon WARN. The latter arise when the compiler is compiling a form like (SEARCH X) or (LET 3 (F)) Then we also distinguish these cases by how serious they are. In particular there are ``errors'' and ``warnings''. However, detecting these anomalies is expected of the compiler, and thus they are not treated as ``errors'' or ``warnings'' in the sense of the lisp functions ERROR or WARN. It doesn't make sense to ``break'' and go into the debugger if the compiler happens to see a variable that was bound but was unused (with no IGNORE declaration). So it isn't clear from the proposal which of these cases are being addressed. If it's really more to control what happens when one does a COMPILE, then the proposal should be changed to say that COMPILE-FILE is not specified as proposed, and what conditions should be reported as being ``warnings'' should be specified. ---Walter ------ FAILvanroggen%aitg.decnet compiler-warning-break<330770.880223@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  rr5 rr5r r5rr5$rr5,rr54rr5r5  Kr  r:rr@Ht3 6 vsuwt? HMp (C(X 01HX 4 tx 5@ t? ~`,4E $PI8K`K` <(yt{}R CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Feb 88 17:42:31 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88 14:34:11 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST Date: 19 Feb 88 14:17 PST From: Masinter.pa@Xerox.COM Subject: Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 16 Feb 88 10:39:02 MST To: sandra%orion@cs.utah.edu cc: cl-cleanup@sail.stanford.edu Message-ID: <880219-141733-9723@Xerox> "Sections 1a and 6 of this proposal refer to the PROCEDURE type. I assume this is really supposed to be the FUNCTION type?" Yes, looks like a typo on my part. "Also, I have a question about 1b, where it states that COMPILED-FUNCTION is a subtype of FUNCTION. Does this imply that it must be a *proper* subtype? For example, in the Lisp I've been working on sporadically for my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a compiled function object (it's a closure which will apply the lambda expression to the function arguments). Likewise I can conceive of implementations which compile everything and don't have an "interpreter" at all. I think this needs to be clarified." I intended not to require that it not be a "proper" subtype in the sense that there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP. This can be clarified. FAILMasinter.pa Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal<329198.880219@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  C0"C 0" C0" C0"C#0"C+0"C30"C;0"!CC0"%CK0")CS0"-C[0"1Cc0"5Ck0"9Cs0"=C{0"  C CC@H1g < 42r1m3 HE)p (3(X 0 HT Ox @ t  ,N`,4 P8``0J%(HK0LU M%CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Feb 88 15:13:24 EST Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 17 Feb 88 11:59:26 PST Date: 17 Feb 88 14:58:00 EDT From: "AITG::VANROGGEN" Subject: two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE To: "cl-cleanup" cc: vanroggen Reply-To: "AITG::VANROGGEN" Before I send more mail, let me state that I have not been following the cleanup subcommittee mail, so I may be repeating previous arguments. I'm not on the cl-cleanup mailing list, either, btw. The comment about what VAX LISP does for DISASSEMBLE-SIDE-EFFECT is incorrect; we don't modify the function cell of the symbol if the function is interpreted. I think we changed the behavior when the mail about this issue first came up, which was several years ago. DRIBBLE-TECHNIQUE: For a while the way we implemented DRIBBLE made it impossible to have nested DRIBBLEs. We fixed this problem many years ago, but at the time a suggested error message was: No double dribbling allowed. ---Walter ------ FAILvanroggen%aitg.decnet two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE<328033.880217@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  mjm mjmmj mmj m"mjm*mjm2mjm:mjmBmj!mJmj%mRmj)mZmj-mbmj1mjmj5mrmj9mzmj=m  mj  n mjmj@Hoi 4 qpo:3 HDp (p0(XO0 H(  $/x p @ t K`,4 P8``#%%X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Feb 88 00:46:36 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 21:22:35 PST Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 21:21:45 PST Received: from bhopal.lucid.com by edsel id AA05999g; Tue, 16 Feb 88 21:07:02 PST Received: by bhopal id AA02339g; Tue, 16 Feb 88 21:12:15 PST Date: Tue, 16 Feb 88 21:12:15 PST From: Jon L White Message-Id: <8802170512.AA02339@bhopal.lucid.com> To: edsel!jlz@labrea.Stanford.EDU Cc: x3J13@sail.Stanford.EDU In-Reply-To: Jan Zubkoff's message of Tue, 16 Feb 88 10:21:23 PST <8802161821.AA28197@sunvalleymall.lucid.com> Subject: March 1988 agenda questions The four of us -- smh, rwk, jonl, and rg -- have an issue that needs more time than a few minutes of cleanup committee covering: the extension of names for definitions (sometimes referred to as "function specs"). Steve (Haflich) has the problem description and issues written down, and Bob (Kerns) has a proposed implementation. It would probably take 10 minutes to present the issue, and conceivably would be met by 5-20 minutes of unmitigated flaming from the floor after it is presented. -- JonL -- FAILedsel!jonl March 1988 agenda questions<327741.880217@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ~y ~y~y ~y!~y)~y1~y9~y A~y$I~y(Q~y,Y~y0a~y4i~y8q~y<y~y    1@Hp  rqp HAmp ((X, 0H@a 4 tx hb@ t "`,4 kP8``\i\i0hxiCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Feb 88 14:48:22 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Feb 88 11:39:05 PST Received: from Salvador.ms by ArpaGateway.ms ; 16 FEB 88 11:33:51 PST Date: Tue, 16 Feb 88 11:33:48 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: FORMAT-COMMA-INTERVAL (Version 2) In-reply-to: <880215-171422-2360@Xerox> To: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880216-113351-3592@Xerox> Grumble. Yeah, I guess Andy's right and the example is bogus. The only way I can see to get what I wanted is to specify that the padding gets commas inserted into it if and only if the padchar is a digit in the output base. This is highly gross, however, so I guess I won't push it. I guess we should just remove the offending example. Sigh. That example was one of the better uses for the facility, too... Pavel FAILPavel.pa Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)<327413.880216@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  222 2 22 222"22*22222:2!2B2%2J2)2R2-2Z212b252j292r2=2z2  f2 " 2Y22@H3 < 5413TxO HAp (p0(X5p0HH\ $/x `]@ h` `,hcP0e8f`f`0ijj* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Feb 88 14:02:05 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 10:45:00 PST Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 10:45:09 PST Received: from sunvalleymall.lucid.com by edsel id AA03090g; Tue, 16 Feb 88 10:16:15 PST Received: by sunvalleymall id AA28197g; Tue, 16 Feb 88 10:21:23 PST Date: Tue, 16 Feb 88 10:21:23 PST From: Jan Zubkoff Message-Id: <8802161821.AA28197@sunvalleymall.lucid.com> To: x3j13@sail.stanford.edu Subject: March 1988 agenda questions I would like to prepare the agenda next week. If you have something that should be discussed or voted on at the March meeting please let me know what it is, the Document number (if any) and approximate time needed. Thanks! ---jan--- FAILedsel!jlz March 1988 agenda questions<327377.880216@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  {->{ -> {-> {->{#->{+->{3->{;->!{C->%{K->){S->-{[->1{c->5{k->9{s->={{->  { < {{@H^; & `[_^Az HAg!p (wk(X 0 HP@ h gs` ,h P0 8 ``k,m08 9Psw0<CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Feb 88 12:46:08 EST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88 09:39:23 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA23751; Tue, 16 Feb 88 10:39:08 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA25191; Tue, 16 Feb 88 10:39:04 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8802161739.AA25191@orion.utah.edu> Date: Tue, 16 Feb 88 10:39:02 MST Subject: FUNCTION-TYPE:STRICT-REDEFINITION proposal To: cl-cleanup@sail.stanford.edu Sections 1a and 6 of this proposal refer to the PROCEDURE type. I assume this is really supposed to be the FUNCTION type? Also, I have a question about 1b, where it states that COMPILED-FUNCTION is a subtype of FUNCTION. Does this imply that it must be a *proper* subtype? For example, in the Lisp I've been working on sporadically for my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a compiled function object (it's a closure which will apply the lambda expression to the function arguments). Likewise I can conceive of implementations which compile everything and don't have an "interpreter" at all. I think this needs to be clarified. -Sandra ------- FAILNET-ORIGIN<327343.880216@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! A*g* *g**g **g *"*g***g*2*g*:*g*B*g!*J*g%*R*g)*Z*g-*b*g1*j*g5*r*g9*z*g=*  *g  +*g*g@H+l&A.,3+rwC H>(p ((X 0}HP? 4 tx h@@ t |)n`,4 IP8``7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 19:39:39 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 16:34:29 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 88 16:30:38 PST Date: 15 Feb 88 16:29 PST From: Daniels.pa@Xerox.COM Subject: Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3) In-reply-to: Masinter.pa's message of 14 Feb 88 11:37 PST To: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880215-163038-2296@Xerox> The rationale contains a type: DO-PACKAGE for DO-SYMBOLS. -- Andy. -- FAILDaniels.pa Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3)<327088.880215@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  *g* *g**g **g *"*g***g*2*g*:*g*B*g!*J*g%*R*g)*Z*g-*b*g1*j*g5*r*g9*z*g=*  *g  +*g*g@H,  .-, H=myp (#C(X 0 H( @ t  zn4` ,4  P8 ``04 4 +4 -CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 12:59:40 EST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:54:11 PST Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA06452; Mon, 15 Feb 88 09:54:37 PST Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2) id AA15221; Mon, 15 Feb 88 09:46:52 PST Received: by clam.sun.com (3.2/SMI-3.2) id AA10068; Mon, 15 Feb 88 09:55:43 PST Date: Mon, 15 Feb 88 09:55:43 PST From: cperdue@Sun.COM (Cris Perdue) Message-Id: <8802151755.AA10068@clam.sun.com> To: edsel!eb@labrea.Stanford.EDU Subject: Re: make-lexical-environment Cc: CommonLoops.PA@xerox.com, cl-cleanup@sail.stanford.edu Just a further note. CLtL, p. 322, does say that the values passed as the last argument to eval hook functions (or apply hook functions) "are suitable for the functions evalhook, applyhook, and macroexpand". This in turn means that these arguments are suitable as the second argument to a macro expander function. (See the discussion of macroexpand.) I guess I don't see anything that implies that all environment objects acceptable to macro expander functions have to be acceptable to evalhook, though the idea is attractive. -Cris FAILNET-ORIGIN<326955.880215@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  *g* *g**g **g *"*g***g*2*g*:*g*B*g!*J*g%*R*g)*Z*g-*b*g1*j*g5*r*g9*z*g=*  *g  +*g*g@H-#  /C/-) H=ap ((X%x 0H@v $/x Hw@ t zb `,4 ~P8``cmu.eccvb-----------------------------------CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 12:34:38 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:28:02 PST Received: by labrea.Stanford.EDU; Mon, 15 Feb 88 09:28:18 PST Received: from kent-state.lucid.com by edsel id AA28423g; Mon, 15 Feb 88 09:15:40 PST Received: by kent-state id AA08272g; Mon, 15 Feb 88 09:20:16 PST Date: Mon, 15 Feb 88 09:20:16 PST From: Eric Benson Message-Id: <8802151720.AA08272@kent-state.lucid.com> To: cperdue@sun.com Cc: CommonLoops.PA@xerox.com, cl-cleanup@sail.stanford.edu In-Reply-To: Cris Perdue's message of Sun, 14 Feb 88 16:10:03 PST <8802150010.AA09197@clam.sun.com> Subject: make-lexical-environment Redistributed: CommonLoops.PA Date: Sun, 14 Feb 88 16:10:03 PST From: cperdue@sun.com (Cris Perdue) Is the following code adequate for make-lexical-environment (compared with the code in walk.lisp), and if not, is it inadequate for a good reason related to the definition of Common Lisp, or just because implementation quirks of some Lisps? This code is certainly a bit simpler. (defmacro current-env (&environment e) `',e) (defun make-lexical-environment (form env) (evalhook `(,(first form) ,(second form) ; Local macro defns () ; No declarations, though according to the ; PCL comments, they are illegal here. (current-env)) ; body of the macrolet nil nil env)) Thanks for any info on this. -Cris In some Common Lisp implementations, the environments used in EVALHOOK and those used in MACROEXPAND are not compatible. This code would take an existing EVALHOOK environment and return a MACROEXPAND environment. The result could not be passed to EVALHOOK again. Furthermore, some implementations allocate environment objects on the stack, so returning that object from CURRENT-ENV would result in garbage. You are probably correct in your assessment that these are "implementation quirks of some Lisps" and not intrinsic to the Common Lisp standard. The operative phrase in CLtL is "The hook feature is provided as an aid to debugging." EVALHOOK (unlike MACROEXPAND) is part of the programming environment rather than part of the programming language. This issue should be addressed by the cleanup committee. FAILedsel!eb make-lexical-environment<326938.880215@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOW YN-!  R R R R #R +R 3R ;R! CR% KR) SR- [R1 cR5 kR9 sR= {R    M  @H\\  f|fTu H:Ep (p0 b(X0 oH,  4 tx P q@ t  tK`,4  zP 8 ` `ues dbutedthe M1988  meet - T-ARRSPLAC (VerX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 18:21:23 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:54:40 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:55:15 PST Date: 14 Feb 88 14:54 PST From: Masinter.pa@Xerox.COM Subject: Common Lisp cleanup issue status to X3J13 To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-145515-1510@Xerox> ! This is the list of issues distributed for the March 1988 X3J13 meeting: - ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87) (Interaction of ADJUST-ARRAY and displaced arrays) - APPEND-DOTTED (Version 5, 14-Jan-88) (What happens to CDR of last CONS? in other than last arg?) - AREF-1D (Version 7, 14-Nov-87) (Add a new function for accessing arrays with row-major-index) Version 5 conditionally passed X3J13/Jun87 Version 7 passed X3j13/Nov87 - ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87) (Extend ASSOC-IF, etc. to allow :KEY) - COLON-NUMBER (Version 1, 22-oct-87) (Is :1 a number, a symbol, or undefined?) Version 1 passed X3J13/Nov87 - COMPILER-WARNING-BREAK (Version 4,23-Nov-87 ) (Does *BREAK-ON-WARNING* affect the compiler?) - DECLARE-MACROS (Version 3, 5-FEB-88) (Disallow macros expanding into declarations.) - DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87) (Documentation string is not evaluated.) - DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88) (DISASSEMBLE doesn't smash the def if not compiled) - DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87) ( DO-SYMBOLS can the same symbol twice?) - DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88) (dribble can't be used programmatically) - FLET-DECLARATION (Version 2, 2 Feb 88) (Allow declarations in FLET, MACROLET) - FORMAT-COMMA-INTERVAL (Version 2, 15 June 87) (paramerize number of digits between commas) Version 2 passed X3J13/Nov87 - FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88) (what iteration does ~:^ exit from?) - FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88) (allow &KEY (:KEYNAME type)) in FUNCTION decls ) - FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88) (allow &rest in function types to refer to element type) - FUNCTION-TYPE (Version 9, 13-Feb-88) (Change definition of FUNCTIONP, function type ...) - GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87) (Environment argument for GET-SETF-METHOD) Version 4 conditionally passed X3J13/Jun87. Version 5 passed X3J13/Nov87. - KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87) (&KEY arguments not in keyword package?) Version 6 conditionally passed X3J13/Jun87. Version 8 passed X3J13/Nov87 - PATHNAME-STREAM (Version 6, 14-Nov-87) (PATHNAME only works on file streams) Version 2 conditionally passed X3J13/Jun 87 Version 6 passed X3J13/Nov 87 - PATHNAME-SYMBOL (Version 5, 5-Feb-88) (Do symbols automaticly coerce to pathnames?) - PUSH-EVALUATION-ORDER (Version 5,25-Nov-87) (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?) - REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88) (Add :KEY to REDUCE) - SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87) (Allow (DEFUN (SETF FOO) ..)) - SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88) (let FIND, SUBSTITUTE etc work on multi-dimensional arrays) - SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43) (What does SHADOW do if symbol is already there?) - SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87) (*FEATURES* are in the keyword package) ! The following issues were mailed prior to the June 1987 meeting and passed at that meeting; they will not be distributed again except by request. - COMPILER-WARNING-STREAM (Version 6, 5-Jun-87) (Compiler warnings are printed on *ERROR-OUTPUT*) Version 6 passed X3J13/Jun87 - DEFVAR-INIT-TIME (Version 2, 29-May-87) (DEFVAR initializes when evaluated, not later.) Version 2 passed X3J13/Jun87. - DEFVAR-INITIALIZATION (Version 4, Jun-87) ((DEFVAR var) doesn't initialize) Version 4 passed X3J13, Jun87. - FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87) (do FLETs have implicit named blocks around them?) Version 6 passed X3J13/Jun87. - FORMAT-ATSIGN-COLON (Version 4, 5-jun-87) (@: == :@ in format) Version 4 passed X3J13/Jun87. - FORMAT-OP-C (Version 5, 11-Jun-87) (What does ~C do?) Version 5 passed X3J13/Jun87. - IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87) (Does IMPORT affect home package?) Version 5 passed X3J13/Jun87. - PRINC-CHARACTER (Version 3) (PRINC behavior on character objections) Version 3 passed X3J13/Jun87. ! For your information only, the following issues are still under consideration by the cleanup committee. Volunteers to help out with the preparation of issue writeups are welcome. If you would like to review the mail discussion on a given topic, please let me know and I will forward it to you. - ADJUST-ARRAY-FILL-POINTER (Interaction of Adjust-ARRAY and fill pointers.) Need volunteer to write up. - CONSTANT-SIDE-EFFECTS (not yet submitted) (It is an error to do destructive operations on constants in code, defconstant.) Discussed 12/86 - 1/87 Will take on if no compiler proposal - DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted) (Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be required to be disjoint from other types?) From CLOS committee, not yet submitted - DECLARATION-SCOPE (Version 2, 2-Feb-88) (What is the scope of SPECIAL declarations? INLINE declarations? where can declarations be placed?) - DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS) (Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e., not a subclass.) Useful after CLOS - DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted) What is the lexical environment of DEFTYPE, DEFINE-SETF bodies? Mail 11-12 Oct 87 on common-lisp Interacts with compiler proposal? - DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file) (p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions. Specify that it is an error for two slots in a single DEFSTRUCT to have the same name. If structure A includes structure B, then no additional slot of A may have the same name as any slot of B." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file) (p 305) "The default value in a defstruct slot is not evaluated unless it is needed in the creation of a particular structure instance. If it is never needed, there can be no type-mismatch error, even if the type of the slot is specified, and no warning should be issued." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - EQUAL-STRUCTURE (not yet submitted) (Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.) What do EQUAL EQUALP and friends do on structures? (Need volunteer. ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu, Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU?) - FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT) (P 425) "Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument." Need volunteer to write up. - FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal) (What does FILE-WRITE-DATE do if no such file?) "there should not be a formal proposal for fixing the file-write-date ambiguity until we are at the point where we can make proposals that discuss signalling named conditions. " Need volunteer. - FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal) "format parameters are assumed to be non-negative integers except as specifically stated" Need volunteer. - FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted) (Change semantics of argument types in function declarations.) - FUNCTION-SPECS (not yet submitted) (add "function specs" for defun, trace etc) beyond SETF-FUNCTION-VS-MACRO. (SMH!franz@ucbarpa.berkeley.edu, JonL, RWK) - GC-MESSAGES (version 1) (Control over unsolicited GC messages in typescript) merge with other controls for unsolicited messages? - LAST-N (version 1, 4-DEC-87) (Extend LAST to take an optional N) Needs rewrite as per Moon - LISP-SYMBOL-REDEFINITION (no formal proposal yet) Is it legal to redefine symbols in the LISP package? Mail 14-Aug-87 Merge with SPECIAL-FORM-SHADOW Needs volunteer - LOAD-TIME-EVAL (Versin 4, 2 Feb 88) (evaluation when compiled file is loaded) - MACRO-FUNCTION-ENVIRONMENT (Add environment argument to MACRO-FUNCTION?) re-extracted from ENVIRONMENT-ARGUMENTS CLOS committee to submit? - PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87) How to deal with subdirectory structures in pathname functions? make :DIRECTORY a list? Need volunteer to rewrite. - PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted) Mail Aug 87 discussion How to deal with logical devices, :unspecific components, etc in pathname functions RWK@YUKON.SCRC.Symbolics.COM may submit proposal. - PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87) (interaction between PEEK-CHAR, READ-CHAR and streams made by MAKE-ECHO-STREAM) "Fixing echo streams is fine, but I don't think that it is appropriate for the standard to specify how terminal interaction must or even ought to work." - PROCLAIM-LEXICAL (Version 5, 14-Nov-87) (add LEXICAL, GLOBAL, CONSTANT proclaimation) some serious problems - PROMPT-FOR (Version 1) (add new function which prompts) Tabled until re-submitted. - REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 ) (Specification of side-effect behavior in CL) DEFINED, VAGUE and IN-BETWEEN - REMF-MULTIPLE (Version 1, 26 Jan 88) (What does REMF do if it sees more than one INDICATOR?) - REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87) (where does REQUIRE look for files?) - REST-LIST-ALLOCATION (not yet submitted) (APPLY #'LIST X) == (COPY-LIST X)? need volunteer - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87) (Change recommendation for (get-setf-method symbol)?) - SETF-SUB-METHODS (version 1, 12-Feb-88) (more careful definition of order of evaluation inside (SETF (GETF ...) ...) ) - SHARPSIGN-PLUS-MINUS-NUMBER (Is #+68000, #-3600 allowed?) Mild disagreement: it is an error? - SPECIAL-FORM-SHADOW (no formal proposal) (Is it OK to shadow a special form with FLET, LABELS, MACROLET?) In discussion, no formal proposal submitted. - SHARPSIGN-BACKSLASH-BITS (What does C-META-H-X mean?) Forwarded to character committee. - STANDARD-INPUT-INITIAL-BINDING (Version 1, 19 Jan 88) Move text of Test case/Example to Problem description. Somewhere between completely undefining and current situation is wanted. - STREAM-CLASS-ACCESS (No formal proposal) (Originally FOLLOW-SYNONYM-STREAM 19-DEC-86) Define stream accessors as if synonym-stream two-way-stream etc were CLOS classes? Need volunteer - STRUCTURE-DEFINITION-ACCESS (No formal proposal) (access to slot accessors for DEFSTRUCT etc.) Need volunteer to write up - SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal) (p 246) "Specify that it is an error for the SUBSEQ indices or any :START or :END argument have a negative index or point past the end of the sequence in question. (With respect to whether signalling is required, this error will be treated the same as array out-of-bounds.)" Need volunteer to write up - TAILP-NIL (no formal proposal yet) (Operation of TAILP given NIL) Needs writeup in current format. - TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87) (Allow trace for SETF functions, macros, etc.) Environment extension? - UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87) (What happens with non-local exits out of UNWIND-PROTECT cleanup clauses?) - VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet) CLtL says that vectors are extended by a "reasonable" amount. What's that? FAILMasinter.pa Common Lisp cleanup issue status to X3J13<326678.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  [~.[~. [~.[~.[%~.[-~.[5~.[=~."[E~.&[M~.*[U~..[]~.2[e~.6[m~.:[u~.>[}~. F[ $ [[@H|  ! }|/ H95p (p0b(X80 >H,} 4 t@ h@ sk ` ,hCP0E8F`F`JJ%* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 17:25:46 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:08:04 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:08:41 PST Date: 14 Feb 88 14:08 PST From: Masinter.pa@Xerox.COM Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 3) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-140841-1482@Xerox> This issue had not been distributed before. ! Issue: SHARPSIGN-PLUS-MINUS-PACKAGE References: #+ (p. 358), #- (p. 359), *FEATURES* (p. 448) Category: CLARIFICATION/CHANGE Edit history: Version 1 by Pitman 01-Mar-87 Version 2 by Masinter 10-Nov-87 Version 3 by Masinter 14-Nov-87 Problem Description: No information is provided in the description of #+ and #- (pp. 358-359) about what package the features are read on. In some systems, the current package is used. Since there is no wording in CLtL to the contrary, it's reasonable to assume that this would be done, but a consequence of this is that you must be much more sensitive to the package you're in at any given time when using #+ or #- even for system-provided features. (This is a problem if the LISP package can contain only the symbols in CLtL because system-provided features will likely not have the names of symbols on LISP and hence will require package prefixes. Having a symbol named LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like #+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or some such, which might get a read error in a non-Symbolics implementation that didn't export SYMBOLICS from SYSTEM...) In some systems, a canonical package (such as KEYWORD) is used. This means that package prefixes are rarely necessary in sharpsign conditionals for system-provided features regardless of the current package or restrictions about what may be in LISP. (For example, the KEYWORD package can have any symbol so it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*). This has implications about what goes on the *FEATURES* list (p. 448). Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD): Specify that the default package while reading feature specs is the keyword package. Other packages may be designated by use of explicit package prefixes. Symbols on *FEATURES* may be in any package but that in practice they will mostly be on the keyword package because that's the package #+/#- uses by default. If symbols in a package other than keyword appear on *FEATURES*, they will be seen by #+/#- only if marked by explicit package prefixes in the written feature-spec. Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448 is KEYWORD. Rationale: Making the behavior of #+ and #- well defined is important for people writing portable code that manipulate *FEATURES* directly. Current Practice: Some implementations bind *PACKAGE* while reading feature specs and others do not. Adoption Cost: Changes to implementations to make them conform should be fairly minor if not trivial. Benefits: As currently specified, using #+ and #- in truly portable code can have bootstrapping problems, since it is sometimes required to conditionally set up *FEATURES* in different ways for different systems. Conversion Cost: Few changes to user code will be required; code that uses #+ and #- will continue to work, although code that manipulates *FEATURES* directly may require editing. Aesthetics: Most users would perceive this as a bug fix either to CLtL or to certain implementations. Discussion: The cleanup committee supports this proposal. It might be reasonable to suggest that only vendors should add keyword symbols to the *FEATURES* list, and that users should add features on their personal packages so that collisions due to user applications were less likely. This idea might be a subject of controversy though, so is not part of this proposal. It would be useful to create a non-binding registry of feature names (and package names) already in use, so that Lisp implementors could pick otherwise unused feature names, and users who wanted to write portable code could know what feature names were preferred. FAILMasinter.pa<326653.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  [~.[~. [~.[~.[%~.[-~.[5~.[=~."[E~.&[M~.*[U~..[]~.2[e~.6[m~.:[u~.>[}~.  ![ 0 [[@HQ   F.uv H9p (p0b(XIH0)HX 4 tx -@ h sjb`,h?P0 8!`!`JJ%* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 17:25:22 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:05:20 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:04:22 PST Date: 14 Feb 88 14:03 PST From: Masinter.pa@Xerox.COM Subject: Issue: SHADOW-ALREADY-PRESENT (version 4) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-140422-1472@Xerox> This issue is new. ! Issue: SHADOW-ALREADY-PRESENT References: CLtL p.186 Category: CLARIFICATION/CHANGE Edit history: Version 1 Moon 24 Aug 87 Version 2 Moon 27 Aug 87 incorporate JonL's suggestions Version 3 Masinter 26-Oct-87 Version 4 Masinter 10-Nov-87 Problem description: The description of the SHADOW function can be interpreted as saying that the function has no effect, if the symbol is already present in the package. This happens if the third sentence in the description ("then nothing is done") is interpreted as applying to the entire description rather than just to the fourth sentence. SHADOW is said to take symbols as arguments, however only the print-name is meaningful for this operation (that fact is already documented). Proposal SHADOW-ALREADY-PRESENT:WORKS: 1) The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is already present in the package. 2) The first argument to SHADOW is allowed to be or contain strings as well as symbols. The specification "the print name of each symbol is extracted" is to be modified accordingly. Test Case: ;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS ;;; list of a package (make-package 'test-1) (intern "TEST" (find-package 'test-1)) (shadow 'test-1::test (find-package 'test-1)) (assert (not (null (member 'test-1::test (package-shadowing-symbols (find-package 'test-1)))))) (make-package 'test-2) (intern "TEST" (find-package 'test-2)) (export 'test-2::test (find-package 'test-2)) (use-package 'test-2 (find-package 'test-1)) ;should not error ;;; To test the use of strings in place of symbols ;;; change the third line of the test case to ;;; (shadow "TEST" (find-package 'test-1)) ;;; Note the use of capital letters in the string. Rationale: CLtL p. 180 describes a name conflict problem that can occur when calling the function USE-PACKAGE. The name conflict is between a symbol directly present in the using package and an external symbol of the used package. This name conflict may be resolved in favor of the symbol directly present in the using package by making it a shadowing symbol. For this to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the package. Since only the print name of a symbol argument is meaningful, a string should also be accepted. This is particularly useful to avoid problems when compiling code in one package environment and loading it into a slightly different package environment, where the symbol that was referred to at compile time may not be present at load time. This is particularly important because the symbol referred to by the print name may be changed by evaluation of the SHADOW form. A close reading of CLtL shows that one can already use (shadow '#:bar) in place of (shadow 'bar), to achieve much the same effect as (shadow "BAR"). But the user should not have to play such games, strings should be accepted. Current practice: Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is already present in the package. Kyoto Common Lisp, Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the symbol is already present in the package. It seems likely that we will find several implementations in each camp. SHADOW accepts strings in Symbolics Common Lisp. Cost to implementors: This should be a minor change to implementations that do not currently work this way. Cost to users: Technically this would be an incompatible change to implementations that do not already behave as proposed, however it is difficult to conceive of a user program that would require any conversion to cope with the change. Some users might want to remove kludges that were only necessary to get around the former misbehavior of SHADOW. Cost of non-adoption: Inconsistency among implementations and lack of a clear way to resolve the name conflict mentioned in Rationale. Benefits: Consistency among implementations and fewer mysterious package problems. Esthetics: The proposal would remove an unnecessary special case, thus simplifying the language slightly. Discussion: The issue was raised by Dieter Kolb on the Common-Lisp mailing list. It would be useless for SHADOW to fail to put a symbol that is already present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon believes CLtL intended to describe what is being proposed, but unfortunately used ambiguous language. The cleanup committee endorses this proposal. FAILMasinter.pa Issue: SHADOW-ALREADY-PRESENT (version 4)<326652.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  [~.[~. [~.[~.[%~.[-~.[5~.[=~."[E~.&[M~.*[U~..[]~.2[e~.6[m~.:[u~.>[}~.  "[ $ [[@H)  I ]u{ H9p (p0 c(XiX0)HX 4 tx -@ h sg`,hAP0!8"`"`ew. sue:  SEQ-FUNC-EXCLRRAYSerenc Sequ (pp2X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 17:18:40 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:54:18 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:54:43 PST Date: 14 Feb 88 13:54 PST From: Masinter.pa@Xerox.COM Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-135443-1454@Xerox> This issue is new. ! Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS References: Sequences (pp245-261) Issue REMF-DESTRUCTURING-UNSPECIFIED (discussion of NREVERSE, NSUBSTITUTE) Issue AREF-1D Category: ENHANCEMENT Edit history: 05-Feb-87, Version 1 by Touretzky 28-Apr-87, Version 2 by Pitman (variations on the theme) 26-Oct-87, Version 3 by Masinter (clean up for release) 11-Nov-87, Version 4 by Masinter (respond to comments) 5-Feb-88, Version 5 by Masinter Description: Common Lisp provides many useful operations on lists and vectors which don't apply to arrays. For example, one can FILL a vector with 0's, but not an array. One can REPLACE the contents of one vector with another, but one can't do this for arrays. One can verify that EVERY element of a vector has some property, but one can't do this for arrays, and so on. The programmer who wishes to use arrays instead of vectors must give up most of the useful tools CLtL provides for manipulating sequences, even though there is no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work on arrays. Common Lisp already provides a facility called "displaced arrays" which can be used to overlay one array on top of a portion of another, even if the two are of different ranks, so that the two share storage or use the awkward convention of creating a displaced array to the operand. However, creating a displaced array merely to perform FILL, REPLACE or EVERY is awkward. Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE): 1) Extend the definitions of sequence functions that either return their argument sequences or return non-sequences so that they also allow arrays of rank other than 1. These functions should treat array arguments as vectors displaced to the array storage (in row-major format). The affected functions are LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE, SORT. For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A 7) should return the same element as (AREF A 0 1 0). :START and :END keywords would be interpreted relative to the vector, as would the results returned by POSITION and SEARCH. 2) Extend the definitions of sequence functions whose result should be the same shape as but not necessarily EQ to some argument. These functions should deal with array arguments by returning an array of the same shape as the argument, and operate on their argument in row-major order. The affected functions are SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP. 3) Sequence functions that modify the number of elements in the array remain unchanged: it is an error to pass arrays of rank other than 1. (The functions are not extended because the shape would be undefined.) The unaffected functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES. Note that EQUALP does -not- treat arrays as vectors. It is not a sequence function, and it already has a well-defined behavior for arrays. To test whether the arrays A and B, of different shapes, have the same elements, one might write: (AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)). Rationale: This is a useful upward compatible extension with relatively low adoption cost. Cost to Implementors: This would involve a lot of changes to functions, but all of the changes are likely to be minor. The presence of displaced arrays in the language already guarantees that the internal storage format needed to back up these proposed changes is already in place. Cost to Users: This change is upward compatible; current user code should run unmodified. Benefits: This proposal adds natural support for multi-dimensional arrays. Currently, users must write nested DO loops every time they want to perform an array operation equivalent to FILL, REPLACE, REDUCE, etc., or else they build displaced vectors by hand and pass them to the sequence functions when necessary. With this proposal, users of arrays do not have to use home-grown utilities to duplicate functionality already primitively provided to users of arrays. The sequence functions become useful in a variety of new situations. Aesthetics: This proposal extends sequence functions to cover arrays while neatly avoiding the temptation to turn Common Lisp into a half-baked APL. Instead of trying to provide a full set of array handling primitives (which would be needed to take arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an operator across a specific dimension of a multidimensional array), it requires just one rule: treat arrays as displaced vectors where it is well-defined. Current Practice: We know of no current implementation of this proposal. Discussion: This issue was discussed by the cleanup committee at length; what follows is only a brief summary of the discussion. An alternative considered was to only affect those functions which didn't explicitly depend on the shape of the array; that is, to modify COUNT, SOME, EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and expressly forbid arrays as arguments to other sequence functions, including LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT, MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes only those functions which do not deal with positional information. Some hedging over REDUCE and FIND, which often have non-positional uses, were considered. Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been building displaced vectors to pass to sequence functions when necessary and really dislikes it. We considered but discarded as unworkable an alternative where POSITION and FIND might deal with "positions" as lists of array subscripts. At one point, this proposal included an extension to COERCE to allow COERCE to translate from array types to sequences, but it was thought better to separate out COERCE. We considered a proposal to only introduce a change to COERCE, and require users who want to operate on arrays explictly perform, e.g., (COUNT item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost but was deemed awkward. Sequence functions like FILL and COUNT are already generalized to arrays in non-Lisp contexts; in English we use the generalized forms all the time, e.g., "count the number of 1's in this matrix." There is some concern that this proposal makes the requirement for row-major ordering of internal storage for arrays even more evident. While such an internal ordering is implied by the ability to create displaced arrays and the AREF-1D proposal, this proposal adds yet another constraint. The general reason for opposing this change is that it adds more mechanism than it is worth. The general reason for liking it is that it adds generality at little cost. FAILMasinter.pa Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)<326642.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  eee e%e-e5e=eEe"Me&Ue*]e.ee2me6ue:}e>  e : ee@HЯ  yP] H9p (p0(XUx0HX\ 4 tx @ t sb[`,4 gP8``* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 17:09:27 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:51:55 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:49:20 PST Date: 14 Feb 88 13:49 PST From: Masinter.pa@Xerox.COM Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-134920-1443@Xerox> This issue is new. ! Issue: REDUCE-ARGUMENT-EXTRACTION References: REDUCE (pp. 251-252), :KEY arguments (p. 246), the astronaut structure (pp. 312-313) Category: ADDITION Edit history: Version 1 by Pierson 5-Dec-87 Version 2 by Pierson 30-Dec-87 Version 3 by Masinter 13-Feb-88 Problem description: REDUCE is the only one of the Common Lisp functions that modify or search lists and sequences which does not accept a :KEY argument. This complicates many uses of REDUCE. Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY): Change the definition of REDUCE to take a :KEY keyword described as follows: If a :KEY argument is supplied, its value must be a function of one argument which will be used to extract the values to reduce. The :KEY function will be applied exactly once to each element of the sequence in the order implied by the reduction order but not to the value of the :INITIAL-VALUE argument, if any. Example: Using REDUCE to obtain the total of the ages of the possibly empty sequence of astronauts ASTROS, would currently require: (REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS)) If this proposal is adopted, the same result could be obtained without creating a new list by: (REDUCE #'+ ASTROS :KEY #'PERSON-AGE) Rationale: This proposal makes many common situations where REDUCE would be useful much less cumbersome. Current practice: We know of no implementation which currently supports this feature. Cost to Implementors: This will require most implementations to make a trivial modification to REDUCE. Implementations which wish to use this as an opportunity to further optimize compiled calls to REDUCE will have to undertake more work (which would be much more difficult today). Cost to Users: None, this is an upward compatible extension. Cost of non-Adoption: REDUCE will continue to be more difficult to use than other sequence functions on sequences of complex objects. Benefits: REDUCE will become easier to use on sequences of complex objects. It will be easier for compilers to convert some calls to REDUCE into efficient loops. Aesthetics: Slightly damaged in one way. All :KEY arguments are currently defined to be used for predicates, this proposal will implicitly broaden :KEY to support general extraction for any purpose. Slightly improved in another way. Many common situations where REDUCE could be used would be easier to write and easier to later read. Discussion: Several members of the committee feel that the increased functionality outweighs the damage to the definition of :KEY. No one has objected to this change in the recent round of discussions. There is some controversy over whether the "definition" of :KEY arguments on page 246 of CLtL really constitutes a definition or just an "unwritten rule". FAILMasinter.pa Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)<326629.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  F5k F5kF5 kF5 k#F5k+F5k3F5k;F5kCF5!kKF5%kSF5)k[F5-kcF51kkF55ksF59k{F5=k  F5& FUF5F5@HD  dE H9/p (p06(X^80 6H,m 4 tx 8@ t{ s?;`,4 BP8``* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 15:49:43 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:31:20 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:29:51 PST Date: 14 Feb 88 12:29 PST From: Masinter.pa@Xerox.COM Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-122951-1359@Xerox> This issue is new. ! Issue: FUNCTION-TYPE-REST-LIST-ELEMENT References: CLtL p. 27, 47-48, 61 "Artifical Intelligence Programming", Charniak et. al. X3J13/86-003 (A:>GLS>clarifications.text.4) Category: CLARIFICATION, ADDITION Edit history: Version 1, 23-Nov-1987 Sandra Loosemore Version 2, 15-Jan-1988 Sandra Loosemore (incorporate comments from Scott Fahlman & others) Version 3, 13-Feb-88 Masinter Related issues: FUNCTION-TYPE-KEY-NAME, FUNCTION-ARGUMENT-TYPE-SEMANTICS Problem description: The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, this is actually of limited usefulness in the context of a declaration, where one normally wants type information about the actual arguments which can be passed to the function rather than the lambda variables to which they are bound. There is a particular problem with &REST lambda variables, which are always bound to a value of type LIST. For the sake of consistency, it would seem that the corresponding type given in the FUNCTION declaration must also be LIST, but since this provides no information about the actual arguments, some users/implementors have instead adopted the convention of supplying the type of the actual arguments which are gathered into the list. CLtL is vague on the issue, mentioning only that &REST may appear in the type specifier without touching upon its interpretation. Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE): Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST is the type of each actual argument, not the type of the corresponding lambda variable. Example: The type of the function + would be specified as: (FUNCTION (&REST NUMBER) NUMBER) Rationale: This is more useful than specifying that the type of a &REST parameter must be LIST, since it provides information about the actual arguments. Current practice: There does not appear to be any concensus on this issue. Most Common Lisp implementations currently ignore FUNCTION type declarations. The only examples found so far are in a text book on Common Lisp, which follows the proposed syntax. Cost to Implementors: Implementations that ignore the FUNCTION type specifier may continue to do so. Probably only a small amount of code would have to be written/changed in implementations that currently think that the &REST argument should be LIST. Cost to Users: Users who have been using the convention that the &REST type parameter must be LIST will have to change their code. However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much. Cost of non-adoption: If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose. Benefits: Adopting the proposal will clear up an area of confusion in the language design. Esthetics: Debatable. One the one hand, since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it would be cleaner and less confusing to provide the type of the lambda variable rather than the type of the actual arguments. However, considering the types specified in the FUNCTION specifier to be the types of the actual arguments rather than the types of the parameters as seen on the receiving end makes the proposed semantics more palatable. Discussion: This issue provoked considerable debate in the cleanup committee. There was some support for an alternative proposal to require that the &REST argument declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST type to allow declarations of the form, e.g., (LIST NUMBER). Those who favor USE-ACTUAL-ARGUMENT-TYPE (including David Moon and Larry Masinter) argue that the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practice, argue for it. Kent Pitman has argued against this proposal on the following grounds: ``* It is bothersome that the same argument declarations which are used internally in the function would not be be usable externally. ``* It is unfair to provide only this special-purpose way of declaring a sequence type when in fact there are numerous other places in the language where it might be useful to declare a sequence type. ``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if it is not already in CLtL somewhere) that the following is illegal: (DEFUN FOO (&REST X) X) (APPLY #'FOO T) since there will be no way to type-declare this. Even though this is an obscure case (that doesn't even work in some implementations), it's the sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.'' FAILMasinter.pa Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)<326589.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  _r _r_r _r #_r+_r3_r;_rC_r!K_r%S_r)[_r-c_r1k_r5s_r9{_r=  9_r& `_r_r@H   gck{n H9p (p03(X`0 -H,[ 4 tx @/@ h3 s8~`,h6oP0889`9`: FUNCTYPE-KME Rnces:LtL p8, 61egory CLAX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 15:40:37 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:23:25 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:23:55 PST Date: 14 Feb 88 12:23 PST From: Masinter.pa@Xerox.COM Subject: Issue FUNCTION-TYPE-KEY-NAME, Version 3 To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-122355-1354@Xerox> This issue is new. ! Issue: FUNCTION-TYPE-KEY-NAME References: CLtL p.47-48, 61 Category: CLARIFICATION, CHANGE Edit history: Version 1, 23-Nov-1987 Sandra Loosemore Version 2, 15-Jan-1988 Sandra Loosemore (from comments by Kent Pitman) Version 3, 13-Feb-88 Masinter Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT, KEYWORD-ARGUMENT-NAME-PACKAGE FUNCTION-ARGUMENT-TYPE-SEMANTICS Problem description: The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, there is a problem with &KEY lambda variables because CLtL does not specify how the types specified in the FUNCTION declaration are matched up to either the actual arguments passed to the function, or the lambda variables in the function definition (since the ordering of keyword arguments is arbitrary). Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD): (1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list should be supplied as lists of the form ( ). The must be a valid keyword-name symbol as must be supplied in the actual arguments of a call. (This is usually a symbol in the keyword package, but, as per KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.) (2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list. The interpretation of such declarations is that, when &KEY is given in a FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given are exhaustive unless &ALLOW-OTHER-KEYS is present. &ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be supplied and, if supplied, may be used. Example: The type of the function MAKE-LIST could be declared as: (FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST) Rationale: (1) This specifies a direct correspondence between the argument type and its matching keyword. All of the information is in one place, and the user does not have to remember (or even know) the order in which &KEY arguments appear in the actual function definition. (2) This is probably an oversight in the original specification. Current practice: Many Common Lisp implementations currently ignore FUNCTION type declarations. The situation regarding type specifications for keyword arguments is so ambiguous that few users attempt to use them. Cost to Implementors: Implementations that ignore the FUNCTION type specifier or keyword arguments in a FUNCTION type specifier may continue to do so. This proposal should not involve massive amounts of code to be rewritten. Cost to users: Because the current situation is so ambiguous, FUNCTION type specifiers and particularly the specification of keyword argument types are not widely used. However, since this is an incompatible change, it would be nice if implementations check for, and warn about, old-style usage. Cost of non-adoption: If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose. Benefits: Adopting the proposal will clear up an area of confusion in the language design. Esthetics: The syntax is fairly obvious and is analogous to the ( ) lambda list syntax. Discussion: The exact semantics of function declarations and the types of arguments is still under discussion, as are several other issues dealing with declarations. However, this issue seemed separable. FAILMasinter.pa Issue FUNCTION-TYPE-KEY-NAME, Version 3<326584.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  D D D D#D+D3D;D!CD%KD)SD-[D1cD5kD9sD={D  A  @H{  C H9}p (p0/(XHx0'HX 4 tx +@ t5 s6 `,4; P?8A`A`GII* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 15:31:10 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:14:19 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:14:54 PST Date: 14 Feb 88 12:14 PST From: Masinter.pa@Xerox.COM Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-121454-1351@Xerox> This issue is new. ! Issue: FORMAT-COLON-UPARROW-SCOPE References: CLtL p. 406 and also p. 403 Category: CLARIFICATION Edit history: version 1: Guy Steele, 30 November 1987 version 2: Guy Steele, 18 January 1988 version 3: Masinter, 5 February 1988 Problem description: Implementations currently differ on the question of what is tested by the FORMAT command "~:^". Some implementations test to see whether any arguments remain in the sublist for the current iteration step; others test to see whether any sublists remain. The text on page 406 is not clear on this point. Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS): ~:^ may be used only if the command it would terminate is ~:{ or ~:@{. The entire iteration process is terminated if and only if the sublist that is supplying the arguments for the current iteration step is the last sublist (in the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:^ is *not* equivalent to ~:#^; the latter terminates the entire iteration if and only if no arguments remain for the current iteration step. Example: (format nil "~:{~@?~:^...~}" '(("a") ("b"))) Under this proposal, this yields "a...b", rather than "a". Rationale: This proposal is desirable because otherwise there is no way to test whether any sublists remain. The text on page 406 may be construed to hint at this proposal indirectly. To quote Nick Gall: "If one thinks about the intent of the parenthetical `(because in the standard case it tests for remaining arguments of the current step only)', one should agree that "a...b" will be returned. In referring to ~^ as the `standard case', which tests the arguments remaining in the current argument sublist, this parenthetical implies that there is an `other case', which tests `something else.' The only `other case' discussed is ~:^, which therefore must test `something else.' I claim that the parentheical makes no sense if we interpret ~:^ as testing the same condition as ~^. If they both test the same condition, why have the parenthetical explanation? "If ~:^ doesn't test the same condition as ~^, then what does it test? I claim that the only test that makes sense is for ~:^ to test the only thing that affects the `entire iteration process:' the number of sublists. When there are no more sublists, `the entire iteration process' is terminated." Current practice: Some implementations already have the proposed behavior, including Symbolics Common Lisp and TI Lisp. Many other implementations currently have a different interpretation: the test case returns "a", since ~:^ in those implementations test for the remaining arguments rather than remaining sublists. These currently include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP. Cost to Implementors: Many implementations will have to make a small change, probably a one-liner. Cost to Users: It is unlikely that much user code depends on the behavior of testing for remaining arguments, but it is possible. The author of this writeup (Steele) judges it somewhat more likely that user code might depend on the behavior of testing for remaining sublists. Cost of non-adoption: Users would have to be warned not to use ~:^ in code that is meant to be portable. Benefits: Elimination of yet one more ambiguity. The proposed semantics allows greater semantic power (there are more things one can test). Esthetics: ``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr. Discussion: Guy Steele very strongly prefers the interpretation FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. Kevin Layer and Rich Robbins have spoken in favor of an alternative proposal, to test for the remaining arguments. Historical note: Steele first implemented this "feature", in Zetalisp, and so the code in Symbolics Common Lisp is likely a direct descendant of the original code. This might cause some to give weight to Steele's opinion. There are two arguments against such credence. First, there is no reason why the original code should be regarded as part of the specification of Common Lisp any more than any other implementation; plainly, Steele botched the specification when he wrote the book. Second, a professor of literature (I believe) once told Isaac Asimov concerning a short story of his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the story, what makes you think you know what it means?" FAILMasinter.pa Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)<326578.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  o3og o3ogo3 ogo3 og"o3og*o3og2o3og:o3ogBo3!ogJo3%ogRo3)ogZo3-ogbo31ogjo35ogro39ogzo3=og  o3 4 oSo3o3@Hr} $ wv s= H9p (p0+(Xn`0 H, 4 tx H@ t s/f`,4 P8``sue:  FOROMMA-VAL encesORMATger png (p-9) X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 15:20:41 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:03:49 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:04:24 PST Date: 14 Feb 88 12:04 PST From: Masinter.pa@Xerox.COM Subject: Issue: FORMAT-COMMA-INTERVAL (Version 2) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-120424-1324@Xerox> This issue is new. ! Issue: FORMAT-COMMA-INTERVAL References: FORMAT integer printing (p. 388-9) Category: ADDITION Edit history: Version 1, Pavel, 10-Jun-87 Version 2, Masinter, 15-Jun-87 Problem description: There are times when users would like to print out numbers with some punctuation between groups of digits. The "commachar" argument to the ~D, ~B, ~O, ~X, and ~R FORMAT directives was introduced to fill that need. Unfortunately, the interval at which the commachar should be printed is always every three digits. This constraint is annoying when a different interval would be more appropriate. Proposal (FORMAT-COMMA-INTERVAL:YES): Add a fourth argument to the ~D, ~B, ~X, and ~O FORMAT directives, and a fifth argument to the ~R directive, to be called the "comma-interval". This value must be an integer and defaults to 3. When the : modifier is given to any of these directives, the "commachar" is printed between groups of "comma-interval" digits. Test Cases: Under the proposal, the following forms return the indicated values: (format nil "~,,' ,4:B" 13) => "1101" (format nil "~,,' ,4:B" 17) => "1 0001" (format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101" (format nil "~3,,,' ,2:R" 17) => "1 22" (format nil "~,,'|,2:D" #xFFFF) => "6|55|35" Rationale: The current specification of FORMAT gives the user control over almost all of the facets of printing integers. Only the wired-in constant for the comma-interval remains, even though there are uses for varying that number. For example, in many contexts, it would be convenient to be able to print out numbers in binary with a space between each group of four bits. FORMAT does not currently allow specification of the commachar printing interval so users needing this functionality must write it themselves, duplicating much of the logic in every implementation's integer printing code. Other uses, requiring other intervals, can be imagined. For example, using a "commachar" of #\Newline and a "comma-interval" of, say, 72, very large bignums could be printed in such a way as to ensure line-breaks at appropriate places. Current practice: No released implementations currently support this feature. Cost to implementors: The change in the implementation of FORMAT is reasonably minor and, in most cases, highly localized. Usually, the change is as simple as taking an extra parameter and using it instead of a wired-in value of 3. Cost to users: Since the proposal involves the addition of an argument to certain directives, the change would be entirely upward-compatible. No user code would need to be converted. Cost of non-adoption: Users desiring this functionality will have to write it themselves, duplicating much of the logic involved in printing integers at all. Benefits: One of the few remaining inflexibilities in integer printing is eliminated with a net increase in user-visible functionality. Esthetics: By parameterizing one of the final pieces of wired-in behavior from integer printing, this small part of the workings of FORMAT would be perceived as having been cleaned up. Discussion: Several members of the cleanup committee endorsed this proposal. No objections were raised. FAILMasinter.pa Issue: FORMAT-COMMA-INTERVAL (Version 2)<326569.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  mgm mgmmg mmg m"mgm*mgm2mgm:mgmBmg!mJmg%mRmg)mZmg-mbmg1mjmg5mrmg9mzmg=m  mg $ nmgmg@Hq'  uGtQqYyj H9p (p0((Xh@0 yH, 4 tx ({@ h s.V`,hP08``IONSferen FLABELSROLETL p.1 J13 dnt 86X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 15:18:34 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:01:21 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:00:15 PST Date: 14 Feb 88 11:59 PST From: Masinter.pa@Xerox.COM Subject: Issue: FLET-DECLARATIONS (Version 2) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-120015-1323@Xerox> ! Issue: FLET-DECLARATIONS References: FLET, LABELS, MACROLET (CLtL p.113) X3J13 document 86-003 item 113 Cleanup issue DECLARATION-SCOPE. Cleanup issue DECLARE-MACROS. Category: ADDITION Edit history: Version 1, Moon, 1 Jan 1988 Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter) Problem description: Declarations are not allowed before the body of FLET, LABELS, and MACROLET, even though Common Lisp allows declarations in other seemingly analogous places, such as LET. Proposal (FLET-DECLARATIONS:ALLOW): Change the syntax of FLET, LABELS, and MACROLET to allow declarations between the list of local function/macro definitions and the body forms. The scope of such declarations in FLET and LABELS includes the bodies of the locally defined functions, when the declarations are pervasive. Non-pervasive declarations have no effect on those bodies, except when LABELS includes the body in the scope of a function non-pervasively declared. This paragraph follows directly from CLtL p.155 if the locally defined function bodies are treated like initialization forms. (This paragraph will be superseded by cleanup issue DECLARATION-SCOPE if it passes.) The scope of such declarations does not include the bodies of the macro expander functions defined by MACROLET. This is consistent with the existing rule that the bodies of those functions are in the global environment, not the local lexical environment. If cleanup issue DECLARE-MACROS is not passed, in MACROLET an invocation of one of the macros locally defined by that MACROLET is permitted to expand into a DECLARE. Example: (defun example (y l) (flet ((attach (x) (setq l (append l (list x))))) (declare (inline attach)) (dolist (x y) (unless (null (cdr x)) (attach x))) l)) (example '((a apple apricot) (b banana) (c cherry) (d) (e)) '((1) (2) (3) (4 2) (5) (6 3 2))) => ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry)) The above function is erroneous in current Common Lisp. With this proposal, it would have an intuitively obvious meaning. Rationale: This will make the syntax of FLET and LET consistent. This will make it possible to attach declarations to function bindings; currently only variable bindings can have attached declarations. Current practice: Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW. Symbolics Common Lisp does not allow declarations in this position. Cost to Implementors: The compilation and interpretation of three special forms will have to be changed, however the same techniques already developed for declarations in LET should be applicable. Cost to Users: No cost since this is an upward-compatible addition. Cost of non-adoption: Unnecessary inconsistency in the syntax of Common Lisp. Benefits: There is no major benefit but the language will be more consistent. Esthetics: Makes the language more consistent. Discussion: We need to resolve this for CLOS, because CLOS introduces two new special forms similar to FLET and LABELS and we need to make their syntax consistent with FLET and LABELS. FAILMasinter.pa Issue: FLET-DECLARATIONS (Version 2)<326564.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ) ) ) )) )) )") )*) )2) ):) )B) !)J) %)R) ))Z) -)b) 1)j) 5)r) 9)z) =)  b)  4 )*) ) @Hl  q9o[mx; H9_p (p0&#(XR80 VH, 4 tx (X@ h\ s,V`,h_P0a8b`b`0eff* W6Y-b8Mv&H6$@X3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 15:11:43 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:55:29 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:55:39 PST Date: 14 Feb 88 11:55 PST From: Masinter.pa@Xerox.COM Subject: Issue: DRIBBLE-TECHNIQUE (Version 2) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-115539-1321@Xerox> This issue has not been distributed before. (In fact, this version had not been distributed to the cleanup committee.) There was no discussion on the issue, however. ! Issue: DRIBBLE-TECHNIQUE References: DRIBBLE (p443) Category: CLARIFICATION Edit history: 06-Dec-87, Version 1 by Pitman 14-Feb-88, Version 2 by Masinter Problem Description: The intent and effect of DRIBBLE is not very clearly specified. Users have complained that DRIBBLE behaves quite differently in different implementations. Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE): Clarify that DRIBBLE is intended primarily for interactive debugging and that its effect cannot be relied upon from programs. Test Case: #1: (PROGN (DRIBBLE "temp") (PRINT 'FOO) (DRIBBLE)) #2: (DRIBBLE "temp") (PROGN (PRINT 'FOO) (DRIBBLE) (PRINC 'BAR)) Rationale: Users of DRIBBLE have been surprised about how differently DRIBBLE behaves in different implementations. This makes the status quo much more explicit and will lead to less surprise. Current Practice: Some implementations implement DRIBBLE as a function which simply assigns streams such as *STANDARD-OUTPUT* to broadcast streams (or the approximate equivalent thereof). Even within this camp, there is not widespread agreement about which streams are affected. However, typically test case #1 will capture the output of (PRINT 'FOO) in the file "temp" and will execute (PRINT 'BAR) but not capture its output. Some implementations (eg, Symbolics) push to a recursive command loop when DRIBBLE is called with an argument, and return from that command loop when DRIBBLE is called with no argument. In these implementations, test case #1 will enter a recursive command loop upon the first call to DRIBBLE and will not execute the (PRINT 'FOO) until (DRIBBLE) is done interactively. When the second (DRIBBLE) in test case #1 is executed, DRIBBLE will complain that output is not currently being recorded. In test case #2, the output of (PRINT 'FOO) will be captured, but the form (PRINT 'BAR) will never be executed because (DRIBBLE) does not return normally (it throws). Cost to implementors: None. This is just a clarification. Cost to users: Anyone who currently uses DRIBBLE in code that is believed to be portable is kidding himself. If such code works in some implementations, it can continue to work. Benefits: Users will be aware that they cannot rely on DRIBBLE in portable code. Aesthetics: No apparent effect. Discussion: DRIBBLE, like other environment features, is a standard interface to a non-standard feature. As such, there is some question as to its place in the ANSI standard. However, if DRIBBLE remains in the standard, its behavior is made explicitly vague by this proposal. FAILMasinter.pa Issue: DRIBBLE-TECHNIQUE (Version 2)<326557.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-#  A AA A AAA AAA AA"A AA*A AA2A AA:A AABA !AAJA %AARA )AAZA -AAbA 1AAjA 5AArA 9AAzA =AA  A  6 A@A A @HD?  H_G D H hb9p (p0#G(XSh0 XH, 4 tx HZ@ t s#l`,4 cP8``#t?hGtUX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 14:55:02 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:37:23 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:37:58 PST Date: 14 Feb 88 11:37 PST From: Masinter.pa@Xerox.COM Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-113758-1303@Xerox> This issue has not been distributed to X3J13 before. ! Issue: DO-SYMBOLS-DUPLICATES References: DO-SYMBOLS, CLtL p.187 Category: Clarification Edit history: Version 1 by Fahlman 17-Apr-87 Version 2 by Masinter 29-May-87 Version 3 by Masinter 23-Nov-87 Problem Description: CLtL specifies that DO-SYMBOLS executes the body once for each symbol accessible in the package. It does not say whether it is permissible for the body to be executed more than once for some accessible symbols. The term "accessible" is defined on page 172 to include symbols inherited from other packages (not including any symbols that may be shadowed). It is very expensive in some implementations to eliminate duplications that occur because the same symbol is inherited from multiple packages. Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED Add to the specification of DO-SYMBOLS a note that it may execute the body more than once for some symbols. Example: (SETQ A (MAKE-PACKAGE 'A)) (SETQ B (MAKE-PACKAGE 'B)) (EXPORT (INTERN "ASYM" A) A) (USE-PACKAGE A B) (EXPORT 'B::ASYM B) (USE-PACKAGE B A) (DO-SYMBOLS (X B) (PRINT X)) ;; this may print ASYM once or twice. Rationale: Most uses of DO-PACKAGE would not be harmed by the presence of duplicates. For these applications it is unreasonable to force users to pay the high cost of filtering out the duplications. Users who really want the duplicates to be removed can add additional code to do this job. Current Practice: Many implementations have always produced duplicate values. Cost to implementors: None. Implemenations would still be free to eliminate the duplications, though code will not be assuming that this has been done. Cost to users: Code written assuming that DO-SYMBOLS eliminates duplications will have to be modified. (Such code was not truly portable.) Benefits: Clarification of a situation that is currently ambiguous. Aesthetics: It would be cleaner to present each symbol exactly once. This is a clear case of choosing efficiency over elegance. Discussion: This issue was discussed on the Common Lisp mailing list in 1985, and the solution proposed here seems to have been informally agreed to at the time -- there was no formal decision-making process in place then. The need for DO-SYMBOLS to be efficient is questionable, however; for many applications (e.g., global package manipulation), duplicate values would create havoc. For some implementations, the performance penalty would be well over a factor of two. Several proposals were considered for adding keyword arguments to DO-SYMBOLS which might specify :ALLOW-DUPLICATES, adding keywords and eliminating DO-EXTERNAL-SYMBOLS, etc., but no clear consensus was reached for making additions. This version is the closest to the status quo. FAILMasinter.pa Issue: DO-SYMBOLS-DUPLICATES (Version 3)<326551.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-#  55 5 55!5)5159 5A$5I(5Q,5Y05a45i85q<5y  Z5 6 u55@Hja& onoj͇} Hith the AI Lab.9p (p0 :(XX0HXO 4 tx @ hT s #`,hWP0Y8Z`Z`0]^^t?hGtUX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Feb 88 14:04:56 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:49:35 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:50:04 PST Date: 14 Feb 88 10:49 PST From: Masinter.pa@Xerox.COM Subject: Issue: APPEND-DOTTED (Version 5) To: X3J13@Sail.stanford.edu cc: Masinter.pa@Xerox.COM reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880214-105004-1227@Xerox> This issue was distributed in hardcopy at the November 1987 meeting of X3J13. ! Issue: APPEND-DOTTED References: APPEND (p268) Category: CHANGE/CLARIFICATION Edit history: 27-Jul-87, Version 1 by Pitman 29-Oct-87, Version 2 by Pitman (loose ends) 14-Nov-87, Version 3 by Masinter 23-Nov-87, Version 4 by Masinter 14-Jan-88, Version 5 by Masinter Problem Description: The description of APPEND on p268 is not adequately clear on the issue of what happens if an argument to APPEND is a dotted list. The only case explicitly mentioned is the last argument, viz: "The last argument [to APPEND] actually need not be a list but may be any LISP object, which becomes the tail end of the constructed list. For example, (append '(a b c) 'd) => (a b c . d)." While this specifies the behavior of APPEND when the last argument is not a list, the behavior when any of the other arguments are not lists is not specified. Proposal (APPEND-DOTTED:REPLACE): Define that the cdr of the last cons in any but the last argument given to APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be returned. In the degenerate case where there is no last cons (i.e., the argument is NIL) in any but the last list argument, clarify that the entire argument is effectively ignored. Point out that in this situation, if the last argument is a non-list, the result of APPEND or NCONC can be a non-list. Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the same, since these two might legitimately differ in situations involving dotted lists. As such, deciding which to use is not just a stylistic issue. Examples: (APPEND '(A B C . D) '()) => (A B C) ;Proposed (NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed Note that (COPY-LIST '(A B C . D)) would still return (A B C . D). (APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed (NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed (APPEND '() 17) => 17 ;Proposed (NCONC (LIST) 17) => 17 ;Proposed Rationale: This function is used a lot and its behavior should be well-defined across implementations. This proposal upholds the apparent status quo in a number of implementations. Current Practice: Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed interpretation (at least in the interpreter). Franz's Allegro Common Lisp conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17, where it returns NIL instead of 17. Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list. Xerox Common Lisp signals an error on APPEND and implements the proposed interpretation on NCONC. Cost to implementors: Technically, the change should be relatively small for those implementations which don't already implement it. However, implementations which have microcoded APPEND or NCONC incompatibly may find the small change somewhat painful. Some implementations may have optimized their APPEND or NCONC to expect only NIL when SAFETY is 0. In this case, depending on implementation details, requiring an ATOM check rather than a NULL check may slow things down. Cost to users: This change is upward compatible. Benefits: Since non-lists are allowed as a last argument and since APPEND and NCONC can therefore produce dotted lists, some readers may have (incorrectly) assumed that APPEND and NCONC can reliably deal in general with dotted lists, something that doesn't appear to be guaranteed by a strict reading. The proposed extension would happen to legitimize such assumptions. Aesthetics: Whether or not users will think this improves the aesthetics of the language will depend largely on how they view the relation between lists and dotted lists. Those who view dotted lists as a special kind of list may feel differently than those who view lists as a special kind of dotted list. Discussion: The cleanup committee supports this proposal. FAILMasinter.pa Issue: APPEND-DOTTED (Version 5)<326495.880214@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  (g( (g((g ((g ("(g(*(g(2(g(:(g(B(g!(J(g%(R(g)(Z(g-(b(g1(j(g5(r(g9(z(g=(  (g  )(g(g@H+  - ,[+ S H6F)p (p0(X(0HXS 4 tx @ t lFD`,4 ]P8``P8PX3J13-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 20:41:56 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:28:50 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:29:36 PST Date: 13 Feb 88 17:29 PST From: Masinter.pa@Xerox.COM Subject: Issues from the cleanup sub-committee To: X3J13@Sail.stanford.edu reply-to: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880213-172936-10523@Xerox> The cleanup committee has a number of issues for discussion and/or voting at the next X3J13 meeting. I will be mailing out those issues which are ready for voting at the next meeting, one at a time. I am uncertain as to the exact procedure for voting; I imagine that Bob Mathis will help clarify. My current understanding is that you should be prepared either to vote for endorsing a proposal or should prepare a written objection. Please address your replies directly to cl-cleanup@Sail.stanford.edu. We promise to summarize and redistribute any replies we get. X3J13@Sail.stanford.edu should *not* be used for technical discussions, however. The cleanup issues fall into several categories. Passed X3J13/Jun87: Mailed to X3J13 prior to the June 1987 meeting of X3J13 and passed (via voice vote) at that meeting. As these were distributed before, they will not be mailed again except by individual request, although the issues will appear on the ballot. Conditionally passed X3J13/Jun87, new version passed X3J13/Nov87: While an earlier version was mailed to X3J13 prior to the Jun87 meeting, the most recent version was distributed only in hardcopy at the November 1987 meeting. Passed X3J13/Nov87: Distributed only via hardcopy at the November 1987 meeting. New ballot items for Mar88: Not previously distributed to X3J13, but ready for voting. In discussion: Some of these issues may be distributed via electronic mail to X3J13 prior to the March meeting for discussion at the meeting, although they will not appear on a ballot at that time. FAILMasinter.pa Issues from the cleanup sub-committee<326309.880213@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOW YN-! (g( (g((g ((g ("(g(*(g(2(g(:(g(B(g!(J(g%(R(g)(Z(g-(b(g1(j(g5(r(g9(z(g=(  F(g  )(g(g@Hqp |{eqv|/ H6 As this issue is somewhat controversial, it is not for inclusion in the mailing. I tried to at least go back and extract what I thought were David's previous arguments about this proposal and include them in the discussion section. Its been almost a year now since this was first brought up... we should get some closure soon. ! Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT References: UNWIND-PROTECT (p140, p142, p39) Issue IGNORE-ERRORS, Draft error proposal. Category: CLARIFICATION/CHANGE Edit history: Version 1 by Pitman 27-Feb-87 Version 2 by Masinter 24-Oct-87 Version 3 by Masinter 27-Oct-87 Version 4 by Masinter 13-Feb-88 Problem Description: If a non-local return is done while in the cleanup form of an UNWIND-PROTECT, the behavior is not always well-defined. There are three basic cases: Situation 0. Transfer to another point within the cleanup form. (UNWIND-PROTECT 3 (BLOCK NIL (RETURN 4)) (PRINT 'XXX)) There is no ambiguity about how this form is to be interpreted. Effectively: . 3 evaluates to itself, which is queued for return from the UNWIND-PROTECT. . The BLOCK expression is entered, 4 is returned to it and discarded because this is a not-for-value situation. . XXX is printed, XXX is returned by the PRINT and that value is discarded because this is a not-for-value situation. . The 3 which was yielded earlier is retrieved and returned as the value of the UNWIND-PROTECT. Situation 1. Transfer to a point inside the point to which control would have transferred. (CATCH 'FOO (CATCH 'BAR (UNWIND-PROTECT (THROW 'FOO 3) (THROW 'BAR 4) (PRINT 'XXX)))) This is a subject of controversy because: . 3 evaluates to itself and is saved by THROW which begins searching for tag FOO. . 4 evaluates to iself and is saved by THROW which begins searching for tag BAR. . Disagreement exists as to whether it is an error if the BAR tag is not found within the local dynamic scope of the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4) but is found within the scope of the target of the pending THROW (to FOO). Situation 2. Transfer to a point outside the point to which return would already have been. For example: (CATCH 'BAR (CATCH 'FOO (UNWIND-PROTECT (THROW 'FOO 3) (THROW 'BAR 4) (PRINT 'XXX)))) This is a subject of controversy because: . 3 evaluates to itself and is saved by THROW which begins searching for tag FOO. . 4 evaluates to iself and is saved by THROW which begins searching for tag BAR. . Disagreement exists as to whether it is an error if the BAR tag is not found within the local dynamic scope of the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4) but is found outside the scope of the target of the pending THROW (to FOO). What is the appropriate behavior for situation 1 and situation 2 and similar ones? For example, suppose that when WITH-OPEN-FILE tries to close the file upon unwinding, it signals an error, and the condition handler also attempts to throw? The question applies to all non-local transfers, whether performed by THROW, RETURN-FROM, RETURN, GO. Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL): In all cases, a transfer of control within an UNWIND-PROTECT cleanup form to a point outside of the UNWIND-PROTECT causes the original control transfer which initiated the execution of the cleanup forms to be abandonded. During the execution of the cleanup forms of an UNWIND-PROTECT a non-local exit to a point outside of the scope of the UNWIND-PROTECT, but still within the dynamic scope of of the target of the original non-local exit succeeds, and the original pending exit is discarded. For example, in Situation 1, the pending seek for tag FOO is discarded by the second THROW to BAR and the value 4 is transfered to (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...) then reurns the 4 because its first argument has returned normally. XXX is not printed. Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a point outside the original non-local exit, control is passed to the outer exit (and the pending original non-local exit is discarded.) For example, in Situation 2, the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed. In no case will UNWIND-PROTECT cleanup forms ever be attempted more than once. Rationale: The primary issues have to do with the safety of the language vs. the uniformity of the model behind non-local transfer of control. Current Practice: Some implementations generate garbage code in situations 1 and 2. Some have differing behavior compiled and interpreted. Most that have implementations seem to implement the proposed semantics for situation 2, but there is some divergence in Situation 1. For example, Spice Lisp and Xerox implement the proposed semantics, while Symbolics Common Lisp signals an error. Adoption Cost: While require some compiler modifications in some implementations, in most cases, that work was in order anyway since compilers may currently be doing nothing particularly useful or defensible with the code in question. Benefits: Having this situation uniformly treated seems critical: Programs that do this accidentally should behave the same on all systems so that bugs can be detected and fixed very early rather than being found later on a system which disagrees. Programs that do this on purpose generally are trying to do something fairly intricate and really need to be able to depend on it being uniformly treated. A portable error/signal system and debugger may be among these. For example, one programmer created his own "top level", to which the system "abort" character would return, by doing: (DEFUN MY-TOPLEVEL () (TAGBODY LOOP (UNWIND-PROTECT (REALLY-MY-TOPLEVEL) (GO LOOP)))) Aesthetics: This proposal is more intuitive to programmers who reason about programs in terms of continuation passing. It falls out of the normal scoping rules as a consequence of the fact that the cleaup code is evaluated in the lexical and dynamic environment in which the UNWIND-PROTECT form appears. The action of THROW is usefully described by saying that it is just like any other function. It happens to discard the current continuation, run some cleanup things (like variable unbindings and UNWIND-PROTECT actions), and transfer control elsewhere in the program. In doing so, the function uses data structure primitives not generally available to other programs, but it is not linguistically different and receives no special exemption with regard to THROWs or other non-local transfers of control done within its execution. A THROW from within an UNWIND-PROTECT cleanup is not different than one in any other code; it discards the ongoing action (stack unwinding) and replaces it by another action (as it happens, another stack unwinding). The previous unwind is never resumed. Conversion Cost: Most user programs don't do this so the cost of converting existing code is probably minimal. (There is some evidence that there are programs that expect this behavior, so there is no conversion cost for those programs.) Discussion: Two alternatives for situation 2 were seriously considered: that it should signal an error, and that it the second non-local exit instead continues the original (more extensive) one; e.g., in Situation 1, the second THROW to BAR would be discarded in lieu of continuing the THROW to FOO. Either of these alternatives would help prevent users from (either intentionally or unintentionally) creating situations where it is impossible to abort a computation with a THROW or other non-local return (e.g., an interrupt implemented via THROW.) For example, given (LOOP (CATCH 'FOO (UNWIND-PROTECT (LOOP) (THROW 'FOO T)))) With this proposal there is no way of exiting such a form. Signalling an error would prevent programmers from getting into this unfortunate situation. However, similar "unstoppable" loops can be created, without resorting to non-nested non-local transfers within UNWIND-PROTECT clauses; for example: (LABELS ((HA () (UNWIND-PROTECT (LOOP) (HA)))) (HA)) While it would be for a programmer to accidentally create such an unstoppable loop, the user has pretty clearly asked to have a loop that cannot be exited and deserves to have that request carried out. One implication is that it is likely that programming environments need to provide some mechanism other than THROW to stop a truly run-away computation. An interesting example which supports this proposal is one where there are two BLOCKs (block foo (block bar (unwind-protect (return-from foo 'foo) (return-from bar 'bar)))) Since there is no reason for FOO and BAR not to be treated interchangably, signalling an error in this situation would be inappropriate. To quote Guy Steele: "We have here a classic case of the irresistible force (QUIT, dammit!) versus the immovable mountain (UNWIND-PROTECT). I find that the suggestion that situation 1 produce an error, but one that IGNORE-ERRORS won't ignore, to be at least one level of epicycle too many. Which mechanism are to we regard as primitive: the error system or the catch/throw system? Or are they disjoint? I prefer, for simplicity, a model in which the error system can be explained. as much as possible, as a complex thing built on top of catch, throw, and unwind-protect." David Moon says: "Of the several alternative proposals for this issue, the only one that seemed appropriate to me has been removed. After re-reading the 12 messages on the topic that I thought were worth saving, I get the feeling that the issues have not really been clarified and that the discussion is largely dealing with strawmen. It seems like the cleanup committee is heading towards making a serious mistake here. Consider the form (loop (catch 'foo (unwind-protect (loop) (throw 'foo t)))) With the proposed semantics, it is impossible to stop this program except by hitting it with two throws in rapid succession, with exactly the right amount of delay between them so that the catch and unwind-protect have not yet been re-established when the second throw strikes. Consider any program-stopping operation that aborts execution by throwing to a catch in the top-level read-eval-print loop (control-G in Maclisp or c-Abort in Genera; most other systems have their own equivalent of this). With the proposed semantics, when this throw executes the unwind-protect cleanup handler, as it must, the throw will be abandoned and execution will resume looping. To me, the inability to stop a program is a much worse problem than providing so-called correct semantics for a contrived program that doesn't correspond to any real application. It was suggested that the error system might depend on the ability to abort throws like this. If that were demonstrated, I would change my tune, but until it's demonstrated I am completely skeptical of the notion that any error system would do this." FAILMasinter.pa Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)<326294.880213@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-#  55 5 55!5)5159 5A$5I(5Q,5Y05a45i85q<5y  $5 ( u55@HBp& KI!Bvv Hith the AI Lab.6,p (A)(Xz 0-HX 4 tx 1@ h l-:`,h!EP0#8$`$`t_titut?hGtUCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 19:47:30 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:39:47 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:39:54 PST Date: 13 Feb 88 16:39 PST From: Masinter.pa@Xerox.COM Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5) To: cl-cleanup@Sail.stanford.edu cc: Masinter.pa@Xerox.COM Message-ID: <880213-163954-10487@Xerox> This is another version that I apparently neglected to mail out. ! Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS References: Sequences (pp245-261) Issue REMF-DESTRUCTURING-UNSPECIFIED (discussion of NREVERSE, NSUBSTITUTE) Issue AREF-1D Category: ENHANCEMENT Edit history: 05-Feb-87, Version 1 by Touretzky 28-Apr-87, Version 2 by Pitman (variations on the theme) 26-Oct-87, Version 3 by Masinter (clean up for release) 11-Nov-87, Version 4 by Masinter (respond to comments) 5-Feb-88, Version 5 by Masinter Description: Common Lisp provides many useful operations on lists and vectors which don't apply to arrays. For example, one can FILL a vector with 0's, but not an array. One can REPLACE the contents of one vector with another, but one can't do this for arrays. One can verify that EVERY element of a vector has some property, but one can't do this for arrays, and so on. The programmer who wishes to use arrays instead of vectors must give up most of the useful tools CLtL provides for manipulating sequences, even though there is no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work on arrays. Common Lisp already provides a facility called "displaced arrays" which can be used to overlay one array on top of a portion of another, even if the two are of different ranks, so that the two share storage or use the awkward convention of creating a displaced array to the operand. However, creating a displaced array merely to perform FILL, REPLACE or EVERY is awkward. Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE): 1) Extend the definitions of sequence functions that either return their argument sequences or return non-sequences so that they also allow arrays of rank other than 1. These functions should treat array arguments as vectors displaced to the array storage (in row-major format). The affected functions are LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE, SORT. For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A 7) should return the same element as (AREF A 0 1 0). :START and :END keywords would be interpreted relative to the vector, as would the results returned by POSITION and SEARCH. 2) Extend the definitions of sequence functions whose result should be the same shape as but not necessarily EQ to some argument. These functions should deal with array arguments by returning an array of the same shape as the argument, and operate on their argument in row-major order. The affected functions are SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP. 3) Sequence functions that modify the number of elements in the array remain unchanged: it is an error to pass arrays of rank other than 1. (The functions are not extended because the shape would be undefined.) The unaffected functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES. Note that EQUALP does -not- treat arrays as vectors. It is not a sequence function, and it already has a well-defined behavior for arrays. To test whether the arrays A and B, of different shapes, have the same elements, one might write: (AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)). Rationale: This is a useful upward compatible extension with relatively low adoption cost. Cost to implementors: This would involve a lot of changes to functions, but all of the changes are likely to be minor. The presence of displaced arrays in the language already guarantees that the internal storage format needed to back up these proposed changes is already in place. Cost to Users: This change is upward compatible; current user code should run unmodified. Benefits: This proposal adds natural support for multi-dimensional arrays. Currently, users must write nested DO loops every time they want to perform an array operation equivalent to FILL, REPLACE, REDUCE, etc., or else they buld displaced vectors by hand and pass them to the sequence functions when necessary. With this proposal, users of arrays do not have to use home-grown utilities to duplicate functionality already primitively provided to users of arrays. The sequence functions become useful in a variety of new situations. Aesthetics: This proposal extends sequence functions to cover arrays while neatly avoiding the temptation to turn Common Lisp into a half-baked APL. Instead of trying to provide a full set of array handling primitives (which would be needed to take arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an operator across a specific dimension of a multidimensional array), it requires just one rule: treat arrays as displaced vectors where it is well-defined. Current Practice: We know of no current implementation of this proposal. Discussion: This issue was discussed by the cleanup committee at length; what follows is only a brief summary of the discussion. An alternative considered was to only affect those functions which didn't explicitly depend on the shape of the array; that is, to modify COUNT, SOME, EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and expressly forbid arrays as arguments to other sequence functions, including LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT, MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes only those functions which do not deal with positional information. Some hedging over REDUCE and FIND, which often have non-positional uses, were considered. Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been building displaced vectors to pass to sequence functions when necessary and really dislikes it. We considered but discarded as unworkable an alternative where POSITION and FIND might deal with "positions" as lists of array subscripts. At one point, this proposal included an extension to COERCE to allow COERCE to translate from array types to sequences, but it was thought better to separate out COERCE. We considered a proposal to only introduce a change to COERCE, and require users who want to operate on arrays explictly perform, e.g., (COUNT item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost but was deemed awkward. Sequence functions like FILL and COUNT are already generalized to arrays in non-Lisp contexts; in English we use the generalized forms all the time, e.g., "count the number of 1's in this matrix." There is some concern that this proposal makes the requirement for row-major ordering of internal storage for arrays even more evident. While such an internal ordering is implied by the ability to create displaced arrays and the AREF-1D proposal, this proposal adds yet another constraint. The general reason for opposing this change is that it adds more mechanism than it is worth. The general reason for liking it is that it adds generality at little cost. FAILMasinter.pa Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)<326277.880213@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! A(g( (g((g ((g ("(g(*(g(2(g(:(g(B(g!(J(g%(R(g)(Z(g-(b(g1(j(g5(r(g9(z(g=(  (g )(g(g@H, (A0K.f, xE H6'+p (A)(X4 0HXX 4 tx @ t l(f`,4 cP8``7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 19:35:49 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:30:13 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:28:49 PST Date: 13 Feb 88 16:28 PST From: Masinter.pa@Xerox.COM Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3) to: cl-cleanup@Sail.stanford.edu cc: Masinter.pa@Xerox.COM Message-ID: <880213-162849-10481@Xerox> very minor edits here ! Issue: REDUCE-ARGUMENT-EXTRACTION References: REDUCE (pp. 251-252), :KEY arguments (p. 246), the astronaut structure (pp. 312-313) Category: ADDITION Edit history: Version 1 by Pierson 5-Dec-87 Version 2 by Pierson 30-Dec-87 Version 3 by Masinter 13-Feb-88 Problem description: REDUCE is the only one of the Common Lisp functions that modify or search lists and sequences which does not accept a :KEY argument. This complicates many uses of REDUCE. Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY): Change the definition of REDUCE to take a :KEY keyword described as follows: If a :KEY argument is supplied, its value must be a function of one argument which will be used to extract the values to reduce. The :KEY function will be applied exactly once to each element of the sequence in the order implied by the reduction order but not to the value of the :INITIAL-VALUE argument, if any. Test Cases/Examples: Using REDUCE to obtain the total of the ages of the possibly empty sequence of astronauts ASTROS, would currently require: (REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS)) If this proposal is adopted, the same result could be obtained without creating a new list by: (REDUCE #'+ ASTROS :KEY #'PERSON-AGE) Rationale: This proposal makes many common situations where REDUCE would be useful much less cumbersome. Current practice: We know of no implementation which currently supports this feature. Cost to Implementors: This will require most implementations to make a trivial modification to REDUCE. Implementations which wish to use this as an opportunity to further optimize compiled calls to REDUCE will have to undertake more work (which would be much more difficult today). Cost to Users: None, this is an upward compatible extension. Cost of non-Adoption: REDUCE will continue to be more difficult to use than other sequence functions on sequences of complex objects. Benefits: REDUCE will become easier to use on sequences of complex objects. It will be easier for compilers to convert some calls to REDUCE into efficient loops. Aesthetics: Slightly damaged in one way. All :KEY arguments are currently defined to be used for predicates, this proposal will implicitly broaden :KEY to support general extraction for any purpose. Slightly improved in another way. Many common situations where REDUCE could be used would be easier to write and easier to later read. Discussion: Several members of the committee feel that the increased functionality outweighs the damage to the definition of :KEY. No one has objected to this change in the recent round of discussions. There is some controversy over whether the "definition" of :KEY arguments on page 246 of CLtL really constitutes a definition or just an "unwritten rule". FAILMasinter.pa Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)<326269.880213@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWgYN-# A55 5 55!5)5159 5A$5I(5Q,5Y05a45i85q<5y  35 ( u55@H :A)8 Hith the AI Lab.6!p ( (X@ 0OHX( 4 tx S@ h- l!]`,h0cP0283`3`t_titut?hGtUCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 19:24:07 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:15:04 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:15:39 PST Date: 13 Feb 88 16:14 PST From: Masinter.pa@Xerox.COM Subject: Issue: FUNCTION-TYPE (version 9) TO: CL-CLEANUP@SAIL.STANFORD.EDU LINE-FOLD: NO cc: Masinter.pa@Xerox.COM Message-ID: <880213-161539-10473@Xerox> I've left the CONSERVATIVE proposal pretty much intact, and attempted to add back in the STRICT-REDEFINITION proposal as an alternative proposal with a shared cost/benefit analysis. We really owe X3J13 a version they can vote on, and I think that this is one issue that is big enough and thorny enough that we can ask for votes on more than one alternative. ! Issue: FUNCTION-TYPE References: functions (p32), types (p33), FUNCTIONP (p76), SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52) Category: COMPATIBLE CHANGE Edit History: 26-Feb-87, Version 1 by Gabriel 15-Mar-87, Version 2 by Cleanup Committee 10-May-87, Version 3 by Fahlman 29-May-87, Version 4 by Masinter (incorporate comments) 15-Jun-87, Version 5 by Fahlman (include two options) 23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION) 09-Nov-87, Version 7 by Masinter (minor cleanup) 14-Nov-87, Version 8 by Pitman (major restructuring) 13-Feb-88, Version 9 by Masinter, (add back 2nd option) Problem Description: The definition of the term ``function'' in CLtL includes all symbols and many lists in addition to `true' functions. Also, page 47 of CLtL states that the FUNCTION type specifier can only be used for declaration and not for discrimination. Some of the original Common Lisp designers maintain that this restriction on the use of the FUNCTION specifier was meant to apply only to long-form FUNCTION specifiers, but since this intent was not explicitly stated, the status of FUNCTION as a type is blurred. A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably be relied upon to be equivalent to (TYPEP x 'FUNCTION). Proposal FUNCTION-TYPE:CONSERVATIVE 1. Introduce a new type PROCEDURE that can be used both for declaration and discrimination. 1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE are pairwise disjoint. In particular, a list may not be used to implement any PROCEDURE subtype. 1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE. Implementations are free to define other subtypes of PROCEDURE. 1c. Introduce a new function, PROCEDUREP, such that (PROCEDUREP x) == (TYPEP x 'PROCEDURE). 2. Define that a ``function'' may be a procedure, a list whose car is the symbol LAMBDA, or any symbol (whether fbound or not). 2a. Clarify that the FUNCTION type behaves as if it had been defined by: (DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA))) (DEFTYPE FUNCTION () `(OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE)) 2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION). This change is compatible. 2c. Clarify that the list form of the FUNCTION type specifier may still only be used for declaration. 2d. Clarify that the symbol form of the FUNCTION type specifier may be used for type discrimination. 2e. Clarify that FUNCALL and APPLY continue to accept functions as arguments. However, some implementations may produce better code for expressions such as (FUNCALL (THE PROCEDURE ...) ...) or (APPLY (THE PROCEDURE ...) ...). 3. Clarify that the result of a FUNCTION special form must be a procedure. 3a. This implies that some (FUNCTION name) may be implicitly interpreted as (THE PROCEDURE (FUNCTION name)). As such, the potential optimizations mentioned in 2e are also possible for (FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...). 4. Clarify that it is an error to use the special form FUNCTION on a symbol that does not denote a function in the lexical environment in which the special form appears. Specifically, it is an error to use the FUNCTION special form on a symbol that denotes a macro or special form. 4a. Some implementations may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a `useful' behavior. 5. Clarifythat it is permissible for FBOUNDP to return true for a macro or special form, and that it is permissible to call SYMBOL-FUNCTION on any symbol for which FBOUNDP returns true. 5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true but the symbol denotes a macro or special form is not well-defined, but SYMBOL-FUNCTION will not signal an error. 5b. Assuming that symbol is fbound, (PROCEDUREP (SYMBOL-FUNCTION symbol)) implies (AND (NOT (MACRO-FUNCTION symbol)) (NOT (SPECIAL-FORM-P symbol))). 5c. The effect of (SETF (SYMBOL-FUNCTION symbol) non-procedure) is not defined. Implementations are permitted to signal an error, but they are also permitted to define useful (non-portable) interpretations. 5d. The motivation for this distinction between FUNCTION and SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day use within programs while SYMBOL-FUNCTION is a data structure accessor used primarily for meta-level applications and not recommended for general use. It is provided primarily to complete the set of accessors on symbols. Implementations are permitted, but not required, to store information about a global macro-function or special form in the function cell. This definition of SYMBOL-FUNCTION is intended to leave enough freedom for such implementations to conveniently implement FUNCTION, SPECIAL-FORM-P, and MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying subprimitive. 6. COERCE is extended to allow objects to be coerced to type procedure. 6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the given symbol, signalling an error if SYMBOL is not fbound or if the contents of the symbol-function cell is not a procedure. 6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to (EVAL `(FUNCTION ,lambda-expression)). 7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function. The function is coerced to a procedure before being called as the expansion interface hook by MACROEXPAND-1. ! Proposal FUNCTION-TYPE:STRICT-REDEFINITION STRICT-REDEFINITION is similar to CONSERVATIVE, except that it redefines the type FUNCTION instead of adding a new type PROCEDURE, and it restricts coercion by functions that take functions as arguments. The numbering of CONSERVATIVE is preserved for comparison. 1. Redefine the type FUNCTION so that it can be used for discrimination as well as declaration. 1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are pairwise disjoint. In particular, a list may not be used to implement any PROCEDURE subtype. 1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION. Implementations are free to define other subtypes of FUNCTION. 2. Define that a ``function'' as used throughout the CLtL is restricted to be exactly those objects of type FUNCTION. 2a. This type no longer includes objects of type SYMBOL or lists with CAR = LAMBDA. 2b. The behavior of FUNCTIONP is defined to be exactly equivalent to #'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible change. 2c. Clarify that the list form of the FUNCTION type specifier may still only be used for declaration. 2d. Clarify that the symbol form of the FUNCTION type specifier may be used for type discrimination. 2e. Change FUNCALL and APPLY such that they accept only a function as the functional argument. This restriction is inherited by all functions in Common Lispthat take a functional argument. It is no longer legal to pass a symbol or lambda expression as the functional argument to any of these functions; to do so "is an error". 3. Clarify that the result of a FUNCTION special form must be a function. 3a. This implies that some (FUNCTION name) may be implicitly interpreted as (THE FUNCTION (FUNCTION name)). 4. Clarify that it is an error to use the special form FUNCTION on a symbol that does not denote a function in the lexical environment in which the special form appears. Specifically, it is an error to use the FUNCTION special form on a symbol that denotes a macro or special form. 4a. Some implementations may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a `useful' behavior. 5. Clarify that it is permissible for FBOUNDP to return true for a macro or special form, and that it is permissible to call SYMBOL-FUNCTION on any symbol for which FBOUNDP returns true. 5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true but the symbol denotes a macro or special form is not well-defined, but SYMBOL-FUNCTION will not signal an error. 5b. Assuming that symbol is fbound, (FUNCTIONP (SYMBOL-FUNCTION symbol)) implies (AND (NOT (MACRO-FUNCTION symbol)) (NOT (SPECIAL-FORM-P symbol))). 5c. The effect of (SETF (SYMBOL-FUNCTION symbol) non-procedure) is not defined. Implementations are permitted to signal an error. 5d. The motivation for this distinction between FUNCTION and SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day use within programs while SYMBOL-FUNCTION is a data structure accessor used primarily for meta-level applications and not recommended for general use. It is provided primarily to complete the set of accessors on symbols. 6. COERCE is extended to allow objects to be coerced to type procedure. 6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the given symbol, signalling an error if SYMBOL is not fbound or if the contents of the symbol-function cell is not a procedure. 6b. (COERCE lambda-expression 'FUNCTION) is equivalent to (EVAL `(FUNCTION ,lambda-expression)). 7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a function before being called as the expansion interface hook by MACROEXPAND-1. ! Rationale: Since the two proposals are similar, they are discussed together. Where motiviation and justification differ, the proposals are referred to by name (STRICT-REDEFINITION, CONSERVATIVE.) The fuzzy definition of ``function'' has descended from older dialects of Lisp, such as Maclisp. Many places in existing code make assumptions about the current meaning, making any change painful. It is very important both for documentation clarity and for program type discrimination (such as CLOS) to have a clear term which denotes a ``true function.'' CONSERVATIVE manages a compatible definition with most existing uses of the term ``function'' while providing a graceful upgrade path to the term ``procedure'' for use in situations that call for a higher degree of clarity. STRICT-REDEFINITION avoids introducing a new term at the cost of incompatible change. Current Practice: In some implementations, (TYPEP x 'FUNCTION) signals an error. In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x). In some implementations, (TYPEP x 'FUNCTION) is the same as what this new proposal calls (TYPEP x 'PROCEDURE). Implementations vary on what my go into the function cell, depending on how much error checking they want to have to do at function call time, and depending on whether they store other kinds of information (such as special form information) in the function cell. Few current Common Lisp implementations are likely to have exactly the semantics described in either. CONSERVATIVE is more compatible with current practice than STRICT-REDEFINITION, however. Cost to Implementors: Bringing type predicates (FUNCTIONP, etc.) and higher order functions (APPLY, etc.) into compliance should require little effort in most implementations. While STRICT-REDEFINITION makes it an error to pass non-function arguments to APPLY, FUNCALL etc, there is no requirement to check for that error. Compiled functions are true functions in almost all current implementations, but in some implementations interpreted functions and closures stored in the function cell of a symbol are represented as lists. Under this proposal, such lists would have to be changed to be procedures (implemented either as structures or to some special internal data type). The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be modified to deal with functions that are not lists (but from which the list form can be reconstructed if necessary). Cost to Users: The conversion cost associated with CONSERVATIVE is very low because the model of FUNCTIONP which it takes is largely consistent with existing practice. The new features introduced by CONSERVATIVE, particularly the PROCEDURE data type, can be converted to fairly lazily. The conversion cost for the STRICT-REDEFINITION proposal is higher. The changes to FUNCTIONP and the FUNCTION type declaration is relatively easy to deal with. However, the strict redefinition of FUNCALL, APPLY and functional arguments will require the addition of an explicit coercion would have to be added whenever a symbol or lambda expression is used as a functional argument. Many such cases can be identified at compile time, but not all. Some implementations might provide tools to assist in detecting implicit coercion of symbols to functions. For example, an implementation might add run-time test in which the implementation still does the coercion but that issues a warning message whenever the coercion is actually needed. Alternatively, a "smart" code-walker or editor macro might find all of the calls to FUNCALL, APPLY, and the 61 Common Lisp functions that take :TEST or :KEY arguments and, if the argument is not already an explicitly quoted FUNCTION form, wrap a COERCE around the body. For either proposal: Because CLtL's language was somewhat fuzzy about what might go into the function cell of a symbol, some code that explicitly deposited symbols or lists in a symbol's function cell might have to change. Such code was already not portable, however, since some implementations signal an error when this is done. Benefits: For CONSERVATIVE: The term ``function'' would be given a useful meaning that was relatively compatible with existing usage. A new term ``procedure'' would be available for descriptional clarity. The new PROCEDURE datatype would be useful for type discrimination in CLOS. For STRICT-REDEFINITION: The term ``function'' would be given a useful and precise meaning. The FUNCTION datatype would be useful for type discrimination in CLOS. STRICT-REDEFINITION provides useful constraints which will be of aid to systems doing automatic program analysis for the purpose of ``selective linking.'' Such tools may in turn make it possible to reduce the total size of a delivered application program because only those Common Lisp functions that are actually called need to be included. For either proposal: The type hierarchy would be simplified. Either proposal brings Common Lisp into closer alignment with Scheme and the work of the EuLisp committee. Scheme, for example, also has the concept of a ``procedure'' which is compatible with this proposal. Aesthetics: Both proposals improve the aesthetics of the language. Discussion: These proposals have been discussed at great length; this section attempts only to summarize the important points. There is general agreement that the definition of the FUNCTION data type must be clarified or revised. The cleanup of the type hierarchy is important to the CLOS group. The description of COMPILE must be changed, since it is no longer meaningful to speak of a symbol with a definition that "is a lambda-expression". We believe this is a subject for a separate proposal, as the behavior of COMPILE needs additional clarification. Many different alternatives have been discussed both in the cleanup committee and X3J13. These two proposals are the distillation of the alternatives. The CONSERVATIVE proposal offers the advantage of backward compatibility, and considerably more flexibility in the language. The STRICT-REDEFINITION proposal offers the advantage of a slightly cleaner resulting language. Some concerns were raised about STRICT-REDEFINITION in a previous discussion about "late binding" of function definitions. Neither proposal disallows late binding of symbols to functions. For example, in the call (MAPCAR #'FROB my-list) the effect of the FUNCTION special form (as generated by the #' read macro) is to obtain the function definition of FROB at the time the #'FROB is evaluated. Neither proposal changes this. Currently, it is allowed to write (MAPCAR 'FROB my-list) while this form would no longer be allowed under the STRICT-REDEFINITION clause. Currently, neither CLtL nor the CONSERVATIVE proposal addresses the question of the time at which FROB's function definition is obtained; if, during the processing of my-list, FROB is redefined, it is not clear whether the processing of subsequent elements would be changed. FAILMasinter.pa Issue: FUNCTION-TYPE (version 9)<326264.880213@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  &g& &g&&g &&g &"&g&*&g&2&g&:&g&B&g!&J&g%&R&g)&Z&g-&b&g1&j&g5&r&g9&z&g=&  m&g $ '&g&g@Hj>  p^nqjD H53p (c(XU 0SHX* 4 tx W@ ta kX`,4g 5Pk8m`m`   <hNh.@HCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 16:40:57 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 13:33:42 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 13:33:24 PST Date: 13 Feb 88 13:32 PST From: Masinter.pa@Xerox.COM to: cl-cleanup@Sail.stanford.edu Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3) Message-ID: <880213-133324-10349@Xerox> This apparently did not get mailed before. This issue is too simple to present two proposals. I've tried to represent TEST-FOR-REMAINING-SUBLISTS as the single proposal and eliminate TEST-FOR-REMAINING-ARGUMENTS. ! Issue: FORMAT-COLON-UPARROW-SCOPE References: CLtL p. 406 and also p. 403 Category: CLARIFICATION Edit history: version 1: Guy Steele, 30 November 1987 version 2: Guy Steele, 18 January 1988 version 3: Masinter, 5 February 1988 Problem description: Implementations currently differ on the question of what is tested by the FORMAT command "~:^". Some implementations test to see whether any arguments remain in the sublist for the current iteration step; others test to see whether any sublists remain. The text on page 406 is not clear on this point. Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS): ~:^ may be used only if the command it would terminate is ~:{ or ~:@{. The entire iteration process is terminated if and only if the sublist that is supplying the arguments for the current iteration step is the last sublist (in the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:^ is *not* equivalent to ~:#^; the latter terminates the entire iteration if and only if no arguments remain for the current iteration step. Test Cases/Examples: (format nil "~:{~@?~:^...~}" '(("a") ("b"))) Under this proposal, this yields "a...b", rather than "a". Rationale: This proposal is desirable because otherwise there is no way to test whether any sublists remain. The text on page 406 may be construed to hint at this proposal indirectly. To quote Nick Gall: If one thinks about the intent of the parenthetical (because in the standard case it tests for remaining arguments of the current step only) one should agree that "a...b" will be returned. In referring to ~^ as the "standard case", which tests the arguments remaining in the current argument sublist, this parenthetical implies that there is an `other case', which tests `something else.' The only `other case' discussed is ~:^, which therefore must test `something else.' I claim that the parentheical makes no sense if we interpret ~:^ as testing the same condition as ~^. If they both test the same condition, why have the parenthetical explanation? If ~:^ doesn't test the same condition as ~^, then what does it test? I claim that the only test that makes sense is for ~:^ to test the only thing that affects the "entire iteration process:" the number of sublists. When there are no more sublists, "the entire iteration process" is terminated. Current practice: Some implementations already have the proposed behavior, include Symbolics Common Lisp and TI Lisp. Many other implementations currently have a different interpretation: the test case returns "a", since ~:^ in those implementations test for the remaining arguments rather than remaining sublists. These currently include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP. Cost to Implementors: Many implementations will have to make a small change, probably a one-liner. Cost to Users: It is unlikely that much user code depends on the behavior of testing for remaining arguments, but it is possible. The author of this writeup (Steele) judges it somewhat more likely that user code might depend on the behavior of testing for remaining sublists.. Cost of non-adoption: Users would have to be warned not to use ~:^ in code that is meant to be portable. Benefits: Elimination of yet one more ambiguity. The proposed semantics allows greater semantic power (there are more things one can test). Esthetics: ``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr. Discussion: Guy Steele very strongly prefers the interpretation FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. Kevin Layer and Rich Robbins have spoken in favor f an alternative proposal, to test for the remaining arguments. Historical note: Steele first implemented this "feature", in Zetalisp, and so the code in Symbolics Common Lisp is likely a direct descendant of the original code. This might cause some to give weight to Steele's opinion. There are two arguments against such credence. First, there is no reason why the original code should be regarded as part of the specification of Common Lisp any more than any other implementation; plainly, Steele botched the specification when he wrote the book. Second, a professor of literature (I believe) once told Isaac Asimov concerning a short story of his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the story, what makes you think you know what it means?" FAILMasinter.pa Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)<326194.880213@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOW eYN-! A"g" "g""g ""g """g"*"g"2"g":"g"B"g!"J"g%"R"g)"Z"g-"b"g1"j"g5"r"g9"z"g="  ""g 4 #"g"g@H, A6f5d, H4Mp ((X 0 H( 1 $/x ` 3@ h  hMp`,h  AP0 !8 "` "`x(CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 02:46:02 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 23:37:24 PST Received: by labrea.Stanford.EDU; Fri, 12 Feb 88 23:37:47 PST Received: from bhopal.lucid.com by edsel id AA19656g; Fri, 12 Feb 88 23:26:38 PST Received: by bhopal id AA13404g; Fri, 12 Feb 88 23:31:35 PST Date: Fri, 12 Feb 88 23:31:35 PST From: Jon L White Message-Id: <8802130731.AA13404@bhopal.lucid.com> To: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU Subject: Issue: SETF-SUB-METHODS Ken Olum and I [JonL White] have given some thought to the problem that spurred the issue SETF-METHOD-FOR-SYMBOLS, and feel that the issue as stated attacks a small manifestation of the problem rather than the root underlying case. Worse yet, the TEMPORARY-VARIABLE proposal requires a change which creates a bug in another area of SETF usage [see below]. We propose that the problem lies in understanding of how SETF works when the SETF expansion for a form like ( ...) involves the sub-recursive SETF expansion of , or in other words, when the accessing technique isn't fully specified just by looking at the get-setf-method of . The class of such 's is enumerated in CLtL, at the top of p96, except that GETF is missing from that list [we propose that it be added there in the next manual]. This message will propose a clarification the issues of left-to-right evaluation in such cases, and will also detail the actions that should be taken by SETF methods on each of these place-types. ! ISSUE: SETF-SUB-METHODS References: CLtL pp. 95-96, 99, 105-106, 166 Issue: PUSH-EVALUATION-ORDER Issue: SETF-METHOD-FOR-SYMBOLS Category: Clarification Edit history: Version 1 JonL & KDO 12-Feb-88 Problem description: Tim Daly of IBM noticed that several implementations do not observe left-to-right order of evaluation in the following form: (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) In these implementations, the side-effect of the setq happens before the evaluation of the "subforms" necessary to fetch the list being updated. A typical result is that 'r' = (B 6), 's' = (A 1 B 2 C 3) after the operation. Surely, it should at least be the case that 's' = (A 1 B 6 C 3), since the expectation is that the B property in this list is being (destructively) changed. Similar problems exist with LDB and CHAR-BIT. It is not necessary to clarify that left-to-right order of evaluation semantics should be observed; CLtL p99 is quite explicit about that. Rather, a distinction needs to be made between the computations involved in "evaluation" of the subforms, and other computations that are implicit in the notion of "doing an access" or "doing a store". Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES Elaborate the documentation of SETF, especially in the case of access forms whose sub-forms are permitted to be generalized variable references [and thus which need to call GET-SETF-METHOD during setf macro expansion]. We remember that GET-SETF-METHOD returns the following: Some temporary variables A list of value-producing forms A list of store-variables (normally one). A storing form. An accessing form. Then we want to say that: Code generated using GET-SETF-METHOD does 2 or 3 of the following things: It evaluates the value-producting forms, and binds the temporary variables to them. This will be called "binding the temporaries." It evaluates the accessing form to get the old value of the place. This will be called "doing the access." It binds the store-variable to a new value and calls the storing form to install it in the place. This will be called "doing the store." The forms listed at the top of CLtL p96 permit recursive specifiers; for each one, we will describe how the sub-recursive information from GET-SETF-METHOD is used. LDB: In a form such as (SETF (LDB ) ) the place referred to by the must always be both accessed and updated. Even if the refers to a bignum, the bignum itself will not be modified but rather a new bignum stored in the . Thus this SETF should generate code to do the following: 1. Evaluate 2. Bind the temporaries for 3. Evaluate 4. Do the access to 5. Do the store into with the given bit-field replaced with the value from step 3. If the evaluation of in step 3 sets a different bit-field in the given place then since the access is done later at step 4 this change will be preserved. See ROTATEF example in discussion below. Nevertheless the evaluations required for binding the temporaries are done in step 2, and thus the expected left-to-right evaluation order is seen. GETF: The case of GETF is complicated by the fact that two different "place" locators are involved: one to use if the specified indicator is present in the property list, and another if not. For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot of the array is NIL, then that slot must be changed, but if it contains a list with the property B then only the cons cell with that property value needs to be changed. This decision cannot be made at macro-expansion time. It depends entirely on the contents of the list in question, and so must be delayed until the last possible moment. In the first place, GETF should be listed among the other place forms that admit place forms as one of their arguments. See CLtL at the bottom of p95 and the top of p96. More specifically, the expansion of (SETF (GETF ) ) should generate code to do the following: 1. Bind the temporaries for 2. Do the access to [Binding the temporaries and then doing the access is equivalent to evaluating the .] 3. Evaluate [and save the result in a temporary variable]. 4. Check whether the value from 2 has the indicator from 3. If so: 5A. Find cons-cell after indicator from above 6A. Evaluate 7A. RPLACA cons-cell from 5A with value from 6A [In this case, we do not do a store into . When the indicator is already present then the location specifed by doesn't need a new value.] If not: 5B. Evaluate 6B. Do the access to , using the temporaries saved from step 1 [this is not another evaluation -- but it may involve some non trivial computation, depending on how complex the access method really is.]. 7B. Do the store into , again using the temporaries saved from step 1, setting it to a list with indicator from 3, new value from 5B, and old list from 6B. Test Cases: (setq integer #x69) (rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer)) Rationale: As a principle, (setf (foo-a x) (setf (foo-b x) ...)) should always set both of the "slots" of X, even if these slots are implemented as bit-fields, getf-properties, and so on. However, (setf (foo-a x) (setf (foo-a x) ...)) is an error [that is, what happens is undefined.] Current Practice: -- Xerox and Franz already operate on GETF according to this perscription. -- Symbolics and Lucid differ by always doing a setf on the variable rather than updating the appropriate cons cell of the property list; additionally, they fail to connect the new value put into 'r' to the original property list which was 'r's value initially. -- HP and VAX Common Lisps update the cons cell, but then set the variable 'r' again, nullifying the effect of the "(setq r nil)" in the computation. Adoption cost: Several implementations would require several hours of programmer and documentation time. Cost of non-adoption: Users will think SETF is unnatural in that left-to-right order of evaluation isn't always observed. Benefits: Uniform semantics and portability in the face of recursive "place specifiers" for SETF. Setf of (LDB ... ) and of (GETF ...) will behave uniformly no matter the nature of the . Anyone who has copied examples from p105 and p106 will continue to be able to use them. Conversion Cost: This is a clarification of a point not sufficiently elaborated in CLtL. Symbolics and Lucid are already modifying their interpretation of this code -- in some way or other. Esthetics: See "Cost of non-adoption" Discussion: In the case that spurred this discussion, (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) the consequent update is a RPLACA to some list cell -- not a setf of the variable 'r' -- and thus 'r' should be NIL and 's' should now be (A 1 B 6 C 3). There is an interesting parallel between this case for GETF and the very common mistake made by Lisp programmers with respect to the function DELETE. How often the complaint is filed that DELETE didn't do anything when it should have; but in fact the filer simply forgot that delete can either update some CAR slot of the list originally given it, or return some tail of the list originally give it, but not both! E.g. (setq l '(a a b c d)) ==> (a a b c d) (delete 'a l) ==> (b c d) l ==> (a a b c d) The unwary user thinks that because 'l' is still eq to the original value that "DELETE didn't do anything". The variability of action at runtime here parallels the variable choice of location specifier for (SETF (GETF ...) ...) A previous proposal to fix this problem was misdirected. It was phrased as follows: Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE Change the result of (get-setf-method 'foo) from NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO to (#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175 The problem with this is that it breaks a relatively simple client of setf technology: (setq integer #x69) (rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer)) no longer does the "right thing". Using the prescription for setf methods on symbols from CLtL p105, the result of this 'rotatef' is that integer = #x96; using that given by the TEMPORARY-VARIABLE proposal leads to either #x99 [or #x66 depending on which order the implementation chooses to do the actual stores in]. In addition, if 'integer' is replaced by '(car x)' here, then the behavior is different under the TEMPORARY-VARIABLE proposal because that only applies to symbols. Implicitly, two "places" are being specified here to be updated; but in fact the two places are not independent -- they both involve setq'ing the variable 'integer'. Furthermore, each store operation implicitly requires fetching the value from that place in order to combine it with DPB. It is necessary to delay the accesses until the last moment before combining with DPB in order to see the side-effects of the earlier store operations. FAILedsel!jonl Issue: SETF-SUB-METHODS<325992.880213@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  a1a1 a1a1a&1a.1a61a>1#aF1'aN1+aV1/a^13af17an1;av1?a~1  pa  aa@H  =k ~ H1>?p (-(X#H 0H h hx 4@ hj b@,`,hmP0o8p`p`7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 88 11:18:55 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 08:13:07 PST Received: from NRL-AIC.ARPA by labrea.Stanford.EDU with TCP; Fri, 12 Feb 88 08:12:32 PST Return-Path: Received: Fri, 12 Feb 88 11:11:02 EST by nrl-aic.arpa id AA02816 Date: 12 Feb 1988 10:22:34 EST (Fri) From: Dan Hoey Subject: Package Odor Message-Id: <571677767/hoey@nrl-aic.arpa> To: mike%acorn@live-oak.lcs.mit.edu Cc: RWK@ai.ai.mit.edu, hilfingr%tully.Berkeley.EDU@ucbvax.berkeley.edu, common-lisp@sail.stanford.edu, CL.BOYER@r20.utexas.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Date: Thu, 11 Feb 88 19:26 est From: mike%acorn@oak.lcs.mit.edu ...My experience is that no one wants to qualify any names so what they do is carefully use every package that they've ever seen, not realizing that (let ((string "abcd")) ....) in their code is creating a spec-bind because they are using a package where string is a special.... Note that this is not *quite* the problem, since STRING is a symbol in the LISP package, and anyone who is using random packages must surely use LISP. In that case it is the error of the other package in proclaiming a symbol of the LISP package SPECIAL (or CONSTANT), and you couldn't defend against the error by not using that package. That this is an error should be made explicit--I once broke the compiler by proclaiming LISP:FUNCTION constant, and the compiler wanted to bind it in a macroexpansion. Making it SPECIAL might have screwed things up beyond hope of diagnosis. The problem of using every package is still there, though. You should know the names of all the symbols you import (including all the symbols exported from packages you use), not only so you don't get surprised about them being special, but so you don't accidentally make them special when they shouldn't be. What the package system buys you is letting this not be all the symbols in the world. Dan FAILhoey Package Odor<325548.880212@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  g gg g "g*g2g:gBg!Jg%Rg)Zg-bg1jg5rg9zg=  g $ gg@He  $#;qz H(qp ((Xc 0 HP $/@ h QL` ,h P0 8 ` `8Mv 7aPP2LVp 04]0* W6Y-b8Mv&H6$@CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Feb 88 05:08:08 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 02:02:58 PST Received: by labrea.Stanford.EDU; Wed, 10 Feb 88 02:02:57 PST Received: from bhopal.lucid.com by edsel id AA05180g; Wed, 10 Feb 88 01:45:42 PST Received: by bhopal id AA05095g; Wed, 10 Feb 88 01:50:27 PST Date: Wed, 10 Feb 88 01:50:27 PST From: Jon L White Message-Id: <8802100950.AA05095@bhopal.lucid.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU, labrea!Hornig%ALDERAAN.SCRC.Symbolics.COM.labrea!moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU In-Reply-To: Kent M Pitman's message of Mon, 8 Feb 88 13:57 EST <880208135758.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE You are asking a broader set of questions that Horning apparently didn't want to address in his original cleanup proposal. There are a plethora of issues related to this -- the whole semantics of declarations in Common Lisp seems to be in disarray now. I think these broader issues must be raised, and that is one reason why what started out as a very small clarification has grown into a much larger controversy. Perhaps it was premature to think we could take the dragon by the tail and not feel his hot breath too. I would actually like to see a *coordinated* set of cleanup issues on declarations. "Coordinated", because it often doesn't make sense to talk about these issues in isolation; witness the extremely close link of this scoping proposal with the FLET-DECLARATIONS:ALLOW proposal. If this proposal -- DECLARATION-SCOPE:LIKE-VARIABLE is to be seriously considered in isolation, the I would at least like to suggest an alteration as outlined below. First, a very brief overview of the proposal: Hornig's purpose stated in the original message of "Tue, 5 Jan 88 08:21 EST" was: . . . The issue is whether the scope of some or all of the declarations includes code appearing in the non-body part of the special form containing the declaration. . . . `Normal' declarations are made to control a particular binding of a variable and should be scoped the same way as that binding. This is as true of `normal' declarations which were pervasive under the old rules as it is of those that were not. So the original DECLARATION-SCOPE proposal would seem to be addressing the specific kinds of problem illustrated by this example: (setf (symbol-value 'x) 0) (trace car) (defun foo (x y) (let ((x (car y)) (car (+ 4 x))) (declare (special x) (inline car +)) (list car (car x)))) A reasonable test, after compiling [and hypothetically assuming that a call to CAR that isn't declared "inline" will go out-of-line] works like: (foo 4 '((hello))) ==> {fn: CAR, arglist: ( ((hello)) )} ;trace output (8 hello) namely, that unlike in some implementations, the special declaration does not apply to the form "(+ 4 x)", and further, the inline declaration applies to "(car x)" but not to "(car y)". But still a lot of issues are left open. [One of them, for example, is how to say that the inline declaration of "car" above doesn't apply to the binding of the variable "car" established in the special form in which the declaration occurs 'normally'. It seems obvious to a reader with intuition; it's not so obvious from reading all the legalese and generalizations of a formal prescription.] I call attention again to Hornig's guiding principle: `Normal' declarations are made to control a particular binding of a variable and should be scoped the same way as that binding. I think it would be a great simplification that declares in a binding special form (like, LET, PROG, LABELS, etc) should either "control a particular binding" and thus by definition have the scope of that binding [and nothing more], or be scoped as follows. For those declarations that in a binding special form that don't correlate with any of the bindings being established -- like the inline declaration for "+" in the example above -- their scope should be the same as if there had been a "variable" in the binding list for it to "control". That is, rather than (let ((z (+ 4 x))) (declare (special z) (inline +)) (+ z 5)) being equivalent to (locally (declare (inline +)) (let ((z (+ 4 x))) (declare (special z)) (+ z 5))) I think it would be more consistent for it to be equivalent to: (let ((z (+ 4 x))) (declare (special z)) (locally (declare (inline +)) (+ z 5))) I could submit a proposal called DECLARATION-SCOPE:FULLY-LEXICAL to specify this. But as I said before, I think there are a whole plethora of issues that ought to be considered together, so some attention needs to be paid to all the related issues. This FULLY-LEXICAL approach would help certify one of your feelings; you posed the example (DEFUN FOO-1 (X) (DECLARE (INLINE FOO-1)) (+ X 1)) (DEFUN BAR-1 (X) (FOO-1 X)) and suggeted that the inline declaration should not apply to the "reference" to FOO-1 in function BAR-1. Easily handled by the "lexical" approach. However, I would even question the appropriateness a form like (DEFUN FOO-3 (X) (DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM)) (+ X 1)) The kind of binding being in this special form is a LAMBDA binding -- a "variable" binding, not a "function" binding -- so the ftype declaration on FOO-3 certainly doesn't apply to X. Hence it ought not to act like a global proclaim. Indeed, PROCLAIM exists precisely to cover the case of setting a global function cell; and this isn't the same kind of binding that occurs in, say, FLET, or LABELS. To achieve the effect you are supposing, you might have to say: (locally (declare (function foo-3 (fixnum) fixnum)) (defun foo-3 (x) (+ x 1))) or possibly (defun foo-3 (X) (flet ((foo-3 (x) (+ x 1))) (declare (function foo-3 (fixnum) fixnum)) (foo-3 x))) -- JonL -- FAILedsel!jonl<324400.880210@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  g 4g 4 g 4 g 4g# 4g+ 4g3 4g; 4!gC 4%gK 4)gS 4-g[ 41gc 45gk 49gs 4=g{ 4  Sg 4 gg@H $ wp H!#p (2o(X28 0 GH  ")Hx H@ hM C`,hPP0R8S`S`on 1) MoonY-BRORC.Sycs.CO: KMPY-BRORC.Sycs.COCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 14:24:17 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 11:12:12 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338778; Mon 8-Feb-88 14:10:25 EST Date: Mon, 8 Feb 88 14:10 EST From: Kent M Pitman Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson@MULTIMAX.ARPA, CL-Cleanup@SAIL.STANFORD.EDU, franz!smh@BERKELEY.EDU In-Reply-To: <19880208184148.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208141018.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 8 Feb 88 13:41 EST From: David A. Moon Kent, I agree with your comments, however you did not address yourself to the issue that Unix requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to go to different output destinations, while Common Lisp requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to be initially bound to synonyms for the same stream. Ah, somehow I missed this issue. It should have been in the problem description, not in the test case/example section. I don't know precisely what the "correct fix" to Common Lisp is here, but I don't think it involves either making all the stream variables' bindings initially undefined, nor leaving all but *TERMINAL-IO* defined to be synonym streams to *TERMINAL-IO*. Maybe the variables should be defined in terms of their contracts rather than their implementations. Sounds like a plausible avenue to pursue. I think the proposal needs another iteration based on a new idea. Agreed. I'm certainly willing to continue entertaining discussion on the issue. If it helps the Unix guys putting together the next round of proposals, I'm willing to have relax the requirement that *ERROR-OUTPUT* be bound to a synonym stream to *TERMINAL-IO*. It's mainly the -IO* variables and *STANDARD-INPUT* and *STANDARD-OUTPUT* that I'm concerned about having point to *TERMINAL-IO* initially. *ERROR-OUTPUT* and *TRACE-OUTPUT* are less important to me as long as the issues are clearly documented. In fact, though, I think that many supposedly portable programs are -extremely- sloppy about distinguishing *ERROR-OUTPUT* and *TERMINAL-IO* and that lots of dumb problems like (FORMAT *ERROR-OUTPUT* "You did something bad: ...") (YES-OR-NO-P "Continue anyway? ") will be shown up if *ERROR-OUTPUT* and *TERMINAL-IO* do not initially point to the same stream. Maybe it's just as well that such bugs do get shown up, but I think there should be a guide to what kinds of things belong on *ERROR-OUTPUT* and what belongs on *QUERY-IO* and what on *TERMINAL-IO* and what on *STANDARD-OUTPUT*. We're still way too vague about all this. Any proposal to fix things must be more specific, not more vague, since systems cannot come up with "creative" solutions to the Unix problem in the absence of cooperation from the users. FAILKMP Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)<323285.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  11 1 11!1)1119 1A$1I(1Q,1Y01a41i81q<1y  1 : q11@HW: < YZYW@5 H!{p (e(X(| 0  H  ")Hx ( @ h C V`,h%P08``%($U C0tCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 14:05:49 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:58:21 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338755; Mon 8-Feb-88 13:58:07 EST Date: Mon, 8 Feb 88 13:57 EST From: Kent M Pitman Subject: Issue: DECLARATION-SCOPE (Version 2) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, Hornig@ALDERAAN.SCRC.Symbolics.COM In-Reply-To: <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208135758.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I support DECLARATION-SCOPE:LIKE-VARIABLE, but I have some related issues I'd like to ask about while we're on the topic. I wonder about the following cases. Do we believe that they all follow clearly from the indicated rules (and/or other known and agreed upon rules)? (DEFUN FOO-1 (X) (DECLARE (INLINE FOO-1)) (+ X 1)) (DEFUN BAR-1 (X) (FOO-1 X)) Can FOO-1 be inlined in BAR-1? I say no because of modularity and incremental debugging constraints. I think there are implementations which do this inlining. I would like to see this and other situations treated explicitly. (DEFUN BAR-2 (X) (FLET ((FOO-2 (X) (DECLARE (INLINE FOO-2)) (+ X 1))) (FOO-2 X))) Can FOO-2 be inlined in BAR-2? I say it's not totally unreasonable and I wouldn't be surprised if some implementations have resorted to this as a way for users to say that FOO-2 is inline since they cannot put the information at the top of the FLET body. I found the wording of this proposal to be a little vague on whether this INLINE declaration spans the whole FLET, but my final impression was that it does. Is this right? Can we get this into the spec? Other examples I'd like to see made explicit: (DEFUN FOO-3 (X) (DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM)) (+ X 1)) (DEFUN BAR-3 (X) (THE FIXNUM (+ (FOO-3 X) 1))) Can I use fixnum arithmetic in FOO-3? (I say yes.) Can I use fixnum arithmetic in BAR-3? (I say no, to avoid problems if one function is changed while the other is not.) (LABELS ((FOO-4 (X) (DECLARE (FUNCTION FOO-4 (FIXNUM) FIXNUM)) (+ X 1)) (BAR-4 (X) (THE FIXNUM (+ (FOO-4 X) 1)))) (FLET ((BAZ-4 (X) (THE FIXNUM (+ (FOO-4 X) 1)))) ...)) Can I use fixnum arithmetic in FOO-4? in BAR-4? In BAZ-4? I hope yes to all. FAILKMP Issue: DECLARATION-SCOPE (Version 2)<323278.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  11 1 11!1)1119 1A$1I(1Q,1Y01a41i81q<1y  {1 < q11@HO > oUy8 H!p (I5(X 0 pH ")Hx (q@ hu C `,hxP0z8{`{`-vp#,"NFS("Tj@h:\MbhDL(( %f2^ CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 14:00:04 EST Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:51:31 PST Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202409; Mon 8-Feb-88 13:52:24 EST Date: Mon, 8 Feb 88 13:51 EST From: David A. Moon Subject: Issue: FLET-DECLARATIONS (Version 2) To: Kent M Pitman cc: CL-Cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <880208134020.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880208185144.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 8 Feb 88 13:40 EST From: Kent M Pitman I found the second paragraph of the proposal part ("The scope of such ...") to be very hard to read. Then we should pass the DECLARATION-SCOPE proposal, which supersedes that paragraph. :-} FAILMoon Issue: FLET-DECLARATIONS (Version 2)<323272.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  VV~V V~ VV~ VV~V"V~V*V~V2V~V:V~!VBV~%VJV~)VRV~-VZV~1VbV~5VjV~9VrV~=VzV~  SV 0 W;VV@HX  [ZXA H!p (-(X 0;H  ")Hx =@ tG Cp`,4M (PQ8S`S`CWRL.OM CpaganI.AI.DU St: Sh McLa "New In-CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 13:47:06 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:42:44 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338725; Mon 8-Feb-88 13:41:39 EST Date: Mon, 8 Feb 88 13:41 EST From: David A. Moon Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) To: Kent M Pitman cc: pierson@MULTIMAX.ARPA, CL-Cleanup@SAIL.STANFORD.EDU, franz!smh@BERKELEY.EDU In-Reply-To: <880208133005.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880208184148.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Kent, I agree with your comments, however you did not address yourself to the issue that Unix requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to go to different output destinations, while Common Lisp requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to be initially bound to synonyms for the same stream. I don't know precisely what the "correct fix" to Common Lisp is here, but I don't think it involves either making all the stream variables' bindings initially undefined, nor leaving all but *TERMINAL-IO* defined to be synonym streams to *TERMINAL-IO*. Maybe the variables should be defined in terms of their contracts rather than their implementations. I think the proposal needs another iteration based on a new idea. FAILMoon Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)<323255.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ~y ~y~y ~y!~y)~y1~y9~y A~y$I~y(Q~y,Y~y0a~y4i~y8q~y<y~y  n $ 1@H  -xw H!p (j.(X 0 cH  ")Hx (d@ hh CQ`,hkP0m8n`n` %''0,-m?CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 13:44:41 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:40:36 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338723; Mon 8-Feb-88 13:40:23 EST Date: Mon, 8 Feb 88 13:40 EST From: Kent M Pitman Subject: Issue: FLET-DECLARATIONS (Version 2) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, Hornig@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19880203020430.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208134020.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I support FLET-DECLARATIONS:ALLOW. I found the second paragraph of the proposal part ("The scope of such ...") to be very hard to read. FAILKMP Issue: FLET-DECLARATIONS (Version 2)<323251.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ~y ~y~y ~y!~y)~y1~y9~y A~y$I~y(Q~y,Y~y0a~y4i~y8q~y<y~y    1@H@?  B_A;@E H!p ([(X` 0 uH  ")Hx v@ t C``,4 ~P8``%K&+W0,-m?CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 13:40:41 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:36:53 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338711; Mon 8-Feb-88 13:36:22 EST Date: Mon, 8 Feb 88 13:36 EST From: Kent M Pitman Subject: Issue: LOAD-TIME-EVAL (Version 4) To: CL-Cleanup@SAIL.Stanford.EDU cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM, kempf%hplabs@hplabs.hp.com In-Reply-To: <19880203022524.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208133616.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I'm afraid we're going in circles on LOAD-TIME-EVAL. I'm not in favor of this approach. Moon's Version 4 undoes all of what was important to me in Version 3. I'll try to get the relevant parties together for a meeting on this internally to Symbolics prior to the March meeting and we'll see if we can present a coherent front. FAILKMP Issue: LOAD-TIME-EVAL (Version 4)<323248.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ~y ~y~y ~y!~y)~y1~y9~y A~y$I~y(Q~y,Y~y0a~y4i~y8q~y<y~y  i 6 1@H+]& /}.+c H!~p (H(X-l 0QH) ")Hx S@ t] B~I`,4c 3Pg8i`i`%K&+W0,-m?CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 13:35:59 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:31:29 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338697; Mon 8-Feb-88 13:30:18 EST Date: Mon, 8 Feb 88 13:30 EST From: Kent M Pitman Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) To: pierson@MULTIMAX.ARPA cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, franz!smh@BERKELEY.EDU In-Reply-To: <8801192339.AA20676@mist.UUCP> Message-ID: <880208133005.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I can't support this proposal. I believe that the correct fix is for wording to be added that explains that *TERMINAL-IO* might be a bidirectional stream which directs input from and to a virtual and not necessarily a physical terminal. As such, *TERMINAL-IO* should properly be initialized to (MAKE-TWO-WAY-STREAM SYSTEM-INTERNALS:*UNIX-STANDARD-INPUT* SYSTEM-INTERNALS:*UNIX-STANDARD-OUTPUT*) If it were, then *STANDARD-INPUT* and *STANDARD-OUTPUT* would behave correctly with no relaxation of the requirements on their initial values. I think it is important that *STANDARD-INPUT*, *STANDARD-OUTPUT*, etc. be defined to be bound to synonym streams initially. Here are some reasons: * It may be important to the programmer to recover the value of this virtual terminal. There is already a restriction on binding *TERMINAL-IO* in Common Lisp, so the virtual terminal will always be accessible from *TERMINAL-IO*. If the virtual terminal were in *STANDARD-INPUT* and *STANDARD-OUTPUT*, the user might bind himself into a corner where he could no longer recover the value of the virtual terminal. * I think the initial I/O pairing should be available as a unit rather than in two different places. * If there is no physical console, the value of *TERMINAL-IO* will have garbage. There is no reason that input/output from/to programs to *TERMINAL-IO* should fail just because an alternate input or output stream was provided. You cannot make *TERMINAL-IO* indirect via synonym stream to *STANDARD-INPUT*,etc. without risking complete disaster. If it did, the user might do: (LET ((*STANDARD-INPUT* (MAKE-SYNONYM-STREAM '*TERMINAL-IO*))) ...) and get a circular synonym stream. In order to make sure that programs can portably use synonym streams at all, it is extremely important that the directionality of synonym streams be well-defined (ie, from *STANDARD-INPUT* to *TERMINAL-IO* and not vice versa) and that there be a known bottoming out point, *TERMINAL-IO*, which cannot be a synonym stream to anything the user can get his hands on. FAILKMP Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)<323241.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  UU U U UU UU U"U U*U U2U U:U !UBU %UJU )URU -UZU 1UbU 5UjU 9UrU =UzU  U  USUU@H  Jz H!W9p (i(XL 0 H ")Hx @@ h BW!`,h P08``ject:versi FUNCTYPE-LIST-NT prl Tot M P Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal To: Kent M Pitman cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880207150705.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880208170043.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 7 Feb 88 15:07 EST From: Kent M Pitman My preference is for EXTEND-LIST-TYPE because.... Does this mean you have a solution in mind for the well-known problems with the element-type argument to the ARRAY type specifier? If so, I'd like to hear it. If not, I think you would be heading towards making the LIST and SEQUENCE type specifiers either have the same problem or be inconsistent with ARRAY. FAILMoon New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal<323186.880208@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!     #+3;C!K%S)[-c1k5s9{=  W  @H}w ˽ɉU Hp ((X 0=H ")Hx ?@ tK ;>`,4Q *PU8W`W`,t'N2t-CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 15:49:15 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:41:59 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338083; Sun 7-Feb-88 15:41:47 EST Date: Sun, 7 Feb 88 15:41 EST From: Kent M Pitman Subject: New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2) To: sandra%orion@cs.utah.edu cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8801152125.AA12185@orion.utah.edu> References: <19880203013624.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880207154134.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I also am mostly happy with version 2 of FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD, though I'd like to see it address Moon's concern about specifying clearly whether the declared keyword list is exhaustive. By the way, on a related point, if I specify FOO as: (FUNCTION FOO (&KEY (:A INTEGER) (:B INTEGER) &ALLOW-OTHER-KEYS)) is it safe to assume that other keys are really ignored. Does this mean I have done: (DEFUN FOO (&KEY A B &ALLOW-OTHER-KEYS) ...) in which case the other keys are literally discarded, or might I have done: (DEFUN FOO (&REST Z &KEY A B &ALLOW-OTHER-KEYS) ...) in which case the other keys might not really be getting ignored. Some clarification on this point might also be useful. FAILKMP New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)<322784.880207@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  jjCj jC jjC jjCj"jCj*jCj2jCj:jC!jBjC%jJjC)jRjC-jZjC1jbjC5jjjC9jrjC=jzjC  %j ( jjj@Hl  n0ml[ Hp (a(X$ 0 H ")Hx @ t ;5*`,4 P#8%`%`2) TsinteXerox cc: on@miPA, Canup@StanfDU ICL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 15:32:31 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:24:15 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338037; Sun 7-Feb-88 15:22:35 EST Date: Sun, 7 Feb 88 15:22 EST From: Kent M Pitman Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) To: Masinter.pa@Xerox.COM cc: pierson@mist.ARPA, CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: <880114-200421-4849@Xerox> References: The message of 30 Dec 87 19:26 EST from Dan L. Pierson Message-ID: <880207152219.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 14 Jan 88 20:03 PST From: Masinter.pa@Xerox.COM I think we can ship a version 3 that has the [[]] remarks removed. Probably we want to add to the Discussion section. What do folks think about a paragraph like: DISASSEMBLE is an environment feature; some question has been raised as to the place and force of environment features in the standard. However, this proposal stands if DISASSEMBLE is part of the standard language. All fine with me. FAILKMP Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)<322775.880207@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  OEOOEOOE OOEO&OEO.OEO6OEO>OEOFOE#ONOE'OVOE+O^OE/OfOE3OnOE7OvOE;O~OE?O 0OE  OeOEOE@Hv : yxvч{A Hg#p ( u(Xl 0QHP) $/@ h* h` ,h-]P0/80`0`+  (( !CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 21:52:17 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:44:10 PST Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 18:44:26 PST Received: from bhopal.lucid.com by edsel id AA03683g; Wed, 3 Feb 88 17:43:28 PST Received: by bhopal id AA12513g; Wed, 3 Feb 88 17:47:47 PST Date: Wed, 3 Feb 88 17:47:47 PST From: Jon L White Message-Id: <8802040147.AA12513@bhopal.lucid.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU, labrea!common-lisp%sail@labrea.Stanford.EDU In-Reply-To: Kent M Pitman's message of Wed, 3 Feb 88 11:34 EST <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT The reason why some users may be mislead about EXPORT is that they fail to heed the directive on the second line of p186: "See section 11.4 for details". The one paragraph description of EXPORT on p186 is grossly incomplete without reference to that other section, which cleary states: (p177, last paragraph) "The function EXPORT takes a symbol that is *accessible* in some specified package ... If the symbols is not accessible at all in the specified package, a correctable error is signalled that, upon continuing, asks the user whether the symbol should be imported." [my emphasis]. Every implementation I'm familiar with seems to implement the above semantics rigidly; no one quietly imports the symbol without first signalling an error. -- JonL -- FAILedsel!jonl<320896.880203@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  4b 4b4b 4b #4b+4b34b;4bC4b!K4b%S4b)[4b-c4b1k4b5s4b9{4b=  4b 0 54b4b@H  E HFLp (a(X/ 0oH 8 ")Hx q@ t{ y Mr`,4 BP8``CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 20:55:54 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:45:36 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306494; Thu 17-Dec-87 20:45:27 EST Date: Thu, 17 Dec 87 20:45 EST From: David A. Moon Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1) To: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <871208-160538-5539@Xerox> Message-ID: <19871218014525.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 8 Dec 87 15:22 PST From: Masinter.pa@Xerox.COM I think we should take a step back and ask what the place of DISASSEMBLE, ED, TRACE, BREAK, DRIBBLE, INSPECT etc.. should be in the ANSI standard. These are things for which constructing a denotational semantics is not feasible, cann't be easily tested with a validation suites, etc. I think a more global change of status for these is called for; I'd propose that the ANSI Standard should say something like: "The following are suggested features for a ANSI Common Lisp programming environment. Conforming implementations are required to document what, if anything, these functions do, in detail. However, no portable ANSI Common Lisp program can rely on the behavior of these functions, because the behavior is specifically not specified in the standard." This seems like a reasonable idea, although it's perhaps not in the domain of the Cleanup committee. Once we move away from conformance and standard into recommendation, we might actually be more able to make better progress recommending, for example, that systems call their GC function (GC) and their exit function (EXIT) etc. I think this would be a mistake. The functions listed earlier are to be called by users and generally are not useful to call from programs. The only reason those functions were ever in CLtL as functions is that Common Lisp didn't want to assume that some kind of command processor, separate from Lisp evaluation, exists since opinions on how this should work diverge so wildly. GC and EXIT are in a different category. GC is likely to be called by programs, except that as we found when we discussed it a while back, it doesn't seem to be possible to say anything at all implementation-independent about the semantics of this, which makes it not very useful for portable programs. EXIT surely must be for programs, rather than users, since every operating system already has a way for users to get out; but again there is no portable semantics. While it's useful to have some "suggested features" for users, to ease learning how to use a new Common Lisp implementation as well as to give implementors an idea of the minimum environment expected, it's not useful to have "suggested features" for programs, since if they are only suggested, no portable program can use them. FAILMoon Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)<301285.871217@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!   1 1  1  1# 1+ 13 1; 1C !1K %1S )1[ -1c 11k 51s 91{ =1   w  8  @H|  a HFEap ( K(XI 0 \H ")Hx (]@ t y E>`,4 gP8``CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 20:40:16 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:35:48 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306483; Thu 17-Dec-87 20:35:35 EST Date: Thu, 17 Dec 87 20:35 EST From: David A. Moon Subject: Cleanup issues from Japanese technical working group To: CL-CLEANUP@SAIL.STANFORD.EDU In-Reply-To: <871210-231038-2589@Xerox> Message-ID: <19871218013528.0.MOON@EUPHRATES.SCRC.Symbolics.COM> I have comments on excerpts from this. For most of the issues raised, I have no comment. Feel free to forward these comments back to our Japanese friends if desired. 1) CLtL says nothing about whether structure or array is self evaluating form. [5.1.1] It is suggested that not only numbers, characters, and bit-vectors, but also structures, arrays, vectors, packages be self-evaluating forms. Yuasa: There may possibly be some reason that these objects are not allowed to be evaluated. But the reason is not known. This simplification is convenient both for the user and for the implementor. Note that some implementations such as Exper Common Lisp signal an error when those objects that CLtL does not explicitly say are self-evaluating are being evaluated. <> It's not true that CLtL says nothing about this; the bottom of page 54 in the English edition says evaluating any other object is an error. I don't know what the rationale was; unless somebody knows, we can't easily provide it in the standard! At Symbolics we pondered this for a while and settled on the idea that only objects of type (OR CONS SYMBOL) do anything special when evaluated, and all other objects evaluate to themselves. We haven't had any problems as a result of this. CLtL says something about implementation-dependent extensions for evaluating other types of objects, but we decided that this didn't make sense for any of the object types defined by CLtL. An implementation could certainly invent a new, non-COMMON object type with a new way of evaluating it, and then that (OR CONS SYMBOL) would be extended to (OR CONS SYMBOL other-type) in that implementation. But since a portable program presumably wouldn't use any objects of that implementation-dependent type, this should't interfere with portability even if we define that all objects of types defined by CLtL, other than CONS and SYMBOL, are self-quoting. Evidently current practice varies between implementations. This needs an issue if we want to change it, but since "is an error" allows complete implementation-dependent freedom, we don't have to say anything if we think the status quo is okay. 1) If read-base is 16, `1E0' is read as an integer and not a float. [2.1.3] << I think this is a wording change rather than an Issue.>> I don't think this is a problem at all, since 22.1.2 (page 343) is very explicit about this. 5) Same keyword parameter can appear more than once in an actual argument list. [5.2.2] This is necessary to overwrite passed keyword arguments. << New issue KEYWORD-ARGUMENT-DUPLICATES? >> Not an issue, 5.2.2 (page 62 in the English edition) is already very explicit about this "If more than one such argument pair matches, it is not an error; the leftmost argument pair is used." 4) --- Q: Is there any way to escape from Lisp context. A: Some systems, such as Lisp machine have no concept of escaping. This is needed for Lisp systems under stock operating systems. It is necessary to determine the name even if the function may be implementation dependent. Recommendation: (QUIT) will be a proper word for this operation. << Seems like it goes in the environment section. >> I remember this was discussed at length a couple years ago, and the conclusion was that the semantics of quitting varied so much between implementations that there was no point in trying to standardize anything. Even without thinking about multiprocess systems, nor about Lisp machines, you have to ask whether after quitting the Lisp vanishes or can be restarted, whether a command string can be returned to the operating system, whether a success/failure code is required to be returned to the operating system, etc. Finally it is unclear how a portable program could usefully benefit from this. FAILMoon Cleanup issues from Japanese technical working group<301280.871217@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  V2Ve V2VeV2 VeV2 Ve"V2Ve*V2Ve2V2Ve:V2VeBV2!VeJV2%VeRV2)VeZV2-VebV21VejV25VerV29VezV2=Ve  }V2 0 VRV2V2@H\=U7 ^}^\I~B HŽp (_(X$ 0 qH  $/x @ hw w =`,hzP0|8}`}`CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Nov 87 15:49:23 EST Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 12:37:45 PST Received: by labrea.stanford.edu; Tue, 17 Nov 87 12:36:20 PST Received: from kent-state.lucid.com by edsel id AA02947g; Tue, 17 Nov 87 12:31:28 PST Received: by kent-state id AA02216g; Tue, 17 Nov 87 12:31:28 PST Date: Tue, 17 Nov 87 12:31:28 PST From: Eric Benson Message-Id: <8711172031.AA02216@kent-state.lucid.com> To: cl-cleanup@sail.stanford.edu In-Reply-To: David A. Moon's message of Thu, 12 Nov 87 19:26 EST <19871113002609.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 3) There's a problem with this SETF method for symbols. Consider the following simplified version of SETF from p.107 of CLtL: (DEFMACRO SETF (REFERENCE VALUE) (MULTIPLE-VALUE-BIND (VARS VALS STORES STORE-FORM ACCESS-FORM) (GET-SETF-METHOD REFERENCE) (DECLARE (IGNORE ACCESS-FORM)) `(LET* ,(MAPCAR #'LIST (APPEND VARS STORES) (APPEND VALS (LIST VALUE))) ,STORE-FORM))) This results in the following macrexpansion for (SETF X 1), using the new SETF method for symbols: (LET* ((G0002 X) (G0001 1)) (SETQ X G0001)) The value of G0002 is never used. The problem is that X might be unbound, so even just binding it to a local variable will fail. I don't think we want to require implementations to eliminate unnecessary bindings in SETF expansions, just to get correct semantics. Nor should each SETF-like macro need a special case when the location being stored is a symbol. Unfortunately, I think special handling for symbols is necessary. If we keep the SETF method for symbols the way it is in CLtL then we need to make a special case for symbols in the SETF methods for GETF, LDB and the like. If we change the SETF method as proposed here, we need to make a special case for symbols in SETF and PSETF and any user defined SETF-like macro that doesn't use the fifth value (ACCESS-FORM) from GET-SETF-METHOD. My feeling is that we should go with the new SETF method for symbols, but describe this problem and point out to implementors that SETF and PSETF must handle symbols specially, effectively resorting to the old SETF method. FAILedsel!eb Issue: SETF-METHOD-FOR-SYMBOLS (version 3)<287181.871117@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  V2Ve V2VeV2 VeV2 Ve"V2Ve*V2Ve2V2Ve:V2VeBV2!VeJV2%VeRV2)VeZV2-VebV21VejV25VerV29VezV2=Ve  V2  VRV2V2@HWX  YxX@W^ Hg p (/(X 0H ` ")Hx @ t vdj`,4 jP8``CL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 21:52:05 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 18:45:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187832; Thu 12-Nov-87 19:34:50 EST Date: Thu, 12 Nov 87 19:34 EST From: David A. Moon Subject: Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2) To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <871110-234924-6361@Xerox> Message-ID: <19871113003437.5.MOON@EUPHRATES.SCRC.Symbolics.COM> This looks ready to release to me, except for the following typo: Adoption Cost: Changes to implementations to make them conform to either of these should be fairly minor if not trivial. "either of these" is left over from when there were two proposals. FAILMoon Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)<284754.871112@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  V2Ve V2VeV2 VeV2 Ve"V2Ve*V2Ve2V2Ve:V2VeBV2!VeJV2%VeRV2)VeZV2-VebV21VejV25VerV29VezV2=Ve  /V2  VRV2V2@H.u  3A.{v< HZp (+(X, 0GH $ ")Hx I@ h) vd\`,h,[P0.8/`/`77WWtGCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 21:24:18 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:03:59 PST Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187844; Thu 12-Nov-87 20:03:50 EST Date: Thu, 12 Nov 87 20:03 EST From: David A. Moon Subject: Re: Issue: PUSH-EVALUATION-ORDER (Version 3) To: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM In-Reply-To: <871109-161932-4273@Xerox> Message-ID: <19871113010337.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 9 Nov 87 16:19 PST From: Masinter.pa@Xerox.COM I'm a little uneasy about "Explicitly state that for the macros CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, that rule is followed except where CLtL specifies to the contrary." I was trying to complete the set of references to macros affected by the proposal, but I agree that this wording is poor. I'm not sure what to replace it with, though. I think that we also have to be careful about the following: suppose a user defines (defmacro wrong-order (x y) `(get ,y ,x)) If the user writes (push a (wrong-order (frob) (baz))) are we willing to guarantee that "the subforms of the macro call (including but not limited to subforms of the generalized variable reference) are evaluated exactly as many times as they appear in the source program, and in exactly the same order as they appear in the source program. "? Good point, and note that the same issue arises for (setf (wrong-order (frob) (baz)) 1), so this point in no way shoots down what we originally set out to do on the PUSH-EVALUATION-ORDER issue. A more complicated version of wrong-order, for example, one with a loop in it, would make it impossible to guarantee that statement. So we have to change the statement. Ick. I think what we mean is that evaluation of the direct subforms of the macro call and of generalized-variable references in the macro call is ordered, but evaluation of subforms of those subforms is determined by the recursive evaluation process as normal. I'd have to think about this more to see if this is the best way to say it, it doesn't strike me as a model of clarity. Similarly if the user writes an "incorrect" setf-method, e.g., (defsetf wrong-order (x y) (z) `(setf (get ,y ,x) ,z)) This is not an issue since CLtL p.103 says "This binding permits the body forms to be written without regard for order-of-evaluation issues." Of course a user could write an incorrect define-setf-method. I wish this weren't so sticky. . . . Me too. I think it's inherent in defining the order of evaluation of things that aren't functions, so there's no easy answer. FAILMoon Re: Issue: PUSH-EVALUATION-ORDER (Version 3)<284736.871112@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  V2Ve V2VeV2 VeV2 Ve"V2Ve*V2Ve2V2Ve:V2VeBV2!VeJV2%VeRV2)VeZV2-VebV21VejV25VerV29VezV2=Ve  V2 . VRV2V2@HXc & [ZVXiC HYp (+(X# 0H k ")Hx @ t vd\ `,4 uP8``77WWtGCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 21:24:15 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:23 PST Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187827; Thu 12-Nov-87 19:21:17 EST Date: Thu, 12 Nov 87 19:21 EST From: David A. Moon Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4) To: CL-Cleanup@SAIL.STANFORD.EDU cc: Dave.Touretzky@C.CS.CMU.EDU In-Reply-To: <871111-004615-6413@Xerox> Message-ID: <19871113002102.3.MOON@EUPHRATES.SCRC.Symbolics.COM> This looks good. An obvious question that is going to arise is why did we define (COERCE array 'SEQUENCE) to be (MAKE-ARRAY ... :DISPLACED-TO array) rather than (CONCATENATE 'VECTOR array). In researching this I note that it's pretty hard to tell from CLtL whether the other sequence coercions are required to allocate new storage, or are allowed to share existing storage, when they don't just return the argument. The word "copy" is used in an off-hand remark, and I had always assumed without thinking about it that COERCE was a copying operation, but CLtL never actually says whether or not the result is allowed to share storage with the argument, when they are not identical. I imagine that unlike any other use of COERCE, our proposed (COERCE array 'SEQUENCE) is -required- to share storage with the argument, so that SETF of ELT may be used on the result, causing the elements of the original argument to be affected. If true, we certainly should put in a sentence or two of rationale to forestall questions. This should both explain that we did it this way not just for "efficiency", but so the user could rely on side-effects propagating from the vector back to the array, and also say something about the relation of this to the vagueness of the other sequence coercions. This raises the question, why is COERCE really in this proposal anyway? It almost seems to be there only to support the remark at the end about how the whole proposal could have been replaced with a proposal just to extend COERCE, but we chose not to do that. Maybe Dave T can comment on the reasons for including COERCE. FAILMoon SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)<284735.871112@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  V2Ve V2VeV2 VeV2 Ve"V2Ve*V2Ve2V2Ve:V2VeBV2!VeJV2%VeRV2)VeZV2-VebV21VejV25VerV29VezV2=Ve  V2 : VRV2V2@HX  ZSY!XzX HYp (+(X 0!H  ")Hx #@ h vd[a`,h3P08``77WWtGCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 21:24:09 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:02 PST Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187823; Thu 12-Nov-87 18:48:57 EST Date: Thu, 12 Nov 87 18:48 EST From: David A. Moon Subject: Issue: LOAD-TIME-EVAL (Version 3) To: Kent M Pitman cc: Masinter.pa@Xerox.COM, CL-CLEANUP@SAIL.STANFORD.EDU In-Reply-To: <871111114311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19871112234843.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Kent, I think the change from #, only being allowed inside constants to #, only being allowed as a form is completely backwards. It's an unnecessary incompatible change, invites the question of why we bother having a reader syntax for #, when it could just as well be a macro that evaluates its subform only the first time it is called (with an optimization to evaluate it at load time rather than on first call), and appears to do violence to the relationship between #, and #.. I don't favor your version of the proposal. I wasn't able to figure out what else your uneasiness might have been, if there was more than the constant-versus-form issue. FAILMoon Issue: LOAD-TIME-EVAL (Version 3)<284734.871112@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  V2Ve V2VeV2 VeV2 Ve"V2Ve*V2Ve2V2Ve:V2VeBV2!VeJV2%VeRV2)VeZV2-VebV21VejV25VerV29VezV2=Ve  (V2  VRV2V2@HX+ & ZkY:X7{ HYp (1(X 09H  ")Hx ;@ h" vd[&`,h%MP0'8(`(`77WWtGCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 21:23:44 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187819; Thu 12-Nov-87 18:42:39 EST Date: Thu, 12 Nov 87 18:42 EST From: David A. Moon Subject: Re: Issue: TRACE-FUNCTION-ONLY (Version 5) To: kempf%hplabsz@hplabs.HP.COM cc: Masinter.pa@XEROX.COM, cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabs@hplabs.hp.com In-Reply-To: <7575.563647026@hplabsz> Message-ID: <19871112234202.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Wed, 11 Nov 87 09:37:06 MST From: kempf%hplabsz@hplabs.HP.COM > I don't know why the fact that this is a part of the environment rather > than the language makes the burden of adoption cost any less. > ("However, compatibility with existing implementations seems less of an > issue here, since TRACE is more a part of the environment.") This was in response to a suggestion by Dave Moon, but I have no objection if it is removed. That's conversion cost. There is less burden on users when we incompatibly change something that they (relatively rarely) type in by hand, than when we incompatibly change something that appears in their programs. I hope everyone agrees with this, once they understand what it says, it's not a profound point. FAILMoon Re: Issue: TRACE-FUNCTION-ONLY (Version 5) <284733.871112@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  Dk[ E DkDk@Hȉ & K^ȕzb Hm;p (m(X> 0%H8 (x X@ h u[KX`,h7P08``3WAPPENNOSHOGUMBYIRFC73NOSHORAYCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Oct 87 16:19:41 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 13:07:31 PST Received: ID ; Tue 27 Oct 87 16:06:49-EST Date: Tue, 27 Oct 1987 16:06 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: kempf%hplabsz@HPLABS.HP.COM Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: TRACE Proposal (Version 2) In-reply-to: Msg of 27 Oct 1987 12:24-EST from kempf%hplabsz at hplabs.HP.COM Several questions and comments: 1. Common Lisp does not currently require implementations to perform a trace if the function in question has been "open coded", which category may include compiled self-calls that do not go through the symbol-function cell, etc. It should be made clear that this modificaiton does not alter that provision. 2. It should be made clear that what is being traced in the case of a macro is the call to the macro-expansion function, and not the execution of the resulting code. Trace would print the calling form going in and the expanded form being returned. I found the wording in the proposal a bit confusing on this point. An example would help. Also make clear that if macro-memoizing is going on, subsequent execution of the same expansion code will not be traced. Current practice: There is currently no way to trace SETF functions, aside from macroexpanding a SETF form and using the resulting name in a TRACE macro invocation. There is currently no way to trace macroexpansion functions when they are invoked through their global names, except through complicated use of *MACROEXPAND-HOOK*. Make that "no way that is standard across all implementations". Some implementations do provide some of these services. Adoption Cost: The proposed syntax is upwardly compatible with the current Common Lisp syntax. It will require the addition of function specification parsing and wrapper code to trace SETF function executions and macrofunction executions. When the Common Lisp Object System is fully implemented, wrapper code for tracing method execution will also be required. Can we assume that the Xerox people will put the necessary hooks into the method-dispatching machinery? This would considerably reduce the implementation cost for those of us who are using PCL as the basis for our CLOS implementations. Cost of non-adoption: Programmers will have to continue using a complicated set of Lisp commands to arrange for SETF function and macrofunction tracing. When the Common Lisp Object System is fully implemented, programmers will have to use metaobject protocol functions to arrange for tracing. This is wrong, I think. The real cost is that implementations will provide this functionality in varying forms and to varying degress, thus making it harder for users to move between one Common Lisp system and another. A few implementations may blow this off altogether, in which case their users will be screwed as described above. Benefits: Allow programmers to obtain information on individual method invocations, and on SETF function and macrofunction invocations. ... in a uniform way across all implemenations. Conversion Cost: Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper generating functions. It is possible that some implementations have made extensions to TRACE that are incompatible with this proposal. The only problem I can see for those of us who currently allow a list of a function name and options in place of simple symbols is that now it would be ambiguous if someone wanted to trace invocations fo the SETF macro. We'll just declare that illegal, since it would probably blow up on you anyway. FAILFahlman TRACE Proposal (Version 2)<275883.871027@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  1Dk  E DkDk@HF? > H_GTƋ Hmp ( 0U(XTh0 H, (x H@ t% u[5`,4+ P/81`1`99NOSHOGUMBYIRFC73NOSHORAYCommon-Lisp-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Oct 87 15:31:38 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Oct 87 12:11:53 PST Received: from Salvador.ms by ArpaGateway.ms ; 27 OCT 87 11:57:07 PST Date: 27 Oct 87 11:18 PDT From: masinter.pa@Xerox.COM Subject: Re: macrolet/flet/labels In-reply-to: pyrnj!pyramid!bein%RUTGERS:EDU:Xerox's message of 24 Oct 87 21:09 To: pyrnj!pyramid!bein@RUTGERS.EDU cc: common-lisp@sail.stanford.edu Message-ID: <871027-115707-1048@Xerox> Until the issue has been resolved, it seems like a good idea to avoid shadowing ANY function or macro in CLtL with MACROLET/FLET/LABELS, but especially special forms. For example, suppose that you had (flet ((cons (x y) (cons y x))) (unwind-protect (my-call) (my-cleanup))) In some systems, unwind-protect might be implemented as a macro which expands into something that invokes CONS. The primary problem is the possibility of references to Common Lisp functions and special forms within macros invoked within the scope of the FLET, LABELS or MACROLET. Until there is a macro expansion mechanism universally adopted which protects macro references from unexpected local rebindings, you're best off avoiding the whole problem by not shadowing functions whose references you have no control over. FAILmasinter.pa Re: macrolet/flet/labels<275865.871027@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  j/_ j/_j/_j/ _!j/_)j/_1j/_9j/_Aj/ _Ij/$_Qj/(_Yj/,_aj/0_ij/4_qj/8_yj/<_  j/  jOj/j/@H,yG 10,~Q Hmpp ( 0Q(X4h0H0u (x 0v@ hz uZp`,h}P08``Common-Lisp-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Oct 87 13:05:07 EST Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 27 Oct 87 09:44:16 PST Received: from Think.COM (THINK.COM) by DOUGHNUT.CS.ROCHESTER.EDU via INTERNET with SMTP id 8517; 27 Oct 87 12:44:34 EST Return-Path: Received: from occam by Think.COM via CHAOS; Tue, 27 Oct 87 12:43:43 EST Date: Tue, 27 Oct 87 12:43 EST From: Barry Margolin Subject: Re: suggestion for language extension To: miller@cs.rochester.edu Cc: cl@doughnut.cs.rochester.edu In-Reply-To: <871027010550.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Message-Id: <871027124353.3.BARMAR@OCCAM.THINK.COM> Date: Tue, 27 Oct 87 01:05 EST From: Brad Miller Date: Mon, 26 Oct 87 18:34 EST From: Barry Margolin I believe CLOS will allow this, although there will probably be some restrictions on the built-in functions that may be converted to generic functions (my feeling is that only functions proclaimed INLINE should be restricted). I don't think this would be general enough, see following... It seems completely general to me. Anything that isn't open-coded could be turned into a generic function that dispatches on the data types of its arguments. What more do you need? You mentioned that overloading could be implemented using an ADVISE feature. A simple-minded ADVISE can be implemented using existing CL facilities, so there is no real need for extending the language: This (a macro) does not alter the run-time semantics of already compiled programs, which would be necessary... Why doesn't it? It redefines the function you want to overload. Unless the function you are overloading was originally a macro or open-coded function, future calls will go to the new definition. Before we got into the habit of customizing the Symbolics environment using ADVISE we used something like it all the time. What I would *like* to do... Take the example of creating something that is a (possibly infinite) list, but lazy-eval'd. So you want to overload all the existing CL functions that can possibly accept lists, That's a LOT of functions! and make them accept lazy-lists as well. ... cons, car, cdr, etc. work on all objects of type list independent of their lazyness. Except that most of the functions already in the environment had CAR and CDR compiled inline, so they won't pick up the overloaded definition. The main intent (for me particularly) is to get scheme-style streams up, but I figured other people might want to create first class objects too... Scheme-style streams don't require overloading. In Scheme you use different functions (HEAD, TAIL) to get the items of a stream from the ones used to get items in a list (CAR, CDR). Scheme doesn't have any special overloading support, either. The other thing I *really* would like is scheme-style continuations, but I suspect this sort of thing would be politically non-feasible at this point. Overloading helps, in that I can make continuations first class objects, but getting to just what a continuation is would still be hard since you need to snapshot the stack... CL already knows how to snapshot the stack, to make lexical closures. The problem is that there are some arbitrary limitations on what a closure can do. This sort of thing may be better addressed as something CL would provide explicitly; I can't think of general underlying mechanisms that solve continuations that would also be useful to make generally available because of their utility in extending the language. (without consing up infinite hair in terms of concrete language semantics). All that needs to be done to CL to make continuations as useful as they are in Scheme is to change the extent of CATCH tags, BLOCK names, and TAGBODY labels from dynamic to indefinite. Unfortunately, this would be a significant change to the language, and I'm not sure that its impact on existing implementations would be worth the gain. But if those restrictions were lifted, the following definition of CALL/CC would suffice: (defmacro call/cc (function &rest args &aux (block-name (gensym))) `(block ,block-name (funcall ,function #'(lambda (&rest results) (return-from ,block-name (values-list results))) .,args))) I'm not a Scheme programmer, and I don't know what the value of being able to transfer into a function that already returned is. One thing I believe CALL/CC is used for is coroutines, and the above CL implementation will support that; however, without tail-recursion optimization you will get pretty deep pretty quickly. barmar FAILbarmar Re: suggestion for language extension<275790.871027@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  Dk * E DkDk@Hg 0 M:C Hmkp ( 0O](X@0 oH(@ t uZk` ,4 uP8 ``^Common-Lisp-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Oct 87 12:54:26 EST Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 09:33:07 PST Posted-Date: Tue, 27 Oct 87 09:33:23 PST Message-Id: <8710271733.AA15979@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA15979; Tue, 27 Oct 87 09:33:43 PST To: COMMON-LISP@sail.stanford.edu From: goldman@vaxa.isi.edu Subject: re: defstruct extensions Cc: goldman@vaxa.isi.edu Date: Tue, 27 Oct 87 09:33:23 PST Sender: goldman@vaxa.isi.edu The recently discussed extensions to DEFSTRUCT are reasonable and needed improvements. But I dissent from the proposal(s) for controlling printing, which seem like they require the use of a sledgehammer to crack an egg -- i.e., rebinding a special variable with dynamic effect on printing of ALL structure instances (or even all instances of a given class), including those embedded withing fields of other instances, when what is wanted, if Corkill's example is representative, is a finer control over a particular instance of printing. In fact, it looks like what is wanted here is the CALL-NEXT-METHOD ability of CLOS. Think of PRINT-STRUCTURE as a generic operation, with a method defined for STRUCTURE (which prints #<...>). Providing a print-function in a defstruct can then be viewed as a syntactic device for defining a PRINT-STRUCTURE method for that specialization of STRUCTURE. If there is sufficient need to resolve this problem prior to any integration of CLOS and structures, I would favor a solution that at least "feels" like this -- e.g., a special form (DEFAULT-PRINT-STRUCTURE) (no arguments) that could ONLY appear lexically within a structure's print function (defstruct (employee (:print-function (lambda (employee stream print-depth) (declare (ignore print-depth)) (cond ((and (not *print-pretty*) *print-escape*) (DEFAULT-PRINT-STRUCTURE)) ;; Pretty printing requested (t (format stream "{Employee: ~A}" (employee-name employee))))))) ...) Alternatively, and less desirable in my mind, a function (WRITE-STRUCTURE-DEFAULT structure-instance) could be provided to ask for an arbitrary instance to be printed with the default structure printer. Neil FAILNET-ORIGIN<275774.871027@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! Aj/_ j/_j/_j/ _!j/_)j/_1j/_9j/_Aj/ _Ij/$_Qj/(_Yj/,_aj/0_ij/4_qj/8_yj/<_  j/ $ jOj/j/@Hor A%ox Hmep (;c(Xb 0HP}@ h~ uZf` ,hP08 ``$ %Ki\LMQm\LSWCL-Cleanup-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Oct 87 12:43:13 EST Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 09:33:28 PST Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Tue 27 Oct 87 09:22:49-PST Received: from hplms2 by hplabs.HP.COM with SMTP ; Tue, 27 Oct 87 09:25:26 PST Received: from hplabsz.hpl.hp.com by hplms2; Tue, 27 Oct 87 09:24:51 pst Return-Path: Received: from hplabsz by hplabsz; Tue, 27 Oct 87 10:24:21 pst To: Masinter.pa@xerox.com Cc: fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu, kempf%hplabs@hplabs.HP.COM Subject: TRACE Proposal (Version 2) X-Mailer: mh6.5 In-Reply-To: Your message of Wed, 21 Oct 87 09:58:09 -0700. <24566.561833889@hplabsz> Date: Tue, 27 Oct 87 09:24:16 PST Message-Id: <15332.562353856@hplabsz> From: kempf%hplabsz@hplabs.HP.COM Larry: As requested, this version makes no mention of a break option and cross references the format note you mentioned. I've also added a reference to Moon's SETF-CLOS proposal, since fixing TRACE will also be needed for it. Is there any sense of where/whether the TRACE-EXECUTION generic function as a system entry point for extensible debugging is appropriate? jak (Font Note: UPPERCASE indicates bold, _this_ indicates italic) ------------------------------------------------------------------------------- Issue: TRACE-CLOS References: trace macro pp. 440-441 TRACE-ARGUMENT-FORMAT-OPTIONS SETF-CLOS Category: MODIFICATION Edit history: Version 1, 21-Oct-87 Kempf Version 2, 27-Oct-87 Kempf Problem description: With the addition of the Common Lisp Object System, there is no command language level way to trace individual method execution. The TRACE macro, as currently specified in Common Lisp, allows only tracing of globally defined functions through their names. Since a generic function name may have several executable methods, users need some way to specify that they would like invocation of particular methods to be traced, rather than invocation of the entire generic function. In addition, the current specification of TRACE does not allow tracing of functions associated with SETF "methods", of macro functions, nor of lexically defined functions or functions invoked via. their function definition objects. While this proposal does not attempt to address the latter two problems, since identification and/or tracing of these is likely to be implementation dependent, it does leave open the option for those implementations which can arrange it. Proposal (TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION) TRACE _{function-spec}*_ _[Macro]_ UNTRACE _{function-spec}*_ _[Macro]_ Invoking TRACE with a function specification causes the function specified to be traced. Henceforth, whenever the specified function is invoked, information about the call, the arguments passed, and the returned values, if any, will be printed to the stream that is the value of *TRACE-OUTPUT*. UNTRACE undoes any tracing. Calling TRACE without any arguments prints a list of currently traced executable entities, calling UNTRACE without any arguments causes tracing to be undone for all currently traced entities. A _function_spec_ is either a symbol naming a function (i.e. a symbol whose global function cell is bound to a function definition object, or to which the application of MACRO-FUNCTION will return a function definition object) or a list whose first element indicates what kind of funcallable object is to be traced and whose tail indicates which particular function should be traced. The complete set of function specifications will necessarily be implementation dependent; however, every implementation is required to support the following: _symbol_-Invocations of the function or macrofunction named by _symbol_ via. _symbol_ as a global name are traced. (METHOD _generic-function-name-specification_ _{method-qualifiers}_* _parameter-specializer-name-list_ ) If the method whose parameter specializer list, generic function name specification, and method qualifiers are listed is tracable, then invocations through the generic function name specification will be traced. (SETF _symbol_)-If the SETF function having the name specification is tracable, it will be traced (see proposal SETF-CLOS for more information on SETF name specifications). Implementations are encouraged to provide for tracing of as many funcallable objects as possible. Rationale: Adoption of the Common Lisp Object System will require the availability of debugging information on individual methods. Adoption of the SETF-CLOS proposal will require means of tracing SETF functions. It is also not possible to easily trace either SETF functions or macrofunctions today. Current practice: There is currently no way to trace SETF functions, aside from macroexpanding a SETF form and using the resulting name in a TRACE macro invocation. There is currently no way to trace macroexpansion functions when they are invoked through their global names, except through complicated use of *MACROEXPAND-HOOK*. Adoption Cost: The proposed syntax is upwardly compatible with the current Common Lisp syntax. It will require the addition of function specification parsing and wrapper code to trace SETF function executions and macrofunction executions. When the Common Lisp Object System is fully implemented, wrapper code for tracing method execution will also be required. Cost of non-adoption: Programmers will have to continue using a complicated set of Lisp commands to arrange for SETF function and macrofunction tracing. When the Common Lisp Object System is fully implemented, programmers will have to use metaobject protocol functions to arrange for tracing. Benefits: Allow programmers to obtain information on individual method invocations, and on SETF function and macrofunction invocations. Conversion Cost: Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper generating functions. FAILNET-ORIGIN<275764.871027@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  DKė DKėDKėDK ė!DKė)DKė1DKė9DKėADK ėIDK$ėQDK(ėYDK,ėaDK0ėiDK4ėqDK8ėyDK<ė  xDK DkDKDK@H.w 32\.n~) Hl)p ( 0K(X/h0H0m  5cx 0n@ hr uX1l`,huP0w8x`x`||5")H0Common-Lisp-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Oct 87 01:29:15 EST Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 22:06:14 PST Date: Tue, 27 Oct 87 01:05 EST From: Brad Miller Subject: Re: suggestion for language extension To: Barry Margolin cc: cl@DOUGHNUT.CS.ROCHESTER.EDU In-Reply-To: <871026183445.4.BARMAR@OCCAM.THINK.COM> Message-ID: <871027010550.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Default-Character-Style: (:FIX :CONDENSED :NORMAL) Fonts: CPTFONTC Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627 Phone: 716-275-1118 Date: Mon, 26 Oct 87 18:34 EST From: Barry Margolin Date: Mon, 26 Oct 87 17:37 EST From: Brad Miller There is, in fact, something conceptually simple that could be added to the spec, is upward compatible with the current language, and would make me sleep a lot easier (though compiler writers may groan a bit): Allow overloading of functions. This would allow me to create my own first-class objects, since I could overload common operators to handle (special case) the new type. What do you mean by this? Do you mean overloading in the Ada sense, where you specify the data types of the arguments that cause a particular implementation of the function to be invoked? Yes. Like Ada, the information would be static, unlike Ada, result type wouldn't (necessarily) need to be taken into account. I believe CLOS will allow this, although there will probably be some restrictions on the built-in functions that may be converted to generic functions (my feeling is that only functions proclaimed INLINE should be restricted). I don't think this would be general enough, see following... You mentioned that overloading could be implemented using an ADVISE feature. A simple-minded ADVISE can be implemented using existing CL facilities, so there is no real need for extending the language: This (a macro) does not alter the run-time semantics of already compiled programs, which would be necessary... ... redefined without affecting the advice, which requires hooks in the implementation; however, I don't think it is necessary for the overloading feature that Brad wants. Then again... Another question: what particular problem does overloading solve for you? What I would *like* to do... Take the example of creating something that is a (possibly infinite) list, but lazy-eval'd. So you want to overload all the existing CL functions that can possibly accept lists, and make them accept lazy-lists as well. Some of them (e.g. reverse) might return an error when you pass them a lazy-list, but most (e.g. cdr) may run the function associated with the lazy-list to generate the next item. Once the lazy-list abstraction/type has been defined, there should be no particular reason existing programs should not be able to accept/deal with them, so long as the underlying functions have been taught how to handle them. You have, with this mechanism, *extended the language* to include the new first class object of lazy-stream, which is considerably different than defining lazy-cons, lazy-car, .... and having your program call these functions itself. To the programmer, the extension is transparent. cons, car, cdr, etc. work on all objects of type list independent of their lazyness. The main intent (for me particularly) is to get scheme-style streams up, but I figured other people might want to create first class objects too... The other thing I *really* would like is scheme-style continuations, but I suspect this sort of thing would be politically non-feasible at this point. Overloading helps, in that I can make continuations first class objects, but getting to just what a continuation is would still be hard since you need to snapshot the stack... This sort of thing may be better addressed as something CL would provide explicitly; I can't think of general underlying mechanisms that solve continuations that would also be useful to make generally available because of their utility in extending the language. (without consing up infinite hair in terms of concrete language semantics). Thanks for your interest! Brad Miller ------ miller@cs.rochester.edu {...allegra!rochester!miller} Brad Miller University of Rochester Computer Science Department FAILmiller Re: suggestion for language extension<275605.871027@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  Dk 2 E DkDk@H " 1?/+ Hl ?p ( 0IE(X!h0  H  Q)x   @ h  uX!`,h!P08``nnCOMMON-LISP-mailer@SAIL.Stanford.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Oct 87 01:08:47 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Oct 87 21:49:55 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 282589; Mon 26-Oct-87 23:37:47 EST Date: Mon, 26 Oct 87 23:37 EST From: Robert W. Kerns Subject: extending DEFSTRUCT To: Don Morrison cc: Rick.Busdiecker@cs.cmu.edu, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <871026122502.1.DFM@WHITBY.Palladian.COM> Message-ID: <19871027043741.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Mon, 26 Oct 87 12:25 EST From: Don Morrison If you do, you probably should make it # where NNN is an integer (decimal?) such that two eq structures always have the same number, and two not eq structures don't. I believe this corresponds pretty closely to current practice for those implementations that do support such a beast. The major difference, I believe, is that often NNN is currently an address that can change over time; it would probably be cleaner for eq structures to always print the same, no matter how manner GCs have intervened. Since the hash or whatever it is you'd stick there would only need to be computed if you're printing the thing, I suspect it wouldn't add any serious overhead to structures that's not already there to support eq hash tables. Wait a minute, EQ hash tables can't work that way; they have to work on bignums and rationals and conses and other things that don't have any private slot to store the hash in. And yes, adding overhead to structures to support this would indeed be prohibitively expensive. On the other hand, if you don't mind having things you print never go away in the GC, you could use EQ hash tables to implement this, and only incur a cost for structures you actually print. But not having structures GC is a serious flaw, too. I don't see that we could reasonably impose this on implementations. Also, the octal address is often useful. I use it all the time when I'm debugging the mouse input code so that I can't just point at structures with the mouse. We used to use it a lot more, and (sys:%find-structure-header #o234725) is sort of an idiom around here amongst the hackers of the lower levels. (It returns the object; it means essentially "object at address", and figures out the type codes). FAILRWK extending DEFSTRUCT<275581.871027@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! ADk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  &Dk  E DkDk@Hƕ >AHkGmFQ Hj`p (@0.(X[`0 H,3 (x @ h  uT`z`,h#IP0%8&`&`@SAIL.Stanford.EDU:Pedersen.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 21:38:56 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 18:31:23 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 18:31:13 PST Date: 26 Oct 87 19:30 PDT From: Pedersen.pa@Xerox.COM Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3) In-reply-to: Masinter.pa's message of 26 Oct 87 16:27 PST To: Masinter.pa@Xerox.COM cc: CL-Cleanup@SAIL.STANFORD.EDU, Pedersen.pa@Xerox.COM Message-ID: <871026-183113-2502@Xerox> "Note that simply extending COERCE, MAKE-SEQUENCE, LENGTH, ELT, and the SETF expander for ELT would have the side effect of extending the remaining functions if they are written in the obvious way. For example: (DEFUN SUBSTITUTE (NEW-ITEM OLD-ITEM SEQUENCE &KEY ...) (LET ((RESULT (MAKE-SEQUENCE (TYPE-OF SEQUENCE)))) (DOTIMES (I (LENGTH SEQUENCE) RESULT) (SETF (ELT RESULT I) (IF (EQL (ELT SEQUENCE I) OLD-ITEM) NEW-ITEM (ELT SEQUENCE I))))))" I think this argument is a canard since any implementation worth its salt will type dispatch for all sequence functions. The :generalize proposal will inescapably induce a large number of small changes to existing Common Lisp implementations. It seems more esthetic to localize those changes in a single extension (eg. (coerce x 'sequence)) rather than spreading them all over the sequence functions. J.P. FAILPedersen.pa Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)<275511.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk< cDk 8 E DkDk@H4  :48B4; HjJp (0(XR 0Mx'H (U@ tW uTM0` ,4] 0Pa8c`c`(HA0B C@SAIL.Stanford.EDU,@Score.Stanford.EDU:kempf%hplabsz@hplabs.HP.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 20:52:07 EST Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:42:06 PST Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 26 Oct 87 17:38:44-PST Received: from hplms2 by hplabs.HP.COM with SMTP ; Mon, 26 Oct 87 13:18:48 PST Received: from hplabsz.hpl.hp.com by hplms2; Mon, 26 Oct 87 13:18:14 pst Return-Path: Received: from hplabsz by hplabsz; Mon, 26 Oct 87 14:17:43 pst To: "Scott E. Fahlman" Cc: kempf%hplabsz@HPLABS.HP.COM, cl-cleanup@SAIL.STANFORD.EDU Subject: Re: Issue: TRACE-FUNCTION-ONLY X-Mailer: mh6.5 In-Reply-To: Your message of Sun, 25 Oct 87 17:31:00 -0500. Date: Mon, 26 Oct 87 13:17:39 PST Message-Id: <2540.562281459@hplabsz> From: kempf%hplabsz@hplabs.HP.COM SF> This doesn't really respond to the objection I raised. I didn't suggest SF> that :BREAK was not worthwhile. I said that there are two distinct SF> issues here: whether to extend TRACE to work for methods and setf SF> functions, and whether to extend trace to do all sorts of other neat SF> things. The former is probably not controversial, and I could SF> support a proposal that contains just this. I understand. I was trying to address both issues, but, as you've pointed out, the :BREAK issue is somewhat more complex. I will rewrite the trace proposal to remove the reference to :BREAK, redo the syntax to conform to that currently in CLtL, and leave it up to someone else (who could possibly be me at a later date) to deal with the break issue. JK> While we're discussing this issue, another part of the proposal was to JK> include a generic function, called TRACE-EXECUTION, which took as an JK> argument an object representing an executable entity, like a method object, JK> generic function, function, symbol, etc. An implementation specific method JK> would run to arrange for tracing code to be inserted. Similar to JK> PRINT-OBJECT, all implementations would have to implement tracing using JK> this generic function. The advantage of this is that if someone extends JK> CLOS/CL by including a new funcallable object, like, for example, a JK> remote procedure call, debugging becomes extensible as well. SF> This is going to be a fairly hairy proposal, I think, since you have to SF> trace function names and not functions (unless you want to force SF> implementors to do surgery on compiled function objects). I'd be SF> interested in seeing the details of this proposal. The intent of the proposal was to provide a system level interface for extending debugging capability and for supporting current debugging technology. Thus, since most current debuggers go through function names, the method for implementing debugging on ordinary functions would discriminate on symbols and would use the function wrapping technique which most Lisps currently use for tracing. For tracing methods, the debugging method would discriminate on a method object, and would wrap the method function itself, since one way of implementing method dispatch is to have the generic function use the method function directly (in fact, this is how the PCL implementation works). More advanced Lisp implementation technologies might make it possible to debug the invocation of a function through the function definition object (fundef object), as you've pointed out. By using a generic function, the usual advantages of object oriented programming, in terms of system extensibility, would be available, since the generic function would provide a portable interface which each implementation could customize with the particular capibilities that it can support. Below is a copy of the proposal I submitted to the objects committee in September. Note that it does not appear in the current draft of the Object System specification, pending disposition of where, precisely, it belongs. I'd appreciate hearing what you think of it. jak ------------------------------------------------------------------------------- Font note: UPPERCASE indicates bold, _this_ indicates italic. TRACE-EXECUTION _object_ &KEY :ENVIRONMENT _[Generic Function]_ TRACE-EXECUTION discriminates on _object_ to select an implementation specific method that arranges for the executable entity associated with _object_ to be traced. The :ENVIRONMENT keyword parameter is for those implementations which require environmental information to arrange for tracing to occur. Implementations are required to provide TRACE-EXECUTION as the system level entry point for implementing TRACE functionality. The exact nature and number of methods associated with TRACE-EXECUTION will differ, depending on what executable entities can be specified by TRACE, but every implementation needs to support methods which dispatch on objects having the following classes: SYMBOL-The function indicated by the symbol will be traced when invoked in the environment. METHOD-The method function is traced when invoked. GENERIC-FUNCTION-The generic function is traced when the discriminator code is invoked. Implementations are encouraged to provide as many methods as the implementation technology can support. FAIL Re: Issue: TRACE-FUNCTION-ONLY NET-ORIGIN<275500.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  Dk  E DkDk@HEw 0 HFE HjIgp (80(X'H0H8F (x PG@ t uTLy`,4 PP8``(HA0B C@SAIL.Stanford.EDU:FAHLMAN@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 20:48:51 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:41:27 PST Received: ID ; Mon 26 Oct 87 20:41:57-EST Date: Mon, 26 Oct 1987 20:41 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Masinter.pa@XEROX.COM Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: Issue: SHADOW-ALREADY-PRESENT (version 3) In-reply-to: Msg of 26 Oct 1987 19:57-EST from Masinter.pa at Xerox.COM I favor WORKS. -- Scott FAILFahlman Issue: SHADOW-ALREADY-PRESENT (version 3)<275498.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  tDkW E DkDk@H/G 20X/ny HjHp (80}(X=0 hH (x @ hn uTL`,hqP0s8t`t`(HA0B C@SAIL.Stanford.EDU:FAHLMAN@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 20:47:58 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:38:43 PST Received: ID ; Mon 26 Oct 87 20:38:29-EST Date: Mon, 26 Oct 1987 20:38 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Masinter.pa@XEROX.COM Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: Issue: SHADOW-ALREADY-PRESENT (version 3) In-reply-to: Msg of 26 Oct 1987 19:57-EST from Masinter.pa at Xerox.COM I don't understand this: Epigram: "Who knows what evil lurks in the hearts of men?" I tried to imagine a package as the heart of a man and evil as a symbol, lurking there, but it escaped me.... Obviously you didn't spend enough time listening to radio back in the 1930's. The next line is "The Shadow knows!" Does that help? -- Scott FAILFahlman Issue: SHADOW-ALREADY-PRESENT (version 3)<275496.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  //h/ /h //h //h/"/h/*/h/2/h/:/h!/B/h%/J/h)/R/h-/Z/h1/b/h5/j/h9/r/h=/z/h  /[ 0//@H1e $ 32@19z& HjHp (80 c(XNh0 H8 (x p@ h  uTJd`,hP08``thinkdrw@CCC.DU@ATHET.EDUdevonleirana.mi@SAIL.Stanford.EDU:FAHLMAN@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 20:46:03 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:38:14 PST Received: ID ; Mon 26 Oct 87 20:34:03-EST Date: Mon, 26 Oct 1987 20:33 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Masinter.pa@XEROX.COM Cc: CL-Cleanup@SAIL.STANFORD.EDU, Pedersen.pa@XEROX.COM Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3) In-reply-to: Msg of 26 Oct 1987 19:27-EST from Masinter.pa at Xerox.COM I'm in favor of this (the GENERALIZE option, that is). While I don't think this is super-important, I do think that it is useful. Some of the earlier impression of luke-warmness may have been due to the earlier inclusion of two different options; I remember thinking that we should adopt one or the other, but that I was indifferent as to which option won. I'm not sure about item 2 in the proposal: extending MAKE-SEQUENCE to take an array specifier. That seems confusing to me. On the other hand, I have never had occasion to use MAKE-SEQUENCE, so I don't care too much about how far we stretch it. -- Scott FAILFahlman SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)<275493.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWeYN-! ADk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  oDk & E DkDk@Hƻ 8AH~#Fd{d Hj@p (@0>e(Xg@0 ,H,Y (x .@ tc uT@c`,4i 6Pm8o`o`@SAIL.Stanford.EDU:Masinter.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 20:30:21 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:21:38 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 17:22:23 PST Date: 26 Oct 87 17:22 PST From: Masinter.pa@Xerox.COM Subject: *FEATURES*, system package name To: cl-cleanup@Sail.stanford.edu Message-ID: <871026-172223-2395@Xerox> OK, I'll send out a message asking people to send in a list of feature names and package names, and write a little hack to generate a sorted list. This is the format (this is just an example, of course): (system "Xerox Common Lisp" From "Masinter.PA@Xerox.COM" (Feature :COMMON Description "Common Lisp available") (Feature :XEROX Description "Running in Xerox Common Lisp.") (Feature :INTERLISP Description "The Interlisp programming language and environment are available") (Package "INTERLISP" nicknames ("IL") Description "Interlisp programming language and environment") (Package "XEROX-COMMON-LISP" nicknames ("XCL") Description "Xerox extensions to Common Lisp") (Package "XCL-USER" Description "Default package for Common Lisp windows in Xerox Common Lisp environment") (Package "LISP" nicknames ("COMMON-LISP" "CL") Description "As in CLtL, package containing all Common Lisp symbols") (Package "SYSTEM" nicknames ("SYS" "SI") Description "as in CLtL, system internals") (Package "D-ASSEM" Description "Xerox D-machine assembler") (Package "FASL" Description "Xerox fast-loader") (Package "COMPILER" nicknames ("XCLC") Description "Xerox Common Lisp Compiler") ) FAILMasinter.pa *FEATURES*, system package name<275487.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  DkS E DkDk@H  eItw Hj8'p (@0(XaH0 <H,y (x X>@ t uT8`,4 GP8``Ki\LMQm\LSW@SAIL.Stanford.EDU:Masinter.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 20:12:03 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:00:58 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 16:57:48 PST Date: 26 Oct 87 16:57 PST From: Masinter.pa@Xerox.COM Subject: Issue: SHADOW-ALREADY-PRESENT (version 3) To: cl-cleanup@Sail.stanford.edu cc: Masinter.pa@Xerox.COM line-fold: 80 Message-ID: <871026-165748-2355@Xerox> There was no response to Moon's version 2. I modified the description and rationale to emphasize that this is really two separate proposals, one a clarification, the other a change (allowing strings.) I added a few comments to the test cases. [I removed Moon's parenthetical remark in brackets.] I added an endorsement to the discussion. I don't understand this: Epigram: "Who knows what evil lurks in the hearts of men?" I tried to imagine a package as the heart of a man and evil as a symbol, lurking there, but it escaped me.... ! Issue: SHADOW-ALREADY-PRESENT References: CLtL p.186 Category: CLARIFICATION/CHANGE Edit history: Version 1 Moon 24 Aug 87 Version 2 Moon 27 Aug 87 incorporate suggestions from JonL Version 3 Masinter 26-Oct-87 Problem description: The description of the SHADOW function can be interpreted as saying that the function has no effect, if the symbol is already present in the package. This happens if the third sentence in the description ("then nothing is done") is interpreted as applying to the entire description rather than just to the fourth sentence. SHADOW is said to take symbols as arguments, however only the print-name is meaningful for this operation (that fact is already documented). Proposal SHADOW-ALREADY-PRESENT:WORKS: 1) The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is already present in the package. 2) The first argument to SHADOW is allowed to be or contain strings as well as symbols. The specification "the print name of each symbol is extracted" is to be modified accordingly. Test Case: ;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS list of a package (make-package 'test-1) (intern "TEST" (find-package 'test-1)) (shadow 'test-1::test (find-package 'test-1)) (assert (not (null (member 'test-1::test (package-shadowing-symbols (find-package 'test-1)))))) (make-package 'test-2) (intern "TEST" (find-package 'test-2)) (use-package 'test-2 (find-package 'test-1)) ;should not error ;;; To test the use of strings in place of symbols ;;; change the third line of the test case to ;;; (shadow "TEST" (find-package 'test-1)) ;;; Note the use of capital letters in the string. Rationale: CLtL p. 180 describes a name conflict problem that can occur when calling the function USE-PACKAGE. The name conflict is between a symbol directly present in the using package and an external symbol of the used package. This name conflict may be resolved in favor of the symbol directly present in the using package by making it a shadowing symbol. For this to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the package. Since only the print name of a symbol argument is meaningful, a string should also be accepted. This is particularly useful to avoid problems when compiling code in one package environment and loading it into a slightly different package environment, where the symbol that was referred to at compile time may not be present at load time. This is particularly important because the symbol referred to by the print name may be changed by evaluation of the SHADOW form. A close reading of CLtL shows that one can already use (shadow '#:bar) in place of (shadow 'bar), to achieve much the same effect as (shadow "BAR"). But the user should not have to play such games, strings should be accepted. Current practice: Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is already present in the package. Kyoto Common Lisp, Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the symbol is already present in the package. It seems likely that we will find several implementations in each camp. SHADOW accepts strings in Symbolics Common Lisp. Adoption Cost: It should be two one-line changes in one function. Cost of non-adoption: Inconsistency among implementations and lack of a clear way to resolve the name conflict mentioned in Rationale. Benefits: Consistency among implementations and fewer mysterious package problems. Conversion Cost: Technically this would be an incompatible change to implementations that do not already behave as proposed, however it is difficult to conceive of a user program that would require any conversion to cope with the change. Some users might want to remove kludges that were only necessary to get around the former misbehavior of SHADOW. Esthetics: The proposal would remove an unnecessary special case, thus simplifying the language slightly. Discussion: The issue was raised by Dieter Kolb on the Common-Lisp mailing list. It would be useless for SHADOW to fail to put a symbol that is already present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon believes CLtL intended to describe what is being proposed, but unfortunately used ambiguous language. The cleanup committee endorses this proposal. FAILMasinter.pa Issue: SHADOW-ALREADY-PRESENT (version 3)<275477.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOW YN-! Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  ADk  E DkDk@HNG 0 XgWdΛ Hj6p (@0aa(XY(0 H, + (x  @ t 5 uT6 `,4 ; P ?8 A` A`(s<($ j{@SAIL.Stanford.EDU:Masinter.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 20:07:36 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 16:55:41 PST Received: from Salvador.ms by ArpaGateway.ms ; 26 OCT 87 16:54:30 PST Date: 26 Oct 87 16:51 PST From: Masinter.pa@Xerox.COM Subject: SETF-FUNCTION-VS-MACRO (Version 2) To: CL-Cleanup@sail.stanford.edu CC: Masinter.pa@Xerox.COM line-fold: 80 Message-ID: <871026-165430-2342@Xerox> I made the edits as previously announced. I added to Benefits the improved utility of SETF independent of CLOS. I made a grammatical change somewhere (I'm having trouble finding it), where I added a semicolon and changed the active element of a sentence. I made several changes in case. ! Issue: SETF-FUNCTION-VS-MACRO References: SETF rules for what -place- can be (pp.94-7) COMPILE function (p.438) DEFUN macro (p.57) DISASSEMBLE function (p.439) DOCUMENTATION function (p.440) FBOUNDP function (p.90) FLET special form (p.113) FMAKUNBOUND function (p.92) FTYPE declaration (p.158) FUNCTION special form (p.87) FUNCTION declaration (p.159) INLINE declaration (p.159) NOTINLINE declaration (p.159) LABELS special form (p.113) SYMBOL-FUNCTION and setf of symbol-function (p.90) TRACE macro (p.440) UNTRACE macro (p.440) Category: ADDITION Edit history: Version 1, 13-Oct-87 Moon (based on discussion among the CLOS working group) Version 2, 26-Oct-87 Masinter, minor mods PROBLEM DESCRIPTION: The Common Lisp Object System needs a well-defined way to relate the name and arguments of a setting function to those of a reading function, because both functions can be generic and can have user-defined methods. We tried to hide the name and arguments of the setting function with macrology, but the complexity got out of hand. It seems better to make this information explicit; the version of the CLOS specification that assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS is much simpler in the relevant areas. PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS): Add to Common Lisp the concept of "setf functions". Right now, Common Lisp only has "setf macros", which are defined by define-setf-method and both forms of defsetf. Terminology: - a "setf macro" is something that produces code (or other specifications, as in define-setf-method) which, when evaluated, will perform the effect of an invocation of setf. - a "setf function" is something that is called to perform directly the effect of an invocation of setf. The form (setf (-name- ...) ...), when -name- is defined as a function (rather than a macro) and no setf macro has been defined for -name-, expands into a call to a setf function. The name of this setf function is a list (setf -name-), where -name- is a symbol. The functions, macros, and special forms defined in CLtL and listed in the References section above need to be enhanced to accept such lists in addition to symbols as function names, so that setf functions can be defined and manipulated. A setf function receives the new value to be stored as its first argument. Thus, #'(setf foo) should have one more required parameter than #'foo, the first required parameter is the new value to be stored, and the remaining parameters should be the same as #'foo's parameters. A setf function must return its first argument, since setf is defined to return the new value. A definition of a setf function can be lexically local, like a definition of a reading function. The following rules specify the behavior of SETF; note that these rules are ordered and the first rule to apply supersedes any later rules. These rules are a consistent extension of the current behavior of Common Lisp and the Cleanup committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only rule 4 is new with this proposal. Rules for the macroexpansion of (setf (foo x) y): (1) If the function-name foo refers to the global function definition, rather than a locally defined function or macro, and if there is a setf macro defined for foo, use the setf macro to compute the expansion. (2) If the function-name foo is defined as a macro in the current scope, use macroexpand-1 to expand (foo x) and try again. (3) If the function-name foo is defined as a special form in the current scope, signal an error. (4) Expand into the equivalent of (let ((#:temp-1 x) ;force correct order of evaluation (#:temp-2 y)) (funcall #'(setf foo) #:temp-2 #:temp-1)) Note that rule 4 is independent of the scope of the function name (setf foo). It does not matter if that scope is different from the scope of the function name foo. This allows some nonsensical programs to be written, but does not seem harmful enough to justify making more complicated rules to compare the scopes of the two function definitions. The above rules are actually implemented by GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself. Thus GET-SETF-METHOD generates the appropriate five values for a form that is not a macro-invocation and does not have a defined setf macro. Normally one does not define both a setf function and a setf macro for the same reading function. Normally one defines a local reading function and a local setf function together in a single FLET or LABELS. In the absence of any setf macro definition, SETF of a function expands into a call to the setf function. This means that the setf function only needs to be defined at run time, not compile time. Examples: ;If SETF of SUBSEQ was not already built into Common Lisp, ;it could have been defined like this (defun (setf subseq) (new-value sequence start &optional end) (unless end (setq end (length sequence))) (setq end (min end (+ start (length new-value)))) (do ((i start (1+ i)) (j 0 (1+ j))) ((= i end) new-value) (setf (elt sequence i) (elt new-value j)))) ;Another example, showing a locally defined setf function (defun frobulate (mumble) (let ((table (mumble-table mumble))) (flet ((foo (x) (gethash x table)) ((setf foo) (new x) (setf (gethash x table) new))) .. (foo a) .. (setf (foo a) b)))) ;get-setf-method could implement setf functions by calling ;this function when rules 1-3 do not apply (defun get-setf-method-for-setf-function (form) (let ((new-value (gensym)) (temp-vars (do ((a (cdr form) (cdr a)) (v nil (cons (gensym) v))) ((null a) v)))) (values temp-vars (cdr form) (list new-value) `(funcall #'(setf ,(car form)) ,new-value ,@temp-vars) `(,(car form) ,@temp-vars)))) RATIONALE: By making the names and arguments of setting functions explicit, CLOS is considerably simplified. In addition, this can supersede any proposals to introduce a lexically local form of defsetf; lexically local setf functions serve the same needs. Current code that resembles (defsetf foo |setf FOO|) (defun foo (x) ..) (defun |setf FOO| (x new) ..) or (defsetf foo internal-foo-setter) (defun foo (x) ..) (defun internal-foo-setter (x new) ..) can be, but is not required to be, replaced with the following code (defun foo (x) ..) (defun (setf foo) (new x) ..) An advantage of this is that several disparate styles of using DEFSETF can be replaced with a single common style of using setf functions, making programs more standardized and readable. CURRENT PRACTICE: A few Common Lisp implementations already have a similar feature, in that they allow setting functions named (SETF reader). We don't know of any implementation that has precisely the proposed feature. ADOPTION COST: The main cost is generalization of a few functions to accept lists beginning with SETF where they now accept only symbols. Implementations must add a data structure to store the function definition of a setf function, however, this can trivially be done with property lists or generated symbols. The cost of making the SETF macro expand into a call to a setf function, when it does not find a setf macro or a regular macro to expand, is negligible. This will be an incompatible change for Symbolics, since it already has setf functions but they do not take the same arguments as proposed here. However, the change is considered worthwhile. COST OF NON-ADOPTION: Non-adoption of this proposal would be a significant roadblock to the Common Lisp Object System. Some major rethinking of CLOS would be required. BENEFITS: Allow CLOS to be defined without out-of-hand complexity. Improve usability of SETF. CONVERSION COST: None, this is an upward-compatible change. ESTHETICS: SETF would be more esthetic, but less powerful, if it had only the proposed setf functions and did not have setf macros. Such a major incompatible change is of course out of the question; however, if setf functions are stressed over setf macros, SETF will be much easier to teach. DISCUSSION: Note that in Common Lisp, setf macro expansion is an operation on function names, not on functions. It differs from some dialects of Scheme, such as T, in this respect. This proposal does not attempt to change that. There was some concern about introducing the notion that the name of the setf-function associated with FOO should be a list, (SETF FOO). This is a considerable extension to the idea of a "function name", at least for standard Common Lisp implementations that do not implement Lisp machine style function-specs. However, the CLOS unsuccessfully tried a number of alternatives. Fundamentally the problem is that there has to be a name that the user uses to define the thing and to talk about it. Trying to hide the name just means you use a more obscure name, like an alternate syntax for DEFUN or DEFUN-SETF. Another reason for making the name explicit is to allow one to use FLET for the setf function -- something which would be difficult if there is not a name-like entity that can be bound. This proposal is not incompatible with other extensions to function specifications present in some implementations. The following related features were considered but are specifically not being proposed at this time, since they are unnecessary for CLOS and appear not to improve the simplicity and esthetics of the language: a) Lexically local setf macros, that is, a cross between DEFSETF and MACROLET. This does not appear to be logically necessary. Would all three ways of defining lexically global setf macros need local counterparts? b) Define the meaning of defmacro or macrolet of (setf foo)? This would be a fourth way to define a setf macro. c) Enhance the definition of global setf macros, for example to say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function that takes two arguments and returns five values. d) Introduce a new name for SYMBOL-FUNCTION, since it accepts non-symbols now. e) Should one allow these extended function names in the car-position of an expression to be evaluated? The extra complexity didn't seem justified, instead, an explicit FUNCALL is required. FAILMasinter.pa SETF-FUNCTION-VS-MACRO (Version 2)<275472.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  Dk 2 E DkDk@HHS L(JfHq Hjp (HFx(X40H0W (x X@ t uT`,4 `P8``LMQm\LSW@SAIL.Stanford.EDU,@DOUGHNUT.CS.ROCHESTER.EDU,@THINK.COM:barmar@Think.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 18:56:23 EST Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 15:34:51 PST Received: from Think.COM (THINK.COM) by DOUGHNUT.CS.ROCHESTER.EDU via INTERNET with SMTP id 8511; 26 Oct 87 18:35:09 EST Return-Path: Received: from occam by Think.COM via CHAOS; Mon, 26 Oct 87 18:34:22 EST Date: Mon, 26 Oct 87 18:34 EST From: Barry Margolin Subject: suggestion for language extension To: miller@cs.rochester.edu Cc: cl@doughnut.cs.rochester.edu In-Reply-To: <871026173702.5.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Message-Id: <871026183445.4.BARMAR@OCCAM.THINK.COM> Date: Mon, 26 Oct 87 17:37 EST From: Brad Miller There is, in fact, something conceptually simple that could be added to the spec, is upward compatible with the current language, and would make me sleep a lot easier (though compiler writers may groan a bit): Allow overloading of functions. This would allow me to create my own first-class objects, since I could overload common operators to handle (special case) the new type. What do you mean by this? Do you mean overloading in the Ada sense, where you specify the data types of the arguments that cause a particular implementation of the function to be invoked? I believe CLOS will allow this, although there will probably be some restrictions on the built-in functions that may be converted to generic functions (my feeling is that only functions proclaimed INLINE should be restricted). You mentioned that overloading could be implemented using an ADVISE feature. A simple-minded ADVISE can be implemented using existing CL facilities, so there is no real need for extending the language: (defmacro advise (function &body body) (let ((new-fun (gensym))) `(progn (setf (symbol-function ',new-fun) (symbol-function ',function)) (defun ,function (&rest arglist) (flet ((do-it () (apply ',new-fun arglist))) .,body))))) This defines something like the lispm :AROUND advice, except that (do-it) is used in place of :do-it. It also doesn't support unadvise, named advice, etc., but those merely require maintaining a database. It also doesn't support the lispm feature that an advised function can be redefined without affecting the advice, which requires hooks in the implementation; however, I don't think it is necessary for the overloading feature that Brad wants. Another question: what particular problem does overloading solve for you? If you want a function that is like READ-CHAR except that it does something different when the stream argument is one of your structures, you can do: (defun my-read-char (stream) (if (my-struct-p stream) (read-char-from-my-struct stream) (read-char stream))) and call my-read-char in place of read-char in your program. If your intent was to pass a my-struct to some other CL input function, such as READ or READ-LINE, advising read-char wouldn't necessarily help (CL gives no guarantee that READ, READ-LINE, etc. call READ-CHAR internally, although particular CL implementations may do so). barmar FAILbarmar suggestion for language extension<275439.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  SDk > E DkDk@H  >Iwp Hip (80#(X' 0 EH( (x @ hM uS~z`,hPP0R8S`S`@SAIL.Stanford.EDU:Daniels.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 18:09:49 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:58:50 PST Received: from Salvador.ms by ArpaGateway.ms ; 26 OCT 87 14:50:59 PST Date: 26 Oct 87 15:50 PDT From: Daniels.pa@Xerox.COM Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2) In-reply-to: Masinter.pa's message of 24 Oct 87 17:30 PDT To: Masinter.pa@Xerox.COM cc: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM Message-ID: <871026-145059-2151@Xerox> I would like to add my support to 1-RETURN-INNER. -- Andy. -- FAILDaniels.pa Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)<275418.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Dk DkDkDk !Dk)Dk1Dk9DkADk IDk$QDk(YDk,aDk0iDk4qDk8yDk<  Dk " E DkDk@H,  .;-/,CyQ Hip (@0w(XDh0HXu (x @ hz uSiU`,h}P08``@SAIL.Stanford.EDU:Masinter.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 17:23:10 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:13:22 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 14:08:46 PST Date: 26 Oct 87 14:55 PDT From: Masinter.pa@Xerox.COM Subject: Issue: PATHNAME-SUBDIRECTORY-LIST In-reply-to: EWeaver.pa's message of Mon, 26 Oct 87 09:35 PST To: cl-cleanup@sail.stanford.edu cc: ibuki!dbp@labrea.stanford.edu Message-ID: <871026-140846-2061@Xerox> I had marked the issue PATHNAME-SUBDIRECTORY-LIST as withdrawn; I thought Moon's point ("the only reason to change the language would be if we want to force all implementations to use the same representation of structured directories, which might be difficult if some implementation uses a strange file system with a directory feature we haven't thought of.") was compelling. However, I think there is some advantage to encouraging some consistency of practice for those systems which do have subdirectory structures... I'd recommend we postpone this issue for now... FAILMasinter.pa Issue: PATHNAME-SUBDIRECTORY-LIST<275386.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWfYN-! C&M&M& M&M%&M-&M5&M=&ME&"MM&&MU&*M]&.Me&2Mm&6Mu&:M}&>M  P&G F&&@H5 &C< Hiɥp (X j5(XFP 0HPI@ hJ uSK9` ,hMP0O8 P`P`TT [ \ ] ^ _ ` a b@SAIL.Stanford.EDU:kessler%cons@cs.utah.eduJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 16:16:18 EST Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 12:52:24 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA17779; Mon, 26 Oct 87 13:52:35 MST Received: by cons.UTAH.EDU (4.30/4.40.2) id AA03833; Mon, 26 Oct 87 13:52:20 mst Date: Mon, 26 Oct 87 13:52:20 mst From: kessler%cons@cs.utah.edu (Robert R. Kessler) Message-Id: <8710262052.AA03833@cons.UTAH.EDU> To: common-lisp@sail.stanford.edu Subject: 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS CALL FOR PAPERS 1988 ACM Conference on LISP AND FUNCTIONAL PROGRAMMING Snowbird, Utah, July 25-27, 1988 The 1988 ACM Conference on LISP and Functional Programming is the fifth in a series of biennial conferences devoted to the theory, design, and implementation of programming languages and systems that support symbolic computation. The conference is jointly sponsored by ACM SIGPLAN, SIGACT, and SIGART. Papers presented at the conference must include new ideas or experimental results that have not been previously published. The conference program is not limited to topics discussed in previous conferences in the series; authors are strongly encouraged to submit papers that in- troduce important new topics that are relevant to functional pro- gramming and symbolic computation. The major topics that have been addressed at previous conferences include: 1) programming language concepts and facilities 2) implementation methods 3) machine architectures 4) semantic foundations 5) programming logics 6) program development environments 7) applications of symbolic computation Authors are invited to submit 11 copies of a technical summary of a prospective confer- ence paper to the program committee chairman. The length of the summary should not exceed 3,000 words (10 pages double-spaced or typeset 10-point on 16-point spacing). Since the committee ex- pects to receive a large number of submissions, the summary should be organized so that it is easily understood. It is im- portant for the summary to identify what has been accomplished, explain why it is significant, and compare it with previous work. Submissions must be received by Jan 22, 1988. They should in- clude a return postal address and an electronic mail address if it is available. Authors will be notified of the acceptance or rejection of their papers by March 11, 1988. Full versions of the accepted papers must be received in camera-ready form by April 22, 1988. Authors of accepted papers will be required to sign ACM copyright release forms. Proceedings will be distribut- ed at the conference and will later be available for purchase from the ACM. The conference site at Snowbird, Utah is a resort located in the rugged Wasatch mountain range approximately 35 miles from Salt Lake City. Summer activities include hiking, climbing, swimming, tennis, and wildflower photography. Program Committee Chairman Program Committee Robert (Corky) Cartwright Harold Abelson, MIT Attn: LFP 88 Richard Bird, Oxford University Rice University Luca Cardelli, DEC Systems Res. Ctr. Department of Computer Science Robert Cartwright, Rice University P. O. Box 1892 Richard Gabriel, Lucid Inc. Houston, TX 77251-1892 Christopher Haynes, Indiana University (713) 527-4834 Gerard Huet, INRIA Rocquencourt cork@rice.edu Gilles Kahn, INRIA Sophia Antipolis David Moon, Symbolics Inc. Guy Steele, Thinking Machines Corp. Carolyn Talcott, Stanford University General Chairman Local Arrangements Chairman Jerome Chailloux Robert Kessler INRIA University of Utah Domaine de Voluceau-Rocquencourt Department of Computer Science B.P. 105 3190 M.E.B. Le Chesnay Cedex Salt Lake City, Utah 84112 France kessler@cs.utah.edu chaillou@inria.inria.fr FAILNET-ORIGIN<275332.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  q q qq$q,q4q<q"Dq&Lq*Tq.\q2dq6lq:tq>|q  U 2 !@H  "wz Hip (y(X 0xXKH 0N (@ hO uSC`,hRP0T8U`U`0XYYg?{04R@SAIL.Stanford.EDU:MATHIS@C.ISI.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 16:01:46 EST Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 12:33:31 PST Date: 26 Oct 1987 12:32-PST Sender: MATHIS@C.ISI.EDU Subject: Wednesday afternoon agenda From: MATHIS@C.ISI.EDU To: x3j13@SAIL.STANFORD.EDU Message-ID: <[C.ISI.EDU]26-Oct-87 12:32:47.MATHIS> I have already gotten an indication from a few people that they have to leave around 2pm or 3pm Wednesday afternoon. That's fine. However, it might make sense to have the last item on the Wednesday agenda be something that might be considered less central to the overall work. Any suggestions? Thanks, Bob FAIL Wednesday afternoon agendaMATHIS<275310.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ++{+ +{ ++{ ++{+"+{+*+{+2+{+:+{!+B+{%+J+{)+R+{-+Z+{1+b+{5+j+{9+r+{=+z+{  t+  ,5++@H-U  /.-ey HihEp (  %(XH0H j ")Hx @ hn uRhT`,hqP0s8t`t`Ki\LMQm\LSW@SAIL.Stanford.EDU:Moon@ALLEGHENY.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Oct 87 12:48:34 EST Received: from [128.81.41.45] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 09:35:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 69583; Mon 26-Oct-87 12:26:44 EST Date: Mon, 26 Oct 87 12:26 EST From: David A. Moon Subject: SETF-FUNCTION-VS-MACRO (Version 1) To: Scott E. Fahlman cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <19871026172642.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 25 Oct 1987 19:50 EST From: "Scott E. Fahlman" ....we might want to say explicitly that (proclaim '(inline (setf foo))) is allowed. Version 1 of the proposal said that. I didn't keep a copy of version 2, so I can't check, but I assume version 2 said so also. FAILMoon SETF-FUNCTION-VS-MACRO (Version 1)<275153.871026@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  [[7 [[7[ [7[[7$[[7,[[74[[7<[[7D["[7L[&[7T[*[7\[.[7d[2[7l[6[7t[:[7|[>[7   [S [;[[@H* & J+a Hf'p ((09K(XHX0H@{ (x H|@ t uL(1`,4 P8 ` `LMQm\LSW@SAIL.Stanford.EDU:Pavel.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Oct 87 19:37:16 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Oct 87 16:20:49 PST Received: from Salvador.ms by ArpaGateway.ms ; 25 OCT 87 16:21:30 PST Date: Sun, 25 Oct 87 15:44:22 PST From: Pavel.pa@Xerox.COM Subject: Re: macrolet/flet/labels In-reply-to: <562125428/bein@pyrnova> To: common-lisp@sail.stanford.edu Message-ID: <871025-162130-1009@Xerox> Date: 24 Oct 87 18:57 PDT From: David Bein What is the current consensus about using a name within a macrolet/flet/labels construct which is a special form? I am cleaning things up this way and it occurred to me that things could go either way. I am of the opinion that the names of the special forms are really reserved words and that you cannot redefine them even lexically. Thus, none of the names of special forms can be used as the defined-name in flet, labels, or macrolet. I can't imagine a case in which this could be anything but extremely confusing to a program reader nor can I think of any reason why it might be useful. Pavel FAILPavel.pa Re: macrolet/flet/labels<274802.871025@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  /l /l/l /l #/l+/l3/l;/lC/l!K/l%S/l)[/l-c/l1k/l5s/l9{/l=  1/lG 0 /l/l@H1`  42u Heyp (80<_(XT80H8 (x @ t% uL%`,4+ P/81`1`,@150 6 00@SAIL.Stanford.EDU:FAHLMAN@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Oct 87 18:11:09 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 15:02:37 PST Received: ID ; Sun 25 Oct 87 18:02:38-EST Date: Sun, 25 Oct 1987 18:02 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: CL-CLEANUP@SAIL.STANFORD.EDU Cc: willc%tekchips.tek.com@RELAY.CS.NET Subject: Issue: FUNCTION-TYPE (Version 6) In-reply-to: Msg of 23 Oct 1987 14:51-EDT from Masinter.pa at Xerox.COM I (still) support FUNCTION-TYPE: STRICT-REDEFINITION. A couple of minor comments on this presentation: There needs to be a heading, "Rationale", I think, after point 8 of the proposal proper. You want to clearly mark the transition from proposal to argument. I still don't subscribe to Clinger's view of selective linking, but the comments in this proposal do no harm. Now that there is no discussion of a coercing version of the proposal, some of the material in the discussion section has dangling pointers. To fix this, just say at the start of the discussion section that one option discussed earlier was similar to this one, but allowed FUNCALL, etc. to take anything that can be coerced to a function. -- Scott FAILFahlman Issue: FUNCTION-TYPE (Version 6)<274765.871025@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  8  8 8 8 #8 +8 38 ;8 !C8 %K8 )S8 -[8 1c8 5k8 9s8 ={8  ( 4 S@H<  > @+_<{ Hep (k(X?T 0 H 7 (x H@ h" uKUV`,h%MP0'8(`(`Ki\LMQm\LSW@SAIL.Stanford.EDU:RAM@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Oct 87 16:41:35 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 13:31:42 PST Received: ID ; Sun 25 Oct 87 16:32:12-EST Date: Sun, 25 Oct 1987 16:32 EST Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Masinter.pa@XEROX.COM Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2) In-reply-to: Msg of 24 Oct 1987 20:30-EDT from Masinter.pa at Xerox.COM I don't see why the "is an error" possibility for case one has been discarded out of hand. The only argument for making this well defined is that it is "in the way of producing a valid portable error system". One could suppose that there are complex, non-obvious, situations in which one of RETURN-INNER or RETURN-OUTER is required to implement an error system. If this were the case, then we would be forced to make that choice. But Moon (I believe) argues that it is quite acceptable to be required to signal an error, and thus SIGNAL-ERROR is presumably not incompatible with having a portable error system. Moon further went on to argue that the error which is required to be signalled is required not to be handleable. This seems to be a strong indication that "is an error" is in fact the correct interpretation. The language semantics of "an error that cannot be handled" is indistinguishable from "is an error", since a program cannot exploit this distinction. This is a pure environment issue. Of course, saying that this condition "is an error" allows all of the suggested interpretations, and thus means that noone is required to to anything. My presonal preference for a definite semantics of this construct is RETURN-INNER. This is largely due to the conceptual simplicity that I as a compiler writer perceive. The reason I have argued for "is an error" is that I don't want to be forced to implement any of the alternatives. I think that people have greatly underestimated the semantic garbage that this change will load on to lexical exits. The reason that this doesn't bother anyone is that existing Common Lisp implementations implement non-local lexical exits on top of dynamic exits, rather than the other way around. It is bogus to suppose that each syntactically distinct BLOCK will have a distinct run-time data structure that you can allocte bits in. If you have a construct like: (block foo ... (block bar ...)) It is not currently required that compilers maintain any distinction between blocks FOO and BAR; those are just different names for the same continuation. Yet if we fill in the ...'s in this way, then SIGNAL-ERROR prevents the obvious interpretation of BLOCK as naming a continuation: (block foo (block bar (unwind-protect (return-from foo 'foo) (return-from bar 'bar)))) FOO and BAR name exactly the same continuation, but they are somehow magically gratuitously distinctified simply due to being used from within an unwind-protect. Note that in this test case, the result of RETURN-INNER and RETURN-OUTER are exactly the same. Although I favor RETURN-INNER, RETURN-OUTER is not nearly as semantically bankrupt as SIGNAL-ERROR, since it doesn't require distinctions to be made between identical continuations. But I still believe RETURN-OUTER is more difficult to implement than RETURN-INNER, since it still introduces an innerness/outerness distinction that is not fundamentally part of a lexical exit. In simply naming these proposals RETURN-INNER/RETURN-OUTER, a dynamic component has implicitly been introduced into lexical exit. RETURN-INNER simply ways "use this continuation"; RETURN-OUTER says "maybe use some other continuation depending on some rule of dynamic scoping that is otherwise totally irrelevant to the semantics of RETURN-FROM unless there is an UNWIND-PROTECT around somewhere". Rob FAILRam Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)<274728.871025@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  -i-5-i-5 -i-5-i-5-i&-5-i.-5-i6-5-i>-5#-iF-5'-iN-5+-iV-5/-i^-53-if-57-in-5;-iv-5?-i~-5  -i 4 --i-i@H.^S 0~/E.f Hu#-Vp (( 2(XL0 cH  ")Hx d@ t Q`,4 iP8``"(@)KITH*C!$0 V R%dh"(@)KITH*C! h2H vx@SAIL.Stanford.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Oct 87 15:16:38 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 87 12:08:25 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 259304; Tue 20-Oct-87 15:09:25 EDT Date: Tue, 20 Oct 87 15:08 EDT From: Kent M Pitman Subject: :1 To: CL-Cleanup@SAIL.STANFORD.EDU cc: KMP@STONY-BROOK.SCRC.Symbolics.COM Message-ID: <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Does anyone have an unambiguous reference to a passage that claims that the syntax ``:1'' denotes a symbol? In the 3600 implementation, it's a number and I've heard people claim that this is a bug, but I just looked and could not find any text which convinced me of this. If no one can convince me, I'll write up a cleanup item. FAILKMP :1<271909.871020@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Em#Em# Em#Em#E%m#E-m#E5m#E=m#"EEm#&EMm#*EUm#.E]m#2Eem#6Emm#:Eum#>E}m#  AE  EE@H  =7p HuQEp (x0-;(X(x0+H ")Dx -@ t5 A[`,4; P?8A`A`IINd:8N$(#Mvh:XlR2\D`@SAIL.Stanford.EDU:DCP@YUKON.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 16:33:09 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 87 13:11:21 PDT Received: from SWAN.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 277966; Fri 16-Oct-87 16:11:56 EDT Date: Fri, 16 Oct 87 16:12 EDT From: David C. Plummer Subject: Re: with-open-stream and with-open-file To: Pavel.pa@Xerox.COM, common-lisp@sail.stanford.edu In-Reply-To: <871016-105629-3613@Xerox> Message-ID: <19871016201200.1.DCP@SWAN.SCRC.Symbolics.COM> Date: Fri, 16 Oct 87 10:56:21 PDT From: Pavel.pa@Xerox.COM [deleted] Surely I'm misunderstanding you. Why use the above form instead of simply `constructor'? In my example, there is no reason... It must be that you mean to do more stuff before the prog1, perhaps to "set up" the stream and/or some other structures concerned with it. ... and indeed this is what I typically use it for. I checked a few of my cases, and what is >really< going on, for me, is in the internals of constructing a stream and is something like (defun open (pathname &rest open-options) (with-open-stream (stream (construct-file-stream)) ...process-options... (shiftf stream nil))) The idea would be to have the implicit unwind-protect around those set-up forms and then be able to leave the unwind-protect with the stream still open. Have I properly understood your intent? Yes. If so, then I must say that I would find the form you describe far less clear than the equivalent explicit unwind-protect. In general, I dislike forms that pass information to invisible parts by the setting of a lexical variable. The information path is just too hidden. That's a good point which I'll have to think about. Five minutes' reflection, clearly not enough, says: - with-open-thing neatly packages the unwind-protect and the abort cleanup. - with-open-thing requires the programmer to remember only one form: the with-open-thing form. This observation is quite weak; convention would dictate that there would be a corresponding open-thing form (e.g., with-open-serial-stream/open-serial-stream). It might be, however, that the with-open-thing is an external symbol and open-thing is internal. The first observation will probably cause me to continue my current practices, though at a higher level of awareness. Whatever consensus we come to, the language should be clarified and faulty implementations corrected so that the goal of writing portable programs isn't diminished. FAILDCP Re: with-open-stream and with-open-file<270375.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  mm mm%m-m5m=m"Em&Mm*Um.]m2em6mm:um>}m  F < E@H.  0!/.|/ Hu^p ((0&A(XpX0uH@; (x @<@ h@ AI`,hCP0E8F`F`JJ Fravid ummer@QUABCRC.Sics.C@SAIL.Stanford.EDU:Pavel.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 14:46:54 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 87 10:58:54 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 16 OCT 87 10:56:29 PDT Date: Fri, 16 Oct 87 10:56:21 PDT From: Pavel.pa@Xerox.COM Subject: Re: with-open-stream and with-open-file In-reply-to: <871016113352.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> To: common-lisp@sail.stanford.edu Message-ID: <871016-105629-3613@Xerox> Date: Fri, 16 Oct 87 11:33 EDT From: David C. Plummer CLtL says that the stream (file) scoped by with-open-stream (with-open-file) is closed when the form is exited, independent of exit-reason. I would like people to consider the following allowance: that if the stream variable is NIL during the close operation, then the stream (file) is not closed. Thus (with-open-stream (stream constructor) (prog1 stream (setq stream nil))) would evaluate to an open stream. [More language supporting the above as an idiom.] Surely I'm misunderstanding you. Why use the above form instead of simply `constructor'? It must be that you mean to do more stuff before the prog1, perhaps to "set up" the stream and/or some other structures concerned with it. The idea would be to have the implicit unwind-protect around those set-up forms and then be able to leave the unwind-protect with the stream still open. Have I properly understood your intent? If so, then I must say that I would find the form you describe far less clear than the equivalent explicit unwind-protect. In general, I dislike forms that pass information to invisible parts by the setting of a lexical variable. The information path is just too hidden. Pavel FAILPavel.pa Re: with-open-stream and with-open-file<270324.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  GGdGGd GGdGGdG&GdG.GdG6GdG>Gd#GFGd'GNGd+GVGd/G^Gd3GfGd7GnGd;GvGd?G~Gd  FG 0 HGG@H`G 2 baf`*|/ Hu.p ((0'?(XpX0uH@; (x @<@ h@ A`,hCP0E8F`F`JJ Fravid ummer@QUABCRC.Sics.C@SAIL.Stanford.EDU:Pavel.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 14:20:30 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 87 10:58:54 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 16 OCT 87 10:56:29 PDT Date: Fri, 16 Oct 87 10:56:21 PDT From: Pavel.pa@Xerox.COM Subject: Re: with-open-stream and with-open-file In-reply-to: <871016113352.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> To: common-lisp@sail.stanford.edu Message-ID: <871016-105629-3613@Xerox> Date: Fri, 16 Oct 87 11:33 EDT From: David C. Plummer CLtL says that the stream (file) scoped by with-open-stream (with-open-file) is closed when the form is exited, independent of exit-reason. I would like people to consider the following allowance: that if the stream variable is NIL during the close operation, then the stream (file) is not closed. Thus (with-open-stream (stream constructor) (prog1 stream (setq stream nil))) would evaluate to an open stream. [More language supporting the above as an idiom.] Surely I'm misunderstanding you. Why use the above form instead of simply `constructor'? It must be that you mean to do more stuff before the prog1, perhaps to "set up" the stream and/or some other structures concerned with it. The idea would be to have the implicit unwind-protect around those set-up forms and then be able to leave the unwind-protect with the stream still open. Have I properly understood your intent? If so, then I must say that I would find the form you describe far less clear than the equivalent explicit unwind-protect. In general, I dislike forms that pass information to invisible parts by the setting of a lexical variable. The information path is just too hidden. Pavel FAILPavel.pa Re: with-open-stream and with-open-file<270299.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  GGdGGd GGdGGdG&GdG.GdG6GdG>Gd#GFGd'GNGd+GVGd/G^Gd3GfGd7GnGd;GvGd?G~Gd  G 0 HGG@He3 2 mSle: Hup (X 2(X| 0 JH(@ t A` ,4 PP8 ``629-3erox>Date: 16 O 11:3 Fravid ummer@QUABCRC.Sics.C@SAIL.Stanford.EDU:sandra%orion@cs.utah.eduJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 14:19:57 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 11:06:13 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA25495; Fri, 16 Oct 87 12:06:14 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA12450; Fri, 16 Oct 87 12:05:57 MDT Date: Fri, 16 Oct 87 12:05:57 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8710161805.AA12450@orion.utah.edu> Subject: compile-time effects of top-level forms To: cl-cleanup@sail.stanford.edu Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS References: CLtL pages 66-70, 143 Category: CLARIFICATION Edit history: V1, 07 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu) V2, 15 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu) Related issues: none Problem description: CLtL currently leaves several issues unresolved regarding the compile-time handling of top-level forms such as DEFMACRO and DEFVAR. The purpose of this proposal is to ensure that all CL implementations support usages which appear to be standard programming practices. This proposal addresses only the semantics of top-level defining forms as it affects compilation of subsequent forms in the same file. Specifically, this proposal does *not* attempt to specify: (1) Compile-time behavior of defining forms which do not appear at top-level within the file being compiled. (2) Inheritance or separation of the compiler environment from the normal, interpreter environment; or inheritance of the compiler environment across calls to COMPILE-FILE. Proposal: Certain defining macros, appearing at top-level within a file being processed by COMPILE-FILE, normally have compile-time side effects which affect how subsequent forms in the same file are compiled. As an example, DEFVAR should store information that tells the compiler that bindings to the named variable that appear later in the file should be made special bindings, rather than the default lexical bindings. In some implementations, compile-time definitions may be handled differently than those which would occur if the file was loaded in the usual way. It should not be assumed that the compile-time effects of the defining forms remain in place after compilation is completed. In particular, an implementation may or may not make the definitions available to the interpreter or to further calls to COMPILE-FILE. The defining forms which have compile-time side effects are as follows: DEFTYPE: Type names defined via DEFTYPE must be recognized as valid in subsequent type declarations. DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile time, so that occurences of the macro later on in the file will be expanded correctly. The body of the macro (*not* the expansion) must be evaluable at compile time. DEFUN: An implementation may choose to store information about the function for the purposes of compile-time error-checking (such as checking the number of arguments on calls). Portable code should not rely on DEFUN making the function definition available at compile time. DEFVAR, DEFPARAMETER: The compiler must recognize that the variables named by these forms have been proclaimed special. The initial value form must not be evaluated at compile time. DEFCONSTANT: An implementation may choose to store information about the variable for the purposes of compile-time error-checking (such as checking for rebinding of or assignment to the variable). An implementation may also choose to evaluate the inital value form at compile time. DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the expansion of calls to SETF later on in the file. The body of DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable at compile time. DEFSTRUCT: The structure type name must be recognized as a valid type name in declarations, as for DEFTYPE. The structure slot accessors must be made known to SETF. In addition, further DEFSTRUCT definitions should be able to :INCLUDE a structure type defined earlier in the file being compiled. The functions which DEFSTRUCT generates, and the #S reader syntax, may or may not be available at compile time. Test Case: ;;; DEFTYPE (deftype small-int () '(int 0 10)) (let ((x 0)) (declare (type (small-int x))) (format t "Type a number between 0 and 10:") (setq x (read)) (format t "The number is ~s.~%" x)) ;;; DEFMACRO (defmacro silly (x) `(car ,x)) (let ((y nil)) (format t "Type a list:") (setq y (read)) (format t "The SILLY macro returned ~s.~%" (silly y))) ;;; DEFVAR and DEFPARAMETER (defvar *v1* (progn (print "Defvar should print this at load time.") 'v1-global-value)) (defparameter *v2* (progn (print "Defparameter should print this at load time.") 'v2-global-value)) (defun test-defvar-and-defparameter () (format t "*v1* = ~s~%" *v1*) (format t "*v2* = ~s~%" *v2*)) (let ((*v1* 'v1-special-binding-value) (*v2* 'v2-special-binding-value)) (test-defvar-and-defparameter)) ;;; DEFCONSTANT (defconstant *v3* (progn (print "This may be printed at compile-time as well as load time.") 'v3-value)) ;;; DEFSETF (defsetf silly set-silly) (defun set-silly (x value) (if (y-or-n-p "Do you want to change the CAR of ~s to ~s?" x value) (setf (car x) value)) value) (setf (silly (list 'a 'b 'c)) 'j-random-luser) ;;; DEFSTRUCT (defstruct person name age sex) (defstruct (astronaut (:include person) (:conc-name astro-)) helmet-size (favorite-beverage 'tang)) Rationale: The proposal reflects standard programming practices. The primary purpose of the proposal is to make an explicit statement that CL supports the behavior that most programmers expect and many implementations already provide. The only reference to compile-time processing of defining forms in CLtL appears to be in reference to DEFMACRO, on page 143, where it is stated that macro definitions must be ``seen'' by the compiler before the first use of the macro. Current practice: Many (probably most) Common Lisp implementations, including VaxLisp and Lucid Lisp, are already largely in conformance. Kyoto Common Lisp is a notable offender. By default, KCL evaluates *all* top level forms as they are compiled, which is clearly in violation of the behavior specified on p 69-70 of CLtL. There is a flag to disable the compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do not make their definitions available at compile-time either. Adoption Cost: The expansions of defining macros typically store information on property lists or in hash tables, where it is later accessed by the compiler. The simplest way to achieve the required behavior is to modify the expansions to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the forms which store this information. Cost of non-adoption: The current vagueness in CLtL on compiler semantics can lead to unexpected portability problems. At least one person commented on the original version of the proposal with, in effect, "Doesn't CLtL already *say* that somewhere?!?" The problem now is that what many people (even experienced programmers) think are portable programming practices are actually not. Benefits: Adoption of the proposal will provide more definite guidelines on how to write programs that will compile correctly under all CL implementations. Conversion Cost: Minimal. Esthetics: Without a definite statement on the compile-time behavior of top-level defining forms, programmers need to wrap an explicit EVAL-WHEN around all such forms to guarantee consistent behavior across implementations. It would be cleaner to specify a default behavior that does what people seem to expect anyway. Discussion: Reaction to an earlier version of this proposal on the CL mailing list was overwhelmingly positive. The current version incorporates a couple additional suggestions that were made by others, notably Robert Kerns. ------- FAILNET-ORIGIN<270295.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  O(O( O(O(O&(O.(O6(O>(#OF('ON(+OV(/O^(3Of(7On(;Ov(?O~(  OO OO@HG 4 MKG Hu/p (X w(XW 0 8H(q@ ts Am` ,4y >P}8 ``du (S J Lore) ge-Id10161A1246on.utu> St: prl forfying@SAIL.Stanford.EDU:sandra%orion@cs.utah.eduJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 14:18:24 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 11:06:55 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA25574; Fri, 16 Oct 87 12:06:57 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA12462; Fri, 16 Oct 87 12:06:51 MDT Date: Fri, 16 Oct 87 12:06:51 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8710161806.AA12462@orion.utah.edu> Subject: proposal for modifying behavior of REQUIRE To: cl-cleanup@sail.stanford.edu Issue: REQUIRE-PATHNAME-DEFAULTS References: CLtL p. 188 Category: CHANGE, ADDITION Edit history: V1, 15 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu) Related issues: none Problem description: If an explicit pathname is not given to the function REQUIRE, it decides what files to load in an implementation-specific manner. The proposal specifies a portable mechanism for locating modules intended to augment current nonportable mechanisms. Proposal: *REQUIRE-PATHNAME-LIST* [Variable] The variable *REQUIRE-PATHNAME-LIST* is a list of pathnames. This list is used by the function REQUIRE in determining where to look for modules an explicit pathnames are not specified. REQUIRE tests for the following cases: (1) If the pathname argument is present and non-NIL, it is a single pathname or a list of pathnames whose files are to be loaded in order, left to right. (2) A pathname is constructed from the module name and merged with successive pathnames from the list *REQUIRE-PATHNAME-LIST*, until a matching file is found and loaded. (3) The system will determine, in some system-dependent manner, which files to load. This will typically involve some central registry of module names and the associated file lists. Users will typically wish to push new pathnames onto the front of *REQUIRE-PATHNAME-LIST* to specify alternate locations where modules may be found. Test Case: Rationale: Because of the wide variation between implementations, leaving it up to REQUIRE to determine which files to load is very nonportable. Providing an explicit pathname is often impractical as well; for example, the same code may run under two implementations with different operating systems and different file naming conventions; the modules may reside in different places on different machines; or it may be desirable to support alternate versions of some modules (such as a release version and an experimental version). This proposal provides a portable way of describing where modules can be found. The value of the *REQUIRE-PATHNAME-LIST* can be established in a startup or initialization file, keeping a system-specific detail separate from portable code files. Allowing a search list rather than a single default pathname gives users extra flexibility to customize the behavior of REQUIRE. Moreover, the current default behavior is still supported for those programs which depend on it. Current practice: The idea of using a search list for loadable modules is modeled after the LoadDirectories* variable used by Portable Standard Lisp. PCLS, the CL compatibility package layered on top of PSL, currently uses a variable SYS:*REQUIRE-PATHNAME-LIST* as described in this proposal. VaxLisp (under VMS) looks for a module with the specified name first in the current directory, then in the place specified by the logical name LISP$MODULES, then in LISP$SYSTEM. Lucid's documentation does not specify how their implementation of REQUIRE works. I was unable to get it to find modules except in *DEFAULT-PATHNAME-DEFAULTS*. KCL looks for modules only in *DEFAULT-PATHNAME-DEFAULTS*. Adoption Cost: The change is minor and isolated to a single function. Here is a suggested implementation of REQUIRE: (defvar *require-pathname-list* nil "Where REQUIRE looks for modules if you don't give an explicit pathname.") (defun require (module &optional pathname) (cond ((member (string module) *modules* :test #'equal)) ((consp pathname) (dolist (p pathname) (load p))) (pathname (load pathname)) ((progn (setq pathname (pathname module)) (some #'(lambda (default) (load (merge-pathnames pathname (pathname default)) :if-does-not-exist nil)) *require-pathname-list*))) ((load pathname :if-does-not-exist nil)) (t (cerror "Nothing will be loaded." "Module ~s could not be found." module))) module) Cost of non-adoption: Using REQUIRE in portable code is difficult. In KCL and Lucid, I was forced to redefine REQUIRE in my startup file to get it to look for modules in places other than *DEFAULT-PATHNAME-DEFAULTS*. Benefits: See above, under "Rationale". Conversion Cost: None. The proposal is entirely compatible with the existing definition. Esthetics: I'd ordinarily be the last person to propose extensions to Common Lisp, but having to learn one feature that works under all implementations is better than having to learn each implementation's own peculiar way of handling the same situation. Discussion: I mentioned the idea of having a variable to specify where REQUIRE looks for modules in passing on the CL mailing list. There were 2 positive responses and no negative ones. Cutting.pa@xerox.com proposed a search list rather than a single pathname, which is actually what I had in mind anyway. ------- FAILNET-ORIGIN<270286.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  mDmD mDmD%mD-mD5mD=mD"EmD&MmD*UmD.]mD2emD6mmD:umD>}mD  9 $ @Hq  pn{n Hug4p (0 (X0]H / ")Hx _@ h3 Ah`,h6oP0889`9`same on nuyou w Thie will youou ;n or hopef@SAIL.Stanford.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 12:46:44 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 87 09:35:56 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 257095; Fri 16-Oct-87 12:35:53 EDT Date: Fri, 16 Oct 87 12:35 EDT From: David A. Moon Subject: Re: Issue: PUSH-EVALUATION-ORDER To: peck@Sun.COM cc: cl-cleanup@Sail.stanford.edu In-Reply-To: <8710160807.AA04926@denali.sun.com> Message-ID: <19871016163545.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 16 Oct 87 01:07:11 -0700 From: peck@Sun.COM I favor PUSH-EVALUATION-ORDER:ITEM-FIRST. I've always believed that on page 99 of CLtL, "subforms of generalized-variable references" is a typographical error for "subforms of macros that manipulate generalized variable references." I only wish this typo had been caught before the book was published. Note the paragraph a little further down the page "As an example of these semantic rules, in the generalized-variable reference (setf reference value), the value form must be evaluated after all the subforms of the reference because the value form appears to the right of them." In this single sentence, the term "generalized-variable reference" is used both to mean a setf-able place and a form that invokes setf. Confusing, isn't it? However, I don't see how this paragraph can be interpreted any other way than that these rules govern the order of evaluation of all the subforms of one of these macros, not just the subforms inside "place". FAILMoon Re: Issue: PUSH-EVALUATION-ORDER <270240.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Em#Em# Em#Em#E%m#E-m#E5m#E=m#"EEm#&EMm#*EUm#.E]m#2Eem#6Emm#:Eum#>E}m#  ME < EE@H+T  -t-;+|R HuQp (h0)3(Xrx 0 BH  ")Dx  C@ hG AQ`,hJP0L8M`M`QQt}PI8@SAIL.Stanford.EDU,@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 11:59:21 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Oct 87 08:32:13 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133767; Fri 16-Oct-87 11:32:33 EDT Date: Fri, 16 Oct 87 11:33 EDT From: David C. Plummer Subject: with-open-stream and with-open-file To: common-lisp@sail.stanford.edu Message-ID: <871016113352.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> CLtL says that the stream (file) scoped by with-open-stream (with-open-file) is closed when the form is exited, independent of exit-reason. I would like people to consider the following allowance: that if the stream variable is NIL during the close operation, then the stream (file) is not closed. Thus (with-open-stream (stream constructor) (prog1 stream (setq stream nil))) would evaluate to an open stream. The strict reading of CLtL says that the stream should be closed and the stream, not the variable, should be considered to have dynamic extent. (I'd quote, except my book is packed.) I don't like the word "considered" as it could be interpreted to legitimize not closing the stream. Personally, I have found the above technique (setting the stream variable to nil and returning the stream) as quite useful; the Symbolics implementation already implementing the relaxation. I ask that the language be clarified. Also, the (prog1 stream (setq stream nil)) is a cliche which can also be written as (shiftf stream nil). For many months I have not liked either of those forms; the way they look, not what they do. Unfortunately, the best form I've been able to think of is (grab-and-clear stream) and I don't like that very much either. FAILDCP with-open-stream and with-open-file<270220.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Em#Em# Em#Em#E%m#E-m#E5m#E=m#"EEm#&EMm#*EUm#.E]m#2Eem#6Emm#:Eum#>E}m#  LE  EE@H,5G .u-c,%|M HuN$p (h0'(Xr 0 AH  ")Dx @B@ hF AO9`,hIP0K8L`L`PPt}PI8@SAIL.Stanford.EDU,@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 11:53:08 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Oct 87 07:38:26 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133712; Fri 16-Oct-87 09:50:40 EDT Date: Fri, 16 Oct 87 09:51 EDT From: David C. Plummer Subject: The IDENTITY function and multiple args To: peck@Sun.COM, common-lisp@sail.stanford.edu In-Reply-To: <8710160417.AA04480@denali.sun.com> Message-ID: <871016095157.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 15 Oct 87 21:17:31 -0700 From: peck@Sun.COM Is there a fundamental reason why #'IDENTITY and #'VALUES should be different? VALUES seems like a much safer function to use for a "default" function, since it will nicely consume any number of args and return them, which is the same behavior that the improverished IDENTITY does for a single arg. Why encourage programmers to make fragile programs by documenting "IDENTITY"? Two reasons I see: 1, Intent: If the intent is to return one value based on one argument, then IDENTITY is the correct function to use. It "is an error" to pass it more or less than one argument, and some implementations "signal an error." If the intent is to accept multiple values and pass them through, then VALUES is the correct function to use. I don't consider VALUES and "safer" or IDENTITY introducing "fragility". On the contrary, I would claim that failure to program the intent will make the program less safe and more fragile. 2, Efficiency (linguistically, this is a weak argument): some (many?) implementations optimize the one return-value case. This makes multiple values less efficient. FAILDCP The IDENTITY function and multiple args<270209.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ff ff&f.f6f>f#Ff'Nf+Vf/^f3ff7nf;vf?~f  L 8  @H? , AA&?h|M Hu9`p (h0&W(Xr 0 AH  ")Dx @B@ hF A:`,hIP0K8L`L`PPPaegi Lgk@SAIL.Stanford.EDU,@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 11:09:20 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Oct 87 07:38:26 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133712; Fri 16-Oct-87 09:50:40 EDT Date: Fri, 16 Oct 87 09:51 EDT From: David C. Plummer Subject: The IDENTITY function and multiple args To: peck@Sun.COM, common-lisp@sail.stanford.edu In-Reply-To: <8710160417.AA04480@denali.sun.com> Message-ID: <871016095157.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 15 Oct 87 21:17:31 -0700 From: peck@Sun.COM Is there a fundamental reason why #'IDENTITY and #'VALUES should be different? VALUES seems like a much safer function to use for a "default" function, since it will nicely consume any number of args and return them, which is the same behavior that the improverished IDENTITY does for a single arg. Why encourage programmers to make fragile programs by documenting "IDENTITY"? Two reasons I see: 1, Intent: If the intent is to return one value based on one argument, then IDENTITY is the correct function to use. It "is an error" to pass it more or less than one argument, and some implementations "signal an error." If the intent is to accept multiple values and pass them through, then VALUES is the correct function to use. I don't consider VALUES and "safer" or IDENTITY introducing "fragility". On the contrary, I would claim that failure to program the intent will make the program less safe and more fragile. 2, Efficiency (linguistically, this is a weak argument): some (many?) implementations optimize the one return-value case. This makes multiple values less efficient. FAILDCP The IDENTITY function and multiple args<270196.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Em#Em# Em#Em#E%m#E-m#E5m#E=m#"EEm#&EMm#*EUm#.E]m#2Eem#6Emm#:Eum#>E}m#  E  EE@HroG ywyru) Huxrp (x(Xd 0 H( @ t @x` ,4  P8 ``(/t}BI8@SAIL.Stanford.EDU:peck@Sun.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 04:17:54 EDT Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 87 01:07:25 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA01645; Fri, 16 Oct 87 01:02:58 PDT Received: from denali.sun.com by snail.sun.com (4.0/SMI-3.2) id AA21892; Fri, 16 Oct 87 01:06:59 PDT Received: from localhost by denali.sun.com (3.2/SMI-3.2) id AA04926; Fri, 16 Oct 87 01:07:15 PDT Message-Id: <8710160807.AA04926@denali.sun.com> To: cl-cleanup@Sail.stanford.edu Subject: Re: Issue: PUSH-EVALUATION-ORDER In-Reply-To: Your message of 09 Oct 87 13:47:00 -0700; <871009-134727-1519@Xerox> . Date: Fri, 16 Oct 87 01:07:11 -0700 From: peck@Sun.COM Issue: PUSH-EVALUATION-ORDER References: CLtL pages 99 vs 270 Category: CLARIFICATION Edit History: Jeff Peck, 15-Oct-1987, (version 1) Problem Description: In the form: (PUSH (ref1) (CAR (ref2))) It is unclear whether (ref1) should be evaluated before (ref2). CLtL, page 99, in a discussion of generalized variable macros, states: "Other macros that manipulate generalized variables include ... PUSH ... Macros that manipulate generalized variables must guarentee the "obvious" semantics: subforms of generalized-variable references are evaluated ... in exactly the same order as they appear in the *source* program." [That is, the sub-forms of Place should be evaluated once, left to right.] "The expansion of these macros must consist of code that follows these rules or has the same effect as such code. This is accomplished by introducing temporary variables bound to the subforms of the reference." ^^^^^^^^^^^^^^^^^^^^^^^^^ This paragraph and a discussion of SETF on the previous pages may also be interpreted as requiring that *all* argument forms of such macros should be evaluated once, in source order, left to right. However, CLtL, page 270 states: "The effect of (PUSH Item Place) is roughly equivalent to (SETF Place (CONS Item Place)) except that the latter would evaluate any subforms of Place twice while PUSH takes care to evaluate them only once." That is, the effect of the form (PUSH Item Place) is to evaluate (SETF Place (CONS Item Place)) but with subforms of Place only evaluated once. Place and Item appear in different order in the PUSH form and the indicated equivalent SETF form. Should the PUSH form have primacy over the obvious SETF form with respect to the left-to-right evaluation? Are all subforms in a macro argument list guarenteed to be evaluated in order, or only those subforms representing generalized variable references? Test Case: (macroexpand '(push (ref1) (car (ref2)))) (LET* ((#:G8 (REF2)) (#:G7 (CONS (REF1) (CAR #:G8)))) (EXCL::.INV-CAR #:G8 #:G7)) ---versus--- (LET* ((#:G5 (REF1)) (#:G4 (REF2))) NIL (SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4))))) Proposal: PUSH-EVALUATION-ORDER:REDEFINE-PUSH The form of PUSH is (PUSH Place Item). Rationale: PUSH is basically defined in the wrong order with respect to the obvious implementation. Other generalized variable access functions are defined with the Place form preceding the Value form. Accept for the natural visual clue that PUSH should attach Item "in front" of Place, it would be more natural to write (PUSH Place Item) and be parallel to SETF forms. Discusion: Never mind, this would break reams of existing code... Proposal: PUSH-EVALUATION-ORDER:PLACE-FIRST Page 270 should be modified to read: "(PUSH Item Place) is equivalent to (SETF Place (CONS Item Place)) except that the subforms of Place are evaluated only once." and "(PUSHNEW Item Place :test P) is equivalent to (SETF Place (ADJOIN Item Place :test P)) except that the subforms of Place are evaluated only once." Rationale: The wording of CLtL on page 99 does not disallow or contradict this interpretation. The wording of page 270 is already very close to this. Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST Page 270 should be modified to read: "(PUSH Item Place) is generally equivalent to (SETF Place (CONS Item Place)) except that the subforms of Place are evaluated only once, and Item is evaluated before Place." and "(PUSHNEW Item Place :test P) is generally equivalent to (SETF Place (ADJOIN Item Place :test P)) except that the subforms of Place are evaluated only once, and Item is evaluated before Place." Page 99 should be modified to explain explicitly that *all* argument forms of *any* macro that ever uses generalized variable references, *must* evaluate in left to right order as appearing in the source. Specifically, the phase "subforms of the reference" which appears several times should be changed to something like: "subforms of the [generalized-variable manipulating macro] arguments". Perhaps PUSH should be used as an example instead of the over worked SETF. Rational: This is the unstated intention of the page 97-100 discussion of generalized-variable referencing macros, and indeed the intended definition of "obvious semantics" for all macros. Current-practice: PLACE-FIRST: Lucid, Franz and Kyoto evaluate Place then Item. ITEM-FIRST: Symbolics evaluates Item then Place. Adoption Cost: Minimal, PUSH could simply be defined by the appropriate macro. Cost of non-adoption: Obvious programs may be non-portable. Although it should be rare that order of evaluation will effect actual operation. Occasional programs may get different results on Symbolics. Benefits: The implementation and semantics of PUSH become obvious to all. With ITEM-FIRST, it is obvious when macros wrapped around PUSH will evaluate their arguments in the proper order, no exceptions need to be made. Esthetics: Most folks won't notice. For true esthetics, see REDEFINE-PUSH. Discussion: David Moon (Symbolics) argues that the unstated intention of page 99 is the definition of the language, while admitting that: "The quoted paragraphs could be taken to restrict order of evaluation only of the subforms of (CAR (ref2)), not all of the subforms of the PUSH form." FAILNET-ORIGIN<270060.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ~f~f ~f~f%~f-~f5~f=~f"E~f&M~f*U~f.]~f2e~f6m~f:u~f>}~f   *  @H5 " uAC HuMp (x%B(Xp 0 oH(@ t @=` ,4 uP8 ``gi  )0+fi ,0.@SAIL.Stanford.EDU:peck@Sun.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Oct 87 00:46:06 EDT Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 15 Oct 87 21:17:38 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA27648; Thu, 15 Oct 87 21:13:14 PDT Received: from denali.sun.com by snail.sun.com (4.0/SMI-3.2) id AA20740; Thu, 15 Oct 87 21:17:16 PDT Received: from localhost by denali.sun.com (3.2/SMI-3.2) id AA04480; Thu, 15 Oct 87 21:17:33 PDT Message-Id: <8710160417.AA04480@denali.sun.com> To: common-lisp@sail.stanford.edu Subject: The IDENTITY function and multiple args Date: Thu, 15 Oct 87 21:17:31 -0700 From: peck@Sun.COM Is there a fundamental reason why #'IDENTITY and #'VALUES should be different? VALUES seems like a much safer function to use for a "default" function, since it will nicely consume any number of args and return them, which is the same behavior that the improverished IDENTITY does for a single arg. Why encourage programmers to make fragile programs by documenting "IDENTITY"? FAILNET-ORIGIN<269991.871016@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  +r++r++r ++r+&+r+.+r+6+r+>+r+F+r#+N+r'+V+r++^+r/+f+r3+n+r7+v+r;+~+r?+  +r  ,+r+r@H-/ 2 /o-- Ht|Lp (80n(X7(0H8_ (x `@ t >L`,4 hP8``@SAIL.Stanford.EDU:FAHLMAN@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Oct 87 20:54:43 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:46:11 PDT Received: ID ; Thu 15 Oct 87 20:46:42-EDT Date: Thu, 15 Oct 1987 20:46 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: CL-Cleanup@SAIL.STANFORD.EDU Subject: SETF-FUNCTION-VS-MACRO (Version 1) In-reply-to: Msg of 15 Oct 1987 20:39-EDT from David A. Moon OK, Moon's proposal looks to me like the right way to go. It would be useful to address the alternative I raised in the proposal and the arguments against it, just so that N other people won't bring up the same idea. -- Scott FAILFahlman SETF-FUNCTION-VS-MACRO (Version 1)<269892.871015@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ????? ???&??.??6??>??F?#?N?'?V?+?^?/?f?3?n?7?v?;?~???  ? , ?-??@HA  CCmAW Ht|Hfp (0 (X#0 nH ")Hx o@ t >I`,4 wP8``_hi Paegi Lgk@SAIL.Stanford.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Oct 87 20:47:34 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:38:43 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256662; Thu 15-Oct-87 20:39:42 EDT Date: Thu, 15 Oct 87 20:39 EDT From: David A. Moon Subject: SETF-FUNCTION-VS-MACRO (Version 1) To: Scott E. Fahlman cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <19871016003933.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 15 Oct 1987 20:21 EDT From: "Scott E. Fahlman" I have no problem with this proposal, except for the notion that the name of the setf-function associated with FOO should be a list, (SETF FOO). Would it not be simpler to introduce a new setf-able access function GET-SETF-FUNCTION which takes a symbol and returns the associated SETF function? The CLOS committee tried that for a long time, but it doesn't work. Fundamentally the problem is that there has to be a name that the user uses to define the thing and to talk about it. Trying to hide the name just means you use a more obscure name, like an alternate syntax for DEFUN or DEFUN-SETF or something. The one problem I can see with this alternative proposal is that it there is no very good way to do something like FLET for the setf function if there is not a name-like entity that can be bound. Precisely. That's the reason for making the name explicit. I assume that this would not preclude the addition of something like the function specs that are present on the Lisp machine? Right. There could be other function names that are not symbols, however we don't really need to propose any others for CLOS. I assume that in either case one must use an explicit funcall and not just drop this "name" into the car-position of an expression to be evaluated. Yes, the extra complexity of allowing something new in the car of a form didn't seem to be justified. I guess I should have listed that among the rejected ideas at the end. FAILMoon SETF-FUNCTION-VS-MACRO (Version 1)<269886.871015@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Em#Em# Em#Em#E%m#E-m#E5m#E=m#"EEm#&EMm#*EUm#.E]m#2Eem#6Emm#:Eum#>E}m#  E < EE@H? " A-A?' Ht|BYp (80s(XP0H8~ (x @ t >E`,4  P8``(/t}iI8@SAIL.Stanford.EDU:FAHLMAN@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Oct 87 20:34:35 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:24:59 PDT Received: ID ; Thu 15 Oct 87 20:21:44-EDT Date: Thu, 15 Oct 1987 20:21 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: CL-Cleanup@SAIL.STANFORD.EDU Subject: SETF-FUNCTION-VS-MACRO (Version 1) In-reply-to: Msg of 15 Oct 1987 17:11-EDT from David A. Moon I have no problem with this proposal, except for the notion that the name of the setf-function associated with FOO should be a list, (SETF FOO). This seems like a more radical change than is really necessary to accomplish the stated purposes. It is a considerable extension to the idea of a "function name", at least for standard Common Lisp implementations that do not implement Lisp machine style function-specs. Would it not be simpler to introduce a new setf-able access function GET-SETF-FUNCTION which takes a symbol and returns the associated SETF function? Under Moon's proposal a SETF form expands into something like (funcall #'(setf foo) ...). This would become (funcall (get-setf-function foo)...). I assume that in either case one must use an explicit funcall and not just drop this "name" into the car-position of an expression to be evaluated. The one problem I can see with this alternative proposal is that it there is no very good way to do something like FLET for the setf function if there is not a name-like entity that can be bound. Is that the reason for introducing this new kind of "name" instead of just setting up the association with a setf-able function? Of course, we could arbitrarily add some tweak to FLET that would locally rebind the setf-function, but maybe Moon's scheme is more regular after all. If we do go ahead with Moon's proposal in its current form, it would be a good idea to address this concern and why something like the alternative discussed here is not a better choice. I assume that this would not preclude the addition of something like the function specs that are present on the Lisp machine? If we finally decide that Common Lisp is going to remain a Lisp-2, then we might want to look at that whole issue again. -- Scott FAILFahlman SETF-FUNCTION-VS-MACRO (Version 1)<269882.871015@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  |f|f |f|f%|f-|f5|f=|f"E|f&M|f*U|f.]|f2e|f6m|f:u|f>}|f  ; :  @HB]  J}JwB Ht{jip ( 0 ](X0 H' ")Hx @ t/ =`,45 P98;`;`TOTOccgi Lgk@SAIL.Stanford.EDU,@STONY-BROOK.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Oct 87 17:27:05 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 87 14:10:45 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 256462; 15 Oct 87 17:11:02 EDT Date: Thu, 15 Oct 87 17:11 EDT From: David A. Moon Subject: SETF-FUNCTION-VS-MACRO (Version 1) To: CL-Cleanup@sail.stanford.edu Message-ID: <19871015211100.8.MOON@EUPHRATES.SCRC.Symbolics.COM> ISSUE: SETF-FUNCTION-VS-MACRO REFERENCES: setf rules for what -place- can be (pp.94-7) compile function (p.438) defun macro (p.57) disassemble function (p.439) documentation function (p.440) fboundp function (p.90) flet special form (p.113) fmakunbound function (p.92) ftype declaration (p.158) function special form (p.87) function declaration (p.159) inline declaration (p(-59) notinline declaration (p.159) labels special form (p.113) symbol-function and setf of symbol-function (p.90) trace macro (p.440) untrace macro (p.440) CATEGORY: ADDITION EDIT HISTORY: Version 1, 13-Oct-87 Moon (based on discussion among the CLOSworking group) PROBLEM DESCRIPTION: The Common Lisp Object System needs a well-defined way to relate the name and arguments of a sehting function to those of a reading functkon, because both functions can be generic and can have user-defined methods. We tried to hide the name and arguments of the setting function with macrology, but the complexity got out of hand. It seems better to make this information explicit; the version of the CLOS specification that assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS is much simpler in the relevant areas. PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS): Add to Common Lisp the concept of "setf functions". Right now, Common Lisp only has "setf macros", which are defined by define-setf-method and both forms of defsetf. Terminology: - a "setf macro" is something that produces code (or other specifications, as in define-setf-method) which, when evaluated, will perform the effect of an invocation of setf. - a "setf function" is something that is called to perform directly the effect of an invocation of setf. The form (setf (-name- ...) ...), when -name- is defined as a function (rather than a macro) and no setf macro has been defined for -name-, expands into a call to a setf function. The name of this setf function is a list (setf -name-), where -name- is a symbol. The functions, macros, and special forms defined in CLtL and listed in the References section above need to be enhanced to accept such lists in addition to symbols as function names, so that setf functions can be defined and manipulated. A setf function receives the new value to be stored as its first argument. Thus, #'(setf foo) should have one more required parameter than #'foo, the first required parameter is the new value to be stored, and the remaining parameters should be the same as #'foo's parameters. A setf function must return its first argument, since setf is defined to return the new value. A definition of a setf function can be lexically local, like a definition of a reading function. The following rules specify the behavior of SETF; note that these rules are ordered and the first rule to apply supersedes any later rules. These rules are a consistent extension of the current behavior of Common Lisp and the Cleanup committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only rule 4 is new with this proposal. Rules for the macroexpansion of (setf (foo x) y): (1) If the function-name foo refers to the global function definition, rather than a locally defined function or macro, and if there is a setf macro defined for foo, use the setf macro to compute the expansion. (2) If the function-name foo is defined as a macro in the current scope, use macroexpand-1 to expand (foo x) and try again. (3) If the function-name foo is defined as a special form in the current scope, signal an error. (4) Expand into the equivalent of (let ((#:temp-1 x) ;force correct order of evaluation (#:temp-2 y)) (funcall #'(setf foo) #:temp-2 #:temp-1)) Note that rule 4 is independent of the scope of the function name (setf foo). It does not matter if that scope is different from the scope of the function name foo. This allows some nonsensical programs to be written, but does not seem harmful enough to justify making more complicated rules to compare the scopes of the two function definitions. The above rules are actually implemented by GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself. Thus GET-SETF-METHOD generates the appropriate five values for a form that is not a macro-invocation and does not have a defined setf macro. Normally one does not define both a setf function and a setf macro for the same reading function. Normally one defines a local reading function and a local setf function together in a single FLET or LABELS. In the absence of any setf macro definition, SETF of a function expands into a call to the setf function. This means that the setf function only needs to be defined at run time, not compile time. TEST CASE: (really more examples than test cases) ;If setf of subseq was not already built into Common Lisp, ;it could have been defined like this (defun (setf subseq) (new-value sequence start &optional end) (unless end (setq end (length sequence))) (setq end (min end (+ start (length new-value)))) (do ((i start (1+ i)) (j 0 (1+ j))) ((= i end) new-value) (setf (elt sequence i) (elt new-value j)))) ;Another example, showing a locally defined setf function (defun frobulate (mumble) (let ((table (mumble-table mumble))) (flet ((foo (x) (gethash x table)) ((setf foo) (new x) (setf (gethash x table) new))) .. (foo a) .. (setf (foo a) b)))) ;get-setf-method could implement setf functions by calling ;this function when rules 1-3 do not apply (defun get-setf-method-for-setf-function (form) (let ((new-value (gensym)) (temp-vars (do ((a (cdr form) (cdr a)) (v nil (cons (gensym) v))) ((null a) v)))) (values temp-vars (cdr form) (list new-value) `(funcall #'(setf ,(car form)) ,new-value ,@temp-vars) `(,(car form) ,@temp-vars)))) RATIONALE: By making the names and arguments of setting functions explicit, CLOS is considerably simplified. In addition, this can supersede any proposals to introduce a lexically local form of defsetf; lexically local setf functions serve the same needs. Current code that resembles (defsetf foo |setf FOO|) (defun foo (x) ..) (defun |setf FOO| (x new) ..) or (defsetf foo internal-foo-setter) (defun foo (x) ..) (defun internal-foo-setter (x new) ..) can be, but is not required to be, replaced with the following code (defun foo (x) ..) (defun (setf foo) (new x) ..) An advantage of this is that several disparate styles of using defsetf can be replaced with a single common style of using setf functions, making programs more standardized and readable. CURRENT PRACTICE: A few Common Lisp implementations already have a similar feature, in that they have setting functions named (SETF reader). I don't know of any implementation that has precisely the proposed feature. ADOPTION COST: The main cost is generalization of a few functions to accept lists beginning with SETF where they now accept only symbols. Implementations must add a data structure to store the function definition of a setf function, however, this can trivially be done with property lists or generated symbols. The cost of making the SETF macro expand into a call to a setf function, when it does not find a setf macro or a regular macro to expand, is negligible. This will be an incompatible change for Symbolics, since it already has setf functions but they do not take the same arguments as proposed here. However, the change is considered worthwhile. COST OF NON-ADOPTION: Non-adoption of this proposal would be a significant roadblock to the Common Lisp Object System. Some major rethinking of CLOS would be required. BENEFITS: Allow CLOS to be defined without out-of-hand complexity. CONVERSION COST: None, this is an upward-compatible change. ESTHETICS: SETF would be more esthetic, but less powerful, if it had only the proposed setf functions and did not have setf macros. Such a major incompatible change is of course out of the question, however by stressing setf functions rather than setf macros SETF could become easier to teach. DISCUSSION: Note that in Common Lisp, setf macroexpansion is an operation on function names, not on functions. It differs from some dialects of Scheme, such as T, in this respect. This proposal does not attempt to change that. The following related features were considered but are specifically not being proposed at this time, since they are unnecessary for CLOS and appear not to improve the simplicity and esthetics of the language: Lexically local setf macros, that is, a cross between defsetf and macrolet. This does not appear to be logically necessary. Do all three ways of defining lexically global setf macros need local counterparts? Should we define the meaning of defmacro or macrolet of (setf foo)? This would be a fourth way to define a setf macro. Should we enhance the definition of global setf macros, for example to say that (macro-function '(setf foo)) returns an expander function that takes two arguments and returns five values? Should we introduce a new name for symbol-function, since it accepts non-symbols now? FAILMoon SETF-FUNCTION-VS-MACRO (Version 1)<269803.871015@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  yyPy yP yyPyyPy$yPy,yPy4yPyy|yP  y $ yyy@H{[  }{}${ Htk.dp (0$(XvH0 EH(@ t 57` ,4 KP8 ``08(H0  S@SAIL.Stanford.EDU:kclmail@rascal.ics.utexas.eduJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Oct 87 15:19:00 EDT Received: from NGP.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 13 Oct 87 11:48:59 PDT Posted-Date: Tue, 13 Oct 87 12:15:32 CDT Received: by ngp.utexas.edu (5.51/5.51) id AA04440; Tue, 13 Oct 87 12:15:47 CDT Date: Tue, 13 Oct 87 12:15:32 CDT From: kclmail@rascal.ics.utexas.edu (Bob Boyer) Message-Id: <8710131715.AA24859@rascal.ics.utexas.edu> Received: by rascal.ics.utexas.edu (3.2/4.22) id AA24859; Tue, 13 Oct 87 12:15:32 CDT To: common-lisp@sail.stanford.edu Subject: KCL Mailing List An electronic mailing list for news about Kyoto Common Lisp has been established. To have your name placed on this list, send a message to the Arpanet/Internet address: kcl-request@rascal.ics.utexas.edu To post an item to those on the list, send a note to Arpanet/Internet address: kcl@rascal.ics.utexas.edu The authors of KCL, Yuasa and Hagiya, are on the list. A discouragingly high percentage of those in electronically remote corners of the U.S.A. or in foreign countries who receive this message and who send a message to kcl-request asking to join the list will be inaccessible from rascal.ics.utexas.edu because of a variety of network problems. If you do not regularly send mail to and receive mail from several Arpanet sites, please include in any request to kcl-request a paper mail address to which I can mail my regrets over your apparent inaccessibility if necessary. Messages to kcl@rascal.ics.utexas.edu will be archived in the file /pub/kcl-mail-archive, accessible by ftping into rascal.ics.utexas.edu as user ftp, any password. In the same place is the file kcl.broadcast, which contains information about obtaining without fee the Kyoto Common Lisp system, including sources, after the appropriate license procedures have been completed. FAILNET-ORIGIN<268747.871013@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  yyPy yP yyPyyPy$yPy,yPy4yPyy|yP  Wy 2 yyy@H{  ~ }9{o} Htk-pY($ 9(X| 0HPP@ hQ 5e` ,pTP0V8 W`W`@08(H0  S@MC.LCS.MIT.EDU,@SAIL.Stanford.EDU:kclmail@rascal.ics.utexas.eduGSB-LOCAL@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Oct 87 15:17:19 EDT Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 13 Oct 87 15:05:07 EDT Received: from NGP.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 13 Oct 87 11:48:59 PDT Posted-Date: Tue, 13 Oct 87 12:15:32 CDT Received: by ngp.utexas.edu (5.51/5.51) id AA04440; Tue, 13 Oct 87 12:15:47 CDT Date: Tue, 13 Oct 87 12:15:32 CDT From: kclmail@rascal.ics.utexas.edu (Bob Boyer) Message-Id: <8710131715.AA24859@rascal.ics.utexas.edu> Received: by rascal.ics.utexas.edu (3.2/4.22) id AA24859; Tue, 13 Oct 87 12:15:32 CDT To: common-lisp@sail.stanford.edu Subject: KCL Mailing List An electronic mailing list for news about Kyoto Common Lisp has been established. To have your name placed on this list, send a message to the Arpanet/Internet address: kcl-request@rascal.ics.utexas.edu To post an item to those on the list, send a note to Arpanet/Internet address: kcl@rascal.ics.utexas.edu The authors of KCL, Yuasa and Hagiya, are on the list. A discouragingly high percentage of those in electronically remote corners of the U.S.A. or in foreign countries who receive this message and who send a message to kcl-request asking to join the list will be inaccessible from rascal.ics.utexas.edu because of a variety of network problems. If you do not regularly send mail to and receive mail from several Arpanet sites, please include in any request to kcl-request a paper mail address to which I can mail my regrets over your apparent inaccessibility if necessary. Messages to kcl@rascal.ics.utexas.edu will be archived in the file /pub/kcl-mail-archive, accessible by ftping into rascal.ics.utexas.edu as user ftp, any password. In the same place is the file kcl.broadcast, which contains information about obtaining without fee the Kyoto Common Lisp system, including sources, after the appropriate license procedures have been completed. FAILNET-ORIGIN<268740.871013@AI.AI.MIT.EDU>[GSB;GSB MAIL]FILENOSHOWYN-!  סWQס WQ סWQ סWQס#WQס+WQס3WQס;WQ!סCWQ%סKWQ)סSWQ-ס[WQ1סcWQ5סkWQ9סsWQ=ס{WQ  uס  סס@HY , [#Y y HtDU@p (h  (X 0 lH  cx 4@ ho "Vy`,hrP0t8u`u`yyPaegi Lgk@SAIL.Stanford.EDU:jbarnett@nrtc.northrop.comJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Oct 87 21:14:40 EDT Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 87 17:42:39 PDT Received: by nrtc.nrtc.northrop.com id aa03397; 8 Oct 87 17:42 PDT Date: Thu, 8 Oct 87 17:34:11 PDT From: Jeff Barnett To: common-lisp@sail.stanford.edu Subject: I need help I am currently trying to design and implement a high level protocol to lash together a bunch of programs running on SYMBOLICS and SUNS. The protocol is a generalization of the EVAL protocol used by the distributed DCLOCKS shell. Unfortunately, the SUN documentation available to me doesn't discuss what is available in terms of stack groups, processes, network code, etc. I need pointers to more detailed SUN documentation, or better yet, a knowledgable individual to talk to. Any suggestions of volunters would be much appreciated. Thanks in advance for any help or sympathy. Jeff Barnett FAILjbarnett I need help<266764.871008@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-$  NNN NNNNN NNN N"NNN*NNN2NNN:NNNBNN!NJNN%NRNN)NZNN-NbNN1NjNN5NrNN9NzNN=N  ANN  NnNNNN@H{   Hsleep or Symbolics... tDD<p ((XH 0)H (x +@ t5 "D`,4; P?8A`A`II@SAIL.Stanford.EDU:RAM@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Oct 87 20:38:20 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:46:10 PDT Received: ID ; Thu 8 Oct 87 18:46:45-EDT Date: Thu, 8 Oct 1987 18:46 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: compile-time actions & top-level forms (long) In-reply-to: Msg of 8 Oct 1987 13:27-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore) This obviously falls within the purview of the Compiler Cleanup comittee, which unfortunately seems to be moribund. I agree with all the expectation of compiler semantics that you mention, and my proposal to the compiler cleanup comittee does have these properties. As a separate but related issue, I'd also like to see a DEF form defined to replace the magical compile-time behavior of the package functions. The solution I propose is to require package manipulation forms to appear at the beginning of the file. The package functions are only special-cased when they appear in that position. My proposal is accessible as cprop.txt on c.cs.cmu.edu. Anybody who knows Lisp compilers and has a recent history of breathing is encouraged to harrass the compiler comittee. Rob FAILRam compile-time actions & top-level forms (long)<266722.871008@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-$  NNN NNNNN NNN N"NNN*NNN2NNN:NNNBNN!NJNN%NRNN)NZNN-NbNN1NjNN5NrNN9NzNN=N  ONN ( NnNNNN@H  O- Hsleep or Symbolics... tD;9p (@0x3(X-`0 H,9 (x @ tC ">`,4I &PM8O`O`0C(HD0E FM@SAIL.Stanford.EDU:Masinter.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Oct 87 20:19:05 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 87 16:55:44 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 87 16:17:35 PDT Date: 8 Oct 87 16:17 PDT From: Masinter.pa@Xerox.COM Subject: Issue: PATHNAME-STREAM (Version 4) TO: CL-Cleanup@sail.stanford.edu CC: MASINTER.pa@Xerox.COM Message-ID: <871008-161735-1333@Xerox> This issue passed conditionally last meeting, pending a change in the wording to not restrict streams with pathnames to "files", since some users model a "device" as something that isn't a "file". I rewrote the description and edited the language of other parts of the proposal. ! Issue: PATHNAME-STREAM References: PATHNAME (p.413), also the introductory text right above it on the same page. Derived references: PARSE-NAMESTRING (p.414), MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417), OPEN (p.418), WITH-OPEN-FILE (p.422), RENAME-FILE (p.423), DELETE-FILE (p.424) Edit History: Version 1 by Moon 11-May-87 Version 2 by Masinter 29-May-87 (minor editing) Version 3 by Masinter 11-Jun-87 (minor editing) Version 4 by Masinter 8-Oct-87 (rewording) Category: CHANGE/CLARIFICATION Problem Description: CLtL says that a stream can be used as an argument and converted to a pathname, but many sources or sinks of data that streams might be connected to have no pathnames associated with them; for example, streams created with make-two-way-stream or open-string-stream. There is no reasonable way to coerce such a stream to a pathname. Proposal PATHNAME-STREAM:FILES-ONLY: Clarify that the use of a stream as an argument that expects a pathname (as described on p413 of CLtL) only applies to streams that are originally opened by use of the OPEN, WITH-OPEN-FILE or the like. For example, it is an error to attempt to obtain a pathname from a two-way-stream or a string-stream. Rationale: This is probably what the designers of Common Lisp intended. This is the only thing that can be implemented without large changes to the language such as extending pathnames to things other than files. Current Practice: Some systems signal an error if a non-file stream is used as a pathname. Adoption Cost: Since the proposal says only "is an error" rather than "signals an error", no implementations need change. Benefits: The description of pathname functions will make more sense. Conversion Cost: None. Aesthetics: Makes language a little cleaner. Discussion: The cleanup committee supports this clarification. FAILMasinter.pa Issue: PATHNAME-STREAM (Version 4)<266706.871008@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-$  NNN NNNNN NNN N"NNN*NNN2NNN:NNNBNN!NJNN%NRNN)NZNN-NbNN1NjNN5NrNN9NzNN=N  ANN  NnNNNN@H3  5$4!3 Hsleep or Symbolics... tD(p (K(XH 0)H (x +@ t5 "c`,4; P?8A`A`II@SAIL.Stanford.EDU:RAM@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Oct 87 19:19:04 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:46:10 PDT Received: ID ; Thu 8 Oct 87 18:46:45-EDT Date: Thu, 8 Oct 1987 18:46 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: compile-time actions & top-level forms (long) In-reply-to: Msg of 8 Oct 1987 13:27-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore) This obviously falls within the purview of the Compiler Cleanup comittee, which unfortunately seems to be moribund. I agree with all the expectation of compiler semantics that you mention, and my proposal to the compiler cleanup comittee does have these properties. As a separate but related issue, I'd also like to see a DEF form defined to replace the magical compile-time behavior of the package functions. The solution I propose is to require package manipulation forms to appear at the beginning of the file. The package functions are only special-cased when they appear in that position. My proposal is accessible as cprop.txt on c.cs.cmu.edu. Anybody who knows Lisp compilers and has a recent history of breathing is encouraged to harrass the compiler comittee. Rob FAILRam compile-time actions & top-level forms (long)<266671.871008@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  pp# pp#p p#pp#$pp#,pp#4pp#p#  p ( p1pp@HO{[ ] HtC `p (X W(XG 0 QH(@ t !` ,4 WP8 ``s & tvel f(long: comisp@stanfou @SAIL.Stanford.EDU:sandra%orion@cs.utah.eduJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Oct 87 14:06:24 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 10:28:02 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA18377; Thu, 8 Oct 87 11:27:55 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA11678; Thu, 8 Oct 87 11:27:49 MDT Date: Thu, 8 Oct 87 11:27:49 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8710081727.AA11678@orion.utah.edu> Subject: compile-time actions & top-level forms (long) To: common-lisp@sail.stanford.edu The following is a rough proposal I've put together to try to get some agreement on what the compile-time behavior of certain top-level macros should be. I came up with many items on this list by noting things that were "broken" or behaved surprisingly in some implementations; KCL is certainly the worst offender in this respect. The situations I've listed appear to be fairly standard programming practices and I think we need to state explicitly somewhere that CL supports them. I have found that some implementations also have disturbing variations from the behavior that is explicitly specified in CLtL regarding evaluation of ordinary function calls appearing at the top level. Some implementors have responded to my complaints by saying, in effect, that if I don't like the default behavior they provide, I can always explicitly wrap the offending form in an eval-when to get the behavior I want. This just isn't good enough -- if everybody is free to diverge from CLtL however they want, then I'd have to wrap *every* top-level form with an eval-when to guarantee portability. Do we really want to force that on unsuspecting users? In many of these cases, the top-level form needs to store information at compile time. I'm leaving open the possibility that the place where the information is stored during compile-time processing might be different than where it gets stored during normal load/eval processing. My primary concern is that the information be available for use by the compiler later on during the compilation of the same file. A simple implementation technique (one which I've used to patch KCL, for example) is to simply wrap the forms which store the information in the macro expansion with an (eval-when (eval compile load) ...). As a separate but related issue, I'd also like to see a DEF form defined to replace the magical compile-time behavior of the package functions. DEFTYPE. Type names defined via DEFTYPE should be recognized as valid in subsequent type declarations. (deftype small-int '(int 0 10)) (let ((x 0)) (declare (type small-int x)) ....) DEFMACRO. Macro definitions must be stored at compile time, so that occurences of the macro later on in the file will be expanded correctly. (defmacro silly (x) `(car ,x)) ... (silly foo) .... ; should compile as (car foo) DEFUN. Nothing special is required here, although an implementation may wish to store information about the lambda-list (etc.) for the purposes of compile-time error checking. DEFVAR, DEFPARAMETER. The compiler must recognize that the variables have been proclaimed special. It is probably not a good idea to evaluate the initial-value form. (defvar *stack* (some-incredibly-hairy-function)) (let ((*stack* *stack*)) ; this should be a special binding. ....) DEFCONSTANT. If this "normally" stores any information that is used by the compiler (for example, to warn about assignment to or rebinding of the variable), then this information should also be stored at compile time. It's probably acceptable to evaluate the initial-value form in this case. DEFSETF. The SETF method should be available during the expansion of calls to SETF later on in the file. (Does anybody care about DEFINE-SETF-METHOD and DEFINE-MODIFY-MACRO?) (defsetf foo modify-foo) (setf (foo x y) z) DEFSTRUCT. The structure type name must be recognized as a valid type name in declarations (as in the DEFTYPE example above). In addition, further DEFSTRUCT definitions should be able to :include a structure type defined earlier in the file being compiled. The functions which DEFSTRUCT generates may or may not be available at compile time. (defstruct person name age sex) (defstruct (astronaut (:include person) (:conc-name astro-)) helmet-size (favorite-beverage 'tang)) Questions & comments are welcome.... -Sandra ------- FAILNET-ORIGIN<266487.871008@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  W/WW/ W W/W W/WW/"WW/*WW/2WW/:W!W/BW%W/JW)W/RW-W/ZW1W/bW5W/jW9W/rW=W/zW   W/  WoW/W/@HZ 2 ^]cZɇz Hs+vp (0 $r(X:0H  ")Hx @ h 1`,hP0 8 ` `Bell atoriNaper, Ill Lin5 Aptly-TAD-FLAI.AI@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 87 17:51:17 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Sep 87 14:36:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238094; Mon 21-Sep-87 17:37:55 EDT Date: Mon, 21 Sep 87 17:36 EDT From: David A. Moon Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1) To: CL-Cleanup@sail.stanford.edu Supersedes: <870921172903.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870921173659.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Issue: SETF-METHOD-FOR-SYMBOLS References: CLtL pp. 105, 99 Category: CHANGE Edit history: Version 1 Moon 21 Sep 87 Problem description: The description of SETF in CLtL is inconsistent in that page 99 requires side-effects to be elaborated in left-to-right order, while page 105 specifies a setf-method for symbols that makes it impossible to implement this in some cases, such as the test case given below (provided by Timothy Daly of IBM). Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE Change the result of (get-setf-method 'foo) from NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO to (#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175 Test Case: Given (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) what is the value of R and S? If side-effects are elaborated in left-to-right order, the setq of R to NIL should not affect the result, since it occurs after R is read and before R is written, and therefore the value of both R and S should be (A 1 B 6 C 3). A typical result in an implementation that believes CLtL p.105 more than CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3). Rationale: The general principle mentioned on p.99 should override the specific example on p.105. The latter is probably just a mistake. Current practice: Symbolics and Lucid return the incorrect result mentioned in the test case above. Franz returns something else: r = nil and s = (a 1 b 6 c 3). Symbolics plans to fix this in the next release. Adoption Cost: SETF is an intricate part of Common Lisp, and the fact that not all implementations currently return the same thing indicates that some care might be required in updating implementations. However, in some implementations changing what get-setf-method returns when its argument is a symbol is the only change required. It's been pointed out that this change might cause less efficient code to be produced in some cases, since setf methods will involve more temporary variables, however Moon believes that the optimizations are not difficult and probably are already done by most implementations. Cost of non-adoption: Users will think SETF is complicated and hard to understand, because implementations won't conform to a simple general principle that side-effects are elaborated in left-to-right order. Benefits: The opposite of what I just said. Conversion Cost: This change is incompatible because it changes the result of some forms that are not erroneous. However, it's unlikely that very many users are intentionally depending on the current behavior. In addition, the current behavior is not consistent across implementations, which makes changing it less problematic. Esthetics: See "cost of non-adoption". Discussion: I wish CLtL did a much better job of explaining the philosophy of SETF, and included some better examples of precisely what is meant by the "`obvious' semantics" mentioned on page 99. I will accept some of the blame for this lack in the documentation. --Moon FAILMoon Issue: SETF-METHOD-FOR-SYMBOLS (version 1)<257944.870921@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  TTTT TT TTT TTTT"TTT*TTT2TTT:TT!TBTT%TJTT)TRTT-TZTT1TbTT5TjTT9TrTT=TzTT  ]T < TTT@HF 6 f?N}" Hs+o1p (0 1(X0 SH ")Hx hT@ hW a`,hZP0\8]`]`0b(c@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 87 17:36:49 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Sep 87 14:10:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238035; Mon 21-Sep-87 17:11:32 EDT Date: Mon, 21 Sep 87 17:10 EDT From: David A. Moon Subject: Re: setf order of evaluation To: NGALL@G.BBN.COM cc: DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <[G.BBN.COM]10-Sep-87 10:40:24.NGALL> Message-ID: <870921171049.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 10 Sep 1987 10:40-EDT From: NGALL@G.BBN.COM Date: Wed, 9 Sep 87 14:40 EDT From: David A. Moon I didn't look inside the Lucid implementation, but in the Symbolics implementation the source of the bug is that (get-setf-method 'r) returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See CLtL page 104 for the description of the meaning of these values. Changing it to return the latter makes your SETF example behave as you expected, evaluating R -before- bashing it, and setq'ing it to the updated property list -after- setq'ing it to nil. Unfortunately, on pg 105 the setf method for the variable X is defined to be () () (#:g0001) (setq X #:g0001) X. So if this is the right place to fix things, then CLtL must be fixed too. This is fine with me, but it would make SETF methods less efficient (or require them to be more intelligent about optimizing). I'm told Symbolics will be fixing our next release to do what I said I thought was right, rather than what CLtL says. I guess that obligates me to write this up and submit it to the cleanup committee, which I will do. I don't take the efficiency issue very seriously; it's very easy to optimize the cases in question, in my opinion. FAILMoon Re: setf order of evaluation<257931.870921@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  I{I{I{ I{%I{-I{5I{=I{EI{"MI{&UI{*]I{.eI{2mI{6uI{:}I{>  wI{  JI{I{@HM.  QNCiy$ Hry\<p (80(X_`0 lxH 0p g@ hq ܅`,htP0v8w`w`0z{{ 00@SAIL.STANFORD.EDU:MATHIS@ADA20.ISI.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Sep 87 07:50:20 EDT Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 04:24:36 PDT Date: 14 Sep 1987 19:53-PDT Sender: MATHIS@ADA20.ISI.EDU Subject: report on ISO NWI and SC22 meeting From: MATHIS@ADA20.ISI.EDU To: x3j13@SAIL.STANFORD.EDU Cc: Mathis@ADA20.ISI.EDU Message-ID: <[ADA20.ISI.EDU]14-Sep-87 19:53:33.MATHIS> At our meeting in Boston in July, the proposed New Work Item for an international standard for Lisp was discussed. After a mail ballot of the membership, it was decided (and subsequently endorsed by X3, the parent committee of X3J13 and the organization responsible for the final US vote on this issue) to forward the following comments with our ballot: In the US there is a very strong feeling that "Lisp" is the name of a family of languages and that it is appropriate to standardize only on a particular dialect and that the name of this dialect must be part of the name of the standard. A name like "ISO Lisp 89" would be too broad and would not answer the concerns expressed here. Within the Lisp family, there have existed many popular dialects with fundamental differences in their design, implementation, and use. While some of these existing differences may be resolved, others will certainly appear since the Lisp family encourages such experimentation and development. The US concern about the name for the resulting ISO standard and the wording of this proposed new work item is not a shallow comment about words only, but is an indication of our deep concern that the goals and objectives of developing a standard within the Lisp family should not interfere with continued developments in other parts of the Lisp family of languages. This is one of the first issues that must be considered by an ISO working group resulting from the approval of this new work item. This naming issue was also raised as part of the report of the SC22 ad hoc working group (ISO/TC97/SC22 N 266) that lead to this NWI proposal. The US feels that report should be one of the initial documents of the working group resulting from this NWI proposal and that the various issues it raises be addressed. Other countries have also submitted comments -- France offered a Convenor, Japan thought there should be more emphasis on Common Lisp, and the United Kingdom emphasized the need for a single standard. ISO/IEC JTC1/SC22 (the SubCommittee on Languages of Joint Technical Committee 1 of the International Organization for Standardization and the International Electrotechnical Commission) decided to form Working Group 16 on Lisp. Christian Queinnic was named Convenor and Richard Gabriel and William Klinger were named as project editors. At that same meeting there was considerable discussion about the handling of large character sets in programming languages. While this issue is frequently thought of in terms of handling Japanese and Chinese, it is also important for European languages other than English and for modern text manipulation systems. The first meeting of WG 16 will be held February 24 and 25, 1988, in Paris, France. There will be an International Workshop on Lisp Evolution and Standardization on February 22 and 23, also in Paris. Participation in the Workshop is separate from participation in the ISO/IEC Working Group. FAIL report on ISO NWI and SC22 meetingMATHIS<254938.870915@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  Gn$Gn$ Gn$Gn$G%n$G-n$G5n$G=n$"GEn$&GMn$*GUn$.G]n$2Gen$6Gmn$:Gun$>G}n$  VG GG@H , 13| Hr# p (@0vC(X|0HPO@ hP 򼑂U` ,hSP0U8 V`V`Y[! ]0/. [0aR@SAIL.STANFORD.EDU:edsel!bhopal!jonl@labrea.stanford.eduJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Sep 87 13:44:01 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:30:27 PDT Received: by labrea.stanford.edu; Fri, 4 Sep 87 10:11:04 PDT Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0) id AA22223; Fri, 4 Sep 87 09:08:33 PDT Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA04816; Fri, 4 Sep 87 09:08:14 PDT Date: Fri, 4 Sep 87 09:08:14 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8709041608.AA04816@bhopal.edsel.com> To: labrea!Ram%C.CS.CMU.EDU@labrea.stanford.edu, labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu Cc: labrea!CARNESE%SPAR-20.ARPA@labrea.stanford.edu, labrea!cl-cleanup%SAIL@labrea.stanford.edu In-Reply-To: navajo!Ram@C.CS.CMU.EDU's message of Thu, 3 Sep 1987 14:17 EDT Subject: [Dan Carnese : proposal] One of the good qualities I liked about Mesa (the Xerox answer to Pascal) was the way programmers were encouraged to write a "defs" file for every "module" -- basically, this file declares the exportable items, along with their syntax (no code, however), and also mentions the importations (a bit like CL's REQUIRE). I don't know how much of a pain it was for programmers to produce correct modules under this regimen, but it sure made it a heck of a lot easier to read someone else's code. I, for one, in my regular work wind up reading a lot of other people's code; and most of my code is eventually read by other people. Hence I would prefer a direction for Common Lisp which facilitated the ability to read other people's code, even at the expense of some programming conveniences. This means that having all the "7 extrememly randoms" at the beginning of a file (except for PROVIDE) is a much better solution than having them sprinkled around random other files in random other modules. -- JonL -- FAILNET-ORIGIN<250301.870904@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  060m 060m06 0m06 0m"060m*060m2060m:060mB06!0mJ06%0mR06)0mZ06-0mb0610mj0650mr0690mz06=0m  06  0V0606@H1J 4 3j2 1! HqDUp (80w(X,H0H8N (x PO@ t bU`,4 XP8``gtbSU 7@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 21:13:37 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87 18:07:54 PDT Received: ID ; Mon 24 Aug 87 21:08:04-EDT Date: Mon, 24 Aug 1987 21:08 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Cl-Cleanup@SAIL.STANFORD.EDU Subject: Issue: SHADOW-ALREADY-PRESENT (version 1) In-reply-to: Msg of 24 Aug 1987 14:33-EDT from David A. Moon I'm in favor of SHADOW-ALREADY-PRESENT:WORKS. Thanks to Moon for writing this up so quickly. -- Scott FAILFahlman Issue: SHADOW-ALREADY-PRESENT (version 1)<245890.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  ?6?m ?6?m?6 ?m?6?m$?6?m,?6?m4?6?m?m  ?6 < ?V?6?6@H@K  BkA!@! HqCMp ((0X(X-0H@O (x P@ t aЕ`,4 XP8`` ^0`aa@SAIL.STANFORD.EDU:Pavel.pa@Xerox.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 16:23:33 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Aug 87 13:09:50 PDT Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 87 13:07:49 PDT Date: Mon, 24 Aug 87 13:07:36 PDT From: Pavel.pa@Xerox.COM Subject: Re: The values returned by SETF In-reply-to: <8708241825.AA20419@NADC.ARPA> To: dml@nadc.arpa (D. Loewenstern) Cc: common-lisp@sail.stanford.edu Message-ID: <870824-130749-7757@Xerox> Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? Common Lisp does not define the behaviour of SETF of VALUES. Do you have a question about one of the ccases that IS defined? Pavel FAILPavel.pa Re: The values returned by SETF<245790.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  I  I I I !I )I 1I 9I AI $II (QI ,YI 0aI 4iI 8qI <yI    Q@HJ  L;JkJ" HqC.up (H W(X 0 LH(@ t a` ,4 RP8 `` X0Z[[([0"@SAIL.STANFORD.EDU:093725%incdp1@LANL.GOVJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 15:19:17 EDT Received: from LANL.GOV by SAIL.STANFORD.EDU with TCP; 24 Aug 87 12:04:35 PDT Received: by LANL.GOV (5.54/1.14) id AA28950; Mon, 24 Aug 87 13:02:21 MDT Date: Mon, 24 Aug 87 13:02:21 MDT Message-Id: <8708241902.AA28950@LANL.GOV> From: 093725%incdp1@LANL.GOV (TOM NORRIS) To: common-lisp@sail.stanford.edu Subject: New Address for Common Lisp Common_Iisp: I have a new mailing address for receiving mail from the Common-lisp. The old address was: 093725%incdp1.xnet@lanl.gov The new address is: tln@beta.lanl.gov Thank-you Tom Norris Los Alamos National Lab. 505-667-4630 FAILNET-ORIGIN<245750.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  -g -g-g -g!-g)-g1-g9-g A-g$I-g(Q-g,Y-g0a-g4i-g8q-g<y-g  |  @H S H y= HqC&tp (0 V^(X0 rH ")Hx `s@ hv a`,hyP0{8|`|`0(@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 15:02:12 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:47:55 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219303; Mon 24-Aug-87 14:48:12 EDT Date: Mon, 24 Aug 87 14:47 EDT From: David A. Moon Subject: The values returned by SETF To: D. Loewenstern cc: common-lisp@sail.stanford.edu In-Reply-To: <8708241825.AA20419@NADC.ARPA> Message-ID: <870824144731.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 24 Aug 87 14:25:04 EDT From: dml@nadc.arpa (D. Loewenstern) Is the value returned by SETF defined in general, for all standard get/put functions? Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? SETF returns the values of its last subform (CLtL p.97). SETF of VALUES is an extension to Common Lisp, but that shouldn't change the rules for what SETF returns. FAILMoon The values returned by SETF<245734.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  -g -g-g -g!-g)-g1-g9-g A-g$I-g(Q-g,Y-g0a-g4i-g8q-g<y-g  |  @H  6 H y= HqC p (0 K(X8d0H q ")Hx @ hv a;`,hyP0{8|`|`0abbgg(g@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 14:47:43 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:38:46 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219273; Mon 24-Aug-87 14:33:31 EDT Date: Mon, 24 Aug 87 14:33 EDT From: David A. Moon Subject: Issue: SHADOW-ALREADY-PRESENT (version 1) To: Cl-Cleanup@sail.stanford.edu References: <8708241350.AA23968@ztivax.uucp>, <8708241451.AA28748@HADES.MIT.EDU> Message-ID: <870824143300.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Issue: SHADOW-ALREADY-PRESENT References: CLtL p.186 Category: CLARIFICATION Edit history: Moon 24 Aug 87 new issue (version 1) Problem description: The description of the SHADOW function can be interpreted as saying that the function has no effect, if the symbol is already present in the package. This happens if the third sentence in the description ("then nothing is done") is interpreted as applying to the entire description rather than just to the fourth sentence. Proposal SHADOW-ALREADY-PRESENT:WORKS: The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is already present in the package. Test Case: (make-package 'test-1) (intern "TEST" (find-package 'test-1)) (shadow 'test-1::test (find-package 'test-1)) (assert (not (null (member 'test-1::test (package-shadowing-symbols (find-package 'test-1)))))) (make-package 'test-2) (intern "TEST" (find-package 'test-2)) (use-package 'test-2 (find-package 'test-1)) ;should not error Rationale: Page 180 describes a name conflict problem that can occur when calling the function USE-PACKAGE. The name conflict is between a symbol directly present in the using package and an external symbol of the used package. This name conflict may be resolved in favor of the symbol directly present in the using package by making it a shadowing symbol. For this to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the package. Current practice: [I have not confirmed any of these myself except Symbolics --Moon] Symbolics and Spice Lisp behave as proposed here. Kyoto Common Lisp behaves the other way. Kolb implied, but did not state explicitly, that Lucid Common Lisp and Xerox Common Lisp behave like KCL. It seems likely that we will find several implementations in each camp. Adoption Cost: It should be a one-line change in one function. Cost of non-adoption: Inconsistency among implementations and lack of a clear way to resolve the name conflict mentioned in Rationale. Benefits: Consistency. Conversion Cost: Technically this would be an incompatible change to implementations that do not already behave as proposed, however it is difficult to conceive of a user program that would require any conversion to cope with the change. Some users might want to remove kludges that were only necessary to get around the misbehavior of SHADOW. Esthetics: The proposal would remove an unnecessary special case, thus simplifying the language slightly. Discussion: The issue was raised by Dieter Kolb on the Common-Lisp mailing list. It would be useless for SHADOW to fail to put a symbol that is already present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon believes CLtL intended to describe what is being proposed, but unfortunately used ambiguous language. FAILMoon Issue: SHADOW-ALREADY-PRESENT (version 1)<245715.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  -g -g-g -g!-g)-g1-g9-g A-g$I-g(Q-g,Y-g0a-g4i-g8q-g<y-g    @H/  1%/a/ ] HqCp (V (X 0 XH(@ t a` ,4 ^P8 `` d0fgg(g@SAIL.STANFORD.EDU:dml@NADC.ARPAJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 14:37:19 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:22:53 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA20419; Mon, 24 Aug 87 14:25:04 EDT Date: Mon, 24 Aug 87 14:25:04 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8708241825.AA20419@NADC.ARPA> To: common-lisp@sail.stanford.edu Subject: The values returned by SETF Cc: dml@NADC.ARPA Is the value returned by SETF defined in general, for all standard get/put functions? Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? Gold Hill's GCLISP (LM version) seems to return 1 when evaled but NIL when compiled. David Loewenstern Naval Air Development Center code 7013 Warminster, PA 18974-5000 FAILNET-ORIGIN<245711.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  -g -g-g -g!-g)-g1-g9-g A-g$I-g(Q-g,Y-g0a-g4i-g8q-g<y-g  { & @H=  }0My8 HqCp (0 UC(X|0 qH ")Hx `r@ hu ag`,hxP0z8{`{`0(@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 14:26:33 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:11:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219204; Mon 24-Aug-87 14:07:36 EDT Date: Mon, 24 Aug 87 14:07 EDT From: David A. Moon Subject: Interpretation of shadowing To: Dieter Kolb , samalone@ATHENA.MIT.EDU cc: Common-lisp@sail.stanford.edu In-Reply-To: <8708241350.AA23968@ztivax.uucp>, <8708241451.AA28748@HADES.MIT.EDU> Message-ID: <870824140704.4.MOON@EUPHRATES.SCRC.Symbolics.COM> I agree with Malone. The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS list, and the informal wording on p.186 of CLtL should not be interpreted otherwise. This does not seem to be on the cleanup subcommittee's agenda yet, so I'll add a writeup of the issue. Thanks for pointing it out. FAILMoon Interpretation of shadowing<245700.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  -F -F-F -F!-F)-F1-F9-F A-F$I-F(Q-F,Y-F0a-F4i-F8q-F<y-F  ! @H o    vuv HqB9Jp (P S(X*\ 0 H - H'x /@ h a<`,h?P0 8!`!`K0&('OQQ@SAIL.STANFORD.EDU:samalone@ATHENA.MIT.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 11:08:58 EDT Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87 07:53:01 PDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA18770; Mon, 24 Aug 87 10:52:55 EDT From: Received: by HADES.MIT.EDU (5.45/4.7) id AA28748; Mon, 24 Aug 87 10:51:46 EDT Message-Id: <8708241451.AA28748@HADES.MIT.EDU> To: "Dieter Kolb" Cc: common-lisp@sail.stanford.edu Subject: Re: Interpretation of shadowing In-Reply-To: Your message of Mon, 24 Aug 87 14:50:37 -0100. <8708241350.AA23968@ztivax.uucp> Date: Mon, 24 Aug 87 10:51:44 EDT CLtL describes in section 11.5, page 180 a name conflict problem by applying the function use-package. The name conflict is between a symbol directly present in the using package and an external symbol of the used package. This name conflict may be resolved in favor of the symbol directly present in the using package by making it a shadowing symbol. However, CLtL gives no advice how that should be done. In our understanding the function shadow should be used to resolve this name conflict. However the function shadow has no effect, if the symbol is already present in the package (CLtL, section 11.7). So, following CLtL, this could not be the solution... I understand your confusion. I believe that the problem is due to an ambiguity in the definition of SHADOW given in CLtL. (Someone on the cleanup committee should correct me if I'm wrong.) Unfortunately, many Common Lisp implementers have taken the wrong interpretation of this section of the manual, and so propagated the confusion on to their users. You are correct that SHADOW should be used to resolve the name conflict you described. Interpreted correctly, CLtL describes a SHADOW function that _is_ capable of resolving the name conflict. When CLtL says that "If such a symbol is present in this package, nothing is done", this is intended to contrast only with the following sentence, which says "Otherwise, a new symbol is created with this print name..." The next sentence that says "The symbol is also placed on the shadowing-symbols list of package" applies regardless of whether such a symbol is present in this package or not. Given this interpretation, SHADOW has an effect whether the symbol is already present in the package or not (unless it is already a shadowing symbol), and so is the correct way to resolve the name conflict you described. From the descriptions you provided, it sounds like the SPICE LISP implementers did the right thing. --Stuart A. Malone FAILsamalone Re: Interpretation of shadowing <245613.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  -F -F-F -F!-F)-F1-F9-F A-F$I-F(Q-F,Y-F0a-F4i-F8q-F<y-F  [W @H 6 '} HqBip ( Q(X0HPT@ hU a` ,hXP0Z8 [`[`0`(aThe@SAIL.STANFORD.EDU:unido!ztivax!kolb@seismo.CSS.GOVJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 09:42:01 EDT Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 24 Aug 87 06:28:20 PDT Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA04764; Mon, 24 Aug 87 09:28:24 EDT Received: by unido.uucp with uucp; Mon, 24 Aug 87 14:52:38 +0100 From: "Dieter Kolb" Date: Mon, 24 Aug 87 14:50:37 -0100 Message-Id: <8708241350.AA23968@ztivax.uucp> Received: by ztivax.uucp; Mon, 24 Aug 87 14:50:37 -0100 To: Common-lisp@sail.stanford.edu Subject: Interpretation of shadowing Cc: unido!Dieter@seismo.CSS.GOV, unido!Kolb@seismo.CSS.GOV CLtL describes in section 11.5, page 180 a name conflict problem by applying the function use-package. The name conflict is between a symbol directly present in the using package and an external symbol of the used package. This name conflict may be resolved in favor of the symbol directly present in the using package by making it a shadowing symbol. However, CLtL gives no advice how that should be done. In our understanding the function shadow should be used to resolve this name conflict. However the function shadow has no effect, if the symbol is already present in the package (CLtL, section 11.7). So, following CLtL, this could not be the solution. Therefore, we investigated some other CL implementations: Lucid Common LISP on Apollo DOMAIN as well as Xerox LISP: The name conflict can be resolved by using the function shadowing-import SPICE LISP: The functionality of the function shadow in SPICE LISP is extended. shadow works also if the symbol is already present. So, the name conflict can be resolved by using the function shadow. (However, shadow works different as described in CLtL.) Kyoto Common Lisp on VAX: shadow works as described in CLtL. The name conflict cannot be resolved in this system. How should CLtL be interpreted with respect to this problem? Dieter Kolb FAILNET-ORIGIN<245586.870824@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  s :s : s : s :s# :s+ :s3 :s; :!sC :%sK :)sS :-s[ :1sc :5sk :9ss :=s{ :  as ss@HIJ  KjOIR}6 HqZpp (0 O(X 0 XH ")Hx  Y@ h[ I`,h^P0`8a`a`0f(g@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Aug 87 16:53:05 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Aug 87 13:28:28 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 215806; Tue 18-Aug-87 16:28:17 EDT Date: Tue, 18 Aug 87 16:27 EDT From: David A. Moon Subject: FLET & declarations To: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <12327146435.14.GZ@OZ.AI.MIT.EDU> Message-ID: <870818162759.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon 17 Aug 87 03:57:47-EDT From: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Are 'pervasive' declarations in FLET supposed to apply to the function bodies? E.g. (flet ((foo () x)) ;Is this x special? (declare (special x)) ...) (flet ((foo () (foo) ...)) ;Does this call to (foo) return a fixnum? (declare (function foo () fixnum)) ...) (flet ((foo () (foo 17))) ;Is (foo 17) inline? (declare (inline foo)) ...) CLtL does not permit DECLARE to be used in that position (see p.113). I believe it has been proposed to change that, although I couldn't find a copy of the proposal in my rather disorganized files. I would argue that the paragraph in the middle of page 155 of CLtL supports the position that when this extension is made, the pervasive declarations should apply to the function bodies. Note that the FUNCTION declaration used in your middle example is not pervasive. Since you use FLET rather than LABELS, this declaration would not apply to the call to FOO within the body of FOO. It's a different FOO. The INLINE declaration is said by CLtL to be pervasive, however I believe that to be a bug since it makes it unclear which of the two FOOs in your example it refers to. Perhaps it refers to both. Anyone putting together a proposal to clean up the specification of declarations in Common Lisp ought to address the issues raised by your question. FAILMoon FLET & declarations<243535.870818@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!  IJɕ IJɕIJ ɕIJ ɕ#IJɕ+IJɕ3IJɕ;IJɕCIJ!ɕKIJ%ɕSIJ)ɕ[IJ-ɕcIJ1ɕkIJ5ɕsIJ9ɕ{IJ=ɕ ')EIJ  KjIJIJ@H) iM?{} HqWmp (00 :( :(Xx0 4H i ")HxH5@h6IM8$,h9uP0;`(80<P =P{:P}8<:P0A8# B>P"0D8! E`%E`*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~     !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~    @SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COMCSTACY-POBOX@AI.AI.MIT.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Aug 87 16:46:37 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Aug 87 13:33:45 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 215815; Tue 18-Aug-87 16:34:16 EDT Date: Tue, 18 Aug 87 16:33 EDT From: David A. Moon Subject: Re: CLOS To: Ken Kahn cc: kgk%cs.brown.edu@RELAY.CS.NET, cl-object-oriented-programming@SAIL.STANFORD.EDU In-Reply-To: <870814-115946-3737@Xerox> Message-ID: <870818163347.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Fri, 14 Aug 87 11:59:18 PDT From: Ken Kahn However, it has been proposed to add a feature by which the programmer can declare that nothing will be added or changed at run time, and then to compile the entire program as a unit. The point is to leave it up to the meta object protocol and not treat the entire program as a unit. Some parts of a program could use such metaclasses and other parts remain unoptimized. I was oversimplifying for the sake of brevity when I referred to the entire program. Of course one can really apply this optimization to just some of the classes in a program. I don't think I really care whether the programmer's declaration that flexibility should be sacrificed for performance is implemented by metaclasses or by some other mechanism. Doing it with metaclasses seems baroque and cumbersome to me, but as long as it's only a question of implementation and doesn't affect the language, I really don't care. FAILMoon Re: CLOS<243523.870818@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWCSTACYNOQCNO-CLINOSHOWCSTACY-VIA-UUCPNOSHOWmit-erl!yarub!cstacyNOSHOWYN-!   A  A A A# A+ A3 A; AC !AK %AS )A[ -Ac 1Ak 5As 9A{ =A    * @  @H  o HpC^Gp (Is(X" 0 eH  (x f@ t !y`,4 nP8`` t0vww@SAIL.STANFORD.EDU:RAM@C.CS.CMU.EDUJAR-CL@AI.AI.MIT.EDUReceived: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Aug 87 17:00:55 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 87 13:46:53 PDT Received: ID ; Sat 8 Aug 87 16:46:33-EDT Date: Sat, 8 Aug 1987 16:46 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: truename, merge-pathnames, etc. In-reply-to: Msg of 6 Aug 1987 16:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore) In CMU Common Lisp, we have hacked around these problems by playing with the rules for filename parsing. Although the result may be somewhat nonintuitive, it is legal common Lisp, since the namestring => pathname translation is not specified. Parse-Namestring contrives to translate pathnames so that Merge-Pathnames "works right". This is mostly done by by sticking special values in the pathname, and is probably similar to the notion of :Unspecified. For example, we get around to problem you mention by having: (pathname-device "foo:") => #() That is, a namestring that specifies only a device is translated so as to make explcit that a directory is being specified as well. The directory has no components, so NAMESTRING translates back to the original namestring, but merging of other directories in inhibited. We are currently running on a Unix filesystem. Since Unix has no notion of devices or logical names, we use the pathname device field for a "search list" mechanism that is implemented by Lisp. If we were on a filesystem where devices meant anything, then this hack probably wound't work so well. There are also some other cases in which merging is inhibited by the appropriate namestring translation: (pathname-device "/foo/") => :ABSOLUTE (pathname-device "foo/") => "Default" (pathname-type "foo.") => "" I agree that Common Lisp should address this, and think that a general solution would be appropriate, but it is possible in many cases to do the right thing within the constraints of the current MERGE-PATHNAMES definition by tweaking the namestring translation. Rob FAILRam truename, merge-pathnames, etc.<239915.870808@AI.AI.MIT.EDU>[JAR;CL MAIL]FILENOSHOWYN-!   A  A A A# A+ A3 A; AC !AK %AS )A[ -Ac 1Ak 5As 9A{ =A Y w @  @H , '?} HpvOpY(`"XS07H  Yx p9@ t? %E`EE F@N,(L0OPPt!@MC.LCS.MIT.EDU:mmdf@SPCA.BBN.COMluke@aspen.lcs.mit.edu@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Aug 87 17:52:15 EDT Received: from BBN.COM (TCP 20026200172) by MC.LCS.MIT.EDU 3 Aug 87 17:50:11 EDT Received: from spca.bbn.com by BBN.COM id as03080; 1 Aug 87 3:16 EDT Date: Sat, 1 Aug 87 3:00:39 EDT From: SPCA Mail System (MMDF) Sender: mmdf@SPCA.BBN.COM Subject: Failed mail (msg.aa20907) To: @BBN.COM,@MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:luke@aspen.lcs.mit.edu After 7 days (161 hours), your message could not be fully delivered. It failed to be received by the following address(es): mbandes Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message follows: Received: from bbn.com by SPCA.BBN.COM id aa20907; 25 Jul 87 9:36 EDT Received: from mc.lcs.mit.edu by BBN.COM id aa10609; 25 Jul 87 9:39 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Jul 87 08:25:52 EDT Received: from EDDIE.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 JUL 87 13:52:03 EDT Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id ; Fri, 24 Jul 87 13:47:24 EDT Path: mit-eddie!rutgers!seismo!columbia!aspen!luke From: Luke McCormick Newsgroups: rec.music.gdead Subject: Re: Delay Towers Summary: Dan Healy has perfected them... Message-Id: <4843@columbia.UUCP> Date: 24 Jul 87 16:30:00 GMT References: <1801@uvacs.CS.VIRGINIA.EDU> Sender: nobody%columbia.uucp@BBN.COM Reply-To: Luke McCormick Lines: 66 Apparently-To: DEAD-FLAMES@AI.AI.MIT.EDU In article <1801@uvacs.CS.VIRGINIA.EDU> mer@uvacs.UUCP (Marc Rouleau) writes: >A coupla folks have referred recently to the satellite speakers used for >large outdoor shows as ``delay speakers'' or ``delay towers.'' I've always >been a little leary of them (although they sounded GREAT at Rochester), >because I always figured that the sound waves from the main speaker banks >by the stage would sorta git in there and mess things up. > >Ever notice how when everyone in a big place is clapping in time to the >music, the people who are far away from you seem to be synchronized with >those around them but not with you or others far from them? I just >assumed that the same kind of problem would occur with the satellites. > >So these references to ``delay towers'' pushed my curiosity button-- >are the signals to them delayed until the sound waves from the main banks >can get there? If so, it seems like a fairly complex thing to regulate. >I mean, you'd have to know precisely how far each delay tower is from >the stage, and then you'd have use some fancy formula to figger out >what the delay is. > >Pretty cool if it's true. Can anyone confirm this or add anything? It's True. Dan Healy has the speakers in the towers hooked up to a delay so that they emit the music when the sound from the stage reaches them. It sounds hard to do properly, and it is. Last year at JFK was the first time I saw this setup, and I noticed that there were parts of the arena where you heard a NASTY slapback echo from the towers. This was particulary evident if you stood immediately IN FRONT of one of the speakers. Then you heard the stage sound a tiny bit before the speakers thought they should fire, and THEN you heard the delayed sound. It sounded like you were in a tin can. And THAT is why I walked around the Foxboro arena in total disbelief. The sound was tight and crisp EVERYWHERE in that huge outdoor arena, with not a hint of slapback anywhere that I ventured. (I hear there was a little high up in the stands at the sides of the stage). I'm really totally impressed with Dan Healy's work, the man is a genius. I'm a little less impressed with his TASTE (like in vocal sounds and drum mixes), but that's a different matter. The sound at Giant's Stadium was, incredibly, even better. The sound I was hearing at the BACK of the floor during TOG was clearer and richer than my stereo. I should add that Dan has a little help in achieving this kind of sound because he uses absolutely top-of-the-line, state of the art -Luke ps. Does anybody know RoseRunner's phone number? I don't think my check bounced, but I HAVE had trouble getting tickets to shows... --- lm1@cunixc.columbia.edu "What I wouldn't give to have a smile like yours luke@aspen.columbia.edu You know that it's forever on my mind" (516)FRY-HELM (379-4356) --DREAMSPEAK 136 Ocean Ave,Freeport,NY 11520 ('wish I was in 'Frisco...) FAILmmdf Failed mail (msg.aa20907)<236980.870803@AI.AI.MIT.EDU>Recipient name apparently rejected. Last reply was: {550 This host does not offer mail service.}YN-!  I%I% I%I%I&%I.%I6%I>%#IF%'IN%+IV%/I^%3If%7In%;Iv%?I~% %'I  II@H  & % r|* HppY(8 0kN.,i( !($ ! ( P0B(X L0 ;H w(xdy@h?chpP`&8!,C EP88  6 P88"`#`(@roch)NL-KR*REQUE+EQV-L,NL-KR-NL-KR.EQV-L/GAVAN0INGRI1JEREM2TDWU3EQV-L4BJN5EAK6JNC7[DSK:8P;.NS9AIL]:O-M;ISTIST?DPH@JTWAPAGANBEQV-LCzvonaD@atheEdevonFanda@GgyroHngresIeley.JosterKs@berLmroseMe@lllNstrazOzPiQCaro.RROX.cSsorceTlUddieVtWall.oXrth@XYcomZc!slo[MN-CS\asp@o]idh@o^drw_mikeg`xab@athbhoptocaren@drgejosh@frggad!tih-crgin@su-j.arpakitpyrlch.csmSNET-n.ARPAob!gnoplabs.qmritre-srdtn%corukeleyvzwad!suxll-cryngarmznera.{du|%webs}c@dec~ec.copaganrchivPAGANEQUESEQV-LZVONASGISTror@lrdo@e gyro@ .com mikeg x@ccc@athelizzimroseasp@acindyenamit-pchivePCNetgnIST[PCNeIGN DFILE-DesiquestISTPCNet est!-Prot"EQV-L#^;$M%n& O')H(0()v*)+^;,S-~. U/00+12 ,3Y4[50.60/7 809^;:a;< c=>02?@x3A^;BiC!D<kEF07G)H8I^;JqK3LMsN0:O7P;QwR?S yT^;U0=VGW)HX>Y}ZN[ \ 1]0@^R_A`Aa Abc8KdXWe  fbgPbhi  jfklmnopqrstuvw> (I x mailyist, z@sh.c{, for|le wh} inte~d > tivessiste in ng th. P who  wanto lisn" arcoura - I'm ly tr to cr a sma discn gro peopo areouslyreste > ail rt to the lo gwmquests.net > Ch > aig Pdge  Netwervicter (@MC.LCS.MIT.EDU:INFO-MAC-Request@SUMEX-AIM.STANFORD.EDUJSPEAR@AI.AI.MIT.EDUJON-O@AI.AI.MIT.EDUKLOTZ-MAC@AI.AI.MIT.EDULSP@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 29 Jan 87 04:00:12 EST Received: from PHOTON.LCS.MIT.EDU (TCP 2206400143) by MC.LCS.MIT.EDU 29 Jan 87 03:58:20 EST Received: from PM-PRJ.LCS.MIT.EDU by PHOTON.LCS.MIT.EDU (4.12/4.7); Thu, 29 Jan 87 03:52:11 est Received: from SUMEX-AIM.STANFORD.EDU (3800000a) by PM-PRJ.LCS.MIT.EDU (4.12/4.7); Thu, 29 Jan 87 03:50:49 est Message-Id: <8701290850.AA01811@PM-PRJ.LCS.MIT.EDU> Date: 28 Jan 87 2307-PST From: Moderator Dwayne Virnau... Reply-To: INFO-MAC@SUMEX-AIM.Stanford.EDU Subject: INFO-MAC Digest V5 #45 To: INFO-MAC@SUMEX-AIM.Stanford.EDU INFO-MAC Digest Wednesday, 28 Jan 1987 Volume 5 : Issue 45 Today's Topics: INITs from Lightspeed Pascal INIT resources and LSP Scrapbook Problems Making BatchX work on my HD20 External SS drive problems Apple-NU bus to VMEbus adapter Broken keys Re: SFGetFile, Putfile improvements User interface suggestion for SFGetFile Macintosh program for producing real postscript Transskel Pascal Docs UTILITY-FONT-EDITOR-10A4.HQX re: Disktimer II results Mac security device 68000 Development Systems, C and Assembly FORTRAN for the Macintosh Wanted. Structured Analysis and Des Evaluating database software for the Mac ---------------------------------------------------------------------- Date: Tue, 27 Jan 87 08:41:21 PST From: PUGH%CCC.MFENET@nmfecc.arpa Subject: INITs from Lightspeed Pascal Can someone more enlightened than I inform us about creating an INIT resource from a Lightspeed Pascal program? I have created a Unit with a Main procedure declared in the Interface section and compiled it using, not the PasLib, but the Small Paslib Project and built it as a CODE resource. All in all it looked fine but it don't run the way it did in the LSP environment. As a metter of fact, disassembling the thing reveals none of my trap calls and a bunch of indecipherable code, so I suspect that I ain't doing something right. Do I need to initialize the toolbox before running an INIT or does the system handle that? Where does one read up these elusive little twits? advTHANKSance for any help Jon PS Sorry about the DB19 versus DB25 screwup. Just a mental typo. ------------------------------ Date: Tue, 27 Jan 87 15:16:53 PST From: PUGH%CCC.MFENET@nmfecc.arpa Subject: INIT resources and LSP Well, I paniced before trying everything. It seems that all you have to do, as far as LSP is concerned, is to declare your procedure like so: unit myINIT; interface Procedure Main; implementation Procedure Main; ... end. The important thing is to read that thing in the LSP supplement about Locking Code Resources. There is a statement "Code resources should be locked while they are executing and unlocked at other times. The Macintosh Toolbox usually takes care of this for you when calling one of the standard types of code resources ('PACK' resources are a notable exception)." Well, so are INITs. Lock the buggers down! Their subsequent example is also slightly wrong. Do this instead: Procedure Main; var pp : ^Ptr; h : Handle; begin pp := Pointer($9CE); { They use Ptr($9CE) which is a type coersion } h := RecoverHandle(pp^); HLock(h); ... HUnlock(h); end; This works fine. Now I have an INIT that randomizes your StartUpSound. I will change it to include the BeepSound also. Let me know if anyone is interested in having it posted. I will even include the source. Jon ------------------------------ Date: Tue, 27 Jan 87 15:49:51 ECT From: FALK%NORUNIT.BITNET@WISCVM.WISC.EDU Subject: Scrapbook Problems Anybody experienced this problem? I run a MAC+ 20MB scsi HD, Finder 5.3 and system 3.2. My HD is divided into one boot-volume, and one working volume. The scrapbook seems ok when opened at Finder level, but opening under some applications on my working volume (Fullpaint, Draft and others) gives trouble. The MAC replies 'EMPTY SCRAPBOOK', The problem arose suddenly (at least I didn't notice until now). I'd be very happy if somebody could advise me on this problem Regards Christian Falck Trondheim Norway :-) ------------------------------ Date: Tue, 27 Jan 87 17:20:00 PST From: woody@Iago.Caltech.Edu (William E. Woody) Subject: Making BatchX work on my HD20 Well, I finally got BatchX to work. It turns out that the name of the magic folder is hardwired into the application as "System Folder", when the name of the magic folder on my system was "sys". The patch was simple: Find the string ":System Folder:" in the BatchX file using Fedit, and change it to ":sys:" with terminating null (\0). - William Woody mac > /|\ && ][n woody@juliet.caltech.edu ------------------------------ Date: Tue, 27 Jan 87 16:19:23 EST From: wilson%husc4@harvard.HARVARD.EDU Subject: External SS drive problems I have a 512KE mac with a single-sided external drive (can't yet afford a double-sided drive to replace it) that is giving me problems. The SS drive makes a scraping, sort of rough noise when the disk is spinning, and especially when seeking. It varies somewhat depending on the disk, and also seems worse when writing. I have used it without losing any data, but it really sounds unhealthy for the drive and disks. I tried cleaning the drive, and it didn't help a bit, so I opened up the drive and watched it run for awhile, but would rather not take a screwdriver to the internals. I think the noise may be due to the little felt pad (that presses the disk surface against the read/write head) getting dirty. The cleaning kit doesn't clean this part of a single-sided drive (it has a cellophane flap to protect the felt pad and warns you against removing it). Has anyone had similar problems or know of a cheap solution? The drive is not under Applecare and I would rather not pay lots to get it working again. Any suggestions would be appreciated. Thanks in advance, Randy Wilson wilson@husc4.harvard.edu harvard!husc4!wilson ------------------------------ Date: Wed, 28 Jan 87 15:16:01 est From: berger%datacube.UUCP@CCA.CCA.COM (Bob Berger) Subject: Apple-NU bus to VMEbus adapter Ok, so the new mac's are going to use a modified form of the NU bus for their expansion slots. Does anyone have or is working on producing a Apple-NU bus to VMEbus adapter? This could be a two card system, one card is of the Apple-Nu bus type and would plug into the new Mac slots, the card would be a VMEbus card and would plug into the VME card cage. Some form of robust cable would then connect the two cards. A range of memory accesses by the Mac cpu would transparently map to a range of addresses on the VMEbus. It would be nice if transfers could also go the other way, a VMEbus master could access chunks of the Mac Memory. If anyone is working on such a beast, we would be interested in volume purchase as an OEM. Please send any info to me via EMail. Bob Berger Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960 VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125 UUCP: ihnp4!datacube!berger {seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!berger ------------------------------ Date: 27 Jan 87 14:52:00 EST From: "Greg Hamm" Subject: Broken keys Reply-to: "Greg Hamm" My three-year-old attacked my Mac and managed to break off one of the keypad keys. The key apparently slides onto a little white tab, and the tab is broken off at the point where it enters the key slot. Does anyone know if this is reparable without buying an entire keyboard? Any other rabid three-year-olds out there? Greg Hamm hamm@biovax.bitnet hamm@waks.rutgers.edu ------------------------------ Date: Tue, 27 Jan 87 10:59:56 PST From: Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu Subject: Re: SFGetFile, Putfile improvements With the introduction of HFS, Apple added lots of keyboard equivalents to control the standard file dialogs. The one they left out was CANCEL. You can do everything in standard file from the keyboard but CANCEL. The obvious way to cancel is COMMAND-. and I see no reason why System 3.3 can't have that so all standard file dialogs retroactively have that feature. David Gelphman BITNET address: DAVEG@SLACVM Bin #88 SLAC ARPANET address: DAVEG@SLACVM.BITNET Stanford, Calif. 94305 UUCP address: ...psuvax1!daveg%slacvm.bitnet 415-854-3300 x2538 usual disclaimer #432 applies: my employer apologies for the fact that I have access to this net. ------------------------------ Date: Wed, 28 Jan 1987 00:54 EST From: HENRY%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: User interface suggestion for SFGetFile I, too, have been frustrated at the behavior of the "Drive" button in the file dialog box. It seems like Apple almost got the right idea about tree-structured file systems, but just made one mistake... Here's the REAL solution: Trees should always have a "root" node, but there's no root in Apple's HFS. Flush the Drive button entirely. When you press the mouse button on the title above the scroll window, you get a pull down menu of the path UP the tree from where you currently are. This path should always end in a unique root node [perhaps displayed as a Macintosh icon]. If you choose the root, you should then see in the scroll menu a list of the available "drives", and then you could choose one. Thus, the "drives" would be treated in an identical manner to folders, except for the icons used to display them. An even better idea: Actually, I was flabbergasted the first time I saw a SFGetFile box appear. What I really wanted, and what I still think would be a neat idea, would be to have a pop-up FINDER window. You could screw around in the finder opening folders, etc., then double click on an icon and it returns that file as the choice to the program that asked for it. I suspect it was just small-machine mentality that led to SFGetFile in the first place. The finder is great as a browser for a tree-structured file system, so it ought to be used uniformly throughout the system. ------------------------------ Date: Wed, 28 Jan 87 10:13:59 PST From: Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu Subject: Macintosh program for producing real postscript There is evidently a program which runs on the Mac which converts the psuedo-postscript (produced by using the COMMAND-F dump of postscript on the Mac) into 'true' postscript. I saw the program listed in a public domain software catalog but I suspect it exists on the net somewhwere. Anybody care to post it or mail it to me for posting? Thanks in advance, David Gelphman BITNET address: DAVEG@SLACVM Bin #88 SLAC ARPANET address: DAVEG@SLACVM.BITNET Stanford, Calif. 94305 UUCP address: ...psuvax1!daveg%slacvm.bitnet 415-854-3300 x2538 usual disclaimer #432 applies: my employer apologies for the fact that I have access to this net. ------------------------------ Date: Wed 28 Jan 87 22:26:09-PST From: Dwayne Virnau... Subject: Transskel Pascal Docs several people reported problems downloading this file, a new copy has been secured and is archived as [SUMEX-AIM.Stanford.EDU]UTILITY-TRANSSKEL-PASCAL-DOC.HQX DoD ------------------------------ Date: Wed, 28 Jan 87 10:49:13 PST From: Reply-to: LOGANJ%BYUVAX.BITNET@forsythe.stanford.edu Subject: UTILITY-FONT-EDITOR-10A4.HQX Macintosh and Xerox 9700/8700/4050 laser printer owners, Here is version 1.0A4 of the Font Editor that I mentioned last month. I have successfully used this version of the Font Editor to create new fonts and modify existing fonts for our 8700. There are still a couple of problems with the program. I will post improved versions. I have downloaded fonts directly to the Macintosh from CMS on an IBM mainframe using Kermit, modified the font, and uploaded the modified font back to the IBM host without problems. I have been using Columbia University Kermit version 0.8(33) on the Macintosh. These file transfers must be done in binary mode (Kermit on the Macintosh and IBM host must both be set to binary mode). For uploading, the Kermit logical record length parameter should be set to 128 on the IBM host. Our Macs are connected to the IBM host (43XX vintage) through a Hydra protocol converter. For anyone interested, the CMS kermit commands that set binary mode and a record size of 128 bytes are as follows: SET FILE BINARY SET LRECL 128 I have also transferred font files to and from VAX systems. To use this font editor you must first download the following hex code to your Macintosh and unhex it with the BinHex utility. Let me know how it works for you... Regards, Jim (loganj@byuvax) [ archived as [SUMEX-AIM.Stanford.EDU]UTILITY-FONT-EDITOR-10A4.HQX DoD ] ------------------------------ Date: 27 Jan 87 10:48:00 EST From: "Greg Hamm" Subject: re: Disktimer II results Reply-to: "Greg Hamm" Since I will soon be buying a hard disk, I appreciate all the work people have done to post timings for the various drives available. However, as the recent message pointed out, issues other than speed are important. For me personally, reliability (first) and simplicity of operation (second) are much more important. So I'd like to see some postings about which drives people have had trouble with, and which are perceived as reliable. Which require some special boot procedures, and which are transparent? Which work well with backup programs? I realise this sort of information is much more subjective and can't be organised into a nice table, but I'd sure appreciate even informed opinion at this stage. Thanks, Greg ------------------------------ Date: Wed 28 Jan 87 16:05:49-PST From: TIEU@USC-ECLB.ARPA Subject: Mac security device Are there any security devices that will lock the mouse and the external drive of a Mac+? Please provide the vendor's name and phone numbers. Thanks in advance Han ------------------------------ Date: Wed 28 Jan 87 00:08:01-EST From: "Mike E. Ciholas" Subject: 68000 Development Systems, C and Assembly I am a graduate student at the MIT AI lab and I am working with a 68000 processor for a mobile robot vision system. I need some advice on development systems. I want to mix C and assembly but I must write _everything_ from the reset routine on up. I would like to use a Mac for this, but can I write code that I can download to a stand alone processor (i.e. no Mac ROM). I have heard good things about LightSpeed C, but does its assembler allow such low level programming (in supervisor mode) of the 68000? Thanxs in advance. You can reply to me directly at MIKEC@OZ.AI.MIT.EDU ------------------------------ Date: Sat, 24 Jan 87 14:31 EDT From: (Christopher F. Baum) Subject: FORTRAN for the Macintosh I have been trying to move several large mainframe econometric research packages into the Mac environment, hoping to get them up and running first and Mac-like second. I have been stymied, as have many others to read the nets and mags, by the lack of support for Fortran for the Mac at the level, say, of Microsoft Fortran for the I...M PC (which I use, occasionally, if I am bribed to do so). I noted in MacWorld Feb. issue several letters about Microsoft (Absoft) Fortran for the Mac, and the editor's response giving a number for Absoft Tech Support in Jacksonville -- 904+423-7587. Since I did indeed buy the Absoft product way back when, and have since gotten the Microsoft-vended upgrades, I thought I'd give them a call, and see if they had a clue about my difficulties in getting the linker to handle sizable applications, random unsavory things happening to variables being transmitted through COMMON, etc. To my surprise and wonder, they not only answered the phone within two rings, but spoke knowledgeably and at length about my problems! From the sound of it, they have given me all the clues necessary to solve them, and will send me an update diskette with a more powerful linker, as well as several other goodies that Microsoft deigned to distribute. For any of you that might be using (or thinking of using) Fortran for the Mac, I'd urge to keep this in mind. The quality of support provided by Absoft for a product that they designed, but do not even directly market (!) is several sigmas above what we are used to getting. A sad commentary on the industry! Note that Absoft is also behind the just-released MS-BASIC Compiler for the Mac. I have no financial interest in Absoft, am just a satisfied customer, with hopes that they succeed. Kit Baum Department of Economics, Boston College BAUM@BCVAX3.BITNET ------------------------------ Date: Tue, 27 Jan 87 20:10:50 CST From: davis%mycroft@gswd-vms.ARPA (Tim Davis) Subject: Wanted. Structured Analysis and Des I'm looking for any leads to Structured Analysis and Design Tools that are specifically avaliable for the Mac's. These tools would compose an integrated system containing; 1. Dataflow Diagram editors 2. Structure Charts editors 3. Data Structures editors 4. Entity-Relationships editors 5. Data Dictionary management capabilities. 6. Reporting Capabilities 7. Modeling Analysis programs 8. Apple Laserwriter interface I have found only a couple of these systems which are avaliable on other computers and operating systems but none for the Mac. Thanks for any assistance you provide. Tim Davis ------------------------------ Date: Tuesday 27 Jan 87 3:31 PM CT From: Subject: Evaluating database software for the Mac I am evaluating database software for the Mac for the purpose of chosing a product to be supported by our center. This DB package would be general purpose, easy to learn and use, and be reasonably priced. I would like to receive comments on any Mac database package. I particularly would like comments on Reflex (previously Interlace), OverVUE, FileMaker Plus (or FileMaker), and Microsoft File. Please include the version you are familiar with and any information on upgrades since. I have eliminated Double Helix and Omnis 3 Plus from the evaluation because of their cost, but would enjoy hearing comments for my own knowledge. Please send your comments to me directly at: Fran Hemingway University of Iowa Weeg Computing Center Iowa City, IA 52242 319-335-5447 Bitnet Address: bptfehpb@uiamvs ------------------------------ End of INFO-MAC Digest ********************** FAILINFO-MAC INFO-MAC Digest V5 #45<146256.870129@AI.AI.MIT.EDU>APPEND[KLOTZ;MAC MAIL]FILENOSHOWlevine@eniNOSHOWYN-!  } I finally got the phone and utility bills figured out. Thanks... if you send me your snail address, I'll send you a check. Speaking of work, how's yours going? The Pengi implementation is going well. Should be done in January. I'm also writing part of the lab ARPA proposal, which is sort of a pain. How's the paper/book? We abandoned it for the indefinite future. No one liked it much; too abstract. Chunks of it will make it into the paper on Pengi, which is much more concrete. And what's an area exam? Much like quals? No, it's sort of a book report. They give you three papers on related topics and you have to say something intelligent about them. I finally committed the Evil Act: I picked up a Dreyfus: "What Computers Can't Do." Well, that book is kind of incoherent. His more recent on (Mind Over Machine) is better. (You can skip most of it and just read the critique of AI). Still better is his commentray on Being and Time, but that's not out yet. Rumor has it that you'll be trying to spend more time out West in the future. Any time in the near future? Not until next summer, probably, unfortunately. It snaw four inches last night. David <[AI.AI.MIT.EDU].121111.861120.ZVONA>FAILDate: Thu, 20 Nov 86 17:11:45 EST From: David Chapman Subject: Final house bills from 423 Pope st. To: dirk@PSYCH.STANFORD.EDU In-reply-to: Msg of Mon 17 Nov 86 19:43:27 PST from Dirk Ruiz Message-ID: <[AI.AI.MIT.EDU].121111.861120.ZVONA> YN-!  22f22f 22f22f2&2f2.2f262f2>2f#2F2f'2N2f+2V2f/2^2f32f2f72n2f;2v2f?2~2f  d2a 3 22@H3 a. 5K3 3 t` HX(` (0X0 C@|xHG(H V+ZQ``}_{ a.5@H 7FAILED: local-dead-heads at BRUBECK.PROTEON.COM; Host appears to be permanently down or not accepting mail. FAILED: local-dead-flame at BRUBECK.PROTEON.COM; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from wharton-10.ARPA (TCP 1200200140) by AI.AI.MIT.EDU 4 Nov 86 22:10:11 EST Date: 4 Nov 86 21:48:00 EDT From: "DANIEL BARRON" Subject: i'm sick to death of the dead To: "dead-heads" Reply-To: "DANIEL BARRON" please log me off of the ded hed list, thanks barron@wharton-10 ------ barron@wharton-10.ARPAFAIL<[AI.AI.MIT.EDU].114775.861105>Msg of Tuesday, 4 November 1986 22:10-ESTCOMSATDate: Wed, 5 Nov 86 16:52:33 EST From: Communications Satellite Subject: Msg of Tuesday, 4 November 1986 22:10-EST To: "barron@wharton-10.ARPA"@WHARTON-10.ARPA Message-ID: <[AI.AI.MIT.EDU].114775.861105> YN-!  [k[ [k[[k [[k[$[k[,[k[4[k[<[k[D[k"[L[k&[T[k*[\[k.[d[k2[l[k6[t[k:[|[k>[  5[k ( \ [k[k@H\ ?? ^+H\ H\ t` HycpY 0GOP0X[0 H('@ |) Us^3P x 3` 85`5`0913>AI.MI].9240909.>AI.MI].9220909>AI.MI].9220908>AI.MI].919JRLKGUMBYReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86 17:00:34 EST Received: from SRI-STRIPE.ARPA (TCP 1201000002) by MC.LCS.MIT.EDU 30 Oct 86 16:58:33 EST Received: from SRI-IU.ARPA by SRI-STRIPE.ARPA with TCP; Wed 29 Oct 86 16:44:43-PST Received: from SRI-JUNIPER.ARPA by SRI-IU.ARPA via SMTP with TCP; Wed, 29 Oct 86 16:26:33-PST Return-path: <@SRI-WARBUCKS.ARPA:simpson@LLL-CRG.ARPA> Received: from SRI-WARBUCKS.ARPA by SRI-BISHOP.ARPA via INTERNET with SMTP id 36041; 29 Oct 86 13:53:50-PST Received: from lll-crg.ARPA by SRI-WARBUCKS.ARPA via SMTP with TCP; Wed, 29 Oct 86 13:55:30-PST Received: Wed, 29 Oct 86 13:35:40 pst by lll-crg.ARPA (4.12/) id AA17295; Wed, 29 Oct 86 13:35:40 pst Date: Wed, 29 Oct 86 13:35:40 pst From: Rea Simpson Message-Id: <8610292135.AA17295@lll-crg.ARPA> To: berger%ucbamber@berkeley.edu, cower@su-csli.ARPA, lll-lcc!leadsv!lefko@lll-crg.ARPA, lll-lcc!unisoft!mtxinu!rtech!cormac@lll-crg.ARPA, pmartin@sri-warbucks.ARPA, ptsfa!pbcna!greg@lll-crg.ARPA, qantel!hplabs!pesnta!valid!pete@lll-crg.ARPA, sowadsky.PA@xerox.com, well!dhawk@lll-crg.ARPA, wilkins@sri-ai.ARPA Subject: JGB Resent-To: local-dead-heads@SRI-STRIPE.ARPA Resent-From: Paul Martin Resent-Date: Wed, 29 Oct 86 16:23 PST Resent-Message-ID: <861029162327.2.PMARTIN@SRI-JUNIPER.ARPA> Nov 10 and 11 @ The Stone. On sale now! FAILNET-ORIGIN<[AI.AI.MIT.EDU].112551.861030>NO-CLINOQCRFC733YN-!  tLtLtL tL%tL-tL5tL=tLEtL"MtL&UtL*]tL.etL2mtL6utL:}tL>  1tL * tltLtL@Htl  w HtlHtlt` HXXh`   P0!@xx)(1H1 _3`3`g prs? -----Date: 3 O 09:1EDT rom: nicatSatel bject of Wday, ober 19:22FAILED: cube-lovers-news at LLL-TIS-B.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from ARDEC-LCSS.ARPA.ARPA by AI.AI.MIT.EDU 6 Oct 86 08:44:03 EDT Date: 6 Oct 86 08:19:00 EST From: "CLSTR1::BECK" Subject: rubiks magic To: "cube-lovers" Reply-To: "CLSTR1::BECK" RUBIK'S MAGIC: 1. In the NYC area the puzzle is available from Macy's for $10. 2. Matchbox Toys "is the distributor" 141 West Commercial Ave Moonachie, NJ 07074 212/696-5400 3. HOTLINE: sat & sun from 9am to 5pm until April 26, 1987. 1800-843-1202, NJ RES 1800-843-1203 4. Repairs from matchbox $3 5. The mechanism is similar to a 2-dimensional Jacobs ladder. 6. Trivial observations: a. The puzzle has a front and back. b. For three intersecting rings the 8 squares have to be arranged as a 2x3x3 and not as a 2x4. 7. It is a good puzzle. / \ |\ / | | \ / / | |\ |\ /\ /| /| | \| \/ \/ |/ | \ |\ |\ /| /| / \| \| \/ |/ |/ \ |\ | /| / \| \|/ |/ \ | / \|/ ------ beck@ardec-lcss.arpaFAIL<[AI.AI.MIT.EDU].102642.861006>Msg of Monday, 6 October 1986 08:44-EDTCOMSATDate: Mon, 6 Oct 86 16:22:07 EDT From: Communications Satellite Subject: Msg of Monday, 6 October 1986 08:44-EDT To: "beck@ardec-lcss.arpa"@ARDEC-LCSS.ARPA Message-ID: <[AI.AI.MIT.EDU].102642.861006> YN-!    $,4<"D&L*T.\2d6l:t>|  S  ]@H] 8  ]]t` HXn `   Pa0e@x3xm(uHu Mw`w`============ A copy of your message is being returned, because: ============ "RIOLO" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS Will try sending to the file "USERS3;RIOLO MAIL". "ENEA!KULING!STARBACK" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS ============ Failed message follows: ============ Received: from ARDEC-LCSS.ARPA.ARPA by AI.AI.MIT.EDU 6 Oct 86 08:44:03 EDT Date: 6 Oct 86 08:19:00 EST From: "CLSTR1::BECK" Subject: rubiks magic To: "cube-lovers" Reply-To: "CLSTR1::BECK" RUBIK'S MAGIC: 1. In the NYC area the puzzle is available from Macy's for $10. 2. Matchbox Toys "is the distributor" 141 West Commercial Ave Moonachie, NJ 07074 212/696-5400 3. HOTLINE: sat & sun from 9am to 5pm until April 26, 1987. 1800-843-1202, NJ RES 1800-843-1203 4. Repairs from matchbox $3 5. The mechanism is similar to a 2-dimensional Jacobs ladder. 6. Trivial observations: a. The puzzle has a front and back. b. For three intersecting rings the 8 squares have to be arranged as a 2x3x3 and not as a 2x4. 7. It is a good puzzle. / \ |\ / | | \ / / | |\ |\ /\ /| /| | \| \/ \/ |/ | \ |\ |\ /| /| / \| \| \/ |/ |/ \ |\ | /| / \| \|/ |/ \ | / \|/ ------ beck@ardec-lcss.arpaFAIL<[AI.AI.MIT.EDU].102521.861006>Msg of Monday, 6 October 1986 08:44-EDTCOMSATDate: Mon, 6 Oct 86 08:47:34 EDT From: Communications Satellite Subject: Msg of Monday, 6 October 1986 08:44-EDT To: "beck@ardec-lcss.arpa"@ARDEC-LCSS.ARPA Message-ID: <[AI.AI.MIT.EDU].102521.861006> YN-!  # # # ## ## #$# #,# #4# #<# #D# "#L# &#T# *#\# .#d# 2#l# 6#t# :#|# >#  m#  #,# # @H#,¥ %LH#,H#,t` HT gbpY0kN.,i0s,X> 0 eH -x h@ | g`8m`m`S0*(+LW[0.7C0/00CMJWSTORKReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 OCT 86 21:53:39 EDT Received: from AMSAA by MC.LCS.MIT.EDU 1 Oct 86 20:57:12 EDT Received: from ardec-1.arpa by AMSAA.ARPA id a022702; 1 Oct 86 9:48 EDT Date: Wed, 1 Oct 86 9:50:49 EDT From: "David G. Sampar" (PM-AL) To: info-cpm@AMSAA.ARPA Subject: MEX114 at 4800/9600 Baud Having used IMP244 and KERMIT405 for various communications chores on my HEATH H89A, I finally got around to trying out MEX114. This is a very impressive program and works fine for me at 1200 and 2400 baud. Trouble starts when I try to connect into my local mainframe at 4800 or 9600 baud. At these rates, MEX starts losing characters on the receiving end. I have tried turning QUEUE off and increasing PQSIZE (from 150 to 450) to no avail. Being new to the program, I'm wondering whether I have missed something. Any hints or pointers would be appreciated. Thanks in advance, Dave Sampar FAILdsampar MEX114 at 4800/9600 Baud<[AI.AI.MIT.EDU].101026.861001>YN-!  4i4i4 i4i%4i-4i54i=4iE4"iM4&iU4*i]4.ie42im46iu4:i}4>i  4 4 T44@HT "  tHTHT` HSR=pY0kN.,i0s,XB`0 9Hs (x 8:@ xy =`8``0>p?0ABB1 MJWSTORKReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 SEP 86 11:16:24 EDT Received: from AMSAA by MC.LCS.MIT.EDU 26 Sep 86 11:15:03 EDT Received: from ll.arpa by AMSAA.ARPA id a012173; 26 Sep 86 10:39 EDT Date: Fri 26 Sep 1986 10:15:18 EDT From: SAGE@LL.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: Automatic Disk Logging To: info-cpm@AMSAA.ARPA Message-ID: I have not really thought through the question of how one would make the disk operating system (DOS) perform automatic disk logging, but I do not think that it is sufficient or necessary to simply check for which disks are set to read-only status. First of all, the user may have set a disk to R/O status (using STAT or another utility), and that diskette may not have been changed. In fact, relogging that diskette would defeat the purpose behind the user's setting it to R/O status, i.e., to prevent any writing to that diskette. Secondly, after a diskette is swapped without resetting with a control-c, the diskette is not yet marked as read-only. I think that what has to be done is the following. Whenever DOS is asked to write to a disk, it must check the allocation table implied by the directory on the diskette with the allocation table stored in the BIOS. If the diskette has not been swapped, the two tables will agree; if they have been swapped chances are very high that they will not agree. The standard Digital Research BDOS does this, and if it finds that the tables do not agree, it then sets the disk status to read-only, which precipitates the "BDOS ERROR: DISK R/O" error message. If you want the DOS to log in the swapped disk, you must take a more complex action at this point. I am sure that the required actions to handle this situation are more complex than meets the eye. If you want to try hacking, have fun! I would start by adding code to log in the new disk in such a way that the write operation can then proceed. Good luck. If you simply want this very nice capability in your system, I strongly recommend that you look into purchasing ZRDOS from Echelon, Inc. (415-948-3820). Although ZRDOS is the DOS used with the Echelon Z operating system, ZRDOS can be used as the DOS in a standard CP/M2.2 system as well (it does require a Z80 or compatible microprocessor). ZRDOS offers quite a few nice features in addition to automatic disk logging, and I am sure that Echelon will be happy to send you more detailed information. As good as ZRDOS is, by the way, it still cannot handle all disk-swap situations. I believe that it has trouble, at least on some systems that support automatic recognition of multiple disk formats, when the swapped diskette has a different format, such as when you remove a Kaypro SSDD diskette and put in an Ampro DSDD diskette. I say all this as an indication that automatic disk logging is not as easy as one might think at first. ZRDOS has gone through a lot of development to get to the point it is at now. Jay Sage FAILSAGE Automatic Disk Logging<[AI.AI.MIT.EDU].99088.860926>YN-!  z z zz$z,z4z<z"Dz&Lz*Tz.\z2dz6lz:tz>|z %¥ 3@H Subject: Floating Point Randomness To: BUG-LISPM@OZ.AI.MIT.EDU Message-ID: <860925213752.1.SHAHRIAR@MORRISON.AI.MIT.EDU> The following is the stack backtrace resulting from evaluating the form: (multiple-value (x-arr y-arr m-arr a1 a2 b1 b2) (main 1.0d0 1.0d0 -1.0d0 1.0d0 -1.0d0 -1.0d0 30 30)) The source of the function MAIN and related functions follows the backtrace. The interesting thing is that the same form can be repeatedly evaluated, sometimes producing a similar error, while other times producing a result, vis. (multiple-value (x-arr y-arr m-arr a1 a2 b1 b2) (main 1.0d0 1.0d0 -1.0d0 1.0d0 -1.0d0 -1.0d0 30 30)) ===> 2.0000000000091265d0 -1.1903260690686309d-14 1.0000000000041342d0 8.989679518168477d-16 -1.0000000000041673d0 2.0000000000091265d0 -1.1903260690686309d-14 1.0000000000041342d0 8.989679518168477d-16 -1.0000000000041673d0 (-0.9999977656749428d0 1.0000000000020897d0 -1.0000022343341837d0 -1.0000000000020777d0) # In addition, the results vary (both when there is an error, and when evaluation succeeds). Trace follows... In Symbolics 3640 Release 6.1, IP-TCP 29.13, Experimental Release-6-7 5.0, 6-1-Patches 1.23, MAC 2.5, Experimental RELATUS 157.30, microcode TMC5-IO4-MIC 336, FEP 127, fep0:>v127-lisp.flod(43), fep0:>v127-loaders.flod(43), fep0:>v127-tests.flod(43), fep0:>v127-debug.flod(31), fep0:>v127-info.flod(43), on Lisp Machine Jim Morrison: >>Error: Attempt to take the square root of -5.31938937342602d-11, which is negative. While in the function SI:DSQRT-COMPONENTS  SQRT  GET-PARAMETERS SI:DSQRT-COMPONENTS: (P.C. = 112) Arg 0 (SI:HIGH): -1110622624 Arg 1 (SI:LOW): 0 Local 2 (SI:*SELECTQ-ITEM*): 988 SQRT: (P.C. = 15) Arg 0 (SI:N): -5.31938937342602d-11 GET-PARAMETERS: (P.C. = 35) Arg 0 (M-ARR): # MAIN: (P.C. = 117) Arg 0 (A): 1.0d0 Arg 1 (B): 1.0d0 Arg 2 (C): -1.0d0 Arg 3 (AA): 1.0d0 Arg 4 (BB): -1.0d0 Arg 5 (CC): -1.0d0 Arg 6 (N-POINT-1): 30 Arg 7 (N-POINT-2): 30 SI:*EVAL: (P.C. = 401) Arg 0 (SI:FORM): (MAIN 1.0d0 1.0d0 -1.0d0 1.0d0 -1.0d0 -1.0d0 30 30) Local 0 (SI:FORM): NIL Arg 1 (SI:ENV): NIL --Defaulted args:-- Arg 2 (SI:HOOK): NIL MULTIPLE-VALUE: (P.C. = 34) Arg 0 (SI:FORM): (MULTIPLE-VALUE (X-ARR Y-ARR M-ARR A1 A2 B1 B2) (MAIN 1.0d0 1.0d0 -1.0d0 1.0d0 -1.0d0 -1.0d0 30 30)) Arg 1 (SI:ENV): NIL SI:*EVAL: (P.C. = 163) Arg 0 (SI:FORM): (MULTIPLE-VALUE (X-ARR Y-ARR M-ARR A1 A2 B1 B2) (MAIN 1.0d0 1.0d0 -1.0d0 1.0d0 -1.0d0 -1.0d0 30 30)) --Defaulted args:-- Arg 1 (SI:ENV): NIL Arg 2 (SI:HOOK): NIL (:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0): (P.C. = 152) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): # TV:WITH-NOTIFICATION-MODE-INTERNAL: (P.C. = 16) Arg 0 (TV:NEW-MODE): :BLAST Arg 1 (TV:STREAM): #:TERMINAL-IO-SYN-STREAM Arg 2 (TV:CONTINUATION): # SI:LISP-COMMAND-LOOP-INTERNAL: (P.C. = 54) Arg 0 (SI:NAME): "Lisp Top Level" Arg 1 (SI:ABORT-FUNCTION): NIL Arg 2 (SI:READ-FUNCTION): NIL Arg 3 (SI:EVAL-FUNCTION): NIL Arg 4 (SI:PRINT-FUNCTION): NIL SI:LISP-COMMAND-LOOP: (P.C. = 67) Arg 0: # Rest arg: (:NAME "Lisp Top Level") SI:LISP-TOP-LEVEL1: (P.C. = 5) Arg 0 (SI:STREAM): # SI:LISP-TOP-LEVEL: (P.C. = 7) This is the source for the various functions (yes, I know there is a lot of code--perhaps you can simulate the error with something less complex). (defvar *x-max*) (defvar *y-max*) (defvar *noisy-data?*) (defvar *x-noise-percent*) (defvar *y-noise-percent*) (defun main (a b c aa bb cc n-point-1 n-point-2) (let* ((a1 0) (a2 0) (b1 0) (b2 0) (npt (+ n-point-1 n-point-2)) (x-val-1 (make-array n-point-1)) (y-val-1(make-array n-point-1)) (x-val-2 (make-array n-point-2)) (y-val-2 (make-array n-point-2)) (x-values (make-array npt)) (y-values (make-array npt))) (points-on-a-line a b c n-point-1 x-val-1 y-val-1) (points-on-a-line aa bb cc n-point-2 x-val-2 y-val-2) (dotimes (i n-point-1) (aset (aref x-val-1 i) x-values i) (aset (aref y-val-1 i) y-values i)) (dotimes (i n-point-2) (aset (aref x-val-2 i) x-values (+ n-point-1 i)) (aset (aref y-val-2 i) y-values (+ n-point-1 i))) ; (dotimes (i npt) ; (format t "~%(~d ~d)" (aref x-values i) (aref y-values i))) (let* ((m-arr (get-essential-parameters x-values y-values))) (multiple-value (a1 a2 b1 b2) (get-parameters m-arr)) (values x-values y-values m-arr a1 a2 b1 b2)))) (defun points-on-a-line (a b c n-points &optional (x-val (make-array n-points)) (y-val (make-array n-points))) (cond ((= 0 a) (cond ((not (= 0 b)) (setq c (// c (float b))))) (dotimes (i n-points) (aset (random *x-max*) x-val i) (aset c y-val i))) (t (cond ((= 0 b) (setq c (// c (float a))) (dotimes (i n-points) (aset (random *y-max*) y-val i) (aset c x-val i))) (t (setq c (// c (float b)) a (// a (float b))) (dotimes (i n-points) (aset (random *x-max*) x-val i) (aset (- c (* a (aref x-val i))) y-val i)))))) (cond (*noisy-data?* (let* ((x 0) (y 0)) (dotimes (i n-points) (setq x (aref x-val i) y (aref y-val i) x (* x (+ 1.0 (* *x-noise-percent* (small-random)))) y (* y (+ 1.0 (* *y-noise-percent* (small-random))))) (aset x x-val i) (aset y y-val i))))) (values x-val y-val)) (defun get-essential-parameters (x-val y-val) ; (print-array x-val) ; (print-array y-val) (let* ((x 0) (y 0) (temp-e 0) (e-arr (make-array 5)) (m-arr (make-array 5)) (sum-e-arr (make-array 5 :initial-value 0)) (sum-ee-arr (make-array '(5 5) :initial-value 0))) (dotimes (i (array-active-length x-val)) (setq x (aref x-val i) y (aref y-val i)) ; (print (list x y)) (aset x e-arr 0) (aset y e-arr 1) (aset (* x x) e-arr 2) (aset (* x y) e-arr 3) (aset (* y y) e-arr 4) (dotimes (j 5) (setq temp-e (aref e-arr j)) (incf (aref sum-e-arr j) temp-e) (dotimes (k 5) (incf (aref sum-ee-arr j k) (* temp-e (aref e-arr k)))))) (setq m-arr (negate-vector (linear-matrix-equation sum-ee-arr sum-e-arr))) ; (print-array m-arr) m-arr)) (defun get-parameters (m-arr) (print-array m-arr) (let* ((a+a (aref m-arr 0)) (aa (aref m-arr 2)) (b+b (aref m-arr 1)) (bb (aref m-arr 4)) (dlt-1 (- (* a+a a+a) (* 4.0 aa))) (dlt-2 (- (* b+b b+b) (* 4.0 bb))) (a1 (// (+ (- a+a) (sqrt dlt-1)) 2.0)) (a2 (// (- (- a+a) (sqrt dlt-1)) 2.0)) (b1 (// (+ (- b+b) (sqrt dlt-2)) 2.0)) (b2 (// (- (- b+b) (sqrt dlt-2)) 2.0))) (print-array m-arr) (print (list a1 b1 a2 b2)) (values a1 b1 a2 b2))) (defun linear-matrix-equation (a-arr b-arr &optional (c-arr (make-array (array-active-length b-arr))) &aux (lu (make-array (array-dimensions a-arr))) (ps (make-array (array-dimensions a-arr)))) (multiple-value (lu ps) (math:decompose a-arr)) (math:solve lu ps b-arr c-arr) c-arr) (defun negate-vector (arr &aux (dim (array-active-length arr))) (loop for i from 0 below dim do (aset (- (aref arr i)) arr i)) arr) Thanks a lot. FAILSHAHRIAR Floating Point Randomness<[AI.AI.MIT.EDU].98772.860925>KWH-DAILYNOSHOWFILE[KWH;KWH MAIL]FILENOSHOWYN-!  lQl)lQ l) lQl)lQl)lQ$l)lQ,l)lQ4l)lQlQ|l) YlQ < llQlQ@Hl 2 nllt` HSLGp89X00 NH$ x(@ x GK8 $9P8 pVP0X`Y`Y`0XYYKWH-BUGReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 SEP 86 20:44:14 EDT Received: from PREP.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 25 Sep 86 20:44-EDT Received: by PREP.AI.MIT.EDU; Thu, 25 Sep 86 20:44:52 EDT Received: from CCRMA-F4 by SU-AI with PUP; 25-Sep-86 17:40 PDT Date: 25 Sep 86 1732 PDT From: Julius Smith Subject: * menus To: "bug-gnu-emacs@prep.ai.mit.edu"@SU-AI.ARPA I think dired and buffer menus should have basically the same mode-specific commands. A feature merge would be great. Also, RMAIL commands could be moved in this direction, especially after a C-M-h (header buffer creation). By the way, undigestify-rmail-message throws the header buffer out of synch with the displayed message. FAILJOS%CCRMA * menus <[AI.AI.MIT.EDU].98736.860925>KWH-DAILYNOSHOWFILE[KWH;KWH MAIL]FILENOSHOWYN-!  PaPaPa Pa%Pa-Pa5Pa=PaEPa"MPa&UPa*]Pa.ePa2mPa6uPa:}Pa> 7Pa  QPaPa@HQ . S!HQHQt` HSL&dpY0kN.,i0s,X]`0 H(/@ x1 &` 8 7`7`xm MJWSTORKReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 SEP 86 19:35:01 EDT Received: from AMSAA by MC.LCS.MIT.EDU 25 Sep 86 19:33:43 EDT Received: from nosc.arpa by AMSAA.ARPA id a026711; 25 Sep 86 18:56 EDT Received: by bass.ARPA (5.31/4.7) id AA17574; Thu, 25 Sep 86 15:57:50 PDT Message-Id: <8609252257.AA17574@bass.ARPA> Date: Thu, 25 Sep 86 15:38:01 PDT From: Marc Wilson To: info-cpm@AMSAA.ARPA Subject: Automatic disk logging I want to add automatic disk logging to my BDOS ( P2DOS ), but I'm not sure about how to go about it. So far, I've produced some very wrird behavior patterns from the BDOS, but no success. I think what needs to be done is for BDOS to check each drive's status upon it's selection, and reset it if it is R/O. Any comments or help would be greatly appreciated. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marc Wilson ARPA: ...!crash!pnet01!mwilson@nosc ( preferred ) ...!crash!pnet01!pro-sol!mwilson@nosc UUCP: [ ihnp4 | cbosgd | sdcsvax | noscvax ]!crash!pnet01!mwilson@nosc "The difference between science and the fuzzy subjects is that science requires reasoning, while those other subjects merely require scholarship." -Lazarus Long ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FAILNET-ORIGIN<[AI.AI.MIT.EDU].98714.860925>YN-!  qq qqq qqq$qq,qq4qqq q  q/qq@Hq/ . sOHq/Hq/t` HSKop`}X 0 ?H I*x0@@ x 8 pFP0H` HI}P0J8 K8 M`` .hH KWH-PERSONALReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 SEP 86 17:36:07 EDT Received: from EDDIE.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 25 Sep 86 17:27-EDT Received: by EDDIE (5.31/4.7) id AA29306; Thu, 25 Sep 86 17:25:01 EDT Received: by MEDIA-LAB.MIT.EDU (5.51/4.8) id AA24103; Thu, 25 Sep 86 17:23:50 EDT Date: Thu, 25 Sep 86 17:23:50 EDT From: Jim Davis Message-Id: <8609252123.AA24103@MEDIA-LAB.MIT.EDU> To: kwh@oz Subject: Scheme to Common Lisp I've heard there is a program to translate, but I don't remember which direction it goes in. Can you remind me? FAILjrd Scheme to Common Lisp<[AI.AI.MIT.EDU].98656.860925>FILE[KWH;KWH MAIL]FILENOSHOWKWH-DAILYNOSHOWFILE[KWH;KWH MAIL]FILE YN-!  )d)d)d )d%)d-)d5)d=)dE)d"M)d&U)d*])d.e)d2m)d6u)d:})d> XZc)d  ,)d)d@H,¡ 4$H,H,` HSKRjp8 88V P HP   P  P08KJP0$  8@?8PHvP P 0r P"0s% P'0o 815Xj 0+ hH,D-x.0@/pl08*R4(pP382;$86(:Pt(P90u88&P wP=x>8<7$APB8FGp|PE0~8DCP `IYPxL088NMQ)HPP8Ox08ST8U ``H[65\]2^xO_8`a6bxUc;de:fx[g>Hhi>jxak?Yl fmBnxgo`%pqFrxmsbwtuJvxswexfyNzxy{h|}R~xq&VxtfZxvf ^ x y bx; fx? jxnx rx%M !v"x#c$%z&x'3()~*x+,-.x/:_012x345 6x7@(89:x;<=>x?Gs@ABxCЯDEFxGS<HIJxKALM"NxO[PQ&RxSTU*VxWbOXY.Zx [g\]2^x_h`a6bxcde:fxgmahi>j!klmBnx)os*pqFrx/stuJvx5wxsxyNzx;{|}R~xA~<VxGAiZxM ^ xS n bxY fx_7jxe7nxkrxqAABCPHJARRDZMLYAABAKRALANDANIELDPHKWH-LOCALPGSRDZZVONADCBPGSALANAWARDCENTPGSReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 SEP 86 16:35:58 EDT Date: Thu, 25 Sep 1986 16:24 EDT Message-ID: To: All-AI%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU From: mck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: Safety Plan If you have office space on the 7th, 8th, or 9th floor, you should by now have had the opportunity to read the safety plan I dropped off in each office and lab. You may safely delete this message as you have read it already...right? If for some reason you didn't recieve this information, I have extra copies in my office. THIS MESSAGE IS FOR THOSE OF YOU WHO DO NOT HAVE OFFICE OR LAB SPACE IN THE AI LAB, but who are here for a significant length of time each week. Please read the following safety plan and take time to peruse the maps posted in several places on each floor. These maps illustrate the exits, fire alarms and other safety features each floor has. MEMBERS OF THE LAB HAVE HAD TO EVACUATE UNDER EMERGENCY CONDITIONS IN THE PAST. So please consider this information a vital part of your knowledge of the Lab. ARTIFICIAL INTELLIGENCE LABORATORY ENVIRONMENTAL HEALTH AND SAFETY PLAN SAFETY PRECAUTIONS AND ACCIDENT PREVENTION PROGRAM The Artificial Intelligence Laboratory's Safety Officer is Lynne Geldard, the Laboratory's Administrative Officer. The Safety Officer works with an informal committee of faculty, staff, and students to anticipate possible hazards and to prepare for emergencies. The committee also establishes rules and procedures for using the machine shop, the robots, electrical equipment, and the Laboratory vehicle. Members of the Safety Committee include: Arthur A. Baker, Priscilla M. Cobb, Inaki Garabieta, John M. Hollerbach, Tomas Lozano-Perez, Laurel A. Simmons, and Ronald Wiken. (Note: Dr. Baker is a medical doctor). HOW TO EXIT THE BUILDING IN AN EMERGENCY The Artificial Intelligence Laboratory occupies space on four floors -- the basement and the 7th, 8th, and 9th floors--at 545 Technology Square. Floors 7, 8, and 9 exit by way of two stairwells located at the south side of the central core of the building. The basement exits to the first floor by way of one stairwell in the central core of the building and to the outside by way of a corridor that opens onto the loading dock at the north side of the buildinq. In an emergency, all handicapped people must be assisted or carried through the stairwells to the first floor, then carried to the CENTRAL COURTYARD (Tech. Sq. side). There are no horizontal evacuation routes or handicapped ramp exits from the building. Floor plans showing the locations of stairwell exits and other safety features (eg. fire alarms, fire extinquishers) on each floor are posted in several locations throughout the Laboratory. WHAT TO DO IF THE FIRE ALARM SOUNDS If the fire alarm sounds, LEAVE THE BUILDING IMMEDIATELY. Take the stairs (NOT THE ELEVATORS) to the first floor and assemble with other members of the Artificial Intelligence Laboratory on the COURTYARD SIDE (Tech. Sq.) of the building. DO NOT stand on the parking lot side of the building because you will interfere with fire-fighting equipment. *Do not use the Elevators *Do not stop to fight the fire. *Do not stop to save property or documents. *Help handicapped or injured persons to evacuate the building. If you cannot help them, report their locations to Fire Department personnel. *Do not enter the building to rescue people or pets. Report people or pets remaining in the building to Fire Department personnel. *RE-ENTER THE BUILDING ONLY WHEN FIRE DEPARTMENT PERSONNEL SAY THAT IT IS SAFE (not, for example, when the fire alarm stops). *Obey instructions of Fire Department personnel and of the Laboratory Fire Wardens. Our Fire Wardens are: Cristina A. Ciro NE43-801 Crisse@OZ 3-8919 Priscilla M. Cobb NE43-808 Cobb@OZ 3-6756 Oded Feingold NE43-908 OAF@OZ 3-8598 W. Eric L. Grimson NE43-725 WELG@OZ 3-5346 Daniel P. Huttenlocher NE43-723 DPH@OZ 3-8843 M. Cathleen Krebs NE43-817 MCK@OZ 3-3562 Christopher J. Lindblad NE43-733 CJL@OZ 3-8828 Gerald L. Roylance NE43-741 GLR@OZ 3-7884 William A. Schulze NE43-908 WLS@OZ 3-1727 Laurel A. Simmons NE43-910 Laurel@OZ 3-6703 Claudia R. Smith NE43-835A Claudia@OZ 3-5217 Elizabeth J. Willey NE43-772A Elizabeth@OZ 3-6693 WHAT TO DO IF YOU DISCOVER A FIRE If you discover a fire, sound the fire alarm and leave the building immediately. *Fire alarm boxes are located by the janitor's closet in the elevator lobby on each floor. *Report the location of the fire to the Fire Department personnel responding to the alarm. Assemble with other members of the Artificial Intelligence Laboratory on the Courtyard side (Tech. Sq.) of the building. Do not stand on the parking lot side because you will interfere with fire-fighting equipment. REMEMBER THE FOLLOWING POINTS ABOUT FIRES *Before opening a closed door during a fire, feel both the door and the doorknob. If either is hot, do not open the door. *It is safer to stay in a smoke-free room than to try to exit through a smoke-filled corridor. Close the door of the smoke-free room and seal the door jamb to keep the smoke out. Signal for help from the window, but do not break the window unless the fire is on a floor above you. HOW TO PREVENT FIRES *Do not let trash accumulate. *Do not keep flammable or combustible materials in the building. *Report hazards such as frayed wires and overheated equipment to the Laboratory Fire Wardens or to members of the Laboratory Safety Committee. *Keep fire exits clear. *Know where the fire alarm boxes are located. *Plan excape routes from all parts of the Laboratory. For example, consider how you would find your way in the dark from all corners of the Laboratory to the staircases. *Reminder: Smoking is prohibited in all areas of the ARtificial Intelligence Laboratory. TOXIC MATERIALS AND HAZARDOUS EQUIPMENT The few toxic or hazardous materials used in connection with the Artificial Intelligence Laboratory's research are kept and used in our ninth-floor machine shop. The faculty, staff, and students who use these materials work primarily on small mechanical design projects in the area of robotics research. The machine shop is also used to construct and repair prototype computing equipment. The following people directly supervise these facilities: *Laurel A. Simmons, Facilities Coordinator. Ms. Simmons is in charge of all Laboratory computer and research facilities. *Oded Feingold, Research Specialist. Mr. Feingold has CPR certification and first aid training. *Inaki Garabieta, Research Engineer. Mr. Garabieta is an experienced mechnical designer and machinist. *William A. Schulze, Junior Computer Operator. Mr. Schulze has CPR certification and damage control training and attended fire-fighting school. *Ronal Wiken, Research Specialist. Mr. Wiken has machine shop and electronics shop training. In addition, Arthur A. Baker, MD, a Visiting Scientist, is willing to assist in emergencies. A committee, composed of the Laboratory Safety Officer, the machine shop area supervisors, and users of the machine shop and darkroom, meets regularly to discuss safety practices, training issues, and elimination of possible hazards. This committee is responsible for enforcing machine shop safety rules, which are clearly posted in the shop. Many of the users of the machine shop are graduate students in the Mechanical Engineering Department who have taken one or more subjects in machine shop practices. The more dangerous pieces of the robot equipment are locked, with access restricted to people who have been trained to use them. The machine shop and darkroom are locked, preventing access to the equipment and chemicals used there, when the supervisors are not present. Only people who have demonstrated that they understand and practice the proper use of the equipment and chemicals are permitted night and weekend access. In addition, people are strongly discouraged from working alone in the machine shop, and the building security guard checks the area regularly. The machine shop is equipped with an Atmospheric Control Products fume hood, a Speakman emergency shower and eye wash, a supply of safety glasses and dust/vapor masks, first aid kits, and fire extinguishers. Eye protection signs are prominently displayed, and contents of containers clearly marked. The darkroom is vented into the Atmospheric Control Products fume hood. The emergency telephone number for the Campus Police is posted beside the telephones in the machine shop. Smoking is prohibited in the machine shop and darkroom, as well as in all areas of the Artificial Intelligence Laboratory. Small quantities of the following chemicals are used regularly in the machine shop: Clover Compound Silicon Carbide Abrasive (various grades) Dixon Ticonderoga No. 2 Flake Graphite DuPont TF Solvent (Freon) Dykem Spray Steel Blue (No. SP1100) Elmers Glue-All GC Freon TF solvent Kerosene Methyl Alcohol Norton Sharpening Oil (Cat. No. XB1, Prod. No. 87760-7) RuGlyde Rubber Lubricant Turner Tornado Propane Fuel WD-40 (Stk No. 42150) Photographic chemicals Laboratory personnel buy only the materials they will use quickly; there is no stock room. PLANS TO INCREASE AWARENESS Plans to increase awareness of safety issues include sponsoring CPR and first aid courses for all members of the Laboratory and discussing fire safety in group meetings. Thank you for your attention. FAILmck%OZ.AI.MIT.EDU Safety Plan<[AI.AI.MIT.EDU].98632.860925>APPENDawardNOSHOWNOQCNO-CLIAPPENDBrotsky.PANOSHOWSMALL-CLINOQCAPPENDRFC733KWH-DAILYNOSHOWFILE[KWH;KWH MAIL]FILENOSHOWNO-CLINOQCNO-CLINOQCRFC733AKR@SNOSHOWno-clinoqcrfc733SMALL-CLIYN-!  W5W5W 5W5%W5-W55W5=W5EW"5MW&5UW*5]W.5eW25mW65uW:5}W>5 )W  W:WW@HW: . YZHW:HW:t` HSJBHP  ` x0X h@ /`/ ``!pxxmGERICHRICHmck@oz DARPA Prop.Cathleen, when you get a chance would you ask PHW what the nominal starting date is for the proposal (and therefore for the milestones). Thanks, Chuck. <[AI.AI.MIT.EDU].98486.860925.RICH>Date: Thu, 25 Sep 86 10:00:36 EDT From: Charles Rich Subject: DARPA Prop. To: mck@OZ.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].98486.860925.RICH> YN-! To To To To#To+To3To;To!CTo%KTo)STo-[To1cTo5kTo9sTo={To   @H] , ՝]]~` HSDx$H@0s,X @(x`  x` x``MAILSILVERSILVERd <[AI.AI.MIT.EDU].98310.860924.SILVER>Date: Wed, 24 Sep 86 22:29:23 EDT From: Bernard Silver To: SILVER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].98310.860924.SILVER> YN-!  To To To To#To+To3To;To!CTo%KTo)STo-[To1cTo5kTo9sTo={To  K  @H] , ם]]t` HX0s, 0 @pxh (Hxw` h` h`t, ..d alt sorthingIf a ate bre maned, th dots weocked orde indeely,  thenuld fiffer becaQueued msg sent to: atp.plummer at R20.UTEXAS.EDU SILVERFAIL<[AI.AI.MIT.EDU].98309.860924>Msg of Wednesday, 24 September 1986 22:13-EDTCOMSATDate: Wed, 24 Sep 86 22:29:15 EDT From: Communications Satellite Subject: Msg of Wednesday, 24 September 1986 22:13-EDT To: SILVER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].98309.860924> YN-!  :]:] :]:]%:]-:]5:]=:]"E:]&M:]*U:].]:]2e:]6m:]:u:]>}:]  x  @H  9t` HRlKpY0kN.,i0s,XEP0Hq x  s@ pu K`8x`x`MJWSTORKReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 SEP 86 20:52:22 EDT Received: from AMSAA by MC.LCS.MIT.EDU 13 Sep 86 20:35:49 EDT Received: from brl-smoke.arpa by AMSAA.ARPA id a000960; 13 Sep 86 7:40 EDT Received: from USENET by SMOKE.BRL.ARPA id a011368; 13 Sep 86 7:35 EDT From: Andrew Klossner Newsgroups: net.micro.cpm Subject: Cheap S-100 memory? Message-ID: <2275@hammer.UUCP> Date: 11 Sep 86 16:57:12 GMT To: info-cpm@AMSAA.ARPA Now that RAM chip prices have dropped through the floor ... Can anyone recommend a cheap board with a huge slug of memory for an IEEE S-100 system, with memory mapping suitable for CP/M 3? My CPU board (a 1978 vintage Ithaca) doesn't do appropriate memory mapping. In 1983 there was a great little board, with each 4k page independently mappable, for a couple of grand; seems like it should cost a couple of hundred by now if still in production. Thanks, -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP] (tekecs!andrew.tektronix@csnet-relay) [ARPA] FAILandrew%hammer.uucp Cheap S-100 memory?<[AI.AI.MIT.EDU].93640.860913>YN-!  ÕCKÕ CKÕCK ÕCKÕ!CKÕ)CKÕ1CKÕ9CK ÕACK$ÕICK(ÕQCK,ÕYCK0ÕaCK4ÕiCK8ÕqCK<ÕyCK OÕ ÕÕ@H 4 t` HRJ~ZH@ 0s,X@'~` t/` t/``TT  Dei056m o8 :uMKLOTZROLYI set your address to be the DEC thing but the mail came back, saying that tarkin didn't exist. I've now set it back here. I hope you read your mail here sometime. Leigh. <[AI.AI.MIT.EDU].92481.860909.KLOTZ>Date: Tue, 9 Sep 86 13:36:27 EDT From: "Leigh L. Klotz" To: ROLY@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].92481.860909.KLOTZ> YN-!  }}A} }A }}A}}A}$}A},}A}4}A}<}A"}D}A&}L}A*}T}A.}\}A2}d}A6}l}A:}t}A>}|}A }  }}}@H} , }}t` HRHlp (80s,(XP 0 zH  x ,@ p} ```5)++00 )++](/FAWCETT@RED.RUTGERS.EDUSILVER@AI.AI.MIT.EDUReceived: from RED.RUTGERS.EDU by AI.AI.MIT.EDU 9 Sep 86 00:48:44 EDT Date: 9 Sep 86 00:44:49 EDT From: Tom Fawcett Subject: phlogiston To: silver@AI.AI.MIT.EDU Message-ID: <12237458056.55.FAWCETT@RED.RUTGERS.EDU> Everybody goes to parties They do the sixteen dances It's time we did 'em right They do the shy tuna They do the camel walk They do the escalator They do the hippo-crit They do the boogaloo , , , So what the hell are you doing? Anything new on the precondition front? I'm trying to get interesting people to come here to talk. How about it? Shall I put you down for, say, September 23rd? Good. We don't have much of an operating budget, so we can't pay your air fare or anything. But we can, um, probably afford to buy you a sandwich at the lunchwagon outside the Hill center. How about it? Why don't you come here to demonstrate, after totally slashing Smadar's career into ribbons by pulling the funding out from under her just when she was on the brink of a breakthrough in machine learning, that GTE's not such a bad place after all. A goodwill tour - how about it? -Tom ------- FAILFAWCETT phlogiston<[AI.AI.MIT.EDU].92288.860909>YN-!  D D D D &D .D 6D >D FD# ND' VD+ ^D/ fD3 nD7 vD; ~D?  JD  dDD@Hd  HdHdt` HRE|pH|(0s,(X 0HPF@ pG 򴢛` J` J`ssXpacket-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 8 Sep 86 23:42:54 EDT Received: by EDDIE (5.31/4.7) id AA14131; Mon, 8 Sep 86 23:33:33 EDT Received: by EDDIE (5.31/4.7) id AA14124; Mon, 8 Sep 86 23:33:15 EDT Message-Id: <8609090333.AA14124@EDDIE> Received: from (DXROODE)UCIVMSA.BITNET by WISCVM.WISC.EDU on 09/08/86 at 22:34:14 CDT Date: Mon, 8-SEP-1986 20:31 PDT From: To: Subject: Interfacing a TNC to Yaseu FT208R Has anyone out there successfully interfaced a TNC to a Yaseu FT208R HT? Dana - WA6NGO DFROODE%UCICP6.BITNET@WISCVM.WISC.EDU FAILNET-ORIGIN<[AI.AI.MIT.EDU].92259.860908>YN-!  M`M`M` M`%M`-M`5M`=M`EM`"MM`&UM`*]M`.eM`2mM`6uM`:}M`> &M` 8 NM`M`@HN  P HNHNt` HR@H0s,xxX @U0 %`  p` p`+++BDAYDRAGONRFC733PAYTHappy Birthday!Happy birthday to you, Happy birthday to you, Happy birthday dear Dave, Happy birthday to you. <[AI.AI.MIT.EDU].91935.860908.DRAGON>FAILDate: Mon, 8 Sep 86 00:02:50 EDT From: Puff the Magic Dragon Subject: Happy Birthday! To: PAYT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].91935.860908.DRAGON> YN-!  n/n_ n/n_n/ n_n/ n_"n/n_*n/n_2n/n_:n/n_Bn/!n_Jn/%n_Rn/)n_Zn/-n_bn/1n_jn/5n_rn/9n_zn/=n_ =n/ " nOn/n/@HnO 8 poHnOHnOt` HR<;0pH|(0s,(X 0qHP9@ p: ;c` =` =`packet-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 7 Sep 86 20:18:56 EDT Received: by EDDIE (5.31/4.7) id AA02281; Sun, 7 Sep 86 20:12:38 EDT Received: by EDDIE (5.31/4.7) id AA02274; Sun, 7 Sep 86 20:12:26 EDT Received: by ucbvax.Berkeley.EDU (5.53/1.16) id AA24823; Sun, 7 Sep 86 17:14:17 PDT Received: by jade.Berkeley.Edu (5.31 (CFC 4.21)/5.6.3) id AA17048; Sun, 7 Sep 86 17:12:51 PDT Message-Id: <8609080012.AA17048@jade.Berkeley.Edu> Received: by CLVM (Mailer X1.23a) id 1317; Sun, 07 Sep 86 20:13:06 EDT Date: Sun, 7 Sep 1986 19:45 EDT From: Bill Kaster Subject: First Step? To: Well a new school year and a funded amateur radio club looking to jump into packet radio! I would like some help selecting equipment. As far as I can tell we need only the TNC at this point. ( We already have a 2m rig and another rig set up for satellite activity. We also have a Zenith Z-248 at our disposal) Our aim is to set up a PBBS. Does anyone have an opinion as to the best path from where we are to having a PBBS? I.e. What is the best TNC-II out there? Along those lines, from a software viewpoint: What is there, why is it the best, and where can we get it, and is source code available? We could write our own code, of course, be we have this insane aversion to duplicating effort. ... and lastly: A question. What is the difference between a PBBS .. and lastly: A question. What is the difference between a PBBS and a digipeater? Can a PBBS also be a digipeater? }Bill Kaster KA2WCS Clarkson U. (K2CC) FAILNET-ORIGIN<[AI.AI.MIT.EDU].91896.860907>YN-!  sE sEsEsE !sE)sE1sE9sEAsE IsE$QsE(YsE,asE0isE4qsE8ysE<  sE  sesEsE@Hse  vHseHset` HR2YlpY00s,X1h0 QH(@xY` ` `)PLUKELReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 SEP 86 12:17:49 EDT Received: from CIPG.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 SEP 86 12:16:05 EDT Return-Path: Received: by cipg.mit.edu (4.12/MIT/CIPG.1x.1) on Sat, 6 Sep 86 12:13:54 edt; Date: Sat, 6 Sep 86 12:13:54 edt From: Greg Troxel To: w1xm@cipg.mit.edu Subject: MEETING THIS WEDNESDAY The first fall term meeting of w1mx and w1xm will be Wednesday, September 10, at 1900 in 66-160 This is a very important meeting for anyone wishing to join the autopatch (this includes those who already know the summer experimental codes, as the codes may change). We will discuss how much the patch fee should be (which of course depends on how many users there are). FAILNET-ORIGIN<[AI.AI.MIT.EDU].91662.860906>YN-! g ggg !g)g1g9gAg Ig$Qg(Yg,ag0ig4qg8yg< ?g ( hgg@Hh . h?HhHh~` HR*'*p00s,X801H`x(@ x9 '[` ?` ?`5SILVERReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 SEP 86 10:30:03 EDT Date: Fri 5 Sep 86 10:27-EDT From: Bernard Silver Subject: test To: silver@AI.AI.MIT.EDU test FAILMARLENE.SILVER%OZ.AI.MIT.EDU test<[AI.AI.MIT.EDU].91336.860905> fYN-E  %-5="E&M*U.]2e6m:u>} 7h C@H > '~^` Hjbvb en weR6-pH|(0s,(Xr 0eHP3@ p4 6c` 7` 7`0<==vpacket-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 3 Sep 86 11:02:05 EDT Received: by EDDIE (5.31/4.7) id AA17664; Wed, 3 Sep 86 10:51:56 EDT Received: by EDDIE (5.31/4.7) id AA17657; Wed, 3 Sep 86 10:50:59 EDT Message-Id: <8609031450.AA17657@EDDIE> Received: from pitt by csnet-relay.csnet id aa03829; 3 Sep 86 10:24 EDT Received: by pitt (5.51/4.7) id AA00514; Tue, 2 Sep 86 10:08:41 EDT To: packet-radio@MIT-EDDIE.ARPA Date: Tue, 2 Sep 86 10:08:36 EDT From: Bob Hoffman Subject: Re: WA8DED Host Mode X-Mailer: ELM [version 1.2] While I can't explain Bill Retzner's inability to connect via digipeaters, I thought I'd pass along this help file. ---Bob. ----- cut here ---- WA8DED HOST MODE USER'S GUIDE Paul T. Williamson, KB5MU 23 May 1986 Abstract: This document explains the use of Host mode with WA8DED's AX.25 Version 2 Multi-channel TNC Firmware, Version 1.1 for the TAPR TNC-1. It is based on the information provided in the WA8DED document (Version 1.0), the W6IXU mailbox software (13 May 1986 revision), and the WA8DED Split Screen Terminal Emulator (SS, 28 April 1986 version). It is intended for use by an application programmer attempting to communicate with the TNC in Host mode, and assumes that the programmer is already familiar with user-mode operation of the WA8DED firmware. 1 Chapter 1 What Is Host Mode? WA8DED's TNC firmware provides two entirely independent user interfaces. The default user interface is designed for use by a human operator at a terminal. Host mode, on the other hand, is designed for use by a specially-designed computer program. It allows the computer to maintain strict control of the computer-TNC link, and to obtain control information that would otherwise be difficult to extract from the normal data stream. One of the most common bugaboos of computer-TNC interfacing has always been flow control. The TNC is capable of sending data faster than the computer can process it, and likewise the computer is capable of sending data faster than the TNC can transmit it. It is theoretically possible to solve this problem with either hardware flow control (RTS/CTS wires in the RS-232 link) or software flow control (XON/XOFF characters inserted in the data stream). Both of these methods are tricky and error-prone, however. Hardware flow control may not always be available, and software flow control, even when it works adequately, leads to data transparency problems (i.e., what if the data being transmitted contains XON or XOFF?). If everything is not exactly right, data will be lost. WA8DED's Host mode solves this problem by 1. Speaking only when spoken to, and 2. Limiting all data bursts to 256 bytes. The first point allows the computer program to go off and do other things (write data out to disk, handle the console, make coffee) without worrying about data coming from the TNC and dropping on the floor. The second point allows computers that have a hard time handling fast serial data (e.g., a Commodore 64 with no UART) to concentrate on the receiving task to fill a 256 byte buffer, then go off and process the data without worrying about additional data arriving before it has time to process that batch. This scheme is very forgiving of inefficient serial routines, so that faster computers can get away with simple byte-level polling (e.g., a program for the IBM PC can use the BIOS serial port routines). On the subject of serial routines, notice that the TNC does not handle either hardware or software flow control when in Host mode. You must make sure that your serial drivers will not send unwanted XON and XOFF characters to the TNC. Since the TNC speaks only when spoken to, the computer must constantly poll the TNC to find out what is happening on the link. In user mode, connected data received over the AX.25 link is immediately displayed (if that channel is selected). In Host mode, the TNC is not allowed to send information unsolicited, so the program must ask the TNC for data periodically. This implies that the computer-TNC link will be busy most of the time. Frequent polling and a relatively high baud rate (say 4800 or 9600 baud) are desirable for applications that require quick response times. A user monitoring data in real time will notice delays if the delay between polls is too great. 2 The format of these short computer-TNC exchanges is carefully specified to eliminate ambiguity and minimize overhead. The computer sends to the TNC in the following format: {channel}{info/cmd}{count}{data...} Channel is the channel number to which the transmission pertains. Info/cmd distinguishes between information to be transmitted and commands to be acted upon by the TNC. Count specifies the number of bytes to follow, and Data... are the actual data bytes or command bytes. The details of this format will be discussed later. All computer-to-TNC transmissions must follow this format. The TNC sends to the computer one of several different formats: {channel}{code=0} short format or {channel}{code=1-5}{data...}{0} null-terminated format or {channel}{code=6-7}{count}{data...} byte-count format] Notice that you can always tell what is to follow from the code received. The last format is very similar to the computer-to-TNC format. The details of these formats will be described later. All computer-to-TNC transmissions will follow one of these formats. 3 Chapter 2 Entering and Exiting Host Mode Host mode is entered by giving a JHOST 1 command to the TNC in the usual way. This sounds simple enough. Just send JHOST1 to the TNC. But what if something has already been sent to the TNC (say by powerup transients)? The will be treated as data (echoed as ^[ by the TNC) and the command will be lost. We can work around this by sending a ^U or ^X first, to clear the junk out. It might also be a good idea to send an XON, in case the junk included an XOFF. So we send ^Q^X^[JHOST1^M (or, if you prefer the ASCII mnemonics, JHOST1): 11 18 1B 4A 48 4F 53 54 31 0D ^Q ^X ^[ J H O S T 1 CR This will work every time, if the TNC is in user mode. If the TNC is in Host mode already, we should detect that fact and recover. Host mode recovery will be discussed later in this document. Exiting Host mode is a simple matter of sending a JHOST0 command to the TNC. The TNC will acknowledge the JHOST0 command in the usual Host-mode fashion before returning to user mode, so you can use your regular Host-mode transaction routine. Note that a QRES command issued in Host mode will dump you back into user mode. It does not acknowledge in Host-mode fashion before doing so. The Host mode parameter is not stored in NOVRAM, so it is not possible to "wake up" in Host mode. It is, however, possible to PERM other parameters from Host mode. 4 Chapter 3 Commanding the TNC OK, now that we're in Host mode, let's look at a simple command exchange. We will gloss over some of the details for this first look. Suppose we want to turn off Unattended mode. In normal user mode, we would type U0. That is, we would send a U0 command to the TNC. To send a U0 command in Host mode, we have to assemble a transmission for the TNC according to the computer-to-TNC format. Recall that the computer-to-TNC format is: {channel}{info/cmd}{count}{data...} The first byte, channel, is the channel number. In user mode, it doesn't matter what channel you are on when you give a U command. Likewise, in Host mode, it doesn't matter which channel you send this command to. Let's choose channel 0. The second byte is info/cmd; this is a command, so this byte has to be 1. The command data we are going to send is simply "U0", the same ASCII string we would have used between and to do the same thing in user mode. This is two bytes long, so the count byte should indicate two bytes. Count is encoded as (length - 1), so the third byte of the message should be 2 - 1 = 1. The following is an illustration of the required transmission. The top line lists the bytes to be sent in hex notation. The first byte sent is on the left. Below each byte of the top line is an explanation of that byte. This format will be used throughout this document to illustrate Host mode transmissions. 00 01 01 55 30 | | | U 0 | | | | | +-- Count = 1 (two bytes) | +----- Info/cmd = 1 (this is a command) +-------- Channel = 0 Note that no carriage return is required or allowed. As soon as the byte count is fulfilled (i.e., when the last byte has been received) the TNC accepts the transmission as complete. How do we know the TNC got the command OK? Simple: it responds with a status message. A U0 command can't fail, so we can guess that the status message will be a success message. A U0 command doesn't return any information, either, so no data field will be present. So, we can guess that the TNC will respond with a transmission in the short format: 00 00 | | | +--- Code = 0 (Success, no data follows) +------ Channel 0 Now we can see the general shape of any computer-TNC transaction: the 5 computer sends a command to the TNC, and the TNC responds with an appropriate message. In writing a program to interface with Host mode, we will have to take care of building these outgoing frames and interpreting the incoming frames. If we take a hint from WA8DED and W6IXU, we will implement a single routine that does the dirty work of sending a transmission and receiving the response. In receiving the response, the routine will have to decide how many characters to read from the serial port by looking at the code in the second byte of the TNC's message. This code tells it in which format the transmission will be: short format with no following data, null-terminated format with some data ending in a null, or byte-count format with a count and the specified number of bytes of information. Notice that the routine that receives the response doesn't have to have any knowledge of the current state of the TNC or the application program. The meaning and encoding of the TNC's response is completely determined by the data in that response. This simplifies the routine that receives the response by isolating it from the complexities of the application program. 6 Chapter 4 Polling the TNC: the G command The most essential, basic transaction in Host mode is the G command, which polls a specific channel of the TNC for events and data. A typical Host-mode application program will constantly send G commands to the TNC and interpret the responses. Since the G command is a query to a specific channel of the TNC, it is necessary to send G commands to all of the channels that may be in use. Data received from a station connected on channel 1 (or 2, or 3, or 4) will be sent to the computer as a response to a G command directed to channel 1 (or 2, or 3, or 4). Monitored data will be sent to the computer as a G command directed to channel 0. The G command has three forms. A command of "G" will return any of the possible responses that is available. A command of "G0" will return only information. A command of "G1" will return only link status responses. This is useful when you are waiting for a link status change and do not wish to handle data, or vice versa. The only other thing that changes in a G command is the channel number. Be sure to send G commands to all channels that may be active. You need not send G commands to channel 4 if Y is 3, for instance, but you must send G commands to channels 0 through 3. The unrestricted G command has the following format: 0x 01 00 47 | | | G | | | | | +--- Count = 0 (one byte of data) | +------ Info/cmd = 1 (this is a command) +--------- Channel = x (where x is 0, 1, 2, 3, or 4) There are only a few possible responses to a G command. If the program polls the TNC constantly with G commands, most of the replies will be "nothing available". This simply means nothing new has happened on the link since the last poll. This response applies to any of the three forms of the G command. Each of the other possible responses indicates an event on the AX.25 channel: a change in Link Status (such as "DISCONNECTED"), which is evoked by G or G1, or receipt of a frame of monitored or connected data, which is evoked by G or G0. The detailed formats of these responses will be discussed later in this document. Monitored information is handled specially by the G command. Monitored data is handled on channel 0 of the TNC. The monitor header is transmitted separately from the monitor information. The monitor header transmission indicates whether or not there is an associated information transmission to come. If there is, it will be the next response on channel 0. This scheme has two results: it spares the programmer the task of parsing out monitor information from the monitor header (if such is desired), and it keeps the maximum transmission length down to the maximum data field size, rather than the data field size plus the monitor header size (and thus allows the count to be a single byte). This scheme for monitored data might be considered a violation of the rule 7 that each computer-TNC transmission is self-contained and self-explanatory. The monitored information transmission is qualified by the immediately preceding monitor header transmission. You many want to treat a monitor header with information as a special case in the application program, and grab the corresponding monitor information transmission immediately. 8 Chapter 5 Details of Computer-to-TNC Format As we said before, the computer-to-TNC transmissions must always follow this format: {channel}{info/cmd}{count}{data...} The three header bytes (channel, info/cmd, and count) are expressed in binary. For instance, to specify 0 for any of these values, send a NULL (^@, '\0' for C fans, CHR$(0) for BASIC fans). DON'T send the ASCII character '0'. The data field will contain one of the following: 1. Data to be transmitted via the AX.25 link. 2. A command string just like you might issue from the normal user mode (the part strictly between the and the ). 3. "G", the Host-mode poll command. If data for the AX.25 link is to be sent, the info/cmd byte must be zero (binary zero, remember, not ASCII "0"). The data field may contain any bytes whatsoever, but not more than 256 of them. Count up the data bytes and subtract one to find the value of the count byte. So if you're connected to me on channel 2, and you want to say Hello to me, send the TNC this transmission: 02 00 05 48 65 6C 6C 6F 0D | | | H e l l o CR | | | | | | | +---- (this is a data byte) | | +- Count = 5 (six bytes of data) | +---- Info/cmd = 0 (this is information to be sent) +------- Channel = 2 (since I'm on your channel 2) Note that the CR is sent as data, and will be transmitted through the AX.25 link. It is not part of the transmission format. If the information is sent to channel 0, it will go out unproto to the address on channel 0 (default CQ). If information is sent on channel 1 - 4 while that channel is not connected, it is ignored. If a command string is to be sent, the info/cmd byte must be one. The data field should contain the ASCII command string. It does not contain or , just the characters that would go between them to form a normal user-mode command. For instance, to set TXDELAY to 30, send the TNC this transmission: 9 00 01 02 54 33 30 | | | T 3 0 | | | | | +- Count = 2 (three bytes of data) | +---- Info/cmd = 1 (this is a command) +------- Channel = 0 (doesn't matter here) The channel number is significant for the C, D, F, G, L, N, O, and V commands. C, D, F, N, O, and V commands are channel specific in exactly the same way as they are in user mode. The L command is different in Host mode, and will be discussed later in this document. The G command has already been discussed. The channel number is not significant for other commands. You may use whatever channel number is convenient. (WA8DED and W6IXU send these commands to channel 0). The byte-count format for the computer-to-TNC transmissions is used because it provides "data transparency". This means that any bytes whatsoever may appear in the data field. The TNC can just accept the next so many bytes from the computer without thinking about it. If a special character were used to signal the end of the data, that character could not occur in the data. The null-terminated format can use this scheme, since the data in these is guaranteed not to contain a null. Unfortunately, the byte-count scheme is not very robust. If a character is lost or a spurious character is inserted, the computer and TNC could stay out of synch forever. We must take pains to detect loss of synch and to recover from the fault. Fortunately, the first byte of a transmission has only five valid values (0-4) and the second byte has only two valid values (0 and 1), so it is possible to detect a loss of synchronization in most cases. Timeouts can also be used to detect synch failures. Once the error is detected, recovery is possible. Host mode recovery will be discussed later in this document. 10 Chapter 6 Details of TNC-to-Computer Format The TNC-to-computer transmission format is a bit more complicated than the computer-to-TNC format. The key to decoding a transmission from the TNC is the code byte that follows the channel number byte. The following table gives the code values: TNC-TO-COMPUTER CODES Code Meaning Format ==== ======= ====== 0 Success, nothing follows short format (Nothing available) 1 Success, message follows null-terminated format 2 Failure, message follows null-terminated format 3 Link status null-terminated format 4 Monitor header/no info null-terminated format 5 Monitor header/info null-terminated format 6 Monitor information byte-count format 7 Connected information byte-count format These various formats are used for different purposes. Codes 0, 1, and 2 are responses to an information or command transmission from the computer. If a batch of information was queued for transmission successfully or if a command completes successfully without returning any information, a code 0 transmission will be the reply: 02 00 | | | +---- Code = 1 (Success, nothing follows) +------- Channel = 2 (same as the info or command sent) If the command is successful and returns information (like any command without an argument), a code 1 transmission will be the reply. The returned data will follow the code, "null terminated". This just means that a 0 byte will appear after the last information byte. For example, consider an M command without an argument. In user mode, the user would type M, and the TNC would display something like * IUSCRT * In Host mode, the command would be 00 01 00 4D | | | M | | | | | +---- Count = 0 (one data byte) | +------- Info/cmd = 1 (this is a command) +---------- Channel = 0 (Doesn't matter here) and the response might be 11 00 01 49 55 53 43 52 54 00 | | I U S C R T | | | +---- Null termination | | | +---- Code = 1 (Success with info) +------- Channel = 0 (same as in the query) If the command failed, or the information cannot be queued for transmission, a code 2 transmission with one of these error messages will be the reply: FAILURE MESSAGES INVALID COMMAND TNC BUSY - LINE IGNORED CHANNEL ALREADY CONNECTED STATION ALREADY CONNECTED For example if you send a data line: 03 00 0C 48 65 6C 6C 6F 20 74 68 65 72 65 2E 0D | | | H e l l o t h e r e . CR | | | | | | | (this is a data byte) ----+ | | +---- Count = 12 (thirteen data bytes) | +------- Info/cmd = 0 (this is information) +---------- Channel = 3 (for instance) when the TNC has no RAM available to buffer the data line, it will respond with a code 2 failure message to inform you of the condition: 03 02 544C432042555359202D204C494C452049474C4F524544 00 | | T N C B U S Y - L I N E I G N O R E D | | | | | +---- Code = 2 (Failure) Null terminator ----+ +------ Channel = 3 (same as the info sent) If you send a bad command: 00 01 03 4A 55 4C 4B | | | J U N K | | | | | +---- Count = 3 (four data bytes) | +------- Info/cmd = 1 (this is a command) +---------- Channel = 0 (Doesn't matter here.) It will complain about it with a code 2 failure message: 00 02 49 4E 56 41 4C 49 44 20 43 4F 4D 4D 41 4E 44 00 | | I N V A L I D C O M M A N D | | | | | +---- Code = 2 (Failure) Null termination --+ +------- Channel = 0 (same as the command sent) 12 The remaining codes, 3 through 7, are used only as responses to a "G" poll command. A 0 code can also be a response to a G poll. A 0 code means that nothing is available for that channel: that is, no events worthy of notice have taken place on the channel polled. This is the most common response to a G command. 0x 00 | | | +---- Code = 0 (Nothing available) +------- Channel = x (same as the G command) A code of 3 signifies a Link Status message. These messages are: LINK STATUS MESSAGES ({n}) BUSY fm {call} via {digipeaters} ({n}) CONNECTED to {call} via {digipeaters} ({n}) LINK RESET fm {call} via {digipeaters} ({n}) LINK RESET to {call} via {digipeaters} ({n}) DISCONNECTED fm {call} via {digipeaters} ({n}) LINK FAILURE with {call} via {digipeaters} CONNECT REQUEST fm {call} via {digipeaters} ({n}) FRAME REJECT (x y z) fm {call} via {digipeaters} ({n}) FRAME REJECT (x y z) to {call} via {digipeaters} These messages should look familiar, since they are identical to the messages displayed by the TNC in user mode. {n} is the channel number. Notice that the channel number in the message is redundant information. The channel number may be omitted from this message in a future release. For instance, if I connect to you direct on channel 2, a poll of channel 2 (not necessarily the next one, depending on what else is going on) will return the event: 02 03 28322920434F4E4E454354454420746F204B42354D55 00 | | ( 2 ) C O N N E C T E D t o K B 5 M U | | | | | +---- Code = 3 (Link Status) Null termination --+ +------- Channel = 2 Codes of 4 and 5 both signify a monitor header. This is a null-terminated format message containing the fm {call} to {call} via {digipeaters} ctl {name} pid {hex} string that forms a monitor header. The monitor header is also identical to the monitor header displayed in user mode. If the code was 4, the monitored frame contained no information field, so the monitor header is all you get. If you monitor KB6C responding to a connect request from me and then poll channel 0, you'll get: 13 0004666D204B42364320746F204B42354D552063746C2055612070494420463000 | | f m K B 6 C t o K B 5 M U c t l U A p i d F 0 | | | | | +---- Code = 4 (Monitor, no info) Null termination ----+ +------- Channel = 0 (Monitor info is always on channel 0) If the code was 5, the monitored frame did contain an information field. In this case, another G command to channel 0 will return the monitored information with a code of 6. Since data transmissions must be transparent, the monitored information is passed as a byte-count format transmission. That is, it is preceded by a count byte (one less than the number of bytes in the field). No null terminator is used in this case. Since codes 4, 5, and 6 pertain to monitored information, they will be seen only on channel 0. If you hear KB6C say "Hi" to NK6K, and then poll channel 0, you'll get: 0005666D204B42364320746F204E4B364B2063746C204930302070494420463000 | | f m K B 6 C t o N K 6 K c t l I 0 0 p i d F 0 | | | | | | | | or whatever ----+-+ | | | | | +---- Code = 5 (Monitor, info follows) Null termination ----+ +------ Channel = 0 (Monitor info is always on channel 0) and then the very next poll to channel 0 will get: 00 06 02 48 69 0D | | | H i CR | | | | | | | +---- (this is a data byte) | | +---- Count = 2 (three bytes of data) | +------- Code = 6 (monitored information) +---------- Channel = 0 (Monitor info is always on channel 0) A code of 7 signifies connected information, so it will only be seen on a connected channel 1 through 4. It is a byte-count format transmission, for data transparency. If you're connected to me on channel 4 and I say "Hi", a poll of channel 4 will return: 04 07 02 48 69 0D | | | H i CR | | | | | | | +---- (this is a data byte) | | +---- Count = 2 (three bytes of data) | +------- Code = 7 (connected information) +---------- Channel = 4 (info was received on channel 4) 14 Chapter 7 Querying Channel Status: the L command One of the most powerful features of the Host mode is the ability to ask the TNC for a status report on a given channel. This report is similar to the report given by the L command in user mode, but more extensive. To obtain the Channel Status report, send an L command to the channel of interest. The TNC will (barring error) respond with a code 1 packet. The information field of this packet will contain six decimal number in ASCII delimited by spaces. A typical Channel Status query: 01 01 00 4C | | | L | | | | | +---- Count = 0 (one data byte) | +------- Info/cmd = 1 (this is a command) +---------- Channel = 1 (give me a report on channel 1) A typical Channel Status report: 01 01 30 20 30 20 30 20 30 20 30 20 30 00 | | 0 0 0 0 0 0 | | | | | | null termination ----+ | +------- Code = 1 (Success with info) +---------- Channel = 1 (this is a report on channel 1) Channel 0 does not have as much state information as a regular connectable channel, so a Channel Status query to channel 0: 00 01 00 4C | | | L | | | | | +---- Count = 0 (one data byte) | +------- Info/cmd = 1 (this is a command) +---------- Channel = 0 (give me a report on channel 0) Will return a Channel Status report similar to this one. 00 01 30 20 33 00 | | 0 3 | | | | | | +---- null termination | +------- Code = 1 (Success with info) +---------- Channel = 0 (this is a report on channel 0) The interpretation of the returned information is as follows: 15 CHANNEL STATUS FORMAT a b c d e f a = Number of link status messages not yet displayed b = Number of receive frames not yet displayed c = Number of send frames not yet transmitted d = Number of transmitted frames not yet acknowledged e = Number of tries on current operation f = Link state Possible link states are: 0 = Disconnected 1 = Link Setup 2 = Frame Reject 3 = Disconnect Request 4 = Information Transfer 5 = Reject Frame Sent 6 = Waiting Acknowledgement 7 = Device Busy 8 = Remote Device Busy 9 = Both Devices Busy 10 = Waiting Acknowledgement and Device Busy 11 = Waiting Acknowledgement and Remote Busy 12 = Waiting Acknowledgement and Both Devices Busy 13 = Reject Frame Sent and Device Busy 14 = Reject Frame Sent and Remote Busy 15 = Reject Frame Sent and Both Devices Busy NOTE 1: Only items a and b are displayed for channel 0. NOTE 2: Only states 0 - 4 are possible if version 1 is in use. How you will use the Channel Status report will depend on your application. An interactive terminal program might simply display some or all of the information and leave it at that. A mailbox program might want to wait for all packets to be acknowledged before starting a timeout timer or before disconnecting. A mail forwarder would want to make sure all data was acknowledged before considering its task done. Any program might want to give up if throughput is too low. These functions are easy to implement with Host mode. 16 Chapter 8 Host Mode Error Recovery What happens if something goes wrong on the computer-TNC link? Maybe there is a loose wire, or maybe RF got into the RS-232 lines. Maybe it's just Murphy. For whatever reason, the data on the line got corrupted. RS-232 links are very reliable, so you may never see an error, but the application program should be ready to cope with one. The error recovery program must assume that the TNC is in a completely unknown state. It might be expecting more bytes to fill a byte count (if bytes coming from the computer were lost). It might be simply waiting for a transmission, but the computer thought there was an error since data was lost or corrupted on its way from the TNC. What we want to do is hit the TNC with a stream of data that will eventually bring it into a known state. Preferably, this process should generate little or no spurious data on the AX.25 link. The first thing to do is dump any further data that may be coming from the TNC. We don't know what it is, and so we can't use it. The possibility exists that this is connected information we're dropping on the floor. This is just too bad. There is nothing we can do. Next, we just send ^A's one at a time until the TNC responds. The first few ^A's may go to fulfill a byte count that the TNC is waiting for. If this happens to be a connected information transmission, these ^A's will go out on the AX.25 link. Tough. When any outstanding byte count is fulfilled (no more than 256 should be required), the following five ^A's will be seen as a command on channel 1. This is why ^A is chosen: to make the TNC interpret the extra transmission as a command. 01 01 01 01 01 | | | ^A ^A | | | | | +-- Count of two bytes. | +----- This is a command. +-------- Channel #1. A command of "^A^A" doesn't mean anything, so the TNC should respond with a failure message: 01 02 49 4E 56 41 4C 49 44 20 43 4F 4D 4D 41 4E 44 00 | | I N V A L I D C O M M A N D | | | | | +---- Failure message. Null termination --+ +------- Same channel as the command specified We don't really care what the response is, though. It may not be exactly what we expect. For instance, the first ^A might fulfill the byte count of a garbled command. This would usually generate an error message of some other type. All we need is to get the first response. Then we know that the TNC is waiting for a command. This implies that we have to wait between ^A's long enough to see if there is 17 a response yet. This can make the recovery process a slow one. For instance, if the TNC spuriously receives 00 00 FF, it expects to see 256 data bytes following, so we will have to send 256 ^A's before we get a response (which will probably be a success message, since this is just a data transmission to the TNC). Fortunately, this error recovery process is not required very often. 18 Chapter 9 Acknowledgements and Comments Thanks are of course due to Ronald E. Raikes, WA8DED, for creating the WA8DED AX.25 Version 2 Multi-channel TNC Firmware, for writing SS, the split screen terminal emulator that takes advantage of Host mode, and for proofreading this document for accuracy. Thanks are also due to Mike Busch, W6IXU, for writing the mailbox software which was my first exposure to Host mode. Comments on this document would be appreciated. You can send them to me by packet (KB5MU KA6IQA on WestNet), by CompuServe (75265,367), by telephone (619-458-1238) or by mail: Paul T. Williamson, KB5MU 6583 Edmonton Ave. San Diego, CA 92122 Heck, you could even send an NTS radiogram. SS, the split screen terminal emulator, is an excellent example of Host-mode software. It is available for non-commercial, non-profit use. It runs on an IBM PC or moderately compatible, and provides connect status display continuously for all five TNC channels, a typing buffer, a transmitted data buffer, a receive buffer, and a Link Status line at the bottom of the screen. It is written in C for the Microsoft C Compiler version 3.0, with a trace of assembly language for interface to console services. I would be happy to send a copy of it to anyone who is interested and sends me a diskette with return postage at the above address. The W6IXU Mailbox software is not available for distribution at this time. It will become available for distribution by some means when it stabilizes and a suitable means of distribution is found. Table of Contents 1 What Is Host Mode? . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Entering and Exiting Host Mode . . . . . . . . . . . . . . . . . . . . 3 3 Commanding the TNC . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Polling the TNC: the G command . . . . . . . . . . . . . . . . . . . . 6 5 Details of Computer-to-TNC Format . . . . . . . . . . . . . . . . . . 8 6 Details of TNC-to-Computer Format . . . . . . . . . . . . . . . . . . 10 7 Querying Channel Status: the L command . . . . . . . . . . . . . . . . 14 8 Host Mode Error Recovery . . . . . . . . . . . . . . . . . . . . . . . 16 9 Acknowledgements and Comments . . . . . . . . . . . . . . . . . . . . 18 FAILNET-ORIGIN<[AI.AI.MIT.EDU].90444.860903>YN-!  h9sh9sh9 sh9s%h9s-h9s5h9s=h9sEh9"sMh9&sUh9*s]h9.seh92smh96suh9:s}h9>s -h9 hYh9h9@Hhy  kHhyHhyt` HR'{p 100 s,X09H8 1@p 'X (E` -`-8 1``*M'LO S12> *x%](/SHOW-QReceived: from DEEP-THOUGHT.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 SEP 86 10:31:24 EDT Date: Tue 2 Sep 86 10:27:16-EDT From: Shawn F. Mckay To: show-q@AI.AI.MIT.EDU Message-ID: <12235729080.13.M.SHAWN@DEEP-THOUGHT.MIT.EDU> ------- FAILM.SHAWN<[AI.AI.MIT.EDU].89966.860902>SHOW-Q"SHOW-Q" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS3;SHOW-Q MAIL".YN-!  33 33%3-353=3E"3M&3U*3].3e23m63u:3}>3  " 9@H9  YH9H9t` HRp~(800s,(XZ`0/HP@ p =` ` `G0$ .3*M'LO S12> *x%](/bundy%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UKSILVER@AI.AI.MIT.EDUReceived: from BRL-VGR.ARPA by AI.AI.MIT.EDU 2 Sep 86 10:02:04 EDT Received: from CS.UCL.AC.UK by VGR.BRL.ARPA id aa29906; 2 Sep 86 9:53 EDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a001057; 1 Sep 86 16:12 BST From: Alan Bundy Date: Mon, 1 Sep 86 16:14:40 -0100 Message-Id: <18797.8609011514@aiva.ed.ac.uk> To: bs30 <@Cs.Ucl.AC.UK,@RELAY.CS.NET:bs30@gte-labs.csnet>, silver <@Cs.Ucl.AC.UK:silver@AI.AI.MIT.EDU>, silver <@Cs.Ucl.AC.UK,@xx.lcs.mit.EDU:silver@mit-oz> Subject: from Fateman From fateman@edu.berkeley.dali Thu Aug 28 17:03:12 1986 Received: from uk.ac.ucl.cs by aiva.ed.ac.uk; Thu, 28 Aug 86 17:02:41 -0100 Received: from [128.32.0.13] by 44d.Cs.Ucl.AC.UK via Satnet with SMTP id a007223; 28 Aug 86 16:20 BST Received: by dali.Berkeley.EDU (5.53/1.16) id AA26067; Thu, 28 Aug 86 08:19:26 PDT Date: Thu, 28 Aug 86 08:19:26 PDT From: Richard Fateman Message-Id: <8608281519.AA26067@dali.Berkeley.EDU> To: bundy Subject: Re: O'Keefe's comments on Fateman's Status: RO thanks for passing this on to me. I shall definitely respond. Maybe we should send the correspondence in to the Sigsam Bulletin? (I'd only do it if we all agreed; we could all go over it again to make minor changes...) Now I have to prepare for class.. FAILNET-ORIGIN<[AI.AI.MIT.EDU].89957.860902>fYN-! C== ==&=.=6=>=F#=N'=V+=^/=f3=n7=v;=~?=   >@HTA :CVBTATA HR -pH|(0s,(X0 0H( h%x @ p a```packet-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 1 Sep 86 18:23:41 EDT Received: by EDDIE (5.31/4.7) id AA00931; Mon, 1 Sep 86 18:17:16 EDT Received: by EDDIE (5.31/4.7) id AA00924; Mon, 1 Sep 86 18:16:58 EDT Date: Mon, 1 Sep 1986 16:15 MDT Message-Id: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Hams@SIMTEL20.ARPA, packet-radio@MIT-EDDIE.ARPA Subject: Electronic Communication Privacy Act (S.2575) update The latest version of the Electronic Communication Privacy Act (S.2575), dated August 12, 1986, is now available from SIMTEL20, thanks to Bill Bogstad , who added them into the posting by Glenn Tenney. Filename Type Bytes CRC Directory PD: PRIVCY2.BILL.1 ASCII 75835 4E46H For those who can handle binary FTP transfers and unsqueeze: Directory PD: PRIVCY2.BQL.1 BINARY 45056 D16DH Reviewing: The Electronic Communications Privacy Act of 1986, which has passed the House, now is a bill in the Senate (S.2575). This one Act affects every usenet, bitnet, bbs, shortwave listener, TV viewer, etc. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA uucp: {ihnp4,allegra,cmcl2,decvax,mcnc,mcvax,vax135}!seismo!SIMTEL20.ARPA!w8sdz GEnie Mail: W8SDZ RCP/M Royal Oak: 313-759-6569 FAILW8SDZ Electronic Communication Privacy Act (S.2575) update<[AI.AI.MIT.EDU].89789.860901>YN-!  99 99%9-959=9E"9M&9U*9].9e29m69u:9}>9   <@H< 4 \H Date: 31 Aug 86 07:46:08 GMT Date-Received: 31 Aug 86 14:56:37 GMT Organization: Bell Communications Research, Inc Lines: 155 "Why Do We Even Need TNCs Anyway?" (or, "Attacking Yet Another Sacred Cow") Phil Karn, KA9Q Since the first days of amateur packet radio, special purpose single board computers known as Terminal Node Controllers (TNCs) have generally provided the necessary hardware and software. The original arguments for using TNCs instead of general purpose personal computers were as follows: 1. Packet radio protocol software is very specialized, requiring a nontrivial coding effort. With the limited resources available, doing it once for a single special-purpose hardware environment is less work. 2. It was assumed that packet radio would operate at channel speeds high enough to justify the use of a synchronous protocol such as HDLC. Since very few general purpose computers have HDLC hardware, it is usually necessary to modify them for packet radio. If a special-purpose single board computer were designed for the task, all necessary hardware (such as an HDLC controller) could be provided. However, I believe that changes in the personal computer industry, along with our own experiences in amateur packet radio, should cause us to reconsider the TNC approach. I offer the following observations and comments as food for thought: 1. Personal computer hardware is cheaper, more plentiful and far more powerful than it was five years ago. The mass marketing of machines such as the IBM PC (particularly its "clones") have generated strong economies of scale. The price/performance ratio of a machine depends very heavily on its popularity; "limited production" machines are inherently expensive. For example, IBM PC clone prices are rapidly decreasing toward TNC prices, with some "premium" TNCs (and NNCs) already costing more than "stripped" PC clones. It therefore seems reasonable to use "off the shelf" hardware whenever possible instead of designing our own. (Of course, it goes without saying that this also conserves a valuable resource -- those amateurs willing to contribute their hardware design talents. Maybe if they weren't so busy designing new TNCs and NNCs, one of them would spend time on a high speed modem instead. Ahem.) 2. Developments in "portable" higher level languages for system programming have made it practical even for operating systems to be written in these languages. They have displaced assembler for all but the very lowest level operations. High level languages make it possible to "port" a complete operating system from one type of machine to another with far less effort than rewriting the system from scratch in a different assembler language. In particular, the C language has gained enormous popularity after its introduction as the primary language of the UNIX Operating System. C compilers are now available for virtually every personal computer, and it is becoming the language of choice for amateur packet radio protocol work as well. This means that it is now much easier to support a wide variety of hardware in packet radio than it was in the embryonic days. 3. The original motivation for using synchronous HDLC (instead of a "byte stuffed" asynchronous protocol) was to allow operation at high speeds (9600 bps and up). Asynchronous operation at high speeds is impractical for the following reasons: a. High speed modems are generally synchronous, i.e., they provide their own clocks. This makes them difficult to use with asynchronous hardware. b. Direct Memory Access (DMA) is necessary, as it may be difficult or impossible for the CPU to keep up if it has to take an interrupt for each character. While DMA can be used when transmitting with asynchronous hardware, it generally cannot be used when receiving. HDLC controllers automatically recognize the flag ending a frame and therefore need interrupt the CPU only after the frame has been transferred to memory. With asynchronous controllers, however, there is no hardware "end-of-packet" indication indication to terminate the transfer. The CPU must examine each character anyway to find the end of a frame. However, the advantages of HDLC are essentially wasted at present. The de facto modem standard, the Bell 202, is asynchronous. Further, current TNCs are incapable of operation much above 9600 bps because they lack DMA capability. The one remaining advantage of HDLC, 20% less overhead because of the lack of start and stop bits, begins to pale in comparison to the opportunity cost of precluding the direct use of many inexpensive personal computers on slow speed packet radio. 3. The original "model" for amateur packet radio operation consisted of two terminals (DTEs) communicating across what looks like a telephone modem connection using "smart modems" (the TNCs). The TNC generally resembles a Packet Assembler/Disassembler (PAD) in common use on commercial X.25 networks. However, the most successful use of packet radio has been terminal/computer and computer/computer communications. The computers are generally packet bulletin board systems (PBBSes), used for electronic mail and bulletin dissemination. Unfortunately, the control and status "protocols" spoken between the TNC and DTE are invariably designed for humans, and it is very awkward for computer programs to use them. Matters are made even worse by the almost complete lack of standards in this area. Jeff Jacobsen, WA7MBL, reports that roughly half of the code in his system is there just to control the TNC and figure out what it's doing! The coupling between a connection-oriented transport protocol and its application is just too tight to be split easily between separate processors. It seems far simpler in the long run to merge the network protocol software with the application software, and run both on the host computer. This is especially true when the application must support multiple simultaneous users, since this greatly complicates an already unwieldy "TNC host-mode protocol". If a separate host and TNC must be used, the split should be made at a less complex level. For example, at the lowest level AX.25 is a datagram protocol. That is, the HDLC frames sent on the channel are completely self-contained, and there is much less state information that must be kept consistent on the two sides. If complete AX.25 frames are composed by the host and passed across the host/TNC link, then this interface is simplified enormously. This is the intent of my recent "Raw TNC" proposal. 4. "Internetworking" protocols now make it possible for computers using different link level protocols to interoperate, assuming they agree to speak a common set of internet and end-to-end protocols above them. This is a very powerful approach, since no one link protocol is optimal in every situation. One example of this in the non-amateur networking world is the choice between a shared bus and a token ring. A shared bus such as Ethernet has the advantages of simplicity, reliability and low cost, but it has an inherent distance limit. A token ring avoids this limit, but tends to be more expensive. Depending on the specific situation, one approach may be better than the other, but an internet protocol still allows these hosts to interoperate. A similar situation exists in amateur packet radio. Currently there is one "standard" link level protocol based on HDLC, but it requires relatively expensive hardware in comparison to an asynchronous packet protocol. With an internet protocol it becomes possible to choose from a variety of link level protocols, picking the best for the situation. Off-shelf personal computers could use a simple asynchronous protocol for slow speed operation yet remain interoperable (through an internet gateway) with stations using HDLC. This would also facilitate experimentation with new link protocols. Summary The "TNC approach" to packet radio should be examined in light of the computer hardware, software and protocol developments of the last several years. While the TNC is probably still best for the user with only a "dumb terminal", far more thought should be given to the increasingly common situation where a local computer is used. The use of an internetworking protocol (such as the ARPA protocol suite) allows the use of a wide variety of link level protocols while retaining the ability of all stations to intercommunicate; the choice of a link protocol becomes a local matter. In particular, IP allows the use of a very simple asynchronous packet protocol requiring only a modem and a radio in addition to a personal computer to operate on packet radio. This can make packet radio possible for many more users who, although they might already have a personal computer, cannot justify the expense of buying a TNC which cannot be used for anything other than packet radio. FAILNET-ORIGIN<[AI.AI.MIT.EDU].89716.860901>YN-!  I!II!I I!II!II!&II!.II!6II!>I#I!FI'I!NI+I!VI/I!^I3I!fI7I!nI;I!vI?I!~I 9I!  IaI!I!@HIah KIaIat` HR a-pH|(0s,(X 0cHX2 >x Xg@ p6 ]`9`9`packet-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 1 Sep 86 08:00:45 EDT Received: by EDDIE (5.31/4.7) id AA24227; Mon, 1 Sep 86 07:48:05 EDT Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site mit-eddie.MIT.EDU Path: mit-eddie!genrad!panda!husc6!seismo!columbia!caip!princeton!allegra!ulysses!bellcore!petrus!karn From: petrus!karn@EDDIE.MIT.EDU (Phil R. Karn) To: packet-radio@EDDIE.MIT.EDU Subject: Re: Network Addresses Message-Id: <288@petrus.UUCP> Date: 28 Aug 86 07:49:24 GMT Date-Received: 28 Aug 86 23:32:14 GMT References: <3019@mit-eddie.MIT.EDU> Organization: Bell Communications Research, Inc Lines: 21 A number of people have, at various times, proposed using grid squares for packet radio addresses. There are, however, some major problems: 1. Grid squares aren't very evenly distributed. in particular, they are most densely concentrated over the poles, places with remarkably few hams. If you are at all concerned about efficiency, this is a problem. 2. It is a mistake to assume that knowing the location of a station automatically tells you how to get there. For example, there may be a satellite "wormhole" between LA and Washington DC. It may very well be the case that a packet from Las Vegas NV to NY City should first go west, despite NYC being rather east of Las Vegas. Routing on the basis of grid squares would be very misleading here. You can assign your addresses in such a way that you can achieve good "compression" in storing your routing tables, but you must have at least the APPEARANCE of having a separate entry in each routing table for each destination. I wrote up such a scheme for doing this in the 4th ARRL Conference proceedings. Phil FAILpetrus!karn Re: Network Addresses<[AI.AI.MIT.EDU].89699.860901>fYN-E   %-5=E"M&U*].e2m6u:}>  2 @Hh  ?HHt` Hjbvb en weR&apH|(0s,(X` 0 H4 >x  @ p  &```vpacket-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 1 Sep 86 01:22:41 EDT Received: by EDDIE (5.31/4.7) id AA21849; Mon, 1 Sep 86 01:12:22 EDT Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site mit-eddie.MIT.EDU Path: mit-eddie!genrad!panda!husc6!seismo!gatech!akgua!lcuxlm!whuxl!houxm!ihnp4!ihlpg!retzner From: ihlpg!retzner@EDDIE.MIT.EDU (Retzner) To: packet-radio@EDDIE.MIT.EDU Subject: WA8DED Host Mode Message-Id: <2411@ihlpg.UUCP> Date: 27 Aug 86 14:31:26 GMT Date-Received: 28 Aug 86 18:28:08 GMT Distribution: net Organization: AT&T Bell Laboratories Lines: 19 I have finally gotten around to try and interface the WA8DED fimrware "host mode" to my computer. I'm sorry to say that the documentation does not really explain this very well about the host mode. Therefore, I have written some routines that allow me to exercise the host mode and it capabilities. Now for the problem. What I can't seem to do is connect to another station VIA a digipeater. It seems like the characters after the first callsign are ignored. The firmware gives a success response, it just ignores the digipeater call signs. Does anybody out there know what the magic cookie is for doing this? I've tried a few things, but nothing seems to work. Bill Retzner ihnp4!ihlpg!retzner FAILihlpg!retzner WA8DED Host Mode<[AI.AI.MIT.EDU].89640.860901>fYN-E   %-5=E"M&U*].e2m6u:}> M  @H * ?HHt` Hjbvb en weQz!CpH|(0s,(X 0?xh H LC @ xG }!`M`M`packet-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 31 Aug 86 10:17:39 EDT Received: by EDDIE (5.31/4.7) id AA16874; Sun, 31 Aug 86 10:02:54 EDT Received: by EDDIE (5.31/4.7) id AA16867; Sun, 31 Aug 86 10:02:47 EDT Return-Path: Received: from enea.UUCP by seismo.CSS.GOV with UUCP; Sun, 31 Aug 86 09:47:17 EDT Received: by enea.uucp (4.40/1.30-enea); Sun, 31 Aug 86 14:38:46 +0200 (MET) Received: by kuling.UUCP; Sun, 31 Aug 86 11:44:38 -0100 Message-Id: <8608311044.AA21679@kuling.UUCP> To: packet-radio@eddie.mit.edu Subject: TNC software Date: 31 Aug 86 11:44:35 N (Sun) From: Anders Klemets (Sorry if you have seen this twice, but I think it got lost the first time.) Is there anybody who can tell what the difference is between release 1.1.1 and the latest (1.1.3 ?) release of the TNC 2 firmware? I've a friend who has a Heathkit HD-4040. We have to switch to AX.25 version 1 to be able to use him as a digipeater. I understand that versions 3.x of the TNC 1 firmware doesn't have this problem. Is his HD-4040 compatible with TAPR software? If not, what should he do? And finally, what exactly is the "KE3Z multiport digipeater software"? I think there is a gateway between 144 and 432 MHz in Germany which operates just as a normal digipeater. You don't need to connect to it at all. 73 de SM0RGV -- klemets@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!klemets) Anders Klemets (SM0RGV), Sikvagen 51, S-135 41 Tyreso, Sweden Phone: +46 8 7124157 FAIL TNC softwareenea!kuling!klemets<[AI.AI.MIT.EDU].89503.860831>YN-!  }}z} }z }}z }}z}"}z}*}z}2}z}:}z!}B}z%}J}z)}R}z-}Z}z1}b}z5}j}z9}r}z=}z}z } 4 ~3}}@H~3 " s~3~3` HQj)\pH|(0s,(Xs` 0 hH  x P@ x u)```   %?o  0w0H,0 packet-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 29 Aug 86 10:35:08 EDT Received: by EDDIE (5.31/4.7) id AA20268; Fri, 29 Aug 86 10:29:05 EDT Received: by EDDIE (5.31/4.7) id AA20253; Fri, 29 Aug 86 10:28:18 EDT Message-Id: <8608291428.AA20253@EDDIE> Date: Fri, 29 Aug 86 10:22:39 EDT From: Bob Clements Subject: TNC2 v1.1.3 changes To: packet-radio@mit-eddie.arpa Cc: clements@ccq.bbn.com In response to: Message-Id: <8608282000.AA03377@kuling.UUCP> To: mit-eddie!packet-radio Cc: kuling!klemets Subject: TNC software Date: 28 Aug 86 21:00:00 N (Thu) From: Anders Klemets Is there anybody who can tell what the difference is between release 1.1.1 and the latest (1.1.3 ?) release of the TNC 2 firmware? 3139 PN 6324 K1BC W0RLI 860529 Via W0RLI: 710 From W0RLI Rcvd 860529/0016z, Sent 860529/0059z Via W0RLI: 1205 From W0RLI Rcvd 860528/2358z, Sent 860529/0014z C2987 CC262 Howard Goldstein (N2WX,2987) 3/22/86 11:24 AM L:43 KEYS:/RXBLOCK DOCUMENTED/FINALLY/ to: TNC 2 1.1.2a and .2b users fm: Howie Goldstein N2WX re: RXBLOCK provisional documentation dist: whomever has appropriate release One of the latest additions to the TNC 2 suite of commands is called RXBLOCK. The RXBLOCK feature should be a boon to folks who feel they've seemingly spent an entire lifetime installing brains in their drivers to discriminate between data units received and TNC-generated messages. INVOKING RXBLOCK: RXBLOCK mode is invoked by first turning the parameter "ON". Correct operation of RXBLOCK is dependant on the AWLEN parameter getting set to 8 (bits) since the character 0xFF marks the beginning of a recieved data unit header. NEW DATA UNIT FORMAT with RXBLOCK invoked: ------------------------------------------------------ | 0xFF | L0 | L1 | PID | data | ------------------------------------------------------ Fields defined: 0xFF ::= A character with all 8 bits set L0 ::= The high order length of the data, length, and PID fields logically ORed with the value 0xF0 L1 ::= The low order length of the data, length, and PID fields PID ::= The Protocol Identifier byte received for the following data field data ::= [Optional], variable length data NOTES: Suggest that parameters like AUTOLF, MFILTER etc. be set OFF in order to prevent uncertanties in the size of the data field. I have not played much with this feature and appreciate all comments and observations on any of it's characteristics. Howie - - - - - - - - - - - - - - - - - - - - N2973 NP4000 Howard Goldstein (N2WX,2987) 3/30/86 2:20 PM L:82 KEYS:/TNC 2 RELEASE 1.1.3/CHANGES FROM 1.1.2/ A: 3008 to: Lyle Johnson, WA7GXD fm: Howie Goldstein, N2WX re: Release 1.1.3 fixes, changes, additions, (i.e. changes from 1.1.2) dist: Whoever has 1.1.3 03/30/86 FIXES o- When AX25L2V2 is ON, the TNC now answers L2 UI frames with P and C set with either: RR if connected (regardless of rcvr flow control state), or DM if not connected. o- Path for SABM received while in link-setup state is not checked. This corrects earlier operation where a self-connect via an odd number of different digipeaters fails. o- T2 utilization corrected for the 2nd through nth link o- FULLDUP operation restored o- Channel capture during busy times improved o- NOMODE bug, where the 'connect mode' setting was not used on received SABMS has been corrected. This bug may have caused the TNC to enter a state where it seemed like the TNC died, when it actually was in TRANSparant mode. CHANGES in operation o- BEACONS not sent if BTEXT is null o- RESPTIME default now at 5; i.e. 500ms ADDITIONS o- RXBLOCK -- see earlier C2987 comment o- TNC "Health" feature group installed. HEALTH Features New COMMAND- HEALled ON/OFF default: OFF This new command allows the user to redefine the functions of the two CPU controllable LEDs (i.e. the STAtus and CONnect leds). When HEALLED is set ON, the two leds flash in a "wierd moving ball" pattern. At a glance, the user may make a judgement on whether the software has gone into never-never land, since the leds will probably not flash if the software fails catastrophically. With HEALLED set OFF, the leds function as before New COUNTERS- Fourteen counters have been added to TNC 2. All of them are 16 bits wide, and are ALWAYS initialized to 0000 on power up or "RESTART". o- ASYRXOVR: Increases when the software does not service the asynchronous receiver in time. Indicates data from the user to the TNC is being dropped. Report to TAPR if this error counter ever becomes non-zero under supported data rates. o- DIGISENT: Each frame digipeated by this TNC causes the counter to increase. o- HOVRERR: Increases when HDLC receiver is not serviced rapidly enough and data is lost. Report to TAPR if counter increments at any supported data rate. o- HUNDRERR: Increases when the HDLC transmitter is not serviced rapidly enough and frames are aborted. Report to TAPR if counter increments at any supported data rate. o- RCVDFRMR: Increases when Frame reject frames are received from a connected station. o- RCVDIFRA: Increases for each reception of an I frame from a connectee o- RCVDREJ: Increases for each reception of an REJect frame from a connectee o- RCVDSABM: Each received SABM frame addressed to the TNC causes this counter to be increased by one. o- RXCOUNT: Increases when any frame is received with good CRC (or any CRC if HGARBAGE is turned on) o- RXERRORS: Increments each time a received frame is thrown out due to it being too short, suffering overrun(s), or it having a bad CRC. Latter occurs only when CRC checking is enabled (i.e. HGARBAGE is OFF) o- SENTFRMR: Increments each time a Frame reject frame is transmitted o- SENTIFRA: Increases by one each time an I frame is sent o- SENTREJ: Whenever a REJect frame is transmitted, this counter is incremented. o- TXCOUNT: Incremented whenever a frame is correctly transmitted. NEW DISPLAY CLASS A new class, "HEALTH", has been added to the display command. Invoke with DISPLAY Health The counters just described, and the setting of HEALled are displayed in response to the health inquiry. --------------- 73 Howie FAILclements TNC2 v1.1.3 changes<[AI.AI.MIT.EDU].88986.860829> YN-!  ~~ ~~%~-~5~=~"E~&M~*U~.]~2e~6m~:u~>}~    ;@H;h {;;` HQib p  (,%?(XKh0HP@ p t8 x0 P8 !   %?P8o  P08w0H,P08 !H P 08%p~BP$'8#)\)  P(08'-0  P,58+g1X7  P008/50  P4C83&9DE P8I879=lK P<Q8;YAPS  P@W8?EPY  PD]8CMIP_JcXK( `5H%?PL0E8GP F  PO0H8NTI('PS0K8RIXxL PW8VQ\-P[8Z`,P_0R8^id S  Pc0U8bh0V(/Pg0W8fBl X%Pk8j%pD  Po8n)t9u(0Ps8r*y\  Px0a8w.}xb  P|8{2WP86 P0g8B (h P8F(P 0l8 QxmgP8e YP8q$h$P8z\  P0v8~!8w  P 8%&H{0's,X(( }P$!8#",#(0P+%8*10L'  P/+8.=4t-(P3382A85P7786Y<P9  P;=8:e@L?  P?C8>mD Eh!PC0#8B H0$2=PG0%8FIL& PK0(8JNP()5POS8NRT8U('PS0,8RX@-  PW_8VJ a[%?P\018Za`(2P_e8^dXg  Pc068bhp7 :Pgq8f&lHs  Pkw8jmpHy('Po}8n"t(Ps0@8rVxAPw0C8vZ|XD('P{8z( P8~AhP8\  P0M8:  N P 0P8 QXQ>P0T8xUhP8EAP0X89(YAP8> dP8B$ P#0]8"F(x^P'8&,0 P+0b8*08c P/0d8.4He P30f82]8(g0s,P786< 0i;%?P=0j8:A0kP@8?yE  PD8CaIl PH8GM2=PL8K6Q2=PP0u8O:Uv(PT0x8S>Yy(PX8WY](P\8[ a(P`0}8_-e0~(Pd08c1i((Ph8g5m  Pl8kJq Pp 8oNu  Pt08s^0x%?Py08wb} 0 P|0 8{v(  P8~ IP08F (P8nH!P #8 -<% P08U(/P08U`('P38q85P08}!h(P =8%8?(P$0!8#V)P"(P(0#8'r- $(P,I8+i K0%?P10&8/5('P4O83j9DQAP8U87=WgP<Y8;"A [gP@]8?&E_gPD008C*I 1 PH038G.M(4(PLi8KuQk(PP068O U(7$]PTo8SY$q$5PXs8WZ]u  P\w8[^ay  P`{8_be } Pd0?8cfi@ Ph8gRm0(Pl0C8k.qHD(Pp0E8ofu@F(Pt0G8sjyHH(Px0I8wJ|%?P}8{5)H P0L8nMP8r , 1P0P8vQ %?P8 z P0S8T0s,P8%?P0V8 WP8  %?P!0Y8%ZP$8#M (%?P)0\`'- `]P,8+]P00``/a3%?P482>8P70c86z0d;%?P<0e8:2@hxfP?8>~C%?PD0i8BH)H8jPG0k8FlK%?PL8JP )HPO0n8N"oS%?PT8R*X PW0q8V1 rP[P\x]0tP^0u8Z5va%?Pb8`=f Pe0x8dExyi%?Pj8hMn<Pm0}8lU~q%?Pr8p_vPu08tcPy8xk |%?P}08{s)DP 8z   1P08~`  ` `9`)(vP  ` !"#$EQV-L%TMRC-&rs@OZ'X-HAT(EQV-L)TWENE*ERS-A+TWENE,ERS-A-OZ.X-HAT/T-ITS0IST1ALAN2Bagle3XEROX4BJN5CSTAC6DANNY7DEVON8ERMES9FVE:R;GumbyJTW@S?KLH@KWH-PAMLYB@PREPCRAYDSAJ@PESUNDAFMESGTKHPI;HATEJEX]KUSERLIONMISTNISTOACCOUPUSER-QIONRISTSISTTACCOUUUSER-VR-OPTWSHOWLXEQV-LYUSER-ZNTS[ACCOU\R-OPT]SHOWL^EQV-L_USER-`NTSaACCOUbEQV-LcUSER-dNTS-AeEfYgDANIEhGumbyiPGSjZvonakNTS-HlEFUSEmEQV-LnUSER-oNTS-ApEqPGSrLsZVONAtACCOUuRCHIVvEQV-LwUSER-xEyA-FILzEQV-L{FILE|NT;US}OUNT]~ACCOUTIFINIST[ACOUCHIV ]DER-FNULLPGSL FILE * ION STIST*MSG*MITIONSTIST*EE*CIPG*XV*MSG*MSG*MSG*MACIONSTIST*XX*OZTEX@ardec-lcss.arpa:beck@clstr1.decnetCUBE-LOVERS@ai.AI.MIT.EDUReceived: from ARDEC-LCSS.ARPA.ARPA by AI.AI.MIT.EDU 29 Aug 86 08:02:18 EDT Date: 29 Aug 86 07:54:00 EST From: "CLSTR1::BECK" Subject: globe puzzle To: "cube-lovers" Reply-To: "CLSTR1::BECK" GLOBE PUZZLE - I made a mistake. The "Globe Puzzle" is NOT a cube. It looks like a cube with the edge pieces broken up into its two faces but the corners are fixed and only the three equators are free to move. It has a metal surface painted as a globe and each surface area has a dimple. These dimples do not make it any easier to work the puzzle. It is the same 3" diameter as a cube ballThe puzzle is made in Hungary. Thus the globe puzzle is three intersecting rings and appears to be simpler then the cube. If the corners could move like the cube would that puzzle also be no more difficult then the cube? Any ideas on how to engineer such a puzzle? AVAILABLE from: the nature company pob 2310 berkley, ca 94702 800/227-1114 globe puzzle, cat # 1449, $12.50 peter beck ------ FAILNET-ORIGIN<[AI.AI.MIT.EDU].88957.860829>RFC733[ALAN;CUBE MAIL]FILENOSHOW@FILE[ALAN;CUBE PEOPLE]FILENOSHOWbeckNOSHOWdragonNOSHOWarpalistsNOSHOWThomas.MathiesNOSHOWREMARCK%UCLASSCF.BITNETNOSHOWJJL8733%RITVAXA.BITNETNOSHOWAMATHSC%WYOCDC1.BITNETNOSHOWGOOSSENS%CERNVM.BITNETNOSHOW8440827%wwu.csnetNOSHOWdnichols%tilde%ti-csl.csnetNOSHOWC0144%CSUOHIO.BITNETNOSHOWJIMR%CLARGRAD.BITNETNOSHOWENEA!KULING!STARBACKSEISMOENEA!KULING!STARBACK"ENEA!KULING!STARBACK" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERSNOSHOWM70S%CBEBDA3T.BITNETNOSHOWhart%taurus.BitNetNOSHOWkgk%brown.csnetNOSHOWsvozzaNOSHOWM14051%mwvmNOSHOWCN0001ER%UKCC.BITNETNOSHOWHaddenNOSHOWBK0HNOSHOWAAPH332%UA.BITNETNOSHOWjethro%vaxNOSHOWFCTY7098%RYERSON.BITNETNOSHOWTONY%SER.BITNETNOSHOWceolsonNOSHOWariceNOSHOWchapman_sys%uta.csnetNOSHOWloebNOSHOWISI-CUBE-LOVERSNOSHOWc-youngNOSHOWmcclimansNOSHOWesc1040%DDAESA10.BITNETNOSHOWU213002%HNYKUN11.BITNETNOSHOWRIOLOARDC.ARPARIOLO"RIOLO" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS Will try sending to the file "USERS3;RIOLO MAIL".NOSHOWthayerNOSHOWCCRJW%UMCVMB.BITNETNOSHOWRandall_Shane%RPI-MTS.MailnetNOSHOWmcneilNOSHOW#d2f%ddathd21.BITNETNOSHOWGOET%HWALHW5.BITNETNOSHOWpesNOSHOWalattoNOSHOWcube-lovers-usersNOSHOWsteveNOSHOWmwm%ucbjade.CCNOSHOWVUYAACOV%WEIZMANN.BITNETNOSHOWELINOSHOWliangNOSHOWF33PAP%DHHDESY3.BITNETNOSHOWots!cubeloversNOSHOWcube%wisdom.bitnetNOSHOWhplabs!oliveb!longNOSHOWSTARKNOSHOWcube-lovers-newsNOSHOWsun!artibeeNOSHOWmfrishkopfNOSHOWhaynesNOSHOWeng20201%BostonU.BITNETNOSHOWcube-lovers-incomingNOSHOWgenrad!decvax!dartvax!andybNOSHOWbbd-cube-loversNOSHOWkelemNOSHOWCLINENOSHOWmeisterNOSHOWRonNOSHOWuci-cube-loversNOSHOWsilver.emoryNOSHOWbts.uncNOSHOWbad.BrownNOSHOWREHMINOSHOWCAKPURDUENOSHOWcak@mNOSHOWCLEMENTSNOSHOWCUBE-LOVERS-INCOMING%TI-CSLNOSHOWcosellNOSHOWdmNOSHOWXeroxCubeLovers^.PANOSHOWleeNOSHOWLoomisNOSHOWJKNOXNOSHOWKornerNOSHOWCliveNOSHOWkorfhageNOSHOWbersonNOSHOWurbanNOSHOWLAURENNOSHOWLauren@RANNOSHOWWRINGNOSHOWOLENOSHOWHSSNOSHOWBBOARD-Cube-LoversNOSHOWStillman.JosephNOSHOWVaughanW.REFLECSNOSHOWPUCC=6000525NOSHOWDavid.AndersonNOSHOWKevin.DowlingNOSHOWMichael.FosterNOSHOWBob.WalkerNOSHOWAGINNOSHOWGLSNOSHOWgls@tNOSHOWLOCAL-CUBE-LOVERSNOSHOWFEATHERNOSHOWHOROWITZNOSHOWKATZNOSHOWlejm%UK.AC.EDINBURGHNOSHOWDDyerNOSHOWHirshNOSHOWcowerNOSHOWPatashnikNOSHOWRestivoNOSHOWBroderNOSHOWTRDNOSHOWJEBNOSHOWNemnich-junkNOSHOWPCO-distyNOSHOWSchaubleNOSHOWRHarvey.mNOSHOWBSGNOSHOWbsg@sNOSHOWSWGNOSHOWG.MenagerieNOSHOWCELNOSHOWcel@xNOSHOWCMBNOSHOWNJASNOSHOWNJASNOSHOWZIMNOSHOWZIMNOSHOWTRBNOSHOWmasscomp!trb@CCNOSHOWYEKTANOSHOWRPNOSHOWRPNOSHOWJURGENNOSHOWcallas%star.decNOSHOWDUFTYNOSHOWdoughty@scNOSHOWDCPNOSHOWDCPNOSHOWAMONOSHOWAMONOSHOWALANNO-CLINOQCRFC733NOSHOWPDLNOSHOWPDLNOSHOWFONER-MAGAZINESNOSHOWFONER-MAGAZINESNOSHOWGAINOSHOWx.gaiNOSHOWEDNOSHOWACWNOSHOWacw@sNOSHOWPAONOSHOWHost appears to be permanently down or not accepting mail. YN-!  ,,;,,;, ,;,,;&,,;.,,;6,,;>,,;F,#,;N,',;V,+,;^,/,;f,3,;n,7,;v,;,;~,?,; ,$ 2=,,@H2=lt 6]H2=H2=` HQ.Up (,3(X?0 kH8 x pm@ x M.8#x@P0u8(vH3P0y8u z  P8}H,P8#$ P"8! '8~BP&08% +8  P* 8)/X   P.08-m30   P281$7X  P6085,; P:089??X P>08=_C   PB08AG   PF08EOK L0XM(pEJ3PNe8IRPg  PQk8PVHm('PUq8TOZ<s PY0;8XW^0<-P]0=8\bX>Pa8`kfP  Pe8dj(/Pi8hDn%Pm0F8l'rG  Pq0I8p+v9w0J(0Pu0K8t,{8L  Pz8y0<  P~0Q8}48RWP0S88(T P8D T P 0X8 H Y(P8S<gP0\8g8] YP0^8sH_h$P0`8|8a  P8#\  P"0g8! '(h($0)s,X*(P&0~8%$.0(0P-08,32  P1080?6h(P5084C:0P90 88[>    P=0 8<gB  PA08@oFh!PE!8D J#2=PI%8HKND' PM+8LPR-5PQ08PTVp('PU38TZ`5  PY08XP]3P^=8\cb?Pa0 8`f0!  PeG8d$j8I :Pi0&8h(n'  Pm0)8lor*('Pq0,8p$v(-(Pu[8t\z@]Pya8x`~,c('P}038|P4 P058G06hP078 88  P u8@Pw P{8 Sl}P8<hP0D8G(EAP8;AP0G8D"8HdP!0I8 H&JP%8$L*<P)0M8(.`N P-8,2 P1806$ P584_:0s,P90U88>V=3P?8<C0 PB0Y8A{G@Z PF0[8EcKX\ PJ0_8I O0`2=PN0a8M<Sb2=PR8Q<WL(PV8U@[ (PZ0g8Y[_0h(P^0i8] c(j(Pb8a/g(Pf8e3k(Pj0n8i7o@o Pn0p8mLs0q Pr0r8qTw(s Pv8udz3P{8yh P~8}x P0y8zIP8H (P 0|8 pH}(P0~8!P08Wx P8W@ (/P 8s0('P0 8#p P"8! '4(P&08%X+p(P*!8)t/(#(P.%8-k3'(P208163P7+85l;( -P:089?AP>08=(C8gPB08A,G@gPF08E0K gPJ?8I4OPA PNE8MwSG(PR0$8Q W(%(PVK8U[M$]PZ0'8Y_H($5P^0)8]\c8*  Pb0+8a`g0,  Pf0-8edk. Pj]8iho _ Pn008mXs`1(Pre8q4w$g(Pvi8ul{ k(Pzm8yp$o(P~q8} s3P0:87)H;Pw8t yP 0=8 xX> 1P8| 3P0A8BP8 0s,P0D8 E3P8#P"0G8!H&3P'8%+ P*0J8)OK.3P/`-3 0P20N81_(OP6`593P:0Q88@>RP=8<|A3PB8@8Fh<PE0W8D(XI3PJ8HN)HPM8L Q3PR0\8P V])HPU8T( Y3PZ0_8X0^`P]8\7Pa0bPb cxcPd8`; g3Ph0f8fClgPk8jK<o3Pp0j8nStxkPs8r[ w3Px0n8ve|(oP{8ziP0q8~qr3P8y)D P0t8 u 1P 8 ` ``;L`+L(/ `(x ` !"#$%&'()*+,-.KLH/KWH-P0MLY1@PREP2RAY3SAJ@P4SUNDA5MES6TK7P8;HATE9EX]:USER;IONACCOU?USER-@IONAISTBISTCACCOUDUSER-ER-OPTFSHOWLGEQV-LHUSER-INTSJACCOUKR-OPTLSHOWLMEQV-LNUSER-ONTSPACCOUQEQV-LRUSER-SNTS-ATEUYVDANIEWGumbyXPGSYZvonaZNTS-H[EFUSE\EQV-L]USER-^NTS-A_E`PGSaLbZVONAcACCOUdRCHIVeEQV-LfUSER-gEhA-FILiEQV-LjFILEkNT;USlOUNT]mACCOUnOTIFIoNpISTq[ACOUrCHIV s]tDER-FuNULLvPGSwLxFILEy*zION{ST|IST}*MSG~*MITONSTIST*EE*CIPG*XV*MSG*MSG*MSG*MAC ION ST IST *XX*OZTEXTHICSNA*MSG*MSG*MSG*MSG*MSG*MSG*ITSIONSTISTBBITSXXgmazzarel%h-sc4@harvard.HARVARD.EDUCUBE-LOVERS@mit-ai.arpaReceived: from harvard.HARVARD.EDU by AI.AI.MIT.EDU 19 Aug 86 10:45:41 EDT Received: by harvard.HARVARD.EDU; Tue, 19 Aug 86 10:44:51 EDT Date: Tue, 19 Aug 86 10:44:51 EDT Received: by h-sc4.HARVARD.EDU; Tue, 19 Aug 86 10:44:36 edt From: mazzarel%h-sc4@harvard.HARVARD.EDU To: cube-lovers@mit-ai.arpa Subject: Paraphernalia I bought a book about four years ago in Boston that had procedures for generating all sorts of patterns on the 3x3 cube. I think it was about five to ten 8-1/2 x 11" pieces of paper folded in half and stapled to form a book. The cover was blue paper. Unfortunately, I lost it moving about half a year after that. By that time I guess interest in the cube was waning; I have not been able to find another copy. If anyone else has a copy or just knows where to find them, could you please post it to this newsgroup? I thought it was quite a find, and think no cube lover should be without one. --Paul (pm@harvard.HARVARD.EDU) FAILmazzarel%h-sc4 Paraphernalia<[AI.AI.MIT.EDU].85445.860819>RFC733[ALAN;CUBE MAIL]FILENOSHOW@FILE[ALAN;CUBE PEOPLE]FILENOSHOWbeckNOSHOWdragonNOSHOWarpalistsNOSHOWThomas.MathiesNOSHOWREMARCK%UCLASSCF.BITNETNOSHOWJJL8733%RITVAXA.BITNETNOSHOWAMATHSC%WYOCDC1.BITNETNOSHOWGOOSSENS%CERNVM.BITNETNOSHOW8440827%wwu.csnetNOSHOWdnichols%tilde%ti-csl.csnetNOSHOWC0144%CSUOHIO.BITNETNOSHOWJIMR%CLARGRAD.BITNETNOSHOWENEA!KULING!STARBACKSEISMOENEA!KULING!STARBACK"ENEA!KULING!STARBACK" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERSNOSHOWM70S%CBEBDA3T.BITNETNOSHOWhart%taurus.BitNetNOSHOWkgk%brown.csnetNOSHOWsvozzaNOSHOWM14051%mwvmNOSHOWCN0001ER%UKCC.BITNETNOSHOWHaddenNOSHOWBK0HNOSHOWAAPH332%UA.BITNETNOSHOWjethro%vaxNOSHOWFCTY7098%RYERSON.BITNETNOSHOWTONY%SER.BITNETNOSHOWceolsonNOSHOWariceNOSHOWchapman_sys%uta.csnetNOSHOWloebNOSHOWISI-CUBE-LOVERSNOSHOWc-youngNOSHOWmcclimansNOSHOWesc1040%DDAESA10.BITNETNOSHOWU213002%HNYKUN11.BITNETNOSHOWRIOLOARDC.ARPARIOLO"RIOLO" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS Will try sending to the file "USERS3;RIOLO MAIL".NOSHOWthayerNOSHOWCCRJW%UMCVMB.BITNETNOSHOWRandall_Shane%RPI-MTS.MailnetNOSHOWmcneilNOSHOW#d2f%ddathd21.BITNETNOSHOWGOET%HWALHW5.BITNETNOSHOWpesNOSHOWalattoNOSHOWcube-lovers-usersNOSHOWsteveNOSHOWmwm%ucbjade.CCNOSHOWVUYAACOV%WEIZMANN.BITNETNOSHOWELINOSHOWliangNOSHOWF33PAP%DHHDESY3.BITNETNOSHOWots!cubeloversNOSHOWcube%wisdom.bitnetNOSHOWhplabs!oliveb!longNOSHOWSTARKNOSHOWcube-lovers-newsNOSHOWsun!artibeeNOSHOWmfrishkopfNOSHOWhaynesNOSHOWeng20201%BostonU.BITNETNOSHOWcube-lovers-incomingNOSHOWgenrad!decvax!dartvax!andybNOSHOWbbd-cube-loversNOSHOWkelemNOSHOWCLINENOSHOWmeisterNOSHOWRonNOSHOWuci-cube-loversNOSHOWsilver.emoryNOSHOWbts.uncNOSHOWbad.BrownNOSHOWREHMINOSHOWCAKPURDUENOSHOWcak@mNOSHOWCLEMENTSNOSHOWCUBE-LOVERS-INCOMING%TI-CSLNOSHOWcosellNOSHOWdmNOSHOWXeroxCubeLovers^.PANOSHOWleeNOSHOWLoomisNOSHOWJKNOXNOSHOWKornerNOSHOWCliveNOSHOWkorfhageNOSHOWbersonNOSHOWurbanNOSHOWLAURENNOSHOWLauren@RANNOSHOWWRINGNOSHOWOLENOSHOWHSSNOSHOWMilunovicNOSHOWBBOARD-Cube-LoversNOSHOWStillman.JosephNOSHOWVaughanW.REFLECSNOSHOWPUCC=6000525NOSHOWDavid.AndersonNOSHOWKevin.DowlingNOSHOWMichael.FosterNOSHOWBob.WalkerNOSHOWAGINNOSHOWGLSNOSHOWgls@tNOSHOWLOCAL-CUBE-LOVERSNOSHOWFEATHERNOSHOWHOROWITZNOSHOWKATZNOSHOWlejm%UK.AC.EDINBURGHNOSHOWDDyerNOSHOWHirshNOSHOWcowerNOSHOWPatashnikNOSHOWRestivoNOSHOWBroderNOSHOWTRDNOSHOWJEBNOSHOWNemnich-junkNOSHOWPCO-distyNOSHOWSchaubleNOSHOWRHarvey.mNOSHOWBSGNOSHOWbsg@sNOSHOWSWGNOSHOWG.MenagerieNOSHOWCELNOSHOWcel@xNOSHOWCMBNOSHOWNJASNOSHOWNJASNOSHOWZIMNOSHOWZIMNOSHOWTRBNOSHOWmasscomp!trb@CCNOSHOWYEKTANOSHOWRPNOSHOWRPNOSHOWJURGENNOSHOWcallas%star.decNOSHOWDUFTYNOSHOWdoughty@scNOSHOWDCPNOSHOWDCPNOSHOWAMONOSHOWAMONOSHOWALANNO-CLINOQCRFC733NOSHOWPDLNOSHOWPDLNOSHOWFONER-MAGAZINESNOSHOWFONER-MAGAZINESNOSHOWGAINOSHOWx.gaiNOSHOWEDNOSHOWACWNOSHOWacw@sNOSHOWPAONOSHOWRecipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "thayer@HUEY.UDEL.EDU"}Host appears to be permanently down or not accepting mail.YN-!  cc cc&c.c6c>c#Fc'Nc+Vc/^c3fc7nc;vc?~c $ @H$  E` HQrpH|(0s,(XN 0H@z x ({@ x A``` packet-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 16 Aug 86 10:07:46 EDT Received: by EDDIE (5.31/4.7) id AA27122; Sat, 16 Aug 86 10:04:18 EDT Received: by EDDIE (5.31/4.7) id AA27103; Sat, 16 Aug 86 10:03:26 EDT Resent-Message-Id: <8608161403.AA27103@EDDIE> Date: Thursday, 14 August 1986 11:20-MDT Message-Id: Sender: Bob Clements From: Bob Clements To: w8sdz@SIMTEL20.ARPA Subject: Version 11.7 of W0RLI Packet Radio Mailbox/Gateway Resent-From: KPETERSEN@SIMTEL20.ARPA Resent-To: packet-radio@MIT-EDDIE, Info-Hams@SIMTEL20 Resent-Date: Sat 16 Aug 1986 08:02-MDT Version 11.7 of the W0RLI MailBox/Gateway has been released and is now available from SIMTEL20 as: Filename Type Bytes CRC Directory PD: PACKT117.ARC.1 BINARY 212704 0B69H This release is being distributed in ARC format because of the more efficient packing methods available. You can extract the files on your CP/M system using one of the following: Directory PD: UNARC.COM-Z80.1 BINARY 4096 C209H <--Z80 version UNARCA.COM-8080.1 BINARY 4736 DF9BH <--8080 version The changes since the last such posting, version 11.2, are summarized below in an extract from the CHANGES.TNC file. For those who have not seen this system before, a brief description: The W0RLI MailBox and GateWay is a system which runs on a Xerox 820 computer and which operates on Amateur Packet Radio via one or two TAPR TNCs (or clones). It also runs with TNC-2s. The W0RLI system is running at over 75 sites in some number of countries and makes up the majority of the packet mail forwarding system. It is also used for gatewaying between local packet areas and long haul links on HF, or to nearby nets on other VHF/UHF bands. For a more complete description, see NOTES.TNC. Hank is not on ARPANET or Usenet. I will be glad to relay comments and questions to him. However, he is also in the process of moving from W1-land to W6-land, so contact is not as solid as it has been. Also, he won't be doing much coding on this system for a while, for the same reason. If you would prefer to get this distribution on ready-to-run disks for your Xerox 820, send a self-addressed stamped 8" SSSD disk (in re-usable mailer) to K7PYK at the address below. Two disks if you want the sources as well. I will do the same under the same conditions. I am good in the Callbook. NOTE - Hank is no longer doing distributions himself. Wes, K7PYK, has kindly volunteered to take over that job. Please do NOT send disks to Hank. 73, Bob, K1BC ARPANET: CLEMENTS@BBN.COM Usenet: {ihnp4, decvax, linus, ...}!bbnccv!clements Packet: K1BC @ K1BC 145.09 and 221.11, near Boston [Extract of NOTES.TNC follows] W0RLI MailBox and GateWay Version 11.7 - 6/22/86 Page 1 Created for packet community by: Hank Oredson, W0RLI 19 North Hill Road Westford, MA 01886 Distributed by: Wes Morris, k7pyk 7422 E. McKinley St. Scottsdale, AZ 85257 Many people contibuted to this project, in many ways. In particular I would like to thank K1BC, KE1G, WB2MNF, W3IWI, WB7DCH K3RLI, KE3Z, K7PYK for their help and encouragment. These notes are rough, more release notes and tech notes than anything else. A SYSOPS Manual (Very nice, 40+ pages) is also available from Wes. It was written by Jon Pearce, WB2MNF. [Extract of CHANGES.TNC follows] W0RLI MailBox and GateWay Version 11.7 Changes and additions since version 11.6 are: Added 3 second delay between connect and sending "*** LINKED ..." Changes and additions since version 11.5 are: Added FL (File Local users) and FB (File BBS). Tag in config to enable/disable retention of "F" msgs on forward. Cleaned up the handling of tnc state changes with MailBox state changes. Changes and additions since version 11.4 are: Login procedure split from TNC.MAC into LOGIN.MAC Logic changed to allow local users to connect if "only bbs" flag set. If station connecting is a bbs: bypass # digi check, exclude checks. New tag in config to exclude connects thru digi with illegal call. Changes from k1bc (Thank you Bob ...) : LM now lists messages TO and FROM user. Changes and additions since version 11.3 are: Changes from k3rli (Thank you Ed ... ) : Help and Info files may be $sys. WN command for users. Message type "F" is never killed after forward, only marked. "Expert user" flag. No logoff message, short prompt. Changes and additions since version 11.2 are: BIOS common code now in files BIOS????.INC Attempt to upload existing file got error msg twice. Added EU with no argument prompt through all users for delete. Added K4NTA code to handle forwarding through a GATOR 2 PAD. Made UA available to remote sysop. [End of extracts] FAILclements Version 11.7 of W0RLI Packet Radio Mailbox/Gateway<[AI.AI.MIT.EDU].84398.860816> YN-!  2e 2e2 e2 e#2e+2e32e;2eC2!eK2%eS2)e[2-ec21ek25es29e{2=e  ,:2u R22@HR$0 rHRHR` HPsSpYO(0,(X 0qH09 YOx  :@ p< 9!8#x0?@ BP8D FP8p  P0H8x0IH,P0J8 #HK P"0L8!'pM~BP&8%+\  P*0R8)/0S  P.8-h3X  P20Y8170Z  P685';D P:89:?l P>8=ZCP  PB8AGP  PF8EOKPLXM( `pJPN08IR   PQ08PV('PU08TJZx PY8XR^-P]8\b,Pa08`kf   Pe08d(j0(/Pi08h?n %Pm'8l'rD)  Pq-8p+v9w/(0Pu18t,{\3  Pz08y0x  P~=8}4?WPA88C P0"8D (# P K8 HM(P0'8Sx(gPS8gU YPW8s$Yh$P[8|\]  P018#82  P"i8! 'k(H60)s,X*( 8P&8%$.(0P-8,32L  P180?6t(P584C:P988[>P  P=8<gBL  PA8@oF h!PE0^8D J0_2=PI0`8HKNa PM0c8LKR(d5PQ8POV8('PU0g8T$Z@h  PY8XK ]P^0l8\cb(mPa8`fX  Pe0q8djpr :Pi8h(nH  Pm8lorH('Pq8p$v(Pu0{8tWz|Py0~8x[~X('P}8|( P8BhP 8 \   P 08;   P0 8 SX P08xhP#8G%AP08;(AP)8?"+dP!-8 C& /P%08$G*xP)58(.07 P-08,28 P10806H  P50!84_:("0s,P9E88> G0P=0$8<B@% PA0&8@{FX' PE0*8DcJ0+2=PI0,8H N-2=PM[8L7RL](PQa8P<V c(PU028T@Z03(PY048X[^(5(P]k8\ bm(Pao8`/fq(Pe098d3j@: Pi0;8h7n0< Pm0=8lGr(> Pq}8pOuPv8t_z Py8xc~ P}0D8|sEIP8{ (P0G8C HH(P 0I8kJ!P0L8 /xM P8W@(/P8W0('P0T8spUP8"4(P!0Y8 &pZ(P%8$S*((P)8(o.(P-0_8,k`1P2806( P50b84g:cAP90e88>8fgP=0g8<#B@hgPA0i8@'F jgPE8D+JP PI8H/N(PM0o8LwR(p(PQ8PV$]PU0r8T ZHs$5PY0t8X^8u  P]0v8\Wb0w  Pa0x8`[fy Pe8d_j  Pi0{8hcn`|(Pm8lSr$(Pq8p/v (Pu8tgz$(Py8xk  }P~08|)HP 87 P08o X  1P 8s P0 8 wP8{ 0s,P08 P!8#P08!P"'8 & )P%08$)P*-8(O. 0/P-0`,(P1580_74P50`39P8;87w=<P=?8;3Ah<AP@0"8?(#DPEG8CI)HIPHK8G MLPM0'8KQ()HPPQ8O# STPU0*8S+Y+PXW8W2YP\0-P] .x^]P__8[6 abPc018a>g2Pfe8eF<gjPk058iNox6Pno8mV qrPs098q`w(:Pvu8udwPz0<8yl=}P~{8|t)D }P0?8{@ 1P8`0 YO` `;9`+9 HD@<840,%! ! "(0%YO`&(x0)YO`*-./0123456789forum:OMET;*DUTCUTCH?*MLSI@EQV-LAMSGSBERMATCR-HEADORCEE*MSGFNAGISTHdIHARONJ*CCCKISTLboardMCCN*CIPGOISTPCIPGQDER-FRNETS*DSPGTISTUDSPGVDER-FWNETX*EDDIYEQV-LZbboar[al\DDIE]DER-F^NET_*EE`ISTaEEb*MULTcEQV-Ldmmtu.eMultifmitbbgMultih*MSGiEQV-LjSYSMSkOMINGl*MSGmEQV-LnBBOARoOMINGp*MSGqEQV-LrMIT-MsEStS-Au vEQV-LwAgre-xpyOZzAI{IST|;AGRE}]~Agre-pIST;MAILUP]Agre-EQV-L[AGREOMINGFILEOZ IST OZ Agre- fordISTsevaxoxforuk@ucarpaEQV-LAgreR-OPTNO-CLR-OPTNOQCDER-FRFC73AlanXIST;ALAN]DER-FRFC73FILEcosell@prophet.bbn.comCUBE-LOVERS@ai.ai.mit.eduReceived: from PROPHET.BBN.COM by AI.AI.MIT.EDU 14 Aug 86 16:36:18 EDT Date: Thu, 14 Aug 86 16:28:18 EDT From: Bernie Cosell To: cube-lovers@ai.ai.mit.edu cc: cube-lovers Subject: Re: CUBE EXCHANGE ``The Games People Play'' in Cambridge, MA (617-492-0711) had, and still has, lots of cubes. Carol (who owns the place) continually complains about the basement-full of 4x4x4 cubes that she's ended up stuck with... /bernie FAILcosell Re: CUBE EXCHANGE<[AI.AI.MIT.EDU].83676.860814>RFC733[ALAN;CUBE MAIL]FILENOSHOW@FILE[ALAN;CUBE PEOPLE]FILENOSHOWbeckNOSHOWdragonNOSHOWarpalistsNOSHOWThomas.MathiesNOSHOWREMARCK%UCLASSCF.BITNETNOSHOWJJL8733%RITVAXA.BITNETNOSHOWAMATHSC%WYOCDC1.BITNETNOSHOWGOOSSENS%CERNVM.BITNETNOSHOW8440827%wwu.csnetNOSHOWdnichols%tilde%ti-csl.csnetNOSHOWC0144%CSUOHIO.BITNETNOSHOWJIMR%CLARGRAD.BITNETNOSHOWENEA!KULING!STARBACKSEISMOENEA!KULING!STARBACK"ENEA!KULING!STARBACK" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERSNOSHOWM70S%CBEBDA3T.BITNETNOSHOWhart%taurus.BitNetNOSHOWkgk%brown.csnetNOSHOWsvozzaNOSHOWM14051%mwvmNOSHOWCN0001ER%UKCC.BITNETNOSHOWHaddenNOSHOWBK0HNOSHOWAAPH332%UA.BITNETNOSHOWjethro%vaxNOSHOWFCTY7098%RYERSON.BITNETNOSHOWTONY%SER.BITNETNOSHOWceolsonNOSHOWariceNOSHOWchapman_sys%uta.csnetNOSHOWloebNOSHOWISI-CUBE-LOVERSNOSHOWc-youngNOSHOWmcclimansNOSHOWesc1040%DDAESA10.BITNETNOSHOWU213002%HNYKUN11.BITNETNOSHOWRIOLOARDC.ARPARIOLO"RIOLO" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS Will try sending to the file "USERS3;RIOLO MAIL".NOSHOWthayerNOSHOWCCRJW%UMCVMB.BITNETNOSHOWRandall_Shane%RPI-MTS.MailnetNOSHOWmcneilNOSHOW#d2f%ddathd21.BITNETNOSHOWGOET%HWALHW5.BITNETNOSHOWpesNOSHOWalattoNOSHOWcube-lovers-usersNOSHOWsteveNOSHOWmwm%ucbjade.CCNOSHOWVUYAACOV%WEIZMANN.BITNETNOSHOWELINOSHOWliangNOSHOWF33PAP%DHHDESY3.BITNETNOSHOWots!cubeloversNOSHOWcube%wisdom.bitnetNOSHOWhplabs!oliveb!longNOSHOWSTARKNOSHOWcube-lovers-newsNOSHOWsun!artibeeNOSHOWmfrishkopfNOSHOWhaynesNOSHOWeng20201%BostonU.BITNETNOSHOWcube-lovers-incomingNOSHOWgenrad!decvax!dartvax!andybNOSHOWbbd-cube-loversNOSHOWkelemNOSHOWCLINENOSHOWmeisterNOSHOWRonNOSHOWuci-cube-loversNOSHOWsilver.emoryNOSHOWbts.uncNOSHOWbad.BrownNOSHOWREHMINOSHOWcakNOSHOWCLEMENTSNOSHOWCUBE-LOVERS-INCOMING%TI-CSLNOSHOWcosellNOSHOWdmNOSHOWXeroxCubeLovers^.PANOSHOWleeNOSHOWLoomisNOSHOWJKNOXNOSHOWKornerNOSHOWCliveNOSHOWkorfhageNOSHOWbersonNOSHOWurbanNOSHOWLAURENNOSHOWLauren@RANNOSHOWWRINGNOSHOWOLENOSHOWHSSNOSHOWMilunovicNOSHOWBBOARD-Cube-LoversNOSHOWStillman.JosephNOSHOWVaughanW.REFLECSNOSHOWPUCC=6000525NOSHOWDavid.AndersonNOSHOWKevin.DowlingNOSHOWMichael.FosterNOSHOWBob.WalkerNOSHOWAGINNOSHOWGLSNOSHOWgls@tNOSHOWLOCAL-CUBE-LOVERSNOSHOWFEATHERNOSHOWHOROWITZNOSHOWKATZNOSHOWlejm%UK.AC.EDINBURGHNOSHOWDDyerNOSHOWHirshNOSHOWcowerNOSHOWPatashnikNOSHOWRestivoNOSHOWBroderNOSHOWTRDNOSHOWJEBNOSHOWNemnich-junkNOSHOWPCO-distyNOSHOWSchaubleNOSHOWRHarvey.mNOSHOWBSGNOSHOWbsg@sNOSHOWSWGNOSHOWG.MenagerieNOSHOWCELNOSHOWcel@xNOSHOWCMBNOSHOWNJASNOSHOWNJASNOSHOWZIMNOSHOWZIMNOSHOWTRBNOSHOWmasscomp!trb@CCNOSHOWYEKTANOSHOWRPNOSHOWRPNOSHOWJURGENNOSHOWcallas%star.decNOSHOWDUFTYNOSHOWdoughty@scNOSHOWDCPNOSHOWDCPNOSHOWAMONOSHOWAMONOSHOWALANNO-CLINOQCRFC733NOSHOWPDLNOSHOWPDLNOSHOWFONER-MAGAZINESNOSHOWFONER-MAGAZINESNOSHOWGAINOSHOWx.gaiNOSHOWEDNOSHOWACWNOSHOWacw@sNOSHOWPAONOSHOWHost appears to be permanently down or not accepting mail.Host appears to be permanently down or not accepting mail. YN-!  2e 2e2 e2 e#2e+2e32e;2eC2!eK2%eS2)e[2-ec21ek25es29e{2=e 2$. R22@HRu rHRHR` HPs:Wp  (,Tu(XA0 nH(@ x 98 !x@P0v8 (wHTuP0z8n {  P8vH,P8 !$ P 8%8~BP$08#)8  P( 8'-X   P,0 8+f10   P08/5X  P4083%9 P80878=X P<08;XA   P@08?E   PD08CMI J0 XK(pGHTuPLg8GPPi  POm8NTHo('PSs8RHX<u PW0<8VP\0=-P[0>8Z`X?P_8^idP  Pc8bh(/Pg8f=l%Pk0G8j%pH  Po0J8n)t9u0K(0Ps0L8r*y8M  Px8w.}<  P|0R8{28SWP0T86(U P8B T P0Y8F Z(P 8 Q<gP0]8e8^ YP0_8qH`h$P0a8z8b  P8~!\  P 0h8%(i&$0's,X((P$08#",0(0P+08*10  P/08.=4h(P3082A80 P70 86Y<    P;08:e@  P?08>mDh!PC#8B H%2=PG'8FILD) PK-8JIP/5PO08NMTp('PS58RX`7  PW08VI[TuP\?8Za`AP_0!8^d0"  PcI8bh8K :Pg0'8f&l(  Pk0*8jmp+('Po0-8n"t(.(Ps]8rUx@_Pwc8vY|,e('P{048zP5 P068~@07hP08889  Pw89 Py P }8 QlP8<hP0E8E(FAP89AP0H8= 8IdP0J8A$KP#8"E(<P'0N8&,`O P+8*0 P/8.4$ P382]80s,P70V86<W0P;8:@  P?8>yDl PC8BaH2=PG8FL2=PK0a8J5Pb(PO0d8N:Te(PS8R>X(PW8VY\(P[0i8Z `0j(P_0k8^-d(l(Pc8b1h  Pg8f5l Pk8jEp Po0r8nM0ssTuPt0t8r]x 0uPw0v8va|(w P{8zq IP0y8~yz(P8A$(P8i H!P 8 -< P08U(/P08U`('P8q8P0 8} h (P8$8(P#08"Q(P(P'08&m, (P+%8*i '/TuP008.4(P3+82e8D-AP7186<3gP;58:!@ 7gP?98>%D;gPC08B)H  PG0!8F-L("(PKE8JuPG(PO0$8NT(%$]PSK8R X$M$5PWO8V\Q  P[S8ZU`U  P_W8^Yd Y Pc0-8b]h. Pg]8fal0_(Pk018jQpH2(Po038n-t@4(Ps058rexH6(Pw078vi8{TuP|q8z)H sP0:8~5;Pw8m,y 1P0>8q? TuP 8 u P0A8yB0s,P8TuP0D8 EP8 TuP 0G8$HP#8" 'TuP(0J8&M, `KP+`*P/0N8.]O2TuP3`1 7P60Q85u0R:TuP;0S891?hxTP>8=}BTuPC0W8AG)H8XPF0Y8EZJTuPK8IO )HPN0\8M!]RTuPS8Q)W PV0_8U0 `PZP[x\0bP]0c8Y4d`TuPa8_<e Pd0f8cDxghTuPi8gLm<Pl0k8kTlpTuPq8o^uPt0n8sboPx8wj {TuP|0q8zr)DrP8~y  1P0t8}u`u  ` `9`)njfb^ZV(}Pu  `(vP{  ` !"#BJN$CSTAC%DANNY&DEVON'ERMES(FVE)R*Gumby+IAN@N,JNC-JTW@S.KLH/KWH-P0MLY1@PREP2RAY3SAJ@P4SUNDA5MES6TK7P8;HATE9EX]:USER;IONACCOU?USER-@IONAISTBISTCACCOUDUSER-ER-OPTFSHOWLGEQV-LHUSER-INTSJACCOUKR-OPTLSHOWLMEQV-LNUSER-ONTSPACCOUQEQV-LRUSER-SNTS-ATEUYVDANIEWGumbyXPGSYZvonaZNTS-H[EFUSE\EQV-L]USER-^NTS-A_E`PGSaLbZVONAcACCOUdRCHIVeEQV-LfUSER-gEhA-FILiEQV-LjFILEkNT;USlOUNT]mACCOUnOTIFIoNpISTq[ACOUrCHIV s]tDER-FuNULLvPGSwLxFILEy*zION{ST|IST}*MSG~*MITONSTIST*EE*CIPG*XV*MSG*MSG*MSG*MAC ION ST IST *XX*OZTEXTHICSNA*MSG*MSG*MSG*MSG*MSG*MSG*ITSIONSTISTBBITSXXg@ardec-lcss.arpa:beck@clstr1.decnetCUBE-LOVERS@ai.AI.MIT.EDUReceived: from ARDEC-LCSS.ARPA.ARPA by AI.AI.MIT.EDU 14 Aug 86 15:44:23 EDT Date: 14 Aug 86 15:34:00 EST From: "CLSTR1::BECK" Subject: CUBE EXCHANGE To: "cube-lovers" Reply-To: "CLSTR1::BECK" I have been a cube person for 5 or 6 years now and I am upset by the almost total disappearance of the cube and its asociated memorabilia and paraphernalia. Therefore, I propose to establish a "CUBE EXCHANGE" to buy, sell and trade cube items in suport of the greater development of cubing. To this end it will be necessary to catalog what was available, what is avaiable and from whom it can be obtained. Your assistance in this endeavor will be much appreciated, including pointers through the archives. So far I have located a source for 3x3x3 cubes (solid colors, card suits, flowers, numbers, domino dots, fruits, sports balls, and ball). Your assistance in who has what for sale would also be much appreciated. peter beck BECK@ARDEC-LCSS.ARPA ------ FAILNET-ORIGIN<[AI.AI.MIT.EDU].83649.860814>RFC733[ALAN;CUBE MAIL]FILENOSHOW@FILE[ALAN;CUBE PEOPLE]FILENOSHOWbeckNOSHOWdragonNOSHOWarpalistsNOSHOWThomas.MathiesNOSHOWREMARCK%UCLASSCF.BITNETNOSHOWJJL8733%RITVAXA.BITNETNOSHOWAMATHSC%WYOCDC1.BITNETNOSHOWGOOSSENS%CERNVM.BITNETNOSHOW8440827%wwu.csnetNOSHOWdnichols%tilde%ti-csl.csnetNOSHOWC0144%CSUOHIO.BITNETNOSHOWJIMR%CLARGRAD.BITNETNOSHOWENEA!KULING!STARBACKSEISMOENEA!KULING!STARBACK"ENEA!KULING!STARBACK" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERSNOSHOWM70S%CBEBDA3T.BITNETNOSHOWhart%taurus.BitNetNOSHOWkgk%brown.csnetNOSHOWsvozzaNOSHOWM14051%mwvmNOSHOWCN0001ER%UKCC.BITNETNOSHOWHaddenNOSHOWBK0HNOSHOWAAPH332%UA.BITNETNOSHOWjethro%vaxNOSHOWFCTY7098%RYERSON.BITNETNOSHOWTONY%SER.BITNETNOSHOWceolsonNOSHOWariceNOSHOWchapman_sys%uta.csnetNOSHOWloebNOSHOWISI-CUBE-LOVERSNOSHOWc-youngNOSHOWmcclimansNOSHOWesc1040%DDAESA10.BITNETNOSHOWU213002%HNYKUN11.BITNETNOSHOWRIOLOARDC.ARPARIOLO"RIOLO" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS Will try sending to the file "USERS3;RIOLO MAIL".NOSHOWthayerNOSHOWCCRJW%UMCVMB.BITNETNOSHOWRandall_Shane%RPI-MTS.MailnetNOSHOWmcneilNOSHOW#d2f%ddathd21.BITNETNOSHOWGOET%HWALHW5.BITNETNOSHOWpesNOSHOWalattoNOSHOWcube-lovers-usersNOSHOWsteveNOSHOWmwm%ucbjade.CCNOSHOWVUYAACOV%WEIZMANN.BITNETNOSHOWELINOSHOWliangNOSHOWF33PAP%DHHDESY3.BITNETNOSHOWots!cubeloversNOSHOWcube%wisdom.bitnetNOSHOWhplabs!oliveb!longNOSHOWSTARKNOSHOWcube-lovers-newsNOSHOWsun!artibeeNOSHOWmfrishkopfNOSHOWhaynesNOSHOWeng20201%BostonU.BITNETNOSHOWcube-lovers-incomingNOSHOWgenrad!decvax!dartvax!andybNOSHOWbbd-cube-loversNOSHOWkelemNOSHOWCLINENOSHOWmeisterNOSHOWRonNOSHOWuci-cube-loversNOSHOWsilver.emoryNOSHOWbts.uncNOSHOWbad.BrownNOSHOWREHMINOSHOWcakNOSHOWCLEMENTSNOSHOWCUBE-LOVERS-INCOMING%TI-CSLNOSHOWcosellNOSHOWdmNOSHOWXeroxCubeLovers^.PANOSHOWleeNOSHOWLoomisNOSHOWJKNOXNOSHOWKornerNOSHOWCliveNOSHOWkorfhageNOSHOWbersonNOSHOWurbanNOSHOWLAURENNOSHOWLauren@RANNOSHOWWRINGNOSHOWOLENOSHOWHSSNOSHOWMilunovicNOSHOWBBOARD-Cube-LoversNOSHOWStillman.JosephNOSHOWVaughanW.REFLECSNOSHOWPUCC=6000525NOSHOWDavid.AndersonNOSHOWKevin.DowlingNOSHOWMichael.FosterNOSHOWBob.WalkerNOSHOWAGINNOSHOWGLSNOSHOWgls@tNOSHOWLOCAL-CUBE-LOVERSNOSHOWFEATHERNOSHOWHOROWITZNOSHOWKATZNOSHOWlejm%UK.AC.EDINBURGHNOSHOWDDyerNOSHOWHirshNOSHOWcowerNOSHOWPatashnikNOSHOWRestivoNOSHOWBroderNOSHOWTRDNOSHOWJEBNOSHOWNemnich-junkNOSHOWPCO-distyNOSHOWSchaubleNOSHOWRHarvey.mNOSHOWBSGNOSHOWbsg@sNOSHOWSWGNOSHOWG.MenagerieNOSHOWCELNOSHOWcel@xNOSHOWCMBNOSHOWNJASNOSHOWNJASNOSHOWZIMNOSHOWZIMNOSHOWTRBNOSHOWmasscomp!trb@CCNOSHOWYEKTANOSHOWRPNOSHOWRPNOSHOWJURGENNOSHOWcallas%star.decNOSHOWDUFTYNOSHOWdoughty@scNOSHOWDCPNOSHOWDCPNOSHOWAMONOSHOWAMONOSHOWALANNO-CLINOQCRFC733NOSHOWPDLNOSHOWPDLNOSHOWFONER-MAGAZINESNOSHOWFONER-MAGAZINESNOSHOWGAINOSHOWx.gaiNOSHOWEDNOSHOWACWNOSHOWacw@sNOSHOWPAONOSHOWHost appears to be permanently down or not accepting mail.Host appears to be permanently down or not accepting mail.YN-!  Z`ZZ`ZZ` ZZ`Z&Z`Z.Z`Z6Z`Z>Z`ZFZ`#ZNZ`'ZVZ`+Z^Z`/ZfZ`3ZnZ`7ZvZ`;Z~Z`?Z Z`u [Z`Z`@H[$> ] H[H[t` HPqN_pH|(0s,(X 0 _Hp @ x 8` ``e03(5(50.?C0/packet-redistribution@EDDIE.MIT.EDUPLUKEL@ai.ai.MIT.EDUReceived: from EDDIE by AI.AI.MIT.EDU 14 Aug 86 07:21:03 EDT Received: by EDDIE (5.31/4.7) id AA00993; Thu, 14 Aug 86 07:08:31 EDT Received: by EDDIE (5.31/4.7) id AA00986; Thu, 14 Aug 86 07:08:25 EDT From: seismo!enea!vaxd.erix!eispet@EDDIE.MIT.EDU Received: from enea.UUCP by seismo.CSS.GOV with UUCP; Thu, 14 Aug 86 06:51:10 EDT Received: by enea.uucp (4.40/1.30-enea); Thu, 14 Aug 86 11:10:55 +0200 (MET) Received: by erix.UUCP (4.40/4.7) id AA28025; Thu, 14 Aug 86 10:31:52 +0100 Date: Thu, 14 Aug 86 10:31:52 +0100 Message-Id: <8608140931.AA28025@erix.UUCP> Subject: Conference87 To: mit-eddie!packet-radio Do anyone have the details about next years Computer Networking Con- ference ? I am interested in closing date for conference papers and time and place of the conference. Thanks for your co-operatin, 73 de Peter Peter Lytz OH2AVP eispet%vaxd@erix.UUCP FAILseismo!enea!vaxd.erix!eispet<[AI.AI.MIT.EDU].83520.860814>YN-!  )8q )8q)8 q)8 q#)8q+)8q3)8q;)8qC)8!qK)8%qS)8)q[)8-qc)81qk)85qs)89q{)8=q Q)8$" )X)8)8@H$ ׇ` HP\pY(PXF0H0GYxHH@ x .-P0P` Q`Q` h?x.  DEVONReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 AUG 86 18:25:23 EDT Date: Mon, 11 Aug 86 18:24:46 EDT From: Communications Satellite Subject: Msg of Saturday, 9 August 1986 11:08-EDT To: DEVON@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].64553.860811> FAILED: rwg at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 AUG 86 11:07:38 EDT Received: from MX.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 9 Aug 86 11:02-EDT Received: from MARVIN.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 9 AUG 86 10:57:28 EDT Date: Saturday, 9 August 1986, 10:56-EDT From: Devon S. McCullough Subject: zmacs bug on cadr-13 To: BUG-LISPM at MIT-OZ CC: devon at ai In Experimental System 99.12, CADR 4.0, Experimental ZMail 54.3, MIT-Specific 23.0, Experimental Macsyma 5.0, microcode 320, GC@2, on Marvin: While in two-window mode, with a dired on the upper window, I did c-X c-F on the lower window, then before the file was read into the lower window I clicked the mouse on the upper window, and typed DDD intending to delete three files (I blew it since I only clicked once and the cursor would have been on the wrong file to delete) but now zmacs is wedged, it crashes whenever I try to abort out of this error because redisplay-all-windows or something like that is busted somehow. >>TRAP 4597 (ARGTYP ARRAY M-A NIL GAHDR) Some argument to AR-1, NIL, was of the wrong type. The function expected an array. Backtrace from the debugger: (:METHOD ZWEI:WINDOW :REDISPLAY) (P.C. = 675) (SELF is #) Arg 0 (.OPERATION.): :REDISPLAY Arg 1 (RECENTER-TYPE): :POINT Arg 2 (RC1): NIL Arg 3 (RC2): NIL Arg 4 (FORCE-TO-COMPLETION-P): NIL Local 0 (LH): 14 Local 1 (NOW): 11967 Local 2 (POINT-PLINE): NIL Local 3 (POINT-LINE): " WWMEM.UPGRADE.9 8 18995(7) 07//02//86 17:40:37 DEVON@MX" Local 4 (POINT-INDEX): 19 Local 5 (TOP-LINE): " SCOPE.LISP.33 7 17265(7) ! 08//09//86 10:48:17 GZ.DEVON" Local 6 (TOP-INDEX): 0 Local 7 (LAST-BP): ("-*- end of CADR WWMEM -*-" 25 :MOVES) Local 8 (INITIAL-DEGREE): 4 Local 9 (POINT-NODE): NIL Local 10 (START-BP-NODE): NIL Local 11 (BUF): NIL Local 12 (NEW-TOP-INDEX): NIL Local 13 (Y): NIL Local 14 (LINE): NIL Local 15 (INDEX): NIL Local 16 (P): NIL Local 17 (LINE-LENGTH): NIL Local 18 (LEN): NIL Local 19 (DWID): NIL Local 20 (CH): NIL Local 21 (FONT): NIL Local 22 (CWT): NIL Local 23 (CWID): NIL Local 24 (RWID): NIL Local 25 (I): 1 Local 26 (TW): 0 Local 27 (L): NIL Local 28 (FROM-INDEX): 0 Local 29 (TO-INDEX): 0 Local 30 (PLINE): 20 Local 31 (STOP-LINE): "-*- end of CADR WWMEM -*-" Local 32 (FROB): NIL Local 33 (PLINE): NIL Local 34: NIL Local 35 (BL): NIL ZWEI::REDISPLAY (P.C. = 58) Arg 0 (WINDOW): # --Defaulted args:-- Arg 1 (RECENTER-TYPE): :POINT Arg 2 (RC1): NIL Arg 3 (RC2): NIL Arg 4 (FORCE-TO-COMPLETION-P): NIL ZWEI::REDISPLAY-ALL-WINDOWS (P.C. = 61) --Defaulted args:-- Arg 0 (FORCE-TO-COMPLETION-P): NIL Arg 1 (SELECT-P): T Local 0: (# #) Local 1 (WINDOW): # (:METHOD ZWEI:WINDOW :EDIT) (P.C. = 259) (SELF is #) Arg 0 (.OPERATION.): :EDIT --Defaulted args:-- Arg 1 (IGNORE): NIL Arg 2 (*COMTAB*): # Arg 3 (*MODE-LINE-LIST*): ("ZMACS " "(" ZWEI::*MODE-NAME-LIST* ") " ...) Arg 4 (TOP-LEVEL-P): T Local 0: ("Return to top level editor command loop.") Local 1: ((SYS:ABORT ERROR) ("Return to top level editor command loop.") T ("Return to top level editor command loop.") ...) Local 2 (CH): NIL (:INTERNAL (:METHOD ZWEI:ZMACS-WINDOW :COMBINED :EDIT) 0) (P.C. = 60) Rest arg (.DAEMON-CALLER-ARGS.): (:EDIT) Local 1 (.DAEMON-MAPPING-TABLE.): # Remainder of stack: FUNCALL (P.C. = 21) (:METHOD ZWEI::DISPLAYER :AROUND :EDIT) (P.C. = 25) (:METHOD ZWEI:ZMACS-WINDOW :COMBINED :EDIT) (P.C. = 39) ZWEI::ZMACS-WINDOW-TOP-LEVEL (P.C. = 38) SI::PROCESS-TOP-LEVEL (P.C. = 115) FAILCOMSAT Msg of Saturday, 9 August 1986 11:08-EDT<[AI.AI.MIT.EDU].82222.860811>NOQCNO-CLIYN-!   ^  ^  ^  ^ & ^ . ^ 6 ^ > ^ F ^# N ^' V ^+ ^ ^/ f ^3 n ^7 v ^; ~ ^?  K ^$  ~ ^ ^@H ~lt H ~H ~t` HPZep(PX `0 CH AxHD@ x -P0J` K`K` x9xp_ |$>DEVONReceived: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 AUG 86 10:01:10 EDT Received: from BORAX.LCS.MIT.EDU by MX.LCS.MIT.EDU 11 Aug 86 10:00:22 EDT Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Mon, 11 Aug 86 09:57:51 edt Date: Mon, 11 Aug 86 09:57:51 edt From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen) Message-Id: <8608111357.AA12653@BORAX.LCS.MIT.EDU> To: escapists Subject: Weather (for Stargazing) Tonight is supposed to be clear (modulo thundershowers this afternoon). I will see what things look like at 1800, and post to the list. My riders should keep their eyes open, and be able to get to Tech [] by 1900 for pickup. jbvb FAILjbvb Weather (for Stargazing)<[AI.AI.MIT.EDU].81984.860811>NOQCNO-CLIYN-!  Z#GZ#GZ# GZ#G%Z#G-Z#G5Z#G=Z#GEZ#"GMZ#&GUZ#*G]Z#.GeZ#2GmZ#6GuZ#:G}Z#>G  hZ#lr ZCZ#Z#@HZC$& \cHZCHZCt` HPXZ~p%(pP(X"l0 `H %x H@ x ,[ P0g`h`h` fltaylor@bbncc7DEVON@ai.ai.mit.eduReceived: from bbncc7 by AI.AI.MIT.EDU 11 Aug 86 03:14:06 EDT Date: Mon, 11 Aug 86 3:12:17 EDT From: Laura Taylor Subject: resend of message To: devon@ai.ai.mit.edu ***** 1958 0 Received: from AI.AI.MIT.EDU by BBNCC7 ; 11 Aug 86 02:08:33 EDT Date: Mon, 11 Aug 86 02:08:01 EDT From: Communications Satellite Subject: Msg of Monday, 11 August 1986 01:51-EDT To: ltaylor@CC7.BBN.COM Message-ID: <[AI.AI.MIT.EDU].81890.860811> FAILED: DEVON at AI.AI.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 AUG 86 01:51:13 EDT Received: from MC.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 11 AUG 86 01:50:26 EDT Received: from bbncc7 by MC.LCS.MIT.EDU 11 Aug 86 01:50:31 EDT Date: Mon, 11 Aug 86 0:38:40 EDT From: Laura Taylor Subject: Re: Perseid meteor shower In-Reply-To: Your message of Sun, 10 Aug 86 19:43:33 EDT To: "Devon S. McCullough" Cc: ltaylor@bbncc7.arpa Hi Dev, That sounds like pretty much fun...'cept... Usually I would have to work then, but the person who usually works from midnight to 8 a.m. on Sunday went on vacation, so I am the one working for her...right now in fact. So because I'm working for her now, I don't have to come in to work on Monday night, however, I'm in the process of trying to find 2 new housemates because both of my present housesmates are moving out at the end of August so I put an add in the Phoenix and several people are coming by on Monday night to check it out so I kind of have to be at home. If you know of any deadheads looking for a place to live, tell them to call me at work or else at home at 863-5607. I live in Lexington. I put an add on the MIT bboard awhile ago advertising for a housemate... did you see it? I am applying for a job at MIT...if I get it then I won't have to work these funky hours and will have more freetime to do things like see meteor showers. Sorry I couldn't talk long the other night...it was really busy here. jubba jubba, Laura  FAILltaylor resend of message<[AI.AI.MIT.EDU].81911.860811>NOQCNO-CLIYN-!  e53e 53 e53 e53e#53e+53e353e;53!eC53%eK53)eS53-e[531ec535ek539es53=e{53 Ge$ ee@H$ t` HPX'&pY(PX 0H0@9xhA@ x ,'YP0F` G`G`  : x-)9x [ |$,>DEVONReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 AUG 86 01:23:52 EDT Received: from mimsy.umd.edu by MC.LCS.MIT.EDU 11 Aug 86 01:23:11 EDT Received: by mimsy.umd.edu (5.9/4.7) id AA24124; Mon, 11 Aug 86 01:24:00 EDT Date: Mon, 11 Aug 86 01:24:00 EDT From: Michael Grant Message-Id: <8608110524.AA24124@mimsy.umd.edu> To: devon@mc.lcs.mit.edu Subject: bounced mail I tried to reply to that messge you sent, it bounced from seismo, user: kin@seismo.css.gov...unknown. Hmmmm.... If you want to send it to kin, go ahead, it may help others be more willing to contribute. -Mike FAILmgrant bounced mail<[AI.AI.MIT.EDU].81871.860811>NOQCNO-CLIYN-!  mom mommo mmo m"mom*mom2mom:momBmo!mJmo%mRmo)mZmo-mbmo1mjmo5mrmo9mzmo=m mo$6 nmomo@Hn$ p/HnHnt` HPX!(p(P WX 0H0S9@pT ,!]P` ` ` )9x [ |$>DEVONReceived: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 AUG 86 01:11:05 EDT Received: from MC.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 11 AUG 86 01:10:18 EDT Received: from mimsy.umd.edu by MC.LCS.MIT.EDU 11 Aug 86 01:09:43 EDT Received: by mimsy.umd.edu (5.9/4.7) id AA24029; Mon, 11 Aug 86 01:10:18 EDT Date: Mon, 11 Aug 86 01:10:18 EDT From: Michael Grant Message-Id: <8608110510.AA24029@mimsy.umd.edu> To: BAndy@lll-crg.arpa, DEVON%MX.LCS.MIT.EDU@mc.lcs.mit.edu, Devon@mc.lcs.mit.edu, Gyro@oz.ai.mit.edu, Jurgen@mc.lcs.mit.edu, RDO@mit-eddie.arpa, Velu@gyre.umd.edu, jsol@ai.ai.mit.edu, kin@seismo.css.gov, mgrant@mc.lcs.mit.edu, vecpyr!sgw@lll-crg.arpa Subject: Re: soap opera Gak! I hope this helps. My check's in the mail. -Mike FAILmgrant<[AI.AI.MIT.EDU].81862.860811>NOQCNO-CLIYN-#  h hh h #h+h3h;hCh!Kh%Sh)[h-ch1kh5sh9{h= CE#h$$ hh@H$ (HHt` HP3:8p5(0s,(0P (XB0 lH  ,x hm@xwP8148(uP8,P0z8 { PP0~80P# P$P%8"!P(0P)08'&0P,08+*0P/8.- P30 824 P6$P7858P:HP; P<x=P>!89?`@D#`A#`F@GG(HH0I MJ@KK(LL0M QN@OO(PP0Q UR@SS(TT0U YV@WW(XX0Y ]Z@[[(\\0] a^@__(``0a eb@cc(dd0e if@gg(hh0i mj@kk(ll0m qn@oo(pp0q ur@ss(tt0u yv@ww(xx0y }z@{{(||0} ~@(0 @(0  @(0   @  (  0 @(0 @(0 @(0 @(0 !@(  0! %"@##($$0% )&@''(((0) -*@++(,,0- 1.@//(0001 52@33(4405 96@77(8809 =:@;;(<<0= A>@??(@@0A EB@CC(DD0E IF@GG(HH0I MJ@KK(LL0M QN@OO(PP0Q UR@SS(TT0U V@WW(XX0Y@Z[[\\Y]^^__``a3bccddae(hf@eg h0ijjkklimnn&oppmq r0s(rt@su(xv@uw x0yzz{{ |y}~~]| q0(@       +@ w0(b(@ 0o@  g0(REHMI@AIUSER-A@AIReceived: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 AUG 86 15:43:53 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 41761; Wed 6-Aug-86 15:43:42-EDT Date: Wed, 6 Aug 86 15:42 EDT From: Alan Bawden Subject: AI -> MX ?!? To: REHMI@AI.AI.MIT.EDU cc: User-A@AI.AI.MIT.EDU, User-A@MX.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].79738.860805.REHMI> Message-ID: <860806154202.8.ALAN@PIGPEN.AI.MIT.EDU> Date: Tue, 5 Aug 86 15:12:22 EDT From: Rehmi Post hello... i was wondering if it might be possible to get an account on MX mainly for reading mail and playing ITS... i heard that people actually depend on AI more so than on MX, and i'm not looking to get in anybody's way, so i'd happily move to MX if it were amenable to all involved... I'm not sure what you are asking for here, but in any case I don't take any responsibility as an administrator for these machines. I have CC'd this message to those people who do. FAILAlan AI -> MX ?!?<[AI.AI.MIT.EDU].80137.860806>SHOWLISTNOSHOWUSER-ACCOUNTSUSER-ACCOUNTS-ARCHIVENOSHOWUSER-A-FILENOSHOWFILE[ACOUNT;USER ACOUNT]FILENOSHOWCSTACYNOQCNO-CLINOSHOWCENTAPPENDNOSHOWDANIELNOSHOWGZ@OZNOSHOWPGSNOSHOWRDZSMALL-CLINOSHOWZVONASMALL-CLINOQCAPPENDRFC733NOSHOWYN-!  LLL L%L-L5L=LEL"ML&UL*]L.eL2mL6uL:}L> L$ lLL@H,$ LH,H,` HP1qTp )(800s,(X*00 }H(@ x ` ` `******************************  a vezengo,re Flo ...FAILRIGINAI.MI].800bundy%aiva.edinburgh.ac.uk@cs.ucl.ac.ukSILVER@MIT-AI.ARPAReceived: from BRL-AOS.ARPA by AI.AI.MIT.EDU 6 Aug 86 08:35:33 EDT Received: from ucl-cs.arpa by AOS.BRL.ARPA id ac11958; 6 Aug 86 8:13 EDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a004673; 6 Aug 86 11:24 BST From: Alan Bundy Date: Wed, 6 Aug 86 11:14:34 -0100 Message-Id: <727.8608061014@aiva.ed.ac.uk> To: fateman@ucb-vax.ARPA Subject: Press report Cc: bs30 <@cs.ucl.ac.uk,@CSNET-RELAY.ARPA:bs30@gte-labs.csnet>, bundy%aiva.edinburgh.ac.uk@cs.ucl.ac.uk, byrd <@cs.ucl.ac.uk:byrd@SRI-STRIPE.ARPA>, lawrence%quintus.uucp@cs.ucl.ac.uk, leon <@cs.ucl.ac.uk,@CSNET-RELAY.ARPA:leon@case>, ok%quintus.uucp@cs.ucl.ac.uk, silver <@cs.ucl.ac.uk:silver@MIT-AI.ARPA>, silver <@cs.ucl.ac.uk,@mit-xx.ARPA:silver@mit-oz> Richard I should thank you for your detailed referees report on our paper on Press and for signing your name to it and inviting a dialogue. I say "I should" because gratitude was not a readily identifiable emotion after I had finished reading it. However, you put in an amount of work far beyond the call of duty and which will be of great benefit to us, and laid yourself open to what could have been an unpleasant dialogue, and for that I am grateful. Your report raised a number of important points, many of which I agree with, and others I would like to reply to. Overall, I feel you judge our work on the wrong grounds. Let me say why by explaining the background to the project. Our principle interest was in automatic theorem proving and, in particular, in guiding the search for a proof through a space of rule firings. We thought the use of numeric scores in A* type search strategies rather crude and tried to look for alternative techniques. The choice of equation solving for a domain was because: a) here was a domain in which there was a massive amount of search when viewed as a resolution-type problem, b) however humans seemed to do pretty well, and c) there was no decision algorithm that they might be using (since domain undecidable - see Richardson's results). So we had an existence proof for some guidance techniques. Press embodied an interesting new guidance technique, and it is on this that it principally has been and should be judged. It has never been presented, by me, as a useful (MACSYMA-like) equation solving package, and whenever anyone has requested to use it on those grounds I have put them right. (So why did we say "the techniques used may have something to offer the field of symbolic and algebraic manipulation"? Well I regret that particular form of words because I now see it is ambiguous. There is "something to offer" which I will discuss below, but it is not the precise equation solving methods of Press except, maybe, in a few special cases.) In summary, I take your criticism to be: 1. (c) above may be true for the whole class of symbolic equations, but probably not for the class Press can actually deal with (if only we would say precisely what that was). 2. Decision algorithms exist for that class which are stronger than Press's methods. 3. Press's `solutions' are sometimes incorrect. It is difficult to counter 1. because the nature of Press makes it hard to specify the class of equations that it deals with. I would appreciate any help you can offer here. Press is probably a terminating algorithm. Certainly each method is individually, but there is no guarantee that the application of methods will terminate. Thus Press is probably a decision algorithm for whatever class it deals with. (Note, by the way that Press is not restricted to single equations in one unknown as you claim on p1). On 2., you state "None of these methods break new ground, by comparision to existing algebraic manipulation systems", but give no evidence. I accept this in the case of Isolation and Polysolve, but would like some pointers into the literature in the case of the other methods, which don't seem anything like the conventional methods I know of. In fact, I understood from Bernard Silver that the pair of you found an example that Press could handle and that Macsyma (for instance) could not. However, it would not surprise me if you were right. It was never our intention to provide a state-of-the-art equation solver, but merely to find some interesting examples of the kind of reasoning which might take place during the guidance of problem solving. The discovery of new methods during this exercise would be entirely fortuitous. On 3., I am prepared to admit there may be errors in Press, but the two examples you quote on p4 are not errors. We took a decision to adopt the usual high-school, equation-solving procedure of deriving consequences from the original equation until a formula of the right syntactic form to be a solution is derived. This formula is guaranteed to include all solutions, but may also include non-solutions if any derivation step was non-reversible. These must then be weeded out by checking, but I'm afraid we never got round to implementing checking because it was not central to our investigation of search control. In the log example there are 2 non-reversible steps: log(x-1) + log(x+1) => log(x+1)(x-1) and x^2 = e^3+1 => x = +/- root(e^3+1) Note that in the directions indicated the inferences are ok, e.g. if x+1 and x-1 are positive then (x+1)(x-1) is. We also took a decision to limit ourselves to real valued solutions (although this was a more arbitrary decision). That is why log(-1) etc should have been rejected by the missing checking step in your second example. In general, the meta-level inference architecture lends intself well to spotting errors, because of its separation of factual and control information. Decision algorithms typically interwine these making checking difficult. This does not mean we spotted them all. So what has Press got to offer conventional systems? I see two potential applications: 1. Meta-level inference may be a useful technique for controlling the application of conventional methods and/or for explaining their application to users. 2. Some of the Press methods may extend conventional methods or may provide more efficient alternatives in some circumstances. As you note on p4, Macsyma's solve routine is limited in its abilities to solve equations `cold'. This was my experience too. It seems to consist of Isolation plus some powerful, but special-purpose polynomial methods. However, its abilities can be increased by preliminary transformation using a simpification method. This will involve some planning. My idea under 1 above, is that each Macsyma method carry a meta-level description of its preconditions and effects that could be used by a Press-like system to plan a solution strategy. This strategy could also be the basis of an explanation to the user, e.g. "You wanted to solve (x^2-1)/(x+1)=0 but this contains 2 occurrences of x and is not a polynomial so I could not do it directly. However, it is a rational function, which I transformed to a polynomial x-1=0 using Ratsimp and then solved to give x=1." (Note: Press does not give explanations in English, but a formal version of the above.) My idea under 2. is that some of the Press methods might help fill in the gaps in existing Macsyma methods and cope with unusual situations like x + sin^2(x) + cos^2(x) = 0. This is neither a polynomial nor a trigonometric equation (although it can be reduced to a polynomial of course, as can any solvable equation). Conventional methods are likely to be stumped (if not on this one exactly, I am sure there are others). However, Collection can be applied to this to remove 2 occurrences of x and produce x=0. As for efficiency, I have no concrete examples, but I know that decision algorithms can be very inefficient and that heuristic methods can be an efficient alternative in particular circumstances. For instance, I understand that some of the original Sin integration techniques were left in Macsyma despite the Risch-Norman algorithm. I also have had personal communications from Joel Moses and John Campbell about the potential value of this in equation solving. I hope we can stay in touch and explore these potential, mutually beneficial interactions. I'm afraid my contribution will be theoretical since my group has now turned its attention to induction proofs in program synthesis (where the benefits of AI techniques are less controversial). However, my ex-student, Bernard Silver, is still working in this area and is specifically addressing the issue of combining Press-like and conventional algebraic manipulation techniques. Alan Bundy FAILNET-ORIGIN<[AI.AI.MIT.EDU].80018.860806>YN-!  _Rߥ _Rߥ_R ߥ_R ߥ#_Rߥ+_Rߥ3_Rߥ;_RߥC_R!ߥK_R%ߥS_R)ߥ[_R-ߥc_R1ߥk_R5ߥs_R9ߥ{_R=ߥ _R$2 _r_R_R@H_ru bH_rH_rt` HP) Up A(80s,(X 0 _H  Ax 0`@ x ```pe  ppwmason@BORAX.LCS.MIT.EDUREHMI@ai.ai.mit.eduReceived: from BORAX.LCS.MIT.EDU by AI.AI.MIT.EDU 5 Aug 86 04:53:41 EDT Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Tue, 5 Aug 86 04:47:59 edt Date: Tue, 5 Aug 86 04:47:59 edt From: mason@BORAX.LCS.MIT.EDU (Nark T. Mason) Message-Id: <8608050847.AA08960@BORAX.LCS.MIT.EDU> To: elbows Subject: Q&A with the stars... QUESTION OF THE DAY: What is your favorite stripe on the flag? Grace Slick, singer: "Point that thing somewhere else!" Paul Kantner, singer: "Michuocan" Marty Balin, singer: "What flag?" Jorma Kaukonen, guitarist: "Let me answer that question by posing another - Why don't the pentacles keep their evil spirits away?" jack Casady, basist: "four" Spencer Dryden, Drummer: "The little lady and I were in st tripe last summer -loveley place- but I hear some of those hippie types are starting to move in. I certainly hope they nip @i(that) one in the bud, toot sweet. FAILmason Q&A with the stars...<[AI.AI.MIT.EDU].79581.860805>YN-!  c)c)c )c)%c)-c)5c)=c)Ec")Mc&)Uc*)]c.)ec2)mc6)uc:)}c>) mcsf c4cc@Hc4$ eTHc4Hc4t` HP(Fop A(80s,(X 0 0Ha  Ax 81@ xg G`m`m` ; ;;stric on tts crg mailists  ;;; AI:T;TUROLICY  mason@BORAX.LCS.MIT.EDUREHMI@ai.ai.mit.eduReceived: from BORAX.LCS.MIT.EDU by AI.AI.MIT.EDU 5 Aug 86 02:31:11 EDT Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Tue, 5 Aug 86 02:25:07 edt Date: Tue, 5 Aug 86 02:25:07 edt From: mason@BORAX.LCS.MIT.EDU (Nark T. Mason) Message-Id: <8608050625.AA08053@BORAX.LCS.MIT.EDU> To: don Subject: Re: the beans live!!! Cc: elbows Sorry, I flushed 'em. but I can save you some of my breakfast from the camping trip this weekend. FAILmason Re: the beans live!!!<[AI.AI.MIT.EDU].79540.860805>YN-! !F FF F #F+F3F;FCF!KF%SF)[F-cF1kF5sF9{F= MO+F$ fFF@Hf$>!HfHft[ HP.ip((  P0(P #(  ((( P ( #( '(+8$((X/0 |H !(@"p# 85'P&8%:`)N,($ P+ 8*-Px/008.4 P382869)HP80 8718;>(  P=P?8<8A@D  DPC!8B P08FGP xI)8HJ+`K+`EPQRUSTHWU('V[WLX<]Y Z00[T\01]-^02_`X3abicidPke  fogvhqi(/jskAlum%n0;o)p<q  r0>s-t9u0?v(0w0@x*y8Az  {|.}<~  0F28GW0H6(I B T  0M F N(Q<g0Qe8R Y0SqHTh$0Uz8V   ~!\"  #0\$%(]&$'s,()*0s+",0t-(0.0u/10v1  20x3=4hy5(60|7A80}9:0~;Y< =  >0?e@A  B0CmDEh!F GH I2=JKILDM NOMPQ5R0 SQTpU('VWX`Y  Z0[M\] ^'_a`a)b0cd0e  f1g!h83i :j0k&lm  n0ompq('r0!s"t("u(vEwYx@GyzK{]|,M}('~0(P) 0*D0+h0,`-  ] = \_  02Q 3 05X609Ex:hw9yA0=A(>@MIT-MULTICS.ARPA:Peter_Lothberg_STUPI@QZCOM.MAILNETALAN@AI.AI.MIT.EDUDEVON@AI.AI.MIT.EDUROLL@AI.AI.MIT.EDUCENT5@AI.AI.MIT.EDUMOON@AI.AI.MIT.EDUSRA@AI.AI.MIT.EDUMRC@AI.AI.MIT.EDUJNC@AI.AI.MIT.EDUTAFT@AI.AI.MIT.EDUReceived: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 3 Aug 86 06:12:57 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2700899905748031@MIT-MULTICS.ARPA>; 03 Aug 1986 05:58:25 edt Date: 02 Aug 86 23:06 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Douglas E. Humphrey" , "Alan Bawden" Cc: DEVON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, "Pandora B. Berman" , MOON@AI.AI.MIT.EDU, "John T. Wroclawski" , "Rob Austein" , MRC@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU Subject: ks and ITS questions Message-ID: <192123@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].78091.860731.ALAN> TU45: Our 2020 has a TU-45 / Tm03 and it works with the tu77 code, without any problem. FAILPeter_Lothberg_STUPI%QZCOM.MAILNET<[AI.AI.MIT.EDU].78968.860803>JNC@XNOSHOWMRC%PANDA@NOSHOWNO-CLINOQCRFC733sra@xNOSHOWMOONNOSHOWCENT@APPENDNOSHOWROLL%SEARN.BITNET@WINOSHOWNOQCNO-CLINO-CLINOQCRFC733YN-!  )) )))%)-)5)=")E&)M*)U.)]2)e6)m:)u>)} OQ_)sf i))@H?$4 ??t` HPp( 8M(P W(  ;[ ( ;[( ;[( ;[((;[((P !( P0 ( P!;(XQX0" H#(3@$x5%  P =x'08&:8)5PC8*L8,?/ EP.0#`-P8104$P3I82(869 KP80&87+8;> ')HP=O8<8@C  DQPBU8APYxF0-G;[8E K.PJ]8IH_`_`DRSTAI.MIU].766V0728.W>XAI.MIY].767Z0728>[AI.MI\].767]0728.^<[AI._T.EDU`84.86aJAR>bAI.MIc].767d0728>eAI.MIf].769g0729.h<[AI.iT.EDUj26.86kGRUPPl<[AI.mT.EDUn29.86o<[AI.pT.EDUq33.86r<[AI.sT.EDUt33.86u<[AI.vT.EDUw33.86x<[AI.yT.EDUz33.86{<[AI.|T.EDU}33.86~<[AI..EDU33.86<[AI.T.EDU33.86<[AI.T.EDU33.86<[AI.T.EDU 33.86 <[AI. T.EDU 33.86<[AI.T.EDU33.86<[AI.T.EDU33.86<[AI.T.EDU33.86<[AI.T.EDU33.86<[AI.T.EDU33.86<[AI.T.EDU33.86<[AI. T.EDU!33.86"<[AI.#T.EDU$33.86%<[AI.&T.EDU'33.86(<[AI.)T.EDU*33.86+<[AI.,T.EDU-33.86.<[AI./T.EDU033.861<[AI.2T.EDU333.864<[AI.5T.EDU633.867<[AI.8T.EDU933.86:<[AI.;T.EDU<33.86=<[AI.>T.EDU?56.86@<[AI.AT.EDUB19.86CJAR>DAI.MIE].770F0729.G<[AI.HT.EDUI46.86JJAR>KAI.MIL].770M0729.N<[AI.OT.EDUP55.86QJAR>RAI.MIS].770T0729.U<[AI.VT.EDUW02.86X<[AI.YT.EDUZ02.86[<[AI.\T.EDU]02.86^<[AI._T.EDU`02.86a<[AI.bT.EDUc03.86d<[AI.eT.EDUf03.86g<[AI.hT.EDUi03.86j<[AI.kT.EDUl33.86m<[AI.nT.EDUo71.86pJAR>qAI.MIr].771s0729.t<[AI.uT.EDUv48.86wAAB>xAI.MIy].772z0729.{>|AI.MI}].772~0729.AI.MI].7720729>AI.MI].7730729.<[AI.T.EDU27.86 DRW> AI.MI ].773 0729.<[AI.T.EDU32.86DRW>AI.MI].7730729.>AI.MI].7730729>AI.MI].7740730.N>AI.MI].7740730>AI.MI].774deh@eneevax.umd.eduTAFT@AI.AI.MIT.EDUSRA@AI.AI.MIT.EDUROLL@AI.AI.MIT.EDUMOON@AI.AI.MIT.EDUJTW@AI.AI.MIT.EDUJNC@AI.AI.MIT.EDUDIGEX@AI.AI.MIT.EDUDEVON@AI.AI.MIT.EDUCENT@AI.AI.MIT.EDUALAN@AI.AI.MIT.EDUReceived: from eneevax.umd.edu by AI.AI.MIT.EDU 3 Aug 86 00:57:40 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA00380; Sat, 2 Aug 86 21:24:11 EDT Date: Sat, 2 Aug 86 21:24:11 EDT From: Douglas Humphrey Message-Id: <8608030124.AA00380@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, MRC%PANDA@SUMEX-AIM.ARPA Subject: Re: ks and ITS questions Cc: CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU Seems that everyone wants the console off of my KA, but I think I will keep it. Let me check with the folks I am working with on the 2020 and see if they have any around. They used to have a number of KA systems. The hardware involved with running the serial link should not be too bad. I have a number of KMC11 sets around here somewhere, and maybe some DMC too. It is the code to handle the serial that I wonder about. What does ITS know about in the way of comm devices for TCP/IP ? Since the vax has a unibus it should be pretty easy (assuming that the powers that be don't flip out) to put the same comm on eneevax that DX has and then either get a leased line or put up antennas and run packet radio. Doug FAILNET-ORIGIN<[AI.AI.MIT.EDU].78924.860803>NO-CLINOQCRFC733APPENDNOQCNO-CLIdeh@eNOSHOWJNC@XNOSHOWjtw@sNOSHOWMOONNOSHOWROLL%SEARN.BITNET@WINOSHOWNO-CLINOQCRFC733sra@xNOSHOWYN-!  mG7m G7 mG7 mG7m#G7m+G7m3G7m;G7!mCG7%mKG7)mSG7-m[G71mcG75mkG79msG7=m{G7 Zm$ ǭmm@Hǭ$  ǭǭt` HO To: joelll%UMass.BITNET@WISCVM.ARPA, kin@ht.ai.mit.edu Subject: Re: a rare flame... Date: Tue, 22 Jul 86 17:20:35 EDT From: joelll%UMass.BITNET@WISCVM.ARPA (Tech_Noir) Subject: a rare flame... [heavily abridged] I am a new user on this list. I was originally added by Andy Hommel, I was added by swa, who had at previous times told me to wait before joining the list. When HE thought I was ready, he added me. Soon after, I attended Kabuki and my second Boskone. More recently, I went to Eliot's party. I got a chance to meet many people, and found them to be PRECISELY the type of people I want to form friend- ships with, and to communicate with, and all of the other wonderful things that make groups of people fun. [...] Should I not even be here because I haven't met Bandy face_to_face, or been on the list for all the years it has existed? I would like to stay here for as long as I can, for as long as I can access Cyber, or any other machine that talks to the Internet, for you people, all of you, mean more to me now than any other group I have hung around with. Ever. I needed to see someone else say it before I realized it, but amen. Ad Infinitum, 'Atrocity' Joelll Herda, 'kin-bounce at Umass manager, Internet: Joelll%Umass.bitnet@Wiscvm.WISC.edu UsNail: 322 River Rd., Hadley MA, 01035 Phone: 413-LIX-HICK Thanks, joelll, you said it better than I could have. I agree with every word. Dave Harmon FAILdmh Re: a rare flame...<[AI.AI.MIT.EDU].74657.860723>NO-CLIFILEFAST-APPEND[USERS1;DRW3RD CLASS]FILENOSHOWYN-!  vhv vhvvh vvhv$vhv,vhv4vhvv =vh$8 wvhvh@Hw$ y(HwHwt` HOFpxP/ 0kN.,i 0i70X0 %H  Ox '@x)88z81PXT5 P;`=`=` Rec: froAX.LCDRW-THIRD-CLASSKFLJBVBReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JUL 86 18:24:07 EDT Received: from HT.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 19 Jul 86 18:16-EDT Received: from seismo.CSS.GOV by ht.ai.mit.edu with TCP; 19 Jul 86 18:14:50 edt Return-Path: <@AI.AI.MIT.EDU:don@brillig.umd.edu> Received: by seismo.CSS.GOV; Sat, 19 Jul 86 18:14:34 EDT Received: from brillig.umd.edu by AI.AI.MIT.EDU 19 Jul 86 18:15:00 EDT Received: by brillig.umd.edu (5.9/4.7) id AA07346; Sat, 19 Jul 86 18:13:48 EDT Date: Sat, 19 Jul 86 18:13:48 EDT From: Don Hopkins Message-Id: <8607192213.AA07346@brillig.umd.edu> To: KFL@ai.ai.mit.edu Cc: ayermish@athena.mit.edu, KIN@ai.ai.mit.edu, don@brillig.umd.edu In-Reply-To: "Keith F. Lynch"'s message of Sat, 19 Jul 86 15:30:17 EDT Subject: Flamage Keith, `-__ _ _ `--__ \ / \ \| \ V \ \_ | | \_ \|/ | \. -*- | \ /|\ / | /|\ | |\ _.--/ | \--._ /| | |-(-| | | | } | | | |-~-| | kiss mine. -Don P.S.: I used a mirror -- it's authentic. FAILdon Flamage<[AI.AI.MIT.EDU].72832.860719>NO-CLIFILEFAST-APPEND[USERS1;DRW3RD CLASS]FILENOSHOWYN-!  mm mm m m mm $mm ,mm 4mm m  qm$< m$mm@Hm$$* oDHm$Hm$t` HOpxP0j 0kN.,i 0i70X80 dH  x e@pg)88]8 kP,(mP0p`q`q` Rec: froAX.LCDRW-THIRD-CLASSKFLJBVBReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JUL 86 18:10:26 EDT Received: from HT.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 19 Jul 86 18:00-EDT Received: from seismo.CSS.GOV by ht.ai.mit.edu with TCP; 19 Jul 86 17:58:06 edt Return-Path: <@MC.LCS.MIT.EDU:mikki@aim.rutgers.edu> Received: by seismo.CSS.GOV; Sat, 19 Jul 86 17:57:51 EDT Message-Id: <8607192157.AA21439@seismo.CSS.GOV> Received: from AIM.RUTGERS.EDU by MC.LCS.MIT.EDU 19 Jul 86 17:59:22 EDT Date: 0 0 00:00:00 EDT From: Subject: hobbit's mother To: "kin" Cc: mikki@seismo.CSS.GOV Reply-To: is Barbara G. Walker. Among the books I have read of hers are "The Crone", "The Women's Encyclopedia of Myths and Secrets", and a tarot book she wrote that has an accompanying deck coming out. She has written many others, but they are tough to find. Let me know what you think of them... Mikki ------ FAILmikki hobbit's mother<[AI.AI.MIT.EDU].72827.860719>NO-CLIFILEFAST-APPEND[USERS1;DRW3RD CLASS]FILENOSHOWYN-!  mm mm m m mm $mm ,mm 4mm m  pm m$mm@Hm$$ oDHm$Hm$t` HOz+pxP0i 0kN.,i 0i70X$0 H (d x 0@pf]88v8 jP,(lP0o`p`p` Rec: froAX.LCDRW-THIRD-CLASSKFLJBVBReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JUL 86 18:00:12 EDT Received: from HT.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 19 Jul 86 17:50-EDT Received: from seismo.CSS.GOV by ht.ai.mit.edu with TCP; 19 Jul 86 17:47:10 edt Return-Path: <@MC.LCS.MIT.EDU:mikki@aim.rutgers.edu> Received: by seismo.CSS.GOV; Sat, 19 Jul 86 17:46:52 EDT Message-Id: <8607192146.AA21327@seismo.CSS.GOV> Received: from AIM.RUTGERS.EDU by MC.LCS.MIT.EDU 19 Jul 86 17:48:10 EDT Date: 0 0 00:00:00 EDT From: Subject: shelli p.s. To: "kin" Cc: mikki@seismo.CSS.GOV Reply-To: Wasn't she the one who said my account should be deleted on unirot because I didn't have enough respect for computer operators?!?!? Oh dear! More cat fights on kin a-brewin'. Well, at least I have the Kik-Mi-Do school to go front kick her to death (if they don't pun her to death first). Mikki ------ FAILmikki shelli p.s.<[AI.AI.MIT.EDU].72823.860719>NO-CLIFILEFAST-APPEND[USERS1;DRW3RD CLASS]FILENOSHOWYN-!  mm mm m m mm $mm ,mm 4mm m  m$6 m$mm@Hm$$, oDHm$Hm$t` HOtjpxPq 0kN.,i 0i70X<0 1H Lc x Dg@xk888sPX:Tw >P}```DRW-THIRD-CLASSKFLJBVBReceived: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JUL 86 17:48:28 EDT Date: Sat 19 Jul 86 17:39-EDT From: David Chapman Subject: Hobbit's mother? To: kin%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU So, what's her name? I want to read her if I haven't already. (Sounds rather like Diane Duane, whom I recommend very highly for anyone who wants great Pagan bisexual swords-and-sorcery with real psychological insight.)FAILZVONA%OZ.AI.MIT.EDU Hobbit's mother?<[AI.AI.MIT.EDU].72820.860719>NO-CLIFILEFAST-APPEND[USERS1;DRW3RD CLASS]FILENOSHOWYN-!  /'//' / /'//'//'$//',//'4//'/'|/ ^/'$" /g/'/'@H/g$ 1/g/gt` HOJ]p P0]0s,X60H X Y@ pZ ` 8^`^` (X CK0Z`[CKp^CENTBARTHReceived: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JUL 86 16:18:38 EDT Date: Sat, 19 Jul 86 16:16:28 EDT From: Richard Barth To: CENT%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU cc: MBECK%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU, BARTH%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].934533.860719.BARTH> Penny- I just transferred over to MX after I found I couldn't read my mail on AI due to the directory being ful. I tried copying my mail file from AI over here to MX and was told the file didn't exist. It's been several days since I checked in here to read my mail and am on a couple of mailing lists, so I don't believe nobody sent me anything. More likely the mail file didn't et created because of the directory problem. Is it still possible to get my mail out of the bit bucket, and if so, how? FAILBARTH%MX.LCS.MIT.EDU<[AI.AI.MIT.EDU].72798.860719>APPENDYN-!  RRR R RRRRR$RR,RR4RRR|R  KR$$ R[RR@Hq$& t+qqt` HO%D0 s,H0P0XX@%X (`h` h0``0`?sI A0!;h"0$!PWORDZVONE___024___024I used to have a T-Abrax@AI, but it's gone.<[AI.AI.MIT.EDU].70851.860716.___024>ZVONE"ZVONE" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS3;ZVONE MAIL".Date: Wed, 16 Jul 86 01:20:07 EDT From: ___024@AI.AI.MIT.EDU To: ZVONE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].70851.860716.___024> YN-!  RRR R RRRRR$RR,RR4RRR|R  R]? R[RR@H$  t` HX0s,0*0 +@xWx](eHe%` (5` (5`============ A copy of your message is being returned, because: ============ "ZVONE" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS3;ZVONE MAIL". ============ Failed message follows: ============ Date: Wed, 16 Jul 86 01:20:07 EDT From: ___024@AI.AI.MIT.EDU To: ZVONE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].70851.860716.___024> I used to have a T-Abrax@AI, but it's gone.___024FAIL<[AI.AI.MIT.EDU].70852.860716>Msg of Wednesday, 16 July 1986 01:20-EDTCOMSAT___024Date: Wed, 16 Jul 86 01:20:10 EDT From: Communications Satellite Subject: Msg of Wednesday, 16 July 1986 01:20-EDT To: ___024@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].70852.860716> YN-!  zdzdzd zd%zd-zd5zd=zdEzd"Mzd&Uzd*]zd.ezd2mzd6uzd:}zd>  #zd$. {zdzd@H{$, }$H{H{t` HX80s,00 @x x(H/` P` P`Queued: leon%case at CSNET-RELAY.ARPA SILVERFAIL<[AI.AI.MIT.EDU].68093.860710>Msg of Thursday, 10 July 1986 19:53-EDTCOMSATDate: Thu, 10 Jul 86 19:53:43 EDT From: Communications Satellite Subject: Msg of Thursday, 10 July 1986 19:53-EDT To: SILVER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].68093.860710> YN-!  X*UX*UX* UX*U%X*U-X*U5X*U=X*UEX*"UMX*&UUX**U]X*.UeX*2UmX*6UuX*:U}X*>U  >X*$2 XJX*X*@HXJX ZjHXJHXJt` HNS~ZpY0kN.,i 0s,X!P0 7Ho x `8@ p; `8>`>` > A} 0@A_ MJWPLKReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUL 86 18:09:33 EDT Received: from AMSAA by MC.LCS.MIT.EDU 10 Jul 86 17:49:04 EDT Received: from brl-smoke.arpa by AMSAA.ARPA id a023537; 10 Jul 86 17:19 EDT Received: from USENET by SMOKE.BRL.ARPA id a003503; 10 Jul 86 17:07 EDT From: "Virginia A. Kaste " Newsgroups: net.micro.cpm Subject: testing distributions again Message-ID: <2094@brl-smoke.ARPA> Date: 10 Jul 86 21:07:48 GMT To: info-cpm@AMSAA.ARPA for info-cpm FAILginny testing distributions again<[AI.AI.MIT.EDU].68044.860710>YN-!  Y YY Y Y YY YY $YY ,YY 4YY Y |Y  aY $ YIY Y @HYIX [YIYIt` HNR|]pY0kN.,i 0s,X70H(Z x |@ p^ |`8a`a` "SHCPMJWPLKReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUL 86 13:32:16 EDT Received: from AMSAA by MC.LCS.MIT.EDU 10 Jul 86 13:29:26 EDT Received: from brl-smoke.arpa by AMSAA.ARPA id a014900; 10 Jul 86 12:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a019630; 10 Jul 86 12:17 EDT From: Sunil Bhargava Newsgroups: net.micro.cpm,net.micro.pc,net.wanted Subject: Re: Removal from mailing list. Message-ID: <2076@brl-smoke.ARPA> Date: 10 Jul 86 16:17:45 GMT Expires: 7/17/86 Keywords: sale wanted To: info-cpm@AMSAA.ARPA I want a second hand baby blue board for an ibm pc. That is the cpm emulation board for the pc. I am willing to pay about $100 for one in perfect working condition, with manual and software. Please reply to me directly since I am not on this mailing list. thanx Reply-to: sunil@brl.arpa FAILsunil Re: Removal from mailing list.<[AI.AI.MIT.EDU].67881.860710>YN-!   %-5="E&M*U.]2e6m:u>}  S$ C@HC$: CCt` HNL@pY00s,X0 0HPO@pP` S` S`rmmD0F!(GL0JEC0K0LQPLUKELReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUL 86 19:02:25 EDT Received: from CIPG.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUL 86 18:59:38 EDT Return-Path: Received: by cipg.mit.edu (4.12/MIT/CIPG.1x.1) on Wed, 9 Jul 86 18:58:43 edt; Date: Wed, 9 Jul 86 18:58:43 edt From: Greg Troxel To: eichin%athena.mit.edu@cipg.mit.edu Subject: correction to last message Cc: w1xm@cipg.mit.edu Mark, Speed dialing to Mary's will not happen because it's very clearly against the rules (regular dialing will not happen either) - it facilitates the regular business of the restaurant. Greg p.s. I cc'd this to the list on purpose - please be careful when replying to do that only if you want to. FAILNET-ORIGIN<[AI.AI.MIT.EDU].67542.860709>iYN-I!  ^  ^  ^  ^ & ^ . ^ 6 ^ > ^ F ^# N ^' V ^+ ^ ^/ f ^3 n ^7 v ^; ~ ^?   b ^$.!  ^ ^@H#u$ %#u#ut` HNIT.pY00s,X9X0HP^@p_y` b` b`/ N8 PpR0TUUPLUKELReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUL 86 07:33:03 EDT Received: from CIPG.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUL 86 07:31:31 EDT Return-Path: Received: by cipg.mit.edu (4.12/MIT/CIPG.1x.1) on Wed, 9 Jul 86 07:30:48 edt; Date: Wed, 9 Jul 86 07:30:48 edt From: Greg Troxel To: w1xm@cipg.mit.edu Subject: correction to last message Ross (N0GSZ) also helped with the controller installation (I was asleep while typing the last message). We are thinking about having speed dial codes for various police/fire/etc, currently planning to include (eventually): CAMBRIDGE PD/FD MIT CP BEL PD/FD WAT PD/FD ARL PD/FD BOS PD/FD/AMB STATE PD (HQ/A Troop/logan/turnpike) Please send me mail if you have any others you would like to see included - if several people live in a town we can probably add them. Greg, N1DAM FAILNET-ORIGIN<[AI.AI.MIT.EDU].67222.860709>YN-!  cLcL cLcL%cL-cL5cL=cL"EcL&McL*UcL.]cL2ecL6mcL:ucL>}cL  $ @Hu ׇt` HNCiYp{(x0s,(X0mH7 {x $o@ xq X(y``x{``K M'ECQjnc@proteon.comTATF@ai.ai.mit.eduReceived: from brubeck.proteon.com by AI.AI.MIT.EDU 8 Jul 86 17:24:41 EDT Date: Tue, 8 Jul 86 15:09:26 EDT From: jnc@brubeck.proteon.com Reply-to: jnc@proteon.com Subject: Ethernet To: cjl@ai.ai.mit.edu,tatf@ai.ai.mit.edu CC: rfb,jnc Well, I juts found out I am flying out to Champaign-Urbana at 7:45 this evening, so I guess I won't be able to come look at the Ethernet this evening after all. Some days you get the elevator, some days you go to Illinois. I'll be back tomorrow.... ------- FAILjnc Ethernet<[AI.AI.MIT.EDU].67002.860708>TATF"TATF" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS3;TATF MAIL".YN-!  R R RR$R,R4R<R"DR&LR*TR.\R2dR6lR:tR>|R  $ @Hq5 #t` HN=%pY00s,XV80HP @p򳞓O` ` `9p% oPLUKELReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JUL 86 23:26:30 EDT Received: from CIPG.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 JUL 86 23:23:58 EDT Return-Path: Received: by cipg.mit.edu (4.12/MIT/CIPG.1x.1) on Mon, 7 Jul 86 23:23:23 edt; Date: Mon, 7 Jul 86 23:23:23 edt From: Greg Troxel To: w1xm@cipg.mit.edu Subject: new controller As you may have noticed, the 9.2 machine has a new controller, which myself, Bill (N1CPK), and Steve (W1GSL) installed this weekend. The machine is currently under test, but the autopatch does work. Probably at about the end of the week, if there are no problems with the controller, the patch codes will be given out to club members. For at least the summer (and probably later - to be decided by the club) the patch will be available ONLY to club members. Any questions regarding this stuff should be directed at me (Greg Troxel, N1DAM, 258-2240 days, 4845692 evenings until 2200) and should not be discussed over the air. Some codes can be used now. These should be told only to club members, but do not need to be worried about very much. 1* (or 1 and carrier drop) - id and send grid square 2* (or 2 and carrier drop) - send time A* - send next message at 13 wpm (instead of 20 wpm) Greg Troxel, N1DAM President, MITUHFRA FAILNET-ORIGIN<[AI.AI.MIT.EDU].66687.860707>YN-!  ma mamama !ma)ma1ma9maAma Ima$Qma(Yma,ama0ima4qma8yma< 246ma$& pmama@Hp$  v!HpHp` HN5Fp(/(`@+(Xg 09H0 (/x 0@ xA 򳉽]8`GPH$P %PKxMPO8($QPS8DUP +PWPY8L ($[P]8T_P#008"s'('@1P&028%++('X3P*i8)/k.+P/068-3 A(7P2o81#7qP6s858u:+P;0;89 ?I*(<P>y8=C {PB0>8A0?F+PG0@8EkK0APJ0B8I@CN+PO8MS PR0E8Q4W(8FPV0G8U[(@HPZ0I8Y_JP^8]Pb8a(f(HPe8d,jhPi8h'n(/Pm8lr Pq0U8pXvV0s,Pu8tg y+Pz0X8xo~ xYP}8|! AP0\8\:0]P0^8 p_P 8$P8 ,P0e8$$50fP0g80 8hP8<,P0m8H"h!nP!8 P&(',P%0q8$c*rP)`(3.@P-8,{`0`w56789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~    Slocum.CSCDA@HI-MULTICS.ARPAPAGANISM@AI.AI.MIT.EDUReceived: from HI-MULTICS.ARPA by AI.AI.MIT.EDU 2 Jul 86 15:33:26 EDT Date: Wed, 2 Jul 86 13:08 CDT From: Brett Slocum Subject: reclaiming letter #3 To: paganism@AI.AI.MIT.EDU, hoptoad!newage@LLL-CRG.ARPA Message-ID: <860702180825.132872@HI-MULTICS.ARPA> [We asked our friend Luis, an anthropologist, who spends time on Pine Ridge, to respond to Brett Slocum's letter. -- eds.] The Finger Pointing at the Moon is not the Moon: Is it Really a Finger? by Luis Kemnitzer In our search for spiritual experience, spiritual knowledge, and spiritual power, we enter a world of shadow and illusion, ambiguity, danger. We're not quite sure what we're looking for until we've found it, or more accurately, it has found us. Then we can't really talk about it, except in roundabout ways and in a vocabulary that is at best only allusory. For most of us who have been separated from the traditions that had or have a living vocabulary to talk about these things, the vocabulary is artificial, borrowed, attenuated. Since we don't know what we're looking for, sometimes in our impatience we might succumb to illusions, either created by ourselves or waved in front of us by people who are good at creating illusions. This is especially poignant in these times when everything is in danger of becoming a commodity, from love to children and, yes, spirituality. The need for connection to the TaoGodGoddessAllThatIsAroundUsInsideUs is compelling, and many of us try to express our understanding of the connectedness of our concerns for the future of the Earth, for community, healing, egalitarian life, peace and justice, all of those fine PC things, in terms of spirituality. Other people try to find some meaning in their personal life, effect personal growth (whatever that means), or gain some measure of control over their life by attaching themselves to what they think is a long tradition that lives beyond the mean oppressiveness of commodity society. Note that I said oppressiveness, not oppression. It is ironic that the main set of traditions (note: plural, not singular) that do have living languages to talk about spiritual experiences and that are connected to the forces that swirl around our home here belong to the people that the society of these new seekers has oppressed for the last 500 years, and continues to oppress, in Lake County, in Arizona, in South Dakota, in Michigan, in most of our neighborhoods. The spiritual traditions of Native Americans, as those of all indigenous people (including Europeans, Africans, Asians, Pacific Islanders) are rooted in their relationships to the land and its inhabitants that they have lived with for generations: that oak tree south of Chico who was the source of the twelve kinds of acorns that fed the maidu, and who bled when the white man cut it down; that rock on the Marin county coast where Coyote smashed the quartz crystal and formed the Golden Gate; that hot spring that heals; that hill where grandfathers for generations back made their vision quest; that creek where this family has cut willows for generations; that butte with the cave where the wolves protected a woman escaping from her enemies a long time ago. All these, and many more, places of food, medicine, spiritual power, comfort or rest for the dead are now fenced in, paved over, chewed up and ripped off, by the society that rejects or is rejected by people who now seek the spiritual power of the people and places that remain, and who if they can't get the power, want to play with the language of that power. And, succumbing to the commodity society, there are Indians who will accommodate them. In all our sincerity and good will, we may forget that while we may borrow the trappings of a romantic image of the original trustees of this continent real Indians are still being forced out of their ancestral homes, real Indians are being denied access to their spiritual locations, real Indians are in jail for being Indians, real Indians are losing their children to strangers, the list of current oppression goes on and on. The life that produced and still produces powerful practices for healing, for communication with the spiritual world, also includes poverty, discrimination, family disorganization, disease, dislocation, and all the other good things that go with commodity society. If you want one, you have to deal with the other. As individuals we may not think of ourselves as oppressors, but we are trapped in the structure as representatives of the oppressing society. In 25 years of close work with Indians I have always been conscious of that fact, and as long as commodity society and its agents can move Navajos off Big Mountain, steal land from White Earth reservation, keep Leonard Peltier in jail, steal Rattlesnake Island, deprive Yuroks of their fishing rights, no amount of good will and deep friendship and constructed kinship is going to change it. I can't offer any resolution to this dilemma. Certainly it's possible that non-Indians could grow and become more effective fellow guardians of the Earth by becoming better acquainted with Native spiritual traditions. Borrowing ideas and actions helps traditions adapt and survive -- the Longhouse of the Iroquois Confederation has its roots in Hiawatha, but Handsome Lake revitalized it with ideas he got from the Quakers and made Iroquois; Navajo got their sheep from the Spanish and a lot of their ritual from the Hopi, but now their Navajo sheep and Navajo rituals. But in the absence of an egalitarian relationship between Indians and non-Indians, observation and borrowing of Indian spiritual ideas can only be done in a consciousness of the relationship between Native Americans and the society that endangers them and uses them as a model to teach racism to the rest of the world. This also means active support for their struggles for life and self-determination, as well as a close examination of one's own motives, and a proper humility in approach to the spirits, the religion, and any knowledge/power that one might gain as a result of the encounter. Claims to have learned this or that ritual, to the acquisition of this or that Indian power, selling of symbols in high-priced "shaman workshops", and the like smell of the 19th century practice of advertising quack medicines by claiming they were secret potions learned from an Indian medicine, and are just repeating another stereotype. One more thing: spiritual power don't make you good. FAILSlocum reclaiming letter #3<[AI.AI.MIT.EDU].64848.860702>ZVONASMALL-CLINOQCAPPENDRFC733NOSHOWhiller.pa@NOSHOWDEVONNOQCNO-CLINOSHOWegk%panda@NOSHOWGYRONOSHOWlah%miro@bNOSHOWoster%lapis@berNOSHOWMROSENOSHOWmroseNOSHOWleslie@lllNOSHOWSTRAZNOSHOWstrazNOSHOWGub@oNOSHOWBATALINOSHOWBATALINOSHOWPWCNOSHOWpwc@oNOSHOWCaro.pa@XENOSHOWsorceror@lNOSHOWrdo@eNOSHOWLIZZITNOSHOWMarshall.osbunorth@XNOSHOWfrieman@arNOSHOWSlocum@HI-NOSHOWasp@oNOSHOWDRWNOSHOWPDBNOSHOWPat%UPenn.CSNETNOSHOWmikegNOSHOWcindyb@athNOSHOWhoptoad!kaaren@NOSHOWwell!josh@NOSHOWhoptoad!tim@lllNOSHOWwatson@su-NOSHOWmag%gitpyr%gatech.csnet@CNOSHOWcullvax!ddg@eddNOSHOWdjb@mNOSHOWkayvan%cory@berNOSHOWoaf@oNOSHOWpaganism-archive@ozNOSHOWYN-!  p p p p#p+p3p;p!Cp%Kp)Sp-[p1cp5kp9sp={p 27i$ @H$4 _` HN4 p(/(`@(M(X1\ 0H0B (/x  C@ pE 򳉶8`(HP$PP0Jx0KP0L8(HMP0N8D(OPP0PP0Q8L (HRP0S8T TP#8"s'(' P&8%++(',P*0Y8)/(Z.(MP/8-3 AP20\81#70]P60^858(_:(MP;89 ?I*P>0a8=CbPB8AF(MPG8EkKPJ8I@ N(MPO0h8MSiPR8Q4W(PV8U[( PZ8Y_ P^0o8]0pPb0q8a(f(rPe0t8d,jh8uPi0v8h'n(/0wPm0x8lryPq8pXv 0s,Pu0{8tg|y(MPz8xo~ <P}08|! A(P8\:P8 8P 08HP08 XP8$$5P80 \P08<XP#8H"h! %P!08 P&('XP%+8$c* -P)0`(3.P-08,{`0`wx4t5p89:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyzN3:{(/|`}@~/;( \ 0B(/HCpD򳉳`(G $  0I 0J0K(HL0MD(N0O0PL(HQ0RT Ss(' Slocum.CSCDA@HI-MULTICS.ARPAPAGANISM@AI.AI.MIT.EDUReceived: from HI-MULTICS.ARPA by AI.AI.MIT.EDU 2 Jul 86 15:30:40 EDT Date: Wed, 2 Jul 86 13:00 CDT From: Brett Slocum Subject: reclaiming letter1 To: paganism@AI.AI.MIT.EDU, hoptoad!newage@LLL-CRG.ARPA Message-ID: <860702180008.899973@HI-MULTICS.ARPA> Some Thoughts on Shamanism in the Pagan Community by Bob Gustafson, Mohawk Nation An oft-told story in Indian country concerns a Plains elder who traveled to Washington, D.C. to express a long-standing grievance with the Bureau of Indian Affairs. In an effort to butter the old man up, the BIA official took him out to dinner at an expensive restaurant and told him he could have whatever he wanted on the menu. The old man promptly ordered a steak and made quick work of it when it was served. Seeing the elder's still- hungry look, the official told him to go ahead and order another. The old man did so and ordered and ate a third as well. In awe, the BIA official said, "Gee, Chief, I sure wish I had your appetite." To which the old man, shaking his head, replied, "You've stolen our land, taken nearly everything we have, and now you even want my appetite." This story reflects the feelings of many of us as we watch non-Indian Pagans take over our traditional ways -- vision quests and sweat lodges, for example. The current vague, and often erroneous, articles and discussions of Shamanism in the non-Indian community are the most recent and disturbing manifestations of this takeover. Before delving into Native traditions, be they the Way of the Longhouse, the Sun Dance, or the Kiva, non-Indian Pagans should keep in mind the following points. First and foremost is the fact that our Warriors have fought and died as recently as the last decade to defend and preserve our old ways. That struggle continues. Second is the fact that all of our medicine ways are tribal and intended to serve the People. Ours is not a tradition where "you do your own thing." Third, true sharing comes only between equals -- not between oppressor and oppressed. Let there be no mistake; we are still an oppressed People in our own homeland. Fourth, our traditional elders do not advertise in the pages of New Age or in Pagan publications. Indeed, our traditional elders are among our most militant political leaders. Many of them urge total separation from the dominant society. Fifth, Europe was once as tribal as we continue to be. Non- Indian Pagans have their own roots to draw upon. Sixth, some of our spiritual leaders have taken under their wings a select number of non-Indians. In my experience, these have been people who have helped us in our struggle, e.g., non-Indian medics who served inside Wounded Knee. Learning our ways is a privilege that must be earned. Finally, keep in your minds that my ancestors presented Dutch invaders with a two-row band of wampum. The two rows were to symbolize that the two cultures were intended to live separately, but in peace, on this continent. The wampum band still exists. Peace with Justice is still a dream. Oneh. FAILSlocum reclaiming letter1<[AI.AI.MIT.EDU].64846.860702>ZVONASMALL-CLINOQCAPPENDRFC733NOSHOWhiller.pa@NOSHOWDEVONNOQCNO-CLINOSHOWegk%panda@NOSHOWGYRONOSHOWlah%miro@bNOSHOWoster%lapis@berNOSHOWMROSENOSHOWmroseNOSHOWleslie@lllNOSHOWSTRAZNOSHOWstrazNOSHOWGub@oNOSHOWBATALINOSHOWBATALINOSHOWPWCNOSHOWpwc@oNOSHOWCaro.pa@XENOSHOWsorceror@lNOSHOWrdo@eNOSHOWLIZZITNOSHOWMarshall.osbunorth@XNOSHOWfrieman@arNOSHOWSlocum@HI-NOSHOWasp@oNOSHOWDRWNOSHOWPDBNOSHOWPat%UPenn.CSNETNOSHOWmikegNOSHOWcindyb@athNOSHOWhoptoad!kaaren@NOSHOWwell!josh@NOSHOWhoptoad!tim@lllNOSHOWwatson@su-NOSHOWmag%gitpyr%gatech.csnet@CNOSHOWcullvax!ddg@eddNOSHOWdjb@mNOSHOWkayvan%cory@berNOSHOWoaf@oNOSHOWpaganism-archive@ozNOSHOWYN-!  | | | |#|+|3|;|!C|%K|)S|-[|1c|5k|9s|={|  $ [@H2$" 5;22t` HN|Ip((00s,(XGH0H0w (x Xx@ x |X(8~``(`` 0~xLAUREL@SRI-KL.ARPARIPPLE@AI.AI.MIT.EDUReceived: from SRI-KL.ARPA by AI.AI.MIT.EDU 2 Jul 86 13:31:53 EDT Date: Wed 2 Jul 86 10:30:18-PDT From: Laurel Shimer Subject: DISK SPACE To: RIPPLE@AI.AI.MIT.EDU, WHALEN@SRI-KL.ARPA cc: ORAM@SRI-KL.ARPA, LAUREL@SRI-KL.ARPA Barbara I need to figure out how to allocate the 600 cylinders of disk space. I'm not sure what the set up will be. I know you and Phil will each have your own big master data base. How many of these might there be? How many records might be in each one at a time? We could put it all into one data id and allow write update from the different editor id's, as long as the data bases themselves have different names. The problem with splitting it up is that if we need to reassign disk space to a different id, then finding that much contiguous dasd without having to get operations involved and doing a compress is not very likely. The simplest would be put it all in one place, but it could be risky if different editors try to access the same database at the same time. Maybe we could talk about it tommorw. I'd like to go ahead and get it set up while you're gone. Laurel ------- FAILLAUREL DISK SPACE<[AI.AI.MIT.EDU].64757.860702>RIPPLE"RIPPLE" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS3;RIPPLE MAIL".YN-!  "t "t"t "t #"t+"t3"t;"tC"t!K"t%S"t)["t-c"t1k"t5s"t9{"t= o"t$ #"t"t@H#$ %4H#H#t` HN-BpY0s, 8 X80gH 4  A@ xi -`o`o`xpX9xhxoDRWGSBReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUL 86 01:37:07 EDT Received: from BORAX.LCS.MIT.EDU by MC.LCS.MIT.EDU 2 Jul 86 01:33:35 EDT Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Wed, 2 Jul 86 01:30:06 edt Date: Wed, 2 Jul 86 01:30:06 edt From: root@BORAX.LCS.MIT.EDU (Melkor) Message-Id: <8607020530.AA01363@BORAX.LCS.MIT.EDU> To: kabuki Kabuki is meeting on Thursday this week at the usual place (Kabuki restaurant), usual time (7:30 PM). RSVPs to kabuki-rsvp@borax. FAILroot<[AI.AI.MIT.EDU].64544.860702>YN-!  fQf fQffQ ffQf$fQf,fQf4fQff fQ$( fqfQfQ@Hfq$< kHfqHfq` HMm &p (D(Xe`0 wH (x D@ x v[8p~P08 8 P` ` `T  / _@SU-AI.ARPA:FAHLMAN@C.CS.CMU.EDUCOMMON-LISP-STUFF@AI.AI.MIT.EDUReceived: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 23:11:37 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jun 86 19:59:14 PDT Received: ID ; Sun 29 Jun 86 22:29:52-EDT Date: Sun, 29 Jun 1986 20:59 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: SANDRA Cc: common-lisp@SU-AI.ARPA Subject: Error signalling Let me get this straight: what is being proposed is that when *user* code is compiled with safety=0, *system* functions are allowed to bypass error checking? Presumably one would have to implement this by having two sets of system functions, the default one that does the error checks and another one that doesn't, and make the compiler smart enough to make the substitution when appropriate. Bleah -- I can see doing this manually for a few functions, but trying to cover all the places where CLtL says "it is an error" seems like a royal pain. If this is adopted as part of the standard, I'd also like to see some mechanisms to help automate the implementation provided. I think "user" code could also make good use of the same hooks for optional error checking. First, to repeat what I said earlier, nobody is proposing that all "it is an error" cases come under this rule. The question was whether we want to do this for three important classes of errors, perhaps creating a precedent for the handling of other things. Second, the cases in question are typically those that are open-coded by the compiler. Everyone agrees that, other things being equal, CDR should check that its argument is a list, SVREF should check for an out-of bounds reference, and function calls should check that the number of arguments is legal. But when these things are open-coded, the cost of these tests might slow things down by a factor of 2 or more. That is why the manual does not currently require that an error be signalled in such cases. The suggestion is that we require every implementation to provide the safe version to users who ask for safety; if user code is compiled with safety = 0, the compiler may (but is not required to) omit the runtime checks in favor of greater speed. My guess is that most implementations will choose to provide only one version of built-in system functions, and that these versions will be safe in the necessary ways. Basically, this would mean that the built in functions do not contain any errors and that they subject the user's arguments to the appropriate scrutiny to make sure that they are legal. It would be allowable to provide a second, quick-and-dirty version that is called by user code compiled when safety = 0, but in most cases the savings would so small that implmentors would not bother to do this. It is always legal to have more safety than is required. A minor point -- why restrict error checking to all-or-nothing? Some assumptions about argument values may be "safer" than others. If you set safety=3 you probably want to be extra paranoid and do *more* error checking than the default. In other words, the error checks should be qualified with a safety setting.... I am not suggesting that we restrict error checking to all-or-nothing. The suggestion was that these particular checks should kick in whenever safety is greater than 0, but the important issue is whether we require these checks to be available at SOME level of safety. Currently this is completely at the discretion of the implementor. -- Scott FAILFahlman Error signalling<[AI.AI.MIT.EDU].63439.860629>FILE[NIL;CL STUFF]FILENOSHOWFILE[NIL;CL STUFF]FILENOSHOW(FILE [NIL;CL STUFF])YN-!   U U  U  U# U+ U3 U; U!C U%K U)S U-[ U1c U5k U9s U={ U $4 @H$: )t` HMm `p (`D (X 0HPi@ pj v8  m8 oP8 pqP0s`t`t`(t,I0E"@SU-AI.ARPA:franz!fizzy!jkf@kim.Berkeley.EDUCOMMON-LISP-STUFF@AI.AI.MIT.EDUReceived: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 23:06:08 EDT Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 29 Jun 86 19:54:45 PDT Received: by kim.Berkeley.EDU (5.51/1.14) id AA24458; Sun, 29 Jun 86 18:50:22 PDT From: franz!fizzy!jkf@kim.Berkeley.EDU Received: from fizzy by franz (5.5/3.14) id AA08721; Sun, 29 Jun 86 18:18:01 PDT Received: by fizzy (4.12/3.14) id AA04052; Sun, 29 Jun 86 18:18:24 pdt Return-Path: Message-Id: <8606300118.AA04052@fizzy> To: ucbkim!utah-cs.arpa!shebs (Stanley Shebs) Cc: common-lisp@su-ai.arpa Subject: Re: Error Signalling In-Reply-To: Your message of Sun, 29 Jun 86 18:09:30 MST. <8606300009.AA12645@utah-orion.ARPA> Date: Sun, 29 Jun 86 18:18:21 PDT >> It's *probably* not a portability problem that (safety 1) means something >> different in different implementations. PCLS uses the speed settings to >> switch various kinds of optimizations, but we didn't have much intuition >> about what the difference between (speed 2) and (speed 3) should be >> ... We also didn't know what should be done for the various settings of speed, size and safety so we put the decision back in the users' hands. Our compiler can perform a number of optimizations, some of the optimizations involve removing safety checks and for these we felt that the user should be aware of what they are and should have control over when they are done. Therefore each optimization is controlled by a function of safety, size and speed. The user is free to redefine the functions if he doesn't like the default function. Here is an example of the function which controls one of the optimizations discussed recently: that of not checking the number of arguments passed to the function: (defvar verify-argument-count-switch #'(lambda (safety size speed) (declare (ignore size)) (or (< speed 3) (> safety 0))) "bound to a function which given safety, size and speed returns t if the compiler should generate code to verify that the correct number of arguments were passed to a function. Note: an argument count check is always done if there are optional or rest arguments.") -john foderaro Franz Inc. FAILNET-ORIGIN<[AI.AI.MIT.EDU].63434.860629>FILE[NIL;CL STUFF]FILENOSHOWFILE[NIL;CL STUFF]FILENOSHOW(FILE [NIL;CL STUFF])YN-!  SSSS SSSSS&SS.SS6SS>S#SFS'SNS+SVS/S^S3SfS7SnS;SvS?S~S 7S$ SOSS@HSO USOSOt` HMMCp((p0s,(XY`0 H(/@ x1 hG` 7` 7`eaderle-diULTIC.EDU>T TO:er-peSoftAULTIC.EDU>T TO:er_PeUmichMAILNLTICSEDU> TO:<@SUMEX-AIM.ARPA,@PANDA,@SUMEX-AIM:chuq@SUN.COMRJK@AI.AI.MIT.EDUReceived: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 25 Jun 86 23:44:03 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 25 Jun 86 20:33:02-PDT Received: from SUMEX-AIM by PANDA with Cafard; Wed 25 Jun 86 18:27:09-PDT Received: from sun.com by SUMEX-AIM.ARPA with TCP; Wed 25 Jun 86 15:14:22-PDT Received: from snail.sun.com (snail-ptp) by sun.com (3.2/SMI-3.0) id AA21358; Wed, 25 Jun 86 15:13:41 PDT Received: from plaid.sun.uucp by snail.sun.com (3.2/SMI-3.2) id AA15229; Wed, 25 Jun 86 15:14:04 PDT Received: by plaid.sun.uucp (1.1/SMI-3.0DEV3) id AA10800; Wed, 25 Jun 86 15:17:45 PDT Date: Wed, 25 Jun 86 15:17:45 PDT From: chuq@SUN.COM (Chuq Von Rospach) Message-Id: <8606252217.AA10800@plaid.sun.uucp> To: kp%plaid@SUN.COM Subject: checks Hmm... Last I looked, the only person who has serious problems (serious enough to bring the subject back from the dead) about the check is Mark. Please! don't restart the check flames, we did that months ago. Lets find something new and interesting to flame about. I for one am still interested in Kabuki-Peninsula, but simply haven't had time to do much about it. If mark is so uninterested, he should probably pull himself off the silly list and let us eat without him (oh, royal death, an evening without Mark...). If he wants to pull the list off of Panda, I'll happily run it from my machine. if you can't say something nice.... chuq FAILNET-ORIGIN<[AI.AI.MIT.EDU].61723.860626>YN-!  !I!%!I!% !I!%!I!%!I&!%!I.!%!I6!%!I>!%#!IF!%'!IN!%+!IV!%/!I^!%3!If!%7!In!%;!Iv!%?!I~!%  ^!I$> !!I!I@H!$$ #!!t` HMLp00s,X70HPZ@p[fy` ^` ^` 0 %   LSICUPLUKELReceived: from EDDIE.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 JUN 86 18:17:05 EDT Received: by EDDIE (5.31/4.7) id AA09465; Wed, 25 Jun 86 18:09:28 EDT Received: by EDDIE (5.31/4.7) id AA09446; Wed, 25 Jun 86 18:08:55 EDT Received: by bass.ARPA (5.31/4.7) id AA02801; Wed, 25 Jun 86 15:11:03 PDT Received: by cod.ARPA (5.31/4.7) id AA01665; Wed, 25 Jun 86 15:11:00 PDT Message-Id: <8606252211.AA01665@cod.ARPA> Date: Tue, 24 Jun 86 15:03:30 PDT Ppath: crash!noscvax!packet-radio@mit-eddie From: pnet01!brock@nosc.ARPA (Brock Meeks) To: crash!noscvax!packet-radio@mit-eddie Subject: Re: TNC+ autoload software I've written about packet radio for a couple of my monthly columns. The response was great. One chap sent me some email that stated he had developed a software based version of the TNC. Based on the Xerox. Anyone know more about this? Brock FAILNET-ORIGIN<[AI.AI.MIT.EDU].61555.860625>YN-!  1Q1)1Q1) 1Q1)1Q1)1Q&1)1Q.1)1Q61)1Q>1)#1QF1)'1QN1)+1QV1)/1Q^1)31Qf1)71Qn1);1Qv1)?1Q~1)  1Q 11Q1Q@H1$ 311t` HMC!2p$f(0 0s,(X0_H00 $fx (1@ xg aiX(o``0$f``"yutaka@su-whitney.arpaRWW@aiReceived: from su-whitney.arpa by AI.AI.MIT.EDU 24 Jun 86 14:50:26 EDT Received: by su-whitney.arpa with Sendmail; Tue, 24 Jun 86 11:45:38 pdt Date: 24 Jun 1986 1145-PDT (Tuesday) From: Yutaka Kanayama To: rww@ai Cc: yutaka@su-whitney.arpa Subject: suggestions to paper Hello Richard, I will move to SB next Monday. I know you are busy, but could you check that in this week? Yutaka ------- FAILyutaka suggestions to paper<[AI.AI.MIT.EDU].61019.860624>RWW"RWW" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS3;RWW MAIL".YN-!  ApA ApAAp AAp A"ApA*ApA2ApA:ApABAp!AJAp%ARAp)AZAp-AbAp1AjAp5ArAp9AzAp=A cAp$, BApAp@HB$ F0HBHB` HM &p (80s,(X- 0 %HK  x 8M@ x] E`c`c`LF+0YGC0Z0[S8\FAWCETT@RED.RUTGERS.EDUSILVER@AI.AI.MIT.EDUReceived: from RED.RUTGERS.EDU by AI.AI.MIT.EDU 17 Jun 86 13:50:30 EDT Mail-From: KELLER created at 28-May-86 10:28:22 Mail-From: PRASAD created at 22-May-86 15:18:15 Date: 22 May 86 15:18:14 EDT From: PRASAD@RED.RUTGERS.EDU Subject: Re: [Paul Rosenbloom : EBG and overgeneralization] To: ROSENBLOOM@SUMEX-AIM.ARPA cc: mahadevan@RED.RUTGERS.EDU, williamson@RED.RUTGERS.EDU, borgida@RED.RUTGERS.EDU, mccarty@RED.RUTGERS.EDU, MITCHELL@RED.RUTGERS.EDU, MOSTOW@RED.RUTGERS.EDU, KELLER@RED.RUTGERS.EDU, KEDAR-CABELLI@RED.RUTGERS.EDU, LAIRD.pa@XEROX.COM, NEWELL@A.CS.CMU.EDU, Dejong%uicsl@A.CS.UIUC.EDU In-Reply-To: <12208752908.16.KEDAR-CABELLI@RED.RUTGERS.EDU> Message-ID: <12208781219.24.PRASAD@RED.RUTGERS.EDU> ReSent-Date: 28 May 86 10:28:22 EDT ReSent-From: KELLER@RED.RUTGERS.EDU ReSent-To: CS-LEX@RED.RUTGERS.EDU ReSent-Message-ID: <12210301312.37.KELLER@RED.RUTGERS.EDU> ReSent-Date: 17 Jun 86 13:46:53 EDT ReSent-From: Tom Fawcett ReSent-To: silver@AI.AI.MIT.EDU ReSent-Message-ID: <12215580333.45.FAWCETT@RED.RUTGERS.EDU> Hello, Your message about over-generalization in SOAR and EBG and your paper comparing the two, are very interesting and clarify many issues. Here is my two cents worth. I basically agree with Paul Rosenbloom that when a theory is defeasible, then EBG gets into problems of overgeneralization. But I think that defeasible theories are completely different kind of beasts, the problems of which are beyond the scope of current EBG. When EBG/EBL people say that their process produces only "justifiable generalizations", (i.e. they never over-generalize), they mean justifiable with respect to their theories. If the theory used to prove a theorem contains a default rule, then the theorem (the result of generalization) is also a default theorem, i.e. it is only true if it can't be proved otherwise. The real difficulty in comparing these two, seems to be due to the different interpretations the two groups place on their ~ symbol. For SOAR it looks like ~P is true, if P is currently not in its working memory. (I am not sure, what it means logically! Does SOAR have a notion of consistency? i.e. Is it gauranteed that if P is provable, then by reordering the productions or changing the speed of the processor or doing some other logically irrelevant change, I can not prove ~P also?) For EBG, ~P must be provable, in order for it to be true. Hence negation is not a serious problem for EBG. (But default rules are, and that is a different issue.) Since SOAR interprets negation in a non-standard, default sense, it is bothered (produces over-generalizations) by a simple negation, while EBG is not. That is my current understanding of the problem. Your further comments are most welcome. Cheers, Prasad ------- FAILPRASAD Re: [Paul Rosenbloom : EBG and overgeneralization]<[AI.AI.MIT.EDU].58237.860617>YN-!   G G  G  G " G * G 2 G : G B G! J G% R G) Z G- b G1 j G5 r G9 z G=  0 G$  g G G@H g$ H gH gt` HM ip (80s,(X 0 (H Q  x |S@ p- E`0`0`0U#(VLF+0YGC0Z0[S8\FAWCETT@RED.RUTGERS.EDUSILVER@AI.AI.MIT.EDUReceived: from RED.RUTGERS.EDU by AI.AI.MIT.EDU 17 Jun 86 13:49:29 EDT Mail-From: KELLER created at 28-May-86 10:28:17 Mail-From: MITCHELL created at 22-May-86 13:04:50 Date: 22 May 86 13:04:49 EDT From: Tom Subject: Re: EBG and overgeneralization To: ROSENBLOOM@SUMEX-AIM.ARPA cc: Keller@RED.RUTGERS.EDU, Kedar-Cabelli@RED.RUTGERS.EDU, DeJong%uicsl@A.CS.UIUC.EDU, Laird.pa@XEROX.COM, Newell@A.CS.CMU.EDU, Mostow@RED.RUTGERS.EDU In-Reply-To: <12208739508.16.ROSENBLOOM@SUMEX-AIM.ARPA> Message-ID: <12208756930.55.MITCHELL@RED.RUTGERS.EDU> ReSent-Date: 28 May 86 10:28:17 EDT ReSent-From: KELLER@RED.RUTGERS.EDU ReSent-To: CS-LEX@RED.RUTGERS.EDU ReSent-Message-ID: <12210301298.37.KELLER@RED.RUTGERS.EDU> ReSent-Date: 17 Jun 86 13:46:39 EDT ReSent-From: Tom Fawcett ReSent-To: silver@AI.AI.MIT.EDU ReSent-Message-ID: <12215580289.45.FAWCETT@RED.RUTGERS.EDU> Paul, Yes, I agree with your example of overgeneralization in the Safe-to-Stack problem. As you say, the problem arises because using default rules can lead to defeasible theories (and defeasible explanations). In fact, the EBG paper discusses this kind of problem with the Safe-to-Stack example, in the final paragraph of section 4.2.1 (the paragraph entitled "The Inconsistent Theory Problem"). But the EBG paper fails to say outright that the learned generalization is overgeneral, and I think your discussion illuminates things--you certainly should include it in your revised paper. Cheers Tom p.s. Can you please send me the revised version of your paper? ------- FAILmitchell Re: EBG and overgeneralization<[AI.AI.MIT.EDU].58234.860617>YN-!  B B B B#B+B3B;B!CB%KB)SB-[B1cB5kB9sB={B P$ @H$> Çt` HM p (80s,(X 0 IH  x \@ pM EO`P`P` 9%;  +AICCEUFAWCETT@RED.RUTGERS.EDUSILVER@AI.AI.MIT.EDUReceived: from RED.RUTGERS.EDU by AI.AI.MIT.EDU 17 Jun 86 13:37:35 EDT Date: 17 Jun 86 13:35:52 EDT From: Tom Fawcett Subject: CS-LEX bboard messages To: SILVER@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].49354.860531.SILVER> Message-ID: <12215578327.45.FAWCETT@RED.RUTGERS.EDU> Hi. Haven't looked into doing automatic message forwarding from our cs-lex bboard, but in the meantime I'll mail you out (in several messages) the exchange between Rutgers and CMU about EBG and SOAR (they have an interesting paper on the mapping between them, by the way. I'd offer to mail it to you, but it's going to be in the AAAI anyway.) -Tom ------- FAILFAWCETT CS-LEX bboard messages<[AI.AI.MIT.EDU].58228.860617>$YN-! $ DDJDDJ DDJDDJD&DJD.DJD6DJD>DJ#DFDJ'DNDJ+DVDJ/D^DJ3DfDJ7DnDJ;DvDJ?D~DJ #OD$* DDD@HDSu$ hsHDSHDS~J` HMg;pY00s,XH0#7Hh# x#;@ x#I Dg` #O` #O`_3_ 5=50U)H9] ;=50O(SILVERReceived: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JUN 86 03:40:44 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86 03:34:03 EDT Received: from RED.RUTGERS.EDU by MC.LCS.MIT.EDU 10 Feb 86 16:38:25 EST Date: 10 Feb 86 16:13:10 EST From: Smadar Subject: philosophy of science bboard--here is the set of msg's on discovery To: cs-lex@RED.RUTGERS.EDU Message-ID: <12182325598.54.KEDAR-CABELLI@RED.RUTGERS.EDU> 22-Jan-86 12:24:58-EST,7993;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 22 Jan 86 12:24:39 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 22 Jan 86 11:28-EST Received: from Xerox.COM by MC.LCS.MIT.EDU 22 Jan 86 03:03:55 EST Received: from Cabernet.ms by ArpaGateway.ms ; 22 JAN 86 00:00:25 PST Date: 22 Jan 86 00:00 PST From: Shrager.pa@Xerox.COM Subject: Is there science in "scientific discovery"? To: Phil-sci@MC.LCS.MIT.EDU Message-ID: <860122-000025-1206@Xerox> (Yet Another Attempt to ReActivate Phil Sci.) I claim to study the psychology of science. Unfortunately, I've come to believe that this isn't a well-defined topic. In fact, I'm rapidly convincing myself that people who talk about the mechanisms of discovery (e.g., Darden, Thagart) and/or write "discovery" AI systems (e.g., Langley, Lenat) are using a term that has no independent meaning. They do not intend to deceive; rather, they are taken in (as I was) by how cool it would be to build a computer program that does "scientific discovery". Is everyone else who thinks that there's something to gain from this is similarly confused, or is it just me? Under this view it's also vacuous to say: "Here's my new learning mechanism. I think it accounts for scientific theory formation." as if there's one thing that *is* scientific theory formation and one can have a science of it (e.g., Gentner, Holyoak). Thus the question: Is "scientific discovery" something that you can have a science of? The only sense I can make of the term "scientific discovery" is that it's the sort of reasoning that the people that we call scientists do. Is this special to scientists? That is, what we call scientific reasoning is some normal combination of learning mechanisms (e.g., analogy, induction, etc) just like those you'd find in a child learning about a new toy, an adult learning about a new car, etc. Perhaps scientists are motivated to test hypotheses a little bit more carefully than the rest of us. Perhaps they also are better at creating theories. I doubt this very much, although they certainly have a lot more domain specific knowledge in their fields than we do. They are also more prone to publish their results than I was when I figured out how my rear windshield wiper worked. Under this view there is no scientific force (in the sense of *our* science of the mind) to studies of "science", per se, beyond what can be learned by similar studies of ("non-scientific") learning. For instance, BACON is a study in search (or whatever other mechanism you wish to attribute to it), NOT a study in science. What would count as a science of scientific reasoning? That is, what would have to be the case for me to buy that there is something called scientific reasoning that is different from non-scientific reasoning and that I can get my head around? (The horrorible self-referential nature of this whole argument is starting to confuse me.) There might be something special in the task itself. How would we tell if the task of the scientists isn't just like the task of the guy trying to figure out how to put his new car into reverse, or the child trying to figure out why gophers go into holes at one place and come out at another. or the hacker trying to figure out his Lispm without reading the manual...? Maybe there is something different in the processing that scientists use to learn about these things. This is an empirical claim for which there is no basis (is there?). The claim is that we learn nothing about "science" by working on scientific reasoning, since "science" isn't anything but learning applied to natural domains. The cognitive psychology literature is empty of studies of "discovery". I used to wonder why this was the case. Under the present view, this lack of research is not because no one cares about scientific reasoning, but because no one is confused into thinking that it's something about which you can have a separate topic. Let me head off some obvious counters. (1) Since scientists thinks about the structure of their learning processes, these processes are somewhat different. That is, learning about these complex systems is so hard (or doing it right is so hard...) that scientists have to think about they way they are going about learning about them, which substantially changes the learning processes. This is one version of the rationalist philosopher-of-science view. First, I *do* believe that it is possible to have something called the "philosophy" of science which somehow rationalizes learning, but I don't buy that that has anything to do with what scientists do. I would claim that almost all of a scientist's real work (even if we just focus on the work that the scientists themselves would call scientific) consists of puzzle-solving (in a broad sense -- I don't just mean "problem solving" in the AI sense), and is not different form similar "non-scientific" learning/puzzle-solving which involves a large number of mechanisms. Further, I think that most people engaged in puzzle solving also have these meta-procedural intuitions, even if they aren't as careful at reasoning about the implications of the meta constructions as the scientist (sometimes) is. (2) The form of theories that scientists devise is different than the form of theories that other people derive. I think that this is wrong. People make up a lot of different sorts of theories about why things happen and/or laws to predict them. Some of these "lay theories" are even mathematical in a simple way -- and some are not so simple (if you consider the implicit computation being done). (3) Studying scientific reasoning is more interesting. The theories are more fun, and the scientific problems (*our* scientific problems) involved are more difficult. I certainly sympathize with the "more fun" argument...that's why I am in the field to begin with. (I really want to be in about 7 different fields at once and cognitive science is a good way to do this.) On the other hand, (a) it's damned difficult to study scientists at work, (b) it's not as easy as you might think to study non-scientist learning in a lay-scientific way, and (c) this doesn't speak to the question of whether we can have a science of scientific reasoning -- that is, whether there's a puzzle to be solved in the structure of science, or if the name signifies nothing in-and-of itself. Granted, it's fun to think about, but it seems that you're making the problem so hard as to be intractable -- at least for psychology. (Real data doesn't seem to bother philosophers or AI researchers, and what real data there is is almost always historical or retrospective at best. (I really think that the historical data hides a great deal of processing. But this is another argument.)) (4) But this is all an empirical claim, and so it stands as a scientific hypothesis (i.e., that scientific reasoning isn't anything different than lay reasoning) and must be scientifically tested. This sounds like an anthropological claim (looking at the tribe of scientists) rather than a psychological one. Perhaps it's right, but it isn't psychology. The relationship between psychology and anthropology seems too hairy to take up right now, but perhaps there's something to be said here. My concern for this is real in the sense that I have been trying to figure out how to make a psychology of science that is NOT retrospective (or historical). The question at hand is whether it's worth the trouble, or should I just be looking more carefully at what I have been looking at (how "normal" people learn about complex things). At least it might make for an interesting discussion. If nothing else, it'll break up the monotony of "Please add me to this list." messages. -- Jeff 22-Jan-86 19:20:35-EST,2344;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 22 Jan 86 19:20:29 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 22 Jan 86 18:36-EST Received: from a.CS.UIUC.EDU by MC.LCS.MIT.EDU 22 Jan 86 18:17:14 EST Received: from p.CS.UIUC.EDU by a.CS.UIUC.EDU with SMTP (UIUC-5.31/9.4), id AA15056; Wed, 22 Jan 86 17:15:39 CST Received: by p.CS.UIUC.EDU (UIUC-5.5/9.4), id AA10494; Wed, 22 Jan 86 17:15:59 CST Date: Wed, 22 Jan 86 17:15:59 CST From: gentner@p.CS.UIUC.EDU (Dedre Gentner) Message-Id: <8601222315.AA10494@p.CS.UIUC.EDU> To: Phil-sci@MC.LCS.MIT.EDU, Shrager.pa@Xerox.COM Subject: Re: Is there science in "scientific discovery"? I have two reactions: 1. You're 100% right in suggesting that there is no real difference betweescientific reasoning and reasoning. No unique process, no special form of knowledge representation, no unique metaconceptions. I also plead innocent to the charge (if you meant this) of saying that scientists think qualitatively differently from the rest of humanity. 2. But, well, there may be some quantitative differences --- some difference in the degree to which certain processes are engaged in, the criteria for solution, etc. --- that, taken together, could make a big difference in the kind of thnking that goes on. One humble candidate is writing out ideas. I hate to be an advocate of pressure to publish-- there's quite enough of that around. But I've noticed that I learn a lot by writing, mainly becuase I notice inconsistencies and places where I disagree with what I've written. So one candidate for how scientific thinking differs from ordinary thinking is that there is (a) a bigger premium on consistency and (b) a set of mechanisms,such as writing, modelling, etc. that help promote consistency. There's another set of issues that might be called "implicit aesthetics" that I think I see in use of analogy and metaphor. Clarity and systematicity are valued in scientific uses; in literary uses, a fuzzy, nonsystematic, internally inconsistent metaphor can be dandy, if it's evocative. In fact, internal paradox can even be part of the appeal. One thing I think scientists have to learn is which kind of aesthetics to use when. Dedre 22-Jan-86 22:49:10-EST,2068;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 22 Jan 86 22:49:06 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 22 Jan 86 22:12-EST Received: from a.CS.UIUC.EDU by MC.LCS.MIT.EDU 22 Jan 86 22:10:43 EST Received: from p.CS.UIUC.EDU by a.CS.UIUC.EDU with SMTP (UIUC-5.31/9.4), id AA22894; Wed, 22 Jan 86 21:09:40 CST Received: by p.CS.UIUC.EDU (UIUC-5.5/9.4), id AA12739; Wed, 22 Jan 86 21:09:52 CST Date: Wed, 22 Jan 86 21:09:52 CST From: forbus@p.CS.UIUC.EDU (Kenneth Forbus) Message-Id: <8601230309.AA12739@p.CS.UIUC.EDU> To: phil-sci%mit-oz@mit-mc.ARPA Subject: Why scientific discovery? In addition to the factors Dedre mentioned, there are at least two other reasons why "scientific discovery" is a useful topic in AI learning research: 1. It is more clear when discoveries actually happen in science than in many other domains. When one makes a "discovery" in daily life, you may later find out that what you really did was adopt a technique that you had ample opportunity to see someone else using. If minds are constructed from complete TMS networks (v. unlikely), we sure can't introspect on them. Priority battles aside, one can see (at least some) of what the scientist started with and (in part) where they end up. 2. All the scientific discovery work I know of focuses on physics, chemistry, or biology. In these areas we have better agreement on what the answers should look like. Would a program which discovered Freud's theory be very clever? How about primal scream therapy? Pick your science narrowly enough and you can avoid spending all of your time in domain representation problems -- at least that's the claim. I personally think doing science right isn't as near a "microworld" as some might claim, at least if you don't want to be ad hoc. But I think we have a better chance to make a human-quality qualitative physics before we make a human-quality formal theory of, say, friendship. 23-Jan-86 00:50:04-EST,780;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 23 Jan 86 00:50:01 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 22 Jan 86 23:56-EST Received: from ari-hq1.ARPA by MC.LCS.MIT.EDU 22 Jan 86 23:55:03 EST Date: 22 Jan 86 09:48:00 EST From: Subject: Phil Sci is dead! Long live Metaphil! To: mar.christoff cc: phil-sci@mit-mc Reply-To: While the phil sci list appears to be dead (or at least, dormant), the metaphilosophers list is very active. You can add your name by sending mail to METAPHILOSOPHERS-REQUEST%MIT-OZ@MIT-MC I don't run the list - I'm just a "subscriber" --- Dik Gregory ------ 23-Jan-86 20:47:30-EST,7135;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by RED.RUTGERS.EDU with TCP; 23 Jan 86 20:47:12 EST Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 23 Jan 86 20:17-EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 23 Jan 86 20:11-EST Received: from CIP.UCI.EDU by MC.LCS.MIT.EDU 23 Jan 86 20:09:36 EST Received: from cip2.uci.edu by CIP.UCI.EDU id a000826; 23 Jan 86 17:03 PST To: phil-sci%mit-oz@mc.lcs.mit.edu Subject: scoping discovery Date: 23 Jan 86 17:01:01 PST (Thu) From: Rogers Hall Hi, I'm new to this net, having received forwarded copies of the Shrager/Gentner/Forbus interchange from a friend. I was struck by some of the questions Jeff asked, and by the replies which he, Dedre and Ken gave. A central line in the interchange was whether or not scientific reasoning (puzzle-solving broadly defined) is different from more mundane forms of reasoning that lay people undertake about their surrounding environment. The answers seemed to be yes and no, but primarily couched within the confines of an individual reasoner's `head.' I'm wondering how a researcher in `scientific discovery' goes about defining puzzle-solving within the confines of a single reasoner, much less as something different from what lay people do? In the same sense that Langley's BACON can be assessed as BACON is a study in search (or whatever other mechanism you wish to attribute to it), NOT a study in science. (Shrager) I wonder whether studies of individual reasoning in scientific discovery might not be attacked on grounds of ecological (or external) validity? Although I am not a philosopher/historian/anthropologist/psychologist of science, I do have some intuitions about claims that researchers make concerning relations between their theoretical models and naturally occuring phenomena. In the BACON case, it seems that Langley is choosing one aspect of what may constitute scientific discovery, examination of measured variables to determine relationships among them, and advancing a computational mechanism for that constituent. Hence, Langley restricts the scope of his definition of scientific discovery narrowly. As a consumer of this work, any of us might ask why he doesn't include other constituents which we might prefer. Pat feels (personal communication) that one must start somewhere, and that his work on BACON represents one point of departure. My point is that there probably can be a `science of scientific discovery,' but that this science will have to incorporate many views of what scientific discovery is, including viewpoints which select and isolate intra-individual constituent reasoning abilities (hypothesized) and viewpoints which consider a larger, inter-individual scope. Advocates of the former may well, as Jeff appears to do, dislike `real data' which is `historical or retrospective at best' and feel that `looking at the tribe of scientists' isn't psychology. What's really fun about the science of scientific discovery or any other area is that its a pluralistic enterprise - that's what makes it exciting for the participants (at least me). A final reflection on some of Ken's comments: I wonder why the inputs (?) and outputs (discoveries) of scientific discovery are more easily observed than those of any other cognitive endeavor? Historians/sociologists of science seem to tell us that textbook presentations of the major tenets of a field (e.g., biology, chemistry, physics) represent sanitized versions of a rather complicated historical/social process that went on, again, between individuals rather than within a single individual. While I agree that a set of physical laws gives a clear set of results from a computational point of view, I don't understand how these results inform us about the process that one or more individuals go through when formulating the results. An interesting example is Zytkow's work on STAHL, discovering componential models of chemical compounds (to appear soon in the new journal, Machine Learning). Primitive reactions are taken as input; componential models (possibly errorful) are given as output; and the intermediate processing is in some way to correspond to what a group of 18th century chemists were up to. Tracking down the points of correspondence between the theoretical model (or the simulation) and the real process which chemists went through is quite tricky, although Zytkow claims to do so. The gist of what makes theories about scientific discovery difficult, in my opinion, is precisely how the natural phenomenon to be explained is cut up by an individual reasearcher. Is it reasonable to take a subset of the probably infinite space of possible chemical reactions available in the natural world as input to STAHL? Well, yes and no. Yes if the theory of discovery being developed is clearly going to address data interpretation, but not experimental design and data collection. No if what is being advanced is a theory of discovery which is to encompass the latter constituents. The `peril' for computational approaches to scientific discovery, in my opinion, is picking a subtly powerful partitioning of the natural phenomena, representing the chosen constituents in a very clever fashion, and advancing the results as a theory of what scientists were or are up to. Perilous from the perspective of cognitive simulation; perhaps commendable from the perspective of constructing powerful computational artifacts. A case in point might be Ken's example of discovering Freud's theory of unconscious psychic forces. Given a properly abstracted representation of hydraulics and some clever but naive observations of human utterances during free association, I expect that a competent AI practitioner could come up with a computational artifact which could be described as `Freud's discovery of psychodynamics!' Moreover, this would serve as a simulation of scientific discovery by analogical reasoning, perhaps embellished with Dedre's theoretical notions of structure mapping or Keith Holyoak's notions of pragmatic analogical reasoning. Reactions of consumers of such a research report would vary by how those consumers cut up discovery and analogical reasoning. For example, psychodynamically-oriented clinicians would be horrified; a graduate student in AI might walk away with a thesis. I'll close by recommending a monograph which I've started reading: De May, M. (1982) The cognitive paradigm: Cognitive science, a newly explored approach to the study of cognition applied in an analysis of science and scientific knowledge. Sociology of Sciences Monographs, D. Reidel Publishing Company: Boston. De May tries to describe a science of science by applying notions from cognitive science to the field of cognitive science. Jeff's self- referential anguish is just the tip of the iceberg, so to speak... Rogers Hall Dept. ICS Univ.Cal.Irvine Irvine, CA 92715 rhall@uci 24-Jan-86 00:31:18-EST,579;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 24 Jan 86 00:31:14 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 23 Jan 86 23:50-EST Received: from aero.ARPA by MC.LCS.MIT.EDU 23 Jan 86 23:50:00 EST Received: by aero.ARPA (4.12/6.0.GT) id AA02815; Thu, 23 Jan 86 20:45:53 pst Date: Thu, 23 Jan 86 20:45:53 pst From: Charlie Crummer Posted-Date: Thu, 23 Jan 86 20:45:53 pst Message-Id: <8601240445.AA02815@aero.ARPA> To: Phil-sci@MC.LCS.MIT.EDU ! 24-Jan-86 18:27:55-EST,1857;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 24 Jan 86 18:27:44 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 24 Jan 86 17:43-EST Received: from nprdc.arpa by MC.LCS.MIT.EDU 24 Jan 86 17:44:54 EST Received: from sdics.CSL (sdics.ARPA) by nprdc.arpa (4.12/ 1.1) id AA15582; Fri, 24 Jan 86 14:43:04 pst Received: from molokini by sdics.CSL scf2.7vax; Fri, 24 Jan 86 14:43:21 PST Date: Fri, 24 Jan 86 14:46 PST From: hollan@nprdc.arpa Subject: Re: Is there science in "scientific discovery"? To: gentner@p.CS.UIUC.EDU, Phil-sci@MC.LCS.MIT.EDU, Shrager.pa@Xerox.COM Cc: hollan@nprdc.arpa In-Reply-To: <8601222315.AA10494@p.CS.UIUC.EDU> Message-Id: <860124144641.0.HOLLAN@MOLOKINI.ucsd> I would like to comment on the claim that "there is no real difference between scientific reasoning and reasoning." I think there is a difference: not a fundamental psychological difference but one engendered by technologies. A great deal of the reasoning that we do is done via the medium of various technologies. In reasoning about scientific matters we have typically employed different technologies or made use of them in differing ways. For example the technology of writing which Dedre alludes to often distinguishes scientific reasoning from other reasoning in that we write differently about scientific matters. We use different forms of argumentation and different types of notational systems. Similarly one of the real fruits of computation is the ability to debug one's reasoning via modeling. To a large extent it is scientific reasoning which draws on these types of technologies. There is, of course, no necessity here. My point is only that our reasoning is influenced by the technologies that we employ. 24-Jan-86 18:54:05-EST,1296;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 24 Jan 86 18:54:01 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 24 Jan 86 17:54-EST Received: from R20.UTEXAS.EDU by MC.LCS.MIT.EDU 24 Jan 86 17:55:05 EST Date: Fri, 24 Jan 1986 16:50 CST From: AI.DUFFY@R20.UTEXAS.EDU To: Cc: mar.christoff , phil-sci@mit-mc, Meta-philosophers-request%OZ@MC Subject: Phil Sci is dead! Long live Metaphil! In-reply-to: Msg of 22 Jan 1986 08:48-CST from Date: Wednesday, 22 January 1986 08:48-CST From: While the phil sci list appears to be dead (or at least, dormant), the metaphilosophers list is very active. You can add your name by sending mail to METAPHILOSOPHERS-REQUEST%MIT-OZ@MIT-MC I don't run the list - I'm just a "subscriber" --- Dik Gregory This is silly. Both PHIL-SCI and META-PHILOSOPHERS are maintained on the same machine, MIT-OZ. Why doesn't some reasonably intelligent MIT person (I understand that MIT has a few) simply merge the two lists, making both names, PHIL-SCI and META-PHILOSOPHERS, coreferent. Is that very difficult? 24-Jan-86 21:34:09-EST,3838;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by RED.RUTGERS.EDU with TCP; 24 Jan 86 21:34:01 EST Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jan 86 21:00-EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 24 Jan 86 20:09-EST Received: from Xerox.COM by MC.LCS.MIT.EDU 24 Jan 86 20:10:12 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 JAN 86 17:01:35 PST Date: 24 Jan 86 16:49 PST From: Shrager.pa@Xerox.COM Subject: Is there science in "scientific discovery"? To: hollan@nprdc.arpa, gentner@p.CS.UIUC.EDU cc: Phil-sci@MC.LCS.MIT.EDU Message-ID: <860124-170135-1956@Xerox> Since this seems to have started some discussion, let me try to make my point more clearly. I seem to have made a different point, which maybe I believe, but isn't what I meant. I was *not* asking whether or not creative scientists use the same mechanisms as everybody else, etc, although that may be a part of the answer. What I wanted to know, as is reflected by the continuous header of all these messages, is: What is the scientific force of saying any of the following: * Creative scientists use analogy a lot. * Creative scientific reasoning is problem solving. * Scientists use the same mechanisms as everyone else. * Scientists use different mechanisms than everyone else * Creativity is problem solving. etc etc etc...you allk know at least ten papers that say something like this, and at least five that try to show it, and at least one whose argument actually carries water in your opinion. I am NOT trying to determine the truth value of any of these. I am even willing to believe any or all of these (for the present discussion). The question is: Are any of these scientific statements? Are any of these testable hypotheses, clearly operationalizable, or even understandable if you think about them hard enough? If scientific discovery merely a social defined phenomenon, how can it be causally connected to a psychological mechanism like analogy? If all of you suddenly decide that Joe Blogs is a creative scientist, does the amount of analogy he does suddenly go up? Obviously not. However, you might be seduced into think that the opposite *is* true -- that if Joe's level of analogy increases, he becomes a creative scientist. This is the issue -- if "creative-scientist" isn't an operationalizable term, then how can we test this hypothesis? If Rogers says that creativeity is search, what has he said? I claim, nothing. If Dedre says that scientists use analogy, have I learned anything about analogy? Obviously not. However, have I learned anything about science or scientists? This is like the former question and I have the same difficulty with it. That is, if Joe is a scientist and Dave isn't, does that mean (if Dedre's claim is true) that Dave uses less analogy? I claim not. So, then, what's the scientific force of -- what have we learned from -- this sentence? It obviously has content -- it says that Joe *used* analogy and somehow that got him into the position of being a creative scientist. That's great for the New York Times, but as a scientist (whatever that means) how has this statement increased my knowledge of my domain in any way beyond lodging a historical fact in my memory? If my domain is "science" (or cretivity, or discovery, or whatever) then I have, in fact, learned something. However, I'm really concerned over whether it makes sense for "science" (or cretivity, or discovery, or whatever) to be a field at all. If you have a field that is delineated by social convention, then you're an anthropologist and I just don't see how social delineation is causally connected (in that direction) with psychological mechanisms. -- Jeff 25-Jan-86 09:37:20-EST,708;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 25 Jan 86 09:37:17 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 25 Jan 86 08:48-EST Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 25 Jan 86 08:50:00 EST Received: from (UL2O)DKAUNI48.BITNET by WISCVM.WISC.EDU on 01/25/86 at 07:48:38 CST Date: 01/25/86 14:48:07 CET To: PHIL-SCI@MIT-MC.ARPA From: UL2O%DKAUNI48.BITNET@WISCVM.WISC.EDU Subject: Hello! Please tell me how I can join your discussion about philosophy in science and artificial intelligence. Send messages to user ul2o at node dkauni48. Thank you! 26-Jan-86 12:09:17-EST,5354;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 26 Jan 86 12:09:05 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 26 Jan 86 11:40-EST Received: from G.CS.CMU.EDU by MC.LCS.MIT.EDU 26 Jan 86 11:41:48 EST Date: 26 Jan 1986 11:27-EST From: Ira.Monarch@G.CS.CMU.EDU Subject: representation, discovery, science, and psychology To: Phil-sci@MC.LCS.MIT.EDU Message-Id: <507140848/iam@G.CS.CMU.EDU> Shrager ends his second message on "this" topic with the following: > If you have a field that is delineated by social convention, then you're an > anthropologist and I just don't see how social delineation is causally > connected (in that direction) with psychological mechanisms. Shrager may be right in the sense that social delineation or factors do not causally influence learning mechanisms, but rather are something like the context in which they work. But to someone who is interested in the design of intelligent computer assisted learning systems or intelligent human-computer interfaces, neither social factors or learning mechanisms should be left out of the reckoning. I think we have to be careful of a certain kind of psychological reduction here. As to some of the others in the discussion, I agree with much of what Hall had to say, tho unlike him, I did, at one time, closely follow discussions in the philosophy/history/sociology of science. Also, my interest is not in building a computational simulation of scientific reasoning or even in the psychology of science, but rather in what I can learn from the philosophy/history/psychology/sociology of science to design and build better human-computer interfaces. I also agree with Gentner and Hollan that a specific difference between scientific and other forms of reasoning is engendered by technologies, but don't feel the force of Hollan's claim that the difference is not fundamentally psychological. I guess I would say if new technologies influence us to represent the world differently and reason differently, then they are capable of engendering psychological differences, even if the learning mechanisms were the same, whatever that might mean. Insofar as there is a psychology of cognitive systems, there's a psychology of science, because science is a cognitive system. Scientific reasoning consists of many of the same learning mechanisms you might find in a child, that is scientific learning and non-scientific learning have much in common. Maybe there's no difference between the two with respect to a certain conception of psychology of learning. But one reason to focus on science is that it is a fairly well delineated basis for studying the cognitive systems of groups as well as individuals - for studying the role of representation, communication, and power in knowledge and learning. Of course there are other ways of doing this. Science isn't the only cognitive system or systems in which social factors come into play. But science is the exemplary cognitive system in our culture. Of course people who have been building computer models of scientific reasoning or even learning in general haven't always been very interested in the role of representation or communication in these processes. But some are, e.g. those interested in graphical interfaces in ICAL. A recent example is Clancey and Richer in their Guidon-Watch. Also as Hollan has pointed out in an on-going discussion of authoring tools, ai, and education on the ai-ed mailing list: "I think it would be a mistake if one were to conclude that graphics and interface issues are outside of the theoretical issues that need to be confronted in ICAI. Interfaces are representational systems used as means of communication and as such confront all the hard representational questions." One could argue that many of the important discoveries in science revolve around new ways of representing the world or, at least, a problem domain. Some examples are: the use of writing co-occuring with the rise of something like what we call science, certainly what we call geometry, in ancient Greece; what can be called the mathematicization of physics starting in the Late Middle Ages and reaching one important stage in Newtonian physics; learning how to use such scientific instruments as the telescope and microscope; Carnot's steam engine; non-visualizable entities like quanta. Kuhn and Feyerabend have studied these shifts of representation, calling them paradigm shifts and likening them to gestalt shifts. No doubt such shifts involve an implicit aesthetics. And there is the important question of how agreement comes to be reached when such shifts take place. Understanding these shifts, whether evolutionary or revolutionary, is arguably part of a theory of cognition and is not unlike the sort of understanding we will need to design better human-computer interfaces and learning aids. I happen to think it's a mistake to compartmentalize scientific questioning into so-called scientific disciplines whose raison d'etre may be as much a question of political power as reasoning. It's not clear that it's necessary to have a psychology of science that is "NOT retrospective (or historical)". Ira 27-Jan-86 17:34:58-EST,669;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by RED.RUTGERS.EDU with TCP; 27 Jan 86 17:34:55 EST Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Jan 86 22:57-EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 26 Jan 86 22:18-EST Received: from csvax.caltech.edu by MC.LCS.MIT.EDU 26 Jan 86 22:19:20 EST Received: by csvax.caltech.edu (5.31/1.2) id AA23987; Sun, 26 Jan 86 19:19:15 PST Date: Sun, 26 Jan 86 19:19:15 PST From: loeb@csvax.caltech.edu (Daniel Loeb) Message-Id: <8601270319.AA23987@csvax.caltech.edu> To: phil-sci@mc.lcs.mit.edu Please take me off of your mailing list 29-Jan-86 00:50:43-EST,1425;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 29 Jan 86 00:50:28 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 29 Jan 86 00:06-EST Received: from ari-hq1.ARPA by MC.LCS.MIT.EDU 29 Jan 86 00:06:19 EST Date: 28 Jan 86 16:51:00 EST From: Subject: PHIL-SCI & METAPHILOSOPHERS To: mly.g.daniels%mit-oz cc: metaphilosophers%mit-oz@mit-mc, phil-sci%mit-oz@mit-mc Reply-To: Dear Gub, In case you are still in the dark re: flames about phil-sci and metaphil: a few days ago I put out a message on phil-sci net after months of inactivity apart from occasional requests to be included. I made the utterly naive suggestion that since the list appeared dead or dormant, interested parties might like their attention drawn to the metaphilosophers list. This was naive (with hindsight of course), because it produced not a welter of new contributors to metaphilosophers, but instead, a series of messages from people whose reason for their obvious outrage is completely beyond me. Ironically, my message to phil-sci coincided with more correspondence than that list has had in two years (or some such). As you were, boys and girls. Sorry I spoke, and let's not waste any more time being unpleasant. --Dik Gregory ------ 3-Feb-86 12:59:54-EST,7936;000000000000 Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by RED.RUTGERS.EDU with TCP; 3 Feb 86 12:59:39 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 3 Feb 86 12:11-EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 FEB 86 11:56:18 EST Date: 3 Feb 1986 11:55 EST (Mon) Message-ID: From: David Kirsh To: Shrager.pa@XEROX.COM Cc: gentner@P.CS.UIUC.EDU, hollan@NPRDC.ARPA, Phil-sci@MC.LCS.MIT.EDU Subject: Is there science in "scientific discovery"? In-reply-to: Msg of 24 Jan 1986 19:49-EST from Shrager.pa at Xerox.COM -- This message is three screens long. Apologies. SCIENTIFIC NORMS CONSTRAIN THE SCIENTIFIC DISCOVERY PROCESS The core of Jeff's worry as I originally read him was roughly this: Why assume that scientists, as problem solvers of scientific problems, do anything very different than we do as problem solvers in everyday life? Isn't the process of scientific discovery just like the process of common sense discovery, a hodge podge of activities with no special characteristics of its own? The refinement that I read him to have made in his second message is that he is more interestedin knowing whether there is any scientific status to these claims. Can we test the claim that the psychological processes underlying scientific discovery are different than those underlying non-scientific discovery? The catch turns on the term `scientific'. If `scientific' refers to an `arbitrary' (ie sociologically determined) subset of the population, we are not singling out a natural psychological group. Why suppose that some people think differently just because they are called scientists? I think a reasonably fashionable answer of the mid 80's would run like this. Psychological processes may be affected by one's belonging to a social group because frequently one can belong to that group only by accepting certain norms or ideals. Scientists are obliged to meet certain standards of rigour. Might these not affect the way they think? The obvious retort is to distinguish the context of discovery from the context of justification. Accordingly, scientists are obliged to ensure that their published material is rigourous and unfolds with a certain logic. But these public standards hide private vices. The truth is that scientists do their thinking the way we all do; only after their discovery do they come back and tart up their theory by reconstructing it rationally. Is this true? Do norms constrain only the justification episode of thought? Let me try a counterargument. It is arguable that we will not understand much about the discovery process in any domain, whether physics, biochemistry or common sense, until we know what the point of discovery is. One of the plausible ends of discovery -- at least the sort of discovery we associate with science -- is improved conceptualization. Clearly there are many kinds of discoveries one can make. Discovering a new concept differs from discovering a new way of simplifying a theory formally, or from discovering a new correlation. But I take it as axiomatic -- by which I mean I will not argue for it here -- that when someone makes a scientific discovery he advances his and our UNDERSTANDING of the subject. What this amounts to is not clear. But we can be sure that discovering a new idea or principle is not like discovering what's in the cabinet downstairs. New facts added to an already adequate conceptual framework do not improve understanding. In general, conceptual revision is involved. What constrains conceptual revision? Here's where the norms and ideals come in. One thing we know is that when we're finished revising our conceptualization of a certain domain we ought to be able to EXPLAIN the phenomena, or explain it better than we could beforehand. This may be a bit extreme since inarticulate people may understand without being able to make explicit what they understand. Nonetheless understanding is linked to explanation in the minimal sense that if someone does understand, say, why metals conduct electricity, then that person must at least be able to grasp an explanation of that fact. Somehow the norms which apply to explanation are going to bear on the discovery process. Different norms can be expected to constrain the process in different ways. The trick is to discover just how. Let me restate my argument. We started by asking 1) Is scientific DISCOVERY different from common sense discovery? We reformulated that question as 2) Is scientific UNDERSTANDING different from common sense understanding? Which in turn can be reformulated as 3) Is scientific EXPLANATION different from common sense explanation? This, then, I take to be the central issue: How different is scientific from common sense explanation? Prima facie if two processes (start from the same spot) but lead to different goals, they are likely to be different processes. If scientific and common sense explanation differ significantly, their discovery processes likely will to. What are the desiderata of good scientific explanation? Explicitness, precision, comprehensiveness, elegance, are a few. Another is coherence with other theories. A scientist needs to check that his theory is consistent with other accepted theories. Indeed, where possible his theory should link up with pre-existing theory. This urge for consistency may exercise a powerful constraining influence on scientific discovery. For discovery is not a single leap of the imagination. It involves judgements as to where to look next for hints. If we suppose that the process of discovery unfolds bit by bit, possible lemma by possible lemma, then some spots in the problem space or whatever, may be more stable, scientifically more acceptable. I share Jeff's concern that this still sounds like a filtering process and not a conjecturing process, but we know so little about the conjecturing process that there may well be constraints on that process that are connected to these stable stopover points. Who is to say that the conjecturing system has not adapted to these stable points? By contrast, consider what are the desiderata of good common sense explanation? Being easy to understand, brief, good enough for the needs of the questioner. Neither consistency nor comprehensiveness are particular requirements of common sense. Our ordinary discoveries support a tissue of criss-crossing, partially overlapping theories. What matters is not elegance or simplicity in a global sense, but ease of use locally, in ways that allow us to deal with everyday life. Solutions can be accepted in common sense that would never even be entertained in science. Our conclusion ought to be, I think, that science and common sense, for all their obvious and important similarities also have significant differences. A first pass at the discovery process is not likely to show up much difference in everyday and scientific discovery. But on second and later passes, new variables will be seen to complicate the scientific discovery process. The need to formulate precisely one's position, to organize reports in a manner that meets the approval of one's peers, to check for consistency with other theories, to test, to discuss, and to defend, are all factors that perturb the scientist's discovery system in novel, non-common sense ways. These perturbing factors complicate the process and also, somehow, constrain the process. The discovery process, after all, is primarily a process of disciplined inquiry. If so, who teaches us the discipline? -- David Kirsh ------- FAILKEDAR-CABELLI philosophy of science bboard--here is the set of msg's on discovery<[AI.AI.MIT.EDU].57955.860617>YN-!  GTG GTGGT GGT G"GTG*GTG2GTG:GTGBGT!GJGT%GRGT)GZGT-GbGT1GjGT5GrGT9GzGT=G (,z GT$* ItGTGT@HIt$& LJ7HItc HM HP  8  8 8 MP`)Y 8 ( 80 8Y 8&Y80s,,`'x!X" X@#(+$B)8% X/` X/``*-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~     !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~    BABYLLIZZITRFC733LIZZITBAndy@LLLGyro@OZVelu@GYREJurgen@MCvecpyr!sgw@LLLRDO@MIT-EDDIEDevon@MCmgrant@MCJSOL@AI kaufman at a.CS.UIUC.EDU (a bull in a china shop) B'est [kaufman: qotd] From: John Romkey be a toroid be a toroid all the world loves a toroid We aquarioids don't get along that well with them. --Kenoid <[AI.AI.MIT.EDU].57797.860616.LIZZIT>Date: Mon, 16 Jun 86 23:32:36 EDT From: kaufman at a.CS.UIUC.EDU (a bull in a china shop) Subject: [kaufman: qotd] To: B'est Message-ID: <[AI.AI.MIT.EDU].57797.860616.LIZZIT> YN-!  wwwww www&ww.ww6ww>wwFw#wNw'wVw+w^w/wfw3wnw7wvw;w~w?w w$ w ww@Hw $  y@Hw Hw t` HMYqp A((0s,(X L 0 @H   Ax pA@ x BY```Q( A$60617AA139CS.UIU> Tam@BOCS.MI Sub Re: Axesdab@BORAX.LCS.MIT.EDUREHMI@ai.ai.mit.eduReceived: from BORAX.LCS.MIT.EDU by AI.AI.MIT.EDU 16 Jun 86 21:24:01 EDT Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Mon, 16 Jun 86 21:21:05 edt Date: Mon, 16 Jun 86 21:21:05 edt From: dab@BORAX.LCS.MIT.EDU (David A. Bridgham) Message-Id: <8606170121.AA03631@BORAX.LCS.MIT.EDU> To: rehmi@ai.ai.mit.edu Subject: borax account I set your password. When romkey asked me to rebuild your account, he didn't tell me what the passwd string was so I just set your password to nopassword. But then I forgot to tell you that in the previous message. Sigh. It's fixed now. Dave FAILdab borax account<[AI.AI.MIT.EDU].57700.860616>YN-!  p2ep2ep2 ep2e%p2e-p2e5p2e=p2eEp2"eMp2&eUp2*e]p2.eep22emp26eup2:e}p2>e  Ip2$ pRp2p2@H%$ '/H%H%t` HX 0s, 0 @px8 (H0A1`  ` `Queued msg sent to: UPDATE-INQUIR at ML.AI.MIT.EDU PLUKELFAIL<[AI.AI.MIT.EDU].57607.860616>Msg of Saturday, 14 June 1986 16:59-EDTCOMSATDate: Mon, 16 Jun 86 17:30:00 EDT From: Communications Satellite Subject: Msg of Saturday, 14 June 1986 16:59-EDT To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57607.860616> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O * $"    @HZS$ \s[HZS{2 HM!^H0P xx0s,,X@  @!` %` %` `0102(H304C(5k0607K(H8BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [PARKER%REAGAN.AI.MIT.EDU@XX.LCS.MIT.EDU: Consulting]]Date: Tue, 3 Jun 86 10:24:46 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [PARKER%REAGAN.AI.MIT.EDU@XX.LCS.MIT.EDU: Consulting] Date: Wed, 28 May 1986 14:27 EDT Sender: PARKER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU From: Randy Parker To: mikeg@BORAX.LCS.MIT.EDU (Michael Golding) Cc: PARKER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: Consulting In-Reply-To: Msg of 28 May 1986 09:48-EDT from mikeg at BORAX.LCS.MIT.EDU (Michael Golding) Date: Wednesday, 28 May 1986 09:48-EDT From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) The company I work for is looking for Lisp Machine Consultant Types at varios levels for the immediate future. we need some high level people, but mainly need mid level people who are interested in the $20 - $40 range. if you are interested in talking send mail to me at this address [mikeg@borax.lcs.mit.edu]. Mike Golding Home: (617)661-9053 I'm actually not in the market for consulting right now [given that I start at Palladian in 3 weeks], but I like to keep in touch with who's got openings, and I know a fair amount of consulting types who might be interested. Please send me some more detail [who, what, when, where]. Thanks, RP <[AI.AI.MIT.EDU].57300.860616.GYRO>Date: Mon, 16 Jun 86 01:12:11 EDT From: "Scott W. Layson" Subject: [mikeg: [PARKER%REAGAN.AI.MIT.EDU@XX.LCS.MIT.EDU: Consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57300.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O ` $2    @H $0 = x@ HM!NH0P x00s,,X h@ F @!` |` |` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [GRANT@XX.LCS.MIT.EDU: "LispM consulting.."]]Date: Tue, 3 Jun 86 10:25:17 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [GRANT@XX.LCS.MIT.EDU: "LispM consulting.."] Date: Wed 28 May 86 14:30:57-EDT From: Kenneth R. Grant Subject: "LispM consulting.." To: mikeg@BORAX.LCS.MIT.EDU What type(s) of LispM are of interest ? To wit, my zetalisp is a bit rustty (and I'm two releases behind in the Symbnolics world) If, however, you need some Interlisp (Xerox) expertise, I'd be very interested in talkiing. If you're interested, give me a call at 576-4626 (leave a message ...) -Ken <[AI.AI.MIT.EDU].57298.860616.GYRO>Date: Mon, 16 Jun 86 01:11:44 EDT From: "Scott W. Layson" Subject: [mikeg: [GRANT@XX.LCS.MIT.EDU: "LispM consulting.."]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57298.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O  $"    @H $   HM!:H0P x0s,,X,h @ Q @!{` h` h` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [uucp@MIT-CCC@mit-mc: Lispm consulting]]Date: Tue, 3 Jun 86 10:25:27 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [uucp@MIT-CCC@mit-mc: Lispm consulting] Date: 28 May 1986 14:31:23-EDT From: uucp@MIT-CCC@mit-mc Apparently-To: >From hga Wed May 28 14:24:34 1986 remote from mirror Received: by mirror.UUCP (4.12/4.7) id AA00617; Wed, 28 May 86 14:24:34 edt Date: Wed, 28 May 86 14:24:34 edt From: mirror!hga (Harold Ancell) Message-Id: <8605281824.AA00617@mirror.UUCP> To: mit-ccc!mikeg@borax.lcs.mit.edu Subject: Lispm consulting I'm interested; what sort of work, and where are they located? I used to work at LMI, and would like to do some Lispm hacking again. - Harold <[AI.AI.MIT.EDU].57296.860616.GYRO>Date: Mon, 16 Jun 86 01:11:25 EDT From: "Scott W. Layson" Subject: [mikeg: [uucp@MIT-CCC@mit-mc: Lispm consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57296.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O  $    @H $0   HM! H0P xP0s,,X(H @ K @!!` ` ` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [SAUND%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: consulting]]Date: Tue, 3 Jun 86 10:25:37 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [SAUND%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: consulting] Date: Wed 28 May 86 20:46:43-EDT From: SAUND%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: consulting To: mikeg@BORAX.LCS.MIT.EDU Cc: saund%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU I might be interested in doing some consulting. I work on shape representation for vision, and I do a lot of hacking on lisp machines. My offices are NE43-825 and E10-104A x3-1299, x3-5774 home: 492-7532 Give me a call, or I will try to reach you at 661-9053. -Eric Saund SAUND@OZ <[AI.AI.MIT.EDU].57294.860616.GYRO>Date: Mon, 16 Jun 86 01:10:40 EDT From: "Scott W. Layson" Subject: [mikeg: [SAUND%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57294.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O u D    @H r$"  H ry) HM zH0P xP0s,,X2 @  @ ` ^` ^` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [GRANT@XX.LCS.MIT.EDU: Re: "LispM consulting.."]]Date: Tue, 3 Jun 86 10:26:12 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [GRANT@XX.LCS.MIT.EDU: Re: "LispM consulting.."] Date: Thu 29 May 86 16:12:21-EDT From: Kenneth R. Grant Subject: Re: "LispM consulting.." To: mikeg@BORAX.LCS.MIT.EDU In-Reply-To: <8605290357.AA06278@BORAX.LCS.MIT.EDU> Thanks for the reply. When would you like to get together? I'm pretty much free all day Friday. For reference, I can be reached at home at 576-4626 , at the office at 253-0587. I do most of my mail reading (and am online most of the time) at a machine called xv (however, the mail gateways to this are not the most reliable known and I do logon to xx to read my mail once or twice a day) Looking forward to talking with you.. -Ken <[AI.AI.MIT.EDU].57292.860616.GYRO>Date: Mon, 16 Jun 86 01:10:20 EDT From: "Scott W. Layson" Subject: [mikeg: [GRANT@XX.LCS.MIT.EDU: Re: "LispM consulting.."]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57292.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O M $*    @H $   wa HM kH0P x80s,,Xp@ 3 @ ` m` m` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [BOYLE%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: LM jobs]]Date: Tue, 3 Jun 86 10:26:30 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [BOYLE%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: LM jobs] Date: Thu 29 May 86 18:13-EDT From: Joe Boyle Subject: LM jobs To: mikeg@BORAX.LCS.MIT.EDU Could you tell me more about this? I'm doing lisp consulting now and will probably be finished with the current job soon. <[AI.AI.MIT.EDU].57290.860616.GYRO>Date: Mon, 16 Jun 86 01:10:06 EDT From: "Scott W. Layson" Subject: [mikeg: [BOYLE%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: LM jobs]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57290.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O  $    @H $ #G  M HM [H0P x@0s,,X2 @  @ ` ^` ^` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [JHC%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: Consulting]]Date: Tue, 3 Jun 86 10:26:44 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [JHC%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: Consulting] Date: Fri, 30 May 1986 11:55 EDT From: JHC%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: mikeg@BORAX.LCS.MIT.EDU (Michael Golding) Cc: JHC%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: Consulting In-Reply-To: Msg of 28 May 1986 23:54-EDT from mikeg at BORAX.LCS.MIT.EDU (Michael Golding) Friday is a bad day for me -- I have to run around to get my car registered and insured. Maybe early next week? More specific specs on my interest are: $25 - $30/hour 10 - 15 hrs/week have a car specialities: vision, robotics, some expert systems machines: have worked on 3600's, 3640's, 3670's, and CADR's never worked with an Explorer -- Jon <[AI.AI.MIT.EDU].57288.860616.GYRO>Date: Mon, 16 Jun 86 01:09:49 EDT From: "Scott W. Layson" Subject: [mikeg: [JHC%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: Consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57288.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O  D    @H 5$ u,5 5zg HM @H0P x0s,,XD@  @ ` ( ` ( ` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [ZVONA@AI.AI.MIT.EDU: ]]Date: Tue, 3 Jun 86 10:27:28 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [ZVONA@AI.AI.MIT.EDU: ] Date: Fri, 30 May 86 17:41:01 EDT From: David Chapman To: MIKEG@AI.AI.MIT.EDU Oh, yeah. Two plausible people for your business partner: Neil Mayle and Phil Greenspun. Neil Mayle was a Sussman person, did some of the scheme chip work, went to symbolics for a while, and left because he was bored. He's also worked at Atari and I think TMC. For the last year he's been consulting free-lance and learning to weave. He's very bright, a complete lispm wizard, and a completely reasonable person. The only draw back might be that he's never sure what he really wants to do and might flake out after a while. Greenspun is a competent Lispm person, worked for ICAD for a year and built most of their stuff, and has also been consulting freelance a lot. He's got a strong business orientation and is less flakey than Neil, but is kind of obnoxious. He's being an EE (analog) grad student in the fall; I don't know if that will get in the way. I'm collecting resume-equivalents from some good hackers for you. Good luck... See you next fall if not sooner. <[AI.AI.MIT.EDU].57286.860616.GYRO>Date: Mon, 16 Jun 86 01:09:22 EDT From: "Scott W. Layson" Subject: [mikeg: [ZVONA@AI.AI.MIT.EDU: ]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57286.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O g $"    @H $0  L ˇ}c HM -H0P x`0s,,X@ N @ _` T` T` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [PARKER@OZ.AI.MIT.EDU: Consulting]]Date: Tue, 3 Jun 86 10:28:42 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [PARKER@OZ.AI.MIT.EDU: Consulting] Date: Fri, 30 May 86 21:42 EDT From: Randy Parker Subject: Consulting To: Michael Golding Cc: PARKER@REAGAN.AI.MIT.EDU In-Reply-To: <8605290355.AA06267@BORAX.LCS.MIT.EDU> Reply-To: PARKER@REAGAN.AI.MIT.EDU Date: Wed, 28 May 86 23:55:57 edt From: mikeg@BORAX.LCS.MIT.EDU (Michael Golding) It is likely that we can find some work for you, could you send a resume and an estimate on what you would want to make per hour. ***ASAP*** Lets get together and talk on Friday or thereabouts. -Mike ********************** I'll be in touch a lot sooner than Friday. We look forward to working with you... If you are around tomorrow (Sat) in the morning or on Tuesday, then I'd love to chat. Otherwise, I will be dealing with family (graduation weekend) until Monday, and then Wednesday I go on vacation for 10 days. My interest (right now) is more informational, as it looks now like I am going to be starting full-time at Palladian soon after my return. However, I would like to be "kept in mind" (i.e. on any rosters you may keep) and so here is my blurb below. If you need a resume, too, I can send you one (all I have is hardcopy) at some point. Thanks, RP Randy Parker MIT AI Lab post-undergrad (SB, Computer Science, 6/86) PARKER@MIT-AI (617) 723-5848 Over three years LispM experience Competences: User interface design and implementation, debugging tools, knowledge of automatic programming research, system internals (Zwei, Mailer, network, windows), knowledge-based systems, object-oriented programming, Common LISP. Location: Based in Boston. Willing to travel some. Fee: Negotiable. Ethics: Not willing to work on classified projects or weapons applications. <[AI.AI.MIT.EDU].57284.860616.GYRO>Date: Mon, 16 Jun 86 01:09:03 EDT From: "Scott W. Layson" Subject: [mikeg: [PARKER@OZ.AI.MIT.EDU: Consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57284.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O  $    @H C$4 c,H Cc HM H0P x0s,,X@ W @ )`  P/` P/` `p:$5pUxpLpL pOpx;x/#BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [rms@PREP.AI.MIT.EDU: ]]Date: Tue, 3 Jun 86 10:27:20 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [rms@PREP.AI.MIT.EDU: ] Date: Fri, 30 May 86 16:39:22 EDT From: rms@PREP.AI.MIT.EDU (Richard M. Stallman) To: mikeg@borax.lcs.mit.edu I hear you are looking for Lisp Machine consultants. If they are not slime machines, I might be interested. <[AI.AI.MIT.EDU].57282.860616.GYRO>Date: Mon, 16 Jun 86 01:08:36 EDT From: "Scott W. Layson" Subject: [mikeg: [rms@PREP.AI.MIT.EDU: ]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57282.860616.GYRO> YN-!  ###### ########&###.###6###>####F#'##N#+##V#/##^#3##f#7##n#;##v#?##~# ##$ #c####@HV$( XWeV HM7H0P x(0s,,X @  @u` pX` pX` `p:QxpLx; x/BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [straz@MEDIA-LAB.MIT.EDU: lispm consulting]]Date: Sun, 8 Jun 86 18:48:20 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [straz@MEDIA-LAB.MIT.EDU: lispm consulting] Date: Wed, 4 Jun 86 22:41:21 EDT From: Steve Strassmann To: mikeg@MIT-BORAX.ARPA Subject: lispm consulting I just saw the follow-up message. Here's the particulars: 1) Resume: to follow in separate email msg 2) Estimate: $12-15/hour 3) Car: yes 4) Areas: Window system, teaching novices, graphics & simulations Primary and extensive experience with 3600, no recent experience with TI/LMI, but this should be no problem. 5) Time available: Almost none this summer, more freedom during the fall. I'd like to be kept on a long-term mailing list. <[AI.AI.MIT.EDU].57280.860616.GYRO>Date: Mon, 16 Jun 86 01:07:06 EDT From: "Scott W. Layson" Subject: [mikeg: [straz@MEDIA-LAB.MIT.EDU: lispm consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57280.860616.GYRO> YN-!  ###### ########&###.###6###>####F#'##N#+##V#/##^#3##f#7##n#;##v#?##~# ^##$0 #c####@HZ#$> ^c,]oZ#}6 HM)H0P x(0s,,XE@ D @]` x` x` `p:QxpLx; x/BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [straz@MEDIA-LAB.MIT.EDU: lispm consulting]]Date: Sun, 8 Jun 86 18:49:03 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [straz@MEDIA-LAB.MIT.EDU: lispm consulting] Date: Wed, 4 Jun 86 22:47:01 EDT From: Steve Strassmann To: mikeg@MIT-BORAX.ARPA Subject: lispm consulting Here's my resume: Steve Strassmann ARPANET address: STRAZ @ MEDIA-LAB.MIT.EDU Home: 3 Ames St. Cambridge, MA. 02139 Phone: (617) 577-1520 Office: E15-413, 20 Ames St. Cambridge, MA. 02139 Phone: (617) 253-0392 Education: MIT, Cambridge, MA Ph.D. candidate in Media Technology. M.S. received in June '86, Thesis entitled "Hairy Brushes in Computer Graphics," at the Media Laboratory. M.S. work involved developing an original rendering algorithm for simulating sumi (Japanese watercolor) brush strokes. The algorithm is used for both interactive painting and animation. Thesis work will be presented at the Technical Session of Siggraph '86. MIT, Cambridge, MA B.S. '84 in Computer Science. Thesis entitled "Learning Lisp: The Barriers to Novice Programmers at MIT". Based on extensive experience as a teaching assistant, I analyzed common difficulties and teaching tricks in MIT's core software course. Concentration studies were on the Japanese language and culture. Experience: MIT Media Lab, Cambridge, MA Fall, 1984 - present Research Assistant. Projects to date include "Sloop", a concrete animation editor in the spirit of MacPaint, "Talking Blocks", an educational microworld for children and illiterate adults, and "Buttons", an icon-based programming microworld (in which "Talking Blocks" was implemented). Thinking Machines Corp., Cambridge, MA Summer 1985 Wrote demonstration and educational programs for the Connection Machine. Implemented graphics programs to run on the CM. Wrote a tutorial program animating and explaining the CM's routing mechanism. Helped integrate the software environment and educate new employees about the CM and LISP. Self employed. Summer 1984 Consultant to CSK, Inc. (Tokyo) and Lisp Machines, Inc. (Cambridge, MA). Helped new users learn the lisp machine programming environment and the Lisp language. Taught an MIT programming course (6.001) at CRI (CSK Research Institute). Developed introductory and advanced course material for LMI and taught it at LMI and at MCC in Austin, Texas. MIT Computer Science Department, Cambridge, MA 1983-4 Teaching assistant for 6.001, "Structure and Interpretation of Computer Programs". Taught course 2 terms to undergraduates, three 2-week intensive courses to industrial participants, and one 2-week course to CSK, Inc. in Tokyo. Used observations in preparation of BS thesis. MIT Artificial Intelligence Lab, Cambridge, MA 1983 and Atari Corp. Research Labs, Cambridge, MA Developed a program which transcribes keyboard performances into conventional score notation, and contributed to various aspects of the Atari music system (running on Symbolics lisp machines). Hewlett-Packard Labs, Palo Alto, CA Summer, 1982 Researcher in the newly-created robotics group. Responsibilities included identifying goals, recommending purchase of start-up equipment, and planning research strategy. MIT Artificial Intelligence Lab, Cambridge, CA Summer, 1981 Designed a VLSI chip to implement and test different three-transistor RAMs. The RAM was to be used in the Connection Machine. Also contributed to the CAD program used to design the chip, simplifying and improving the user interface. Other Activities: Alpha Phi Omega (service fraternity)- Brother, active member. Sigma Xi (honorary fraternity) - member Eagle Scout National Merit Scholarship winner Piano - play and compose jazz and rock. Tutor - (1984 - present) Resident Graduate Tutor in an undergraduate dorm. Helping undergraduates with social and academic problems. Papers: "Hairy Brushes" to be presented at Siggraph '86. References: Available upon request. <[AI.AI.MIT.EDU].57278.860616.GYRO>Date: Mon, 16 Jun 86 01:06:54 EDT From: "Scott W. Layson" Subject: [mikeg: [straz@MEDIA-LAB.MIT.EDU: lispm consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57278.860616.GYRO> YN-!  ###### ########&###.###6###>####F#'##N#+##V#/##^#3##f#7##n#;##v#?##~# ##$* #c####@H\/$ bOb)H\/ HMH0P x`0s,,Xq@  @A` (e` (e` `p:QxpLx; x/BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [ZVONA@AI.AI.MIT.EDU: consultants]]Date: Sun, 8 Jun 86 18:51:27 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [ZVONA@AI.AI.MIT.EDU: consultants] Date: Sat, 7 Jun 86 18:28:22 EDT From: David Chapman Subject: consultants To: mikeg@BORAX.LCS.MIT.EDU Here is the list I promised you. It's recycled from a list constructed for another purpose, so the set of people who are on it is slightly random. If you have questions about any of them, I can give you an impression. Philip E Agre MIT AI Lab grad student Agre@AI.AI.MIT.EDU (617) 253-8826 Five years' LispM experience Competences: Language and user interface design, VLSI and CAD, extensive knowledge of AI theory and system design practice, experience programming parallel machines, experienced Lisp teacher. Location: Based in Boston but spends a few months a year in the San Francisco area. Willing to travel. Fee: Typically $400 a day, varying with the nature and location of the work. Not willing to work on classified projects or weapons applications. John Batali MIT AI Lab grad student Batali@MC.LCS.MIT.EDU (617) 253-8839 Seven years' experience on LispMs Competences: Zwei, vision and database systems, large AI systems, language and representation design, experienced Lisp teacher. Location: Based in Boston, willing to travel Fee: Negotiable but steep Not willing to work on classified projects or weapons applications. David Chapman MIT AI Lab grad student Zvona@AI.AI.MIT.EDU (617) 253-8827 Seven years' experience on LispMs Location: Boston, willing to travel for up to a week. Time: not more than (long-term) 1 day/week or (short term) chunks of a week or two every few months. Special competences: AI (reasoning, representation, theorem proving, rule systems, planning, etc.); smart software engineering technology (program analysis, optimizing compilers, smart debuggers, etc.); advanced symbolic programming (embedded languages, programming parallel processors, code optimization, etc.) Not willing to work on classified projects or weapons applications. James R Davis MIT Media Lab grad student JRD@MIT-Media-Lab (617) 253-0314 Five years' experience on Lispms Competences: Has implemented several large systems. Especially good with windows and teaching. Location: Based in Boston, negotiable Time: In general, summer or January only, but short-term school-year projects are possible. Fee: Negotiable Not willing to work on classified projects or weapons applications. Gavan Duffy GAVAN@Reagan (512) 471-5121 Currently an MIT graduate student finishing doctoral dissertation while serving as a tenure-track instructor at the University of Texas at Austin Dept of Government. Ph.D. expected May, 1986. Five years experience on LispMs Competences: Natural language: built a transformational English-language parser, lexicon, categorial disambiguator, temporal representation, Zwei interface and resource allocation software for a large natural language system. Extensive knowledge of statistical methods. Location: Austin, Texas. Willing to travel (especially during the summer). Consulting limited by University policy to one day per week while school is in session. Fee: Negotiable Kenneth W Haase MIT AI Lab grad student KWH@AI.AI.MIT.EDU (617) 253-3516 Six years' experience on LispMs Competences: Window system, editor, and mail system internals. Experience in computer graphics, animation, design of embedded languages and representations. Has implemented several large systems. Location: Based in Boston, willing to travel for no more than one week. Fee: Negotiable (usually upward of $500 a day) Not willing to work on classified projects or weapons applications. Daniel P Huttenlocher MIT AI Lab grad student DPH@AI.AI.MIT.EDU (617) 253-8843 Five years' experience on LispMs Competences: Speech and signal processing (including Spire), model-based computer vision systems, experienced Lisp teacher. Location: Based in Boston, willing to travel Fee: Negotiable Not willing to work on classified projects or weapons applications. John C Mallery Graduate student in international relations and machine learning JCMA@AI.AI.MIT.EDU Phone: (617) 253-5966 Six years experience on Lisp Machines Competences: Extensive experience with large LISP systems, including the Winston analogy program, and more recently, Relatus, a large natural language system designed with Gavan Duffy. Designed and implemented knowledge representations, constraint-interpreting reference system, sentential constraint poster, question answering system, user interfaces, resource management and program development tools. Experience with editor and Zmail internals. Extensive knowledge of economics, organization theory, and international relations. Languages: Spanish and French. Location: Based in Boston, willing to travel Time: Short periods, one week to one month during the summer, occasional days at other times. Booked through August 1986. Fee: Negotiable Ethics: Not willing to work on classified projects or weapons applications. Randy Parker MIT AI Lab post-undergrad (SB, Computer Science, 6/86) PARKER@MIT-AI (617) 723-5848 Over three years LispM experience, five years with Lisp Competences: User interface design and implementation, debugging tools, knowledge of automatic programming research, system internals (Zwei, Mailer, network, windows), knowledge-based systems, object-oriented programming, Common Lisp. Location: Based in Boston. Willing to travel some. Fee: Negotiable. Ethics: Not willing to work on classified projects or weapons applications. Mark H. Shirley MIT AI Lab grad student Mhs@HT.AI.MIT.EDU work: (617) 253-5848 home: (617) 723-9263 Five years' experience on LispMs Competences: large AI systems, user interface design, CAD / logic simulators Location: Based in Boston, willing to travel Time: Short term work only Fee: Negotiable Ethics: Situational Raul E. Valdes-Perez MIT AI Lab Research Scientist CMU Graduate Student (Fall 1986) VALDES@MIT-HTVAX (617) 253- 5899 2 years of experience with Lisp machines. Competence: Knowledge-based (expert) systems, algorithms. Teaching. Location: Boston/Pittsburgh, willing to travel. Time: Short-term work only. Fee: Negotiable. Ethics: Yes. David Vinayak Wallace MIT AI Lab undergraduate Gumby@MC.LCS.MIT.EDU (617) 253-7885 Six years' experience on LispMs Competences: Systems programming (window system, zwei, network code), representation and programming languages. Location: Based in Boston, willing to travel Time: In general limited to when school is not in session Fee: Negotiable Ethics: Situational Daniel S Weld MIT AI Lab grad student Weld@AI.AI.MIT.EDU (617) 253-8837 Five years' experience on LispMs Competences: Knowledge representation, AI programming techniques, user interface design, large software systems, expert systems Fee: Negotiable Location: Based in Boston, willing to travel Ethics: Situational <[AI.AI.MIT.EDU].57276.860616.GYRO>Date: Mon, 16 Jun 86 01:06:40 EDT From: "Scott W. Layson" Subject: [mikeg: [ZVONA@AI.AI.MIT.EDU: consultants]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57276.860616.GYRO> YN-!  ###### ########&###.###6###>####F#'##N#+##V#/##^#3##f#7##n#;##v#?##~# ##$( #c####@HV$ X:W_Vzg HMdH0P x 0s,,X@  @` t ` t ` `2*(& M')1<S<I.] / _BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [GRANT@XX.LCS.MIT.EDU: LispM consulting..]]Date: Sun, 8 Jun 86 20:43:39 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [GRANT@XX.LCS.MIT.EDU: LispM consulting..] Date: Fri 6 Jun 86 12:17:12-EDT From: Kenneth R. Grant Subject: LispM consulting.. To: Mikeg@BORAX.LCS.MIT.EDU Hi again..After our failed meeting at T-Square, I sent you a message to which I haven't received a reply. I'm not sure what this means , so thought I'd try one more time.. My particulars, which I never sent you are as follows.. Have spent the last 6 years at MIT - SB in Comp Sci, Research Staff for a year, PhD Student in MIS, currently back on Research Staff. Have hacked 3600s (rusty at this point). Installed a network of Xerox Dandilions/Tigers while on staff, resident Interlisp guru (at Sloan). Have attended KEE training at Intellicorp. Have hacked lots of other (non LispM) things for a lot of people. I have a car. My time is pretty flexible but I am full time staff (this means that taking a day or two off is no problem most of the time, taking a week off is doable with a little notice) Anyway, if there is a continuing interest from your end, send mail. Thanks, -Ken <[AI.AI.MIT.EDU].57274.860616.GYRO>Date: Mon, 16 Jun 86 01:05:42 EDT From: "Scott W. Layson" Subject: [mikeg: [GRANT@XX.LCS.MIT.EDU: LispM consulting..]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57274.860616.GYRO> YN-!    O  O  O  O & O . O 6 O > O# F O' N O+ V O/ ^ O3 f O7 n O; v O? ~ O x $,    @H $ )l y8 HMbH0P x0s,,X @ ] @` ` ` ` 0XIqhH~!P  BABYLGYRORFC733GYROPLUKEL@AI [mikeg: [GILLETT%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: Re: Consulting]]Date: Fri, 13 Jun 86 20:47:30 edt From: mikeg at BORAX.LCS.MIT.EDU (Michael Golding) To: gyro Re: [GILLETT%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: Re: Consulting] Date: Mon 9 Jun 86 18:00:29-EDT From: "Walter E. Gillett" Subject: Re: Consulting To: mikeg@BORAX.LCS.MIT.EDU In-Reply-To: <8605281348.AA22988@BORAX.LCS.MIT.EDU> Mike, Although I am not available at the moment, I may be doing some consulting in the future and am interested in your message. Could you tell me (1) what the company is (2) more about the requirements - what is the system/application. I am a first-year grad student (psych department/ A.I. Lab) working on vision. Before coming to MIT, I spent four years in the software industry, including one year of consulting. Thanks, Walter <[AI.AI.MIT.EDU].57271.860616.GYRO>Date: Mon, 16 Jun 86 01:03:33 EDT From: "Scott W. Layson" Subject: [mikeg: [GILLETT%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: Re: Consulting]] To: PLUKEL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].57271.860616.GYRO> YN-! D DD D "D*D2D:DBD!JD%RD)ZD-bD1jD5rD9zD=  D$$ dDD@HDS$ NsHDSHDS` HLpoH0P(X,@ 8oG` P 0z8  @{` @{(``10mXnT r6 edtBABYLKIRSHRFC733KIRSHSHIM@AIShimon, I'm collating the annual president's report this year. It's due in early July so we have to act fast. I'm enclosing a copy of your texts from last year's Lab blurb. Could you put together your own sections soon -- say, by a week from this Monday, that is, JUNE 23? I leave it to you and Tomaso to decide who will do what. When revising remember that everything following the command \blurb{} will appear only in the Laboratory blurb. The president's report contains none of the sentences demarcated by the {}. I'm also sending a message system wide stating that anyone not in last year's blurb who wishes to be included in this year's should contact either you, if he thinks of you as his supervisor, or me. Have fun. -- David %% Here's your entry from last year \subsection {\foo{Early Biological and Machine Vision}} Professor Poggio, Professor Ullman, and their associates are developing a theory of computational vision intended to shed light on both biological and machine vision. The theoretical understanding of artificial vision benefits from the study of human vision because biological visual systems provide the best-known examples of efficient visual processors. Problems studied include regularization theory, edge detection, stereo, motion, surface reconstruction, multigrid algorithms, the computation of color, the computation of spatial properties, the development of an artificial eye-head system, the understanding of trajectories, intelligent signal processing, new parallel analog hardware, and biophysics of computation. \pp Professor Poggio is working on many early-vision problems that are mathematically ill-posed in the sense of Hadamard. Regularization analysis, developed in recent years, can be used to solve those early-vision problems using variational principles that enforce constraints derived from a physical analysis of the problem. This is a new theoretical framework for some of the variational solutions already obtained in the analysis of early vision processes. It also shows how several other problems in early vision can be approached and solved. \pp Professor Poggio, Professor Vincent Torre (of the University of Genoa, Italy), Dr. Alan L. Yuille, Mr. Harry L. Voorhees, and Ms. Anya Hurlbert applied regularization analysis to several problems in early vision, including edge detection, color computation, and stereo matching. At the same time, Mr. Jose Marroquin, Dr. Demetri Terzopoulos, and Dr. Yuille, continued to extend regularization theory in order to deal with discontinuities and to fuse information from different vision modules. \pp As proposed by Professors Torre and Poggio, edge detection, when defined as a problem of numerical differentiation, is an ill-posed problem. Using standard regularization theory, the problem can be regularized. The regularized solution is then the solution to a variational principle. In the case of non-exact image data Professor Poggio, Mr. Voorhees, and Dr. Yuille prove three things: that this variational principle leads to a convolution filter for the problem of one-dimensional edge detection; that the form of this filter---a spline---is very similar to the Gaussian filter; and that the regularizing parameter $\lambda$ in the variational principle effectively controls the scale of the filter. Mr. David Geiger and Professor Poggio are exploring the use of methods from regularizing theories for finding the optimal value of the regularizing parameter $\lambda$ and the connection between these methods and the scale-space method for edge detection. \pp The problem of stereo vision continued to be an important focus of research. Dr. Yuille and Professor Poggio explored constraints on the stereo matching from the perspective geometry of the imaging process and derived a generalized ordering constraint that can be exploited in future stereo algorithms. \pp The computation of motion is another typical problem of early vision. Its solution is important because reliable information about the three-dimensional structure of the environment is encrypted in the relative movement between features in the changing two-dimensional image that is projected onto the eye. Dr. Ellen C. Hildreth and Dr. Norberto M. Grzywacz have designed and tested computer algorithms that can recover the three-dimensional structure of both rigid and nonrigid objects in motion. These algorithms are extensions of previous work by Professor Ullman. \blurb{Experiments with computer simulations indicate that these algorithms can provide a robust recovery of structure for computer vision systems and reveal qualitative similarities between their behavior and human perceptual behavior. These studies raise important questions regarding the quantitative ability with which the human visual system can recover three-dimensional structure from relative movement.} \pp Dr. Terzopoulos studied the computation of visible-surface representations, another ill-posed problem of early vision. A variational principle was developed which governs the reconstruction of dense visible surfaces from sparse, local three-dimensional shape estimates collected from multiple visual modules. \blurb{The principle is based on controlled continuity, a nonrestrictive assumption which is employed in the variational detection of surface discontinuities. A novel, concurrent multigrid method was developed for efficiently solving the variational principle. Concurrent multigrid coordination produces a fully parallel, cooperative algorithm which is ideally suitable for implementation on connection machine architectures.} \pp Another problem that is presently approached with regularization techniques is the computation of spectral reflectance of surfaces. A basic goal of biological color vision is to recover the invariant spectral reflectance properties of an object's surface. Ms. Hurlbert and Professor Poggio are developing a regularization algorithm in which two constraining assumptions allow the decomposition of the intensity array into surface reflectance and source illumination: the single source assumption, which states that the spatial variation of the source illumination is the same for each wavelength channel; and the spatial regularization assumption, which states that the spatial variation of the effective source illumination is slower than that of the surface reflectance. \blurb{Ms. Hurlbert and Professor Poggio are also exploring the possibility of learning standard regularizing algorithms from examples without having to formulate explicitly the variational principle that embeds the relevant physical constraints. This is important because the exact form of the relevant constraints depends on the specific situation. In some cases, a standard regularizing linear operator can be synthesized without an explicit variational principle by computing the pseudoinverse of the data, if a sufficient set of correct input-output data pairs are available. The learning scheme can be extended to nonquadratic regularization principles. One possibility is to use a linear associative scheme preceded by appropriate nonlinear coding of the input data. A better possibility is to find the nonlinear operator that minimizes an appropriate distance between the data and the solution set.} \pp The theoretical framework, based on the concept of ill-posedness of early vision, shows clearly not only the attractions but also the limitations that are intrinsic to the standard Tikhonov form of regularization theory. The main problem involves the degree of smoothness required for the unknown function that has to be recovered. Mr. Marroquin and Professor Poggio have developed extensions of standard regularization for the problem of preserving discontinuities in the reconstruction of surfaces from depth data. \blurb{The corresponding variational principle embeds prior knowledge about the geometry of the discontinuities and, in particular, that they are continuous and often straight contours.} \pp Unconventional analog computational machines for solving the variational problems of standard regularization are being explored by Dr. Christof Koch and Professor Poggio. This work is closely connected to the area of biophysics of computational systems, a new theoretical approach aimed at understanding the computational mechanisms used by nervous systems. The work being carried out by Professor Poggio, Dr. Koch, and others has already shown that single neurons are likely to be very highly parallel devices performing hundreds of independent analog operations on their inputs. \blurb{Dr. Yuille and Dr. Koch have addressed various questions concerning the use of these and similar networks within the framework of early vision. In particular, they have proven that networks of the type used by Hopfield in the context of associative memory can find the unique solution to quadratic variational problems if the gain function of the elements is linear. Under these conditions, Hopfield's rule for updating the state of every neuron is equivalent to a steepest descent algorithm.} \subsection {\foo {The Interface Between Vision and Motor Control}} Another important area of research is the frontier between visual perception and motor control. Ms. Katie Cornog, with Dr. H. Keith Nishihara and Professor Poggio, studied the computational problems related to eye-head coordination by building an artificial eye-head system provided of two stereo CCD cameras. The requirements for such a system are not unlike those for the primate oculomotor system: to scan the visual environment, locate, and fixate objects of interest; to stabilize the images of such objects despite object or self movement; and to reduce the bandwidth of visual information by the use of a small, high-density photoreceptor array which requires sequential relocation to different spots in a wide field of view. \blurb{Ms. Cornog has utilized an electro-mechanical two-camera positioner, the eye-head robot, to develop and implement control algorithms for the guidance of eye and head movements during the tasks of fixating and tracking an object in three dimensions. The algorithm, executed in LISP, allows the eye-head robot to track an object moving up to 15$\deg$ per second for brief periods and to hold the image stable to within 3 pixels. She has found that typical biological control strategies, such as those used by the primate oculomotor system, including both positional and velocity feedback, improve the ability of the robot to fixate and stabilize the image of a moving target.} \pp Mr. Bror Saxberg studied another computational problem at the interface between vision and motor control. In particular, he looked at how gravity can be used as a constraint in the case of a free-fall trajectory projected onto an image plane by central projection. He has also checked for similar processing by the human visual system by looking at results from a simple video game designed to test if we are able to use the same kinds of information suggested by the theoretical implementations. -- HARD COPY TO FOLLOW <[AI.AI.MIT.EDU].56674.860614.KIRSH>shim@NOSHOWDate: Sat, 14 Jun 86 03:57:23 EDT From: David Kirsh To: SHIM@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].56674.860614.KIRSH> YN-!  EEfE Ef EEf EEfE"EfE*EfE2EfE:Ef!EBEf%EJEf)EREf-EZEf1EbEf5EjEf9ErEf=EzEf tE$ F EE@Hxr$ HxrHxr` HLp}p (P(X 0 fH (x @ x 8=Px0s`t`t`/x=[fC%Q,_3@SU-AI.ARPA:FAHLMAN@C.CS.CMU.EDUALAN@AI.AI.MIT.EDUReceived: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jun 86 00:53:17 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jun 86 21:49:13 PDT Received: ID ; Sat 14 Jun 86 00:49:10-EDT Date: Sat, 14 Jun 1986 00:49 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: cl-steering@SU-AI.ARPA Subject: [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Lisp standardization] Here is Ida's response to the note I sent him. It is a bit hard to parse, as you will see, but it does contain lots of good information about the structure of the effort in Japan. I'm still trying to sort it all out, but it looks like Ida is certainly one of the people we want, maybe on the steering committee as he suggests. Suggestions are welcome at this point. -- Scott --------------------------------------------------------------------------- Date: Sat, 14 Jun 86 11:57:40+0900 From: Masayuki Ida To: fahlman, ida at UTOKYO-RELAY.CSNET Re: Lisp standardization Professor Fahlman, Thank you for your quick responce to my mail. Here are my views/opinions/descriptions about the things you wrote to me. 1) My visit to Lisp conference and AAAI conference. I will visit USA with several persons of our committee as a team. Scheduled dates are one week stay at Boston from Aug.3 to 10, and another one week stay at AAAI site, roughly. 1') I will join you at the meeting you suggested. and I am pleased to know I will be welcomed to discuss and tell the situation in japan. 1'') As I stated in 1), I will be with several colleagues at hotel. We will have a meeting at the hotel. So, I want to arrange an invitation to our meeting. Can you spare your time to join us at Boston ? 2)General steps toward the standardization of computer languages in japan. There is only one committee for MITI whose name is JIS programming language standardization or so. All the computer languages are defined by this committee. But the actual working is not carried by the committee, like SC22 forms WG for each language. The membership of this top committee are not opened and I am not the member of this top committee. I think almost all the members are very senior persons. From my experinece and my knowledge, the standardization is initially directed by MITI. This task force is undertaken by Jeida or IPSJ. After the actual works by Jeida or IPSJ finish, MITI calls the members for the top JIS committee and ask them to guarantee it. The draft which appear to the top committee is not actually discused, when the language spec is parallely defined to ANSI. Jeida standardization team is carried by Prof. Yoneda (u-tokyo). IPSJ standardization team is carried by prof. Nakata (u-Tsukuba). Prof. Nakata is an official member of ISO TC22 as a representative of Japan. (he gave me a copy of Bob Mathis's proposal of Ad Hoc Group on the preparation of NWI on Prolog and LISP to ISO/TC97/SC22) The documents appeared at ISO are send to MITI, then forwarded to several persons, including Prof. Nakata at least. He has, currently, a role to catch up the standardization of Fortran, Cobol,... On the other hand, Prof. Yoneda has a role to establish a standard for more "fresh" languages, like C, Ada, Lisp,... MITI select and decide which team is more suitable for any computer languages. Last tuesday, June 10, I was called by the staff of Prof. Yoneda's committee at Jeida. He told me that MITI suggest to start the working committee for Lisp standardization, and that the committee is under Prof. Yoneda's committee and I should be the chair of the JIS committee also. Then I will start the working committee to make a JIS draft with 13 members. the number of members is prior assigned and given to me. The scheduled dates of this year is one-a-two-month. The first meeting will be in July. Prof.Yoneda (and Prof. Nakata) is very senior person. I think the formal process in Japan is going just like you mentioned. I mean I agree your suggestion of your mail. i.e. ANY offical activities for standardization in Japan need senior persons who have responsibilities to totally control the whole process, even though he has only a basic knowledge about the language, and he can not understand the details or he have no time to spare to learn the language details. This JIS committee is different from the Common Lisp committee I have been talking about. But, they are all in Jeida. And they will be gathered to form a one large committee, I think. I think it is very usual to form a JIS working committee which is parallel to ANSI/ISO committee and the JIS committee will communicate with ANSI committee. 3) Member to ANSI committee from Japan I think the chair of the JIS committee should be a member of ANSI committee for this case. The reason is to avoid the separation of two standardizations and to keep ANSI committee can totally control the whole thing. I think the latter property is important, considering an unfortunate condition. Further, I even think it might be the best that someone in ANSI committee will attend Jeida committee. My current Jeida Common Lisp committee have totaly , over 40 members from 26 different organizations. They have more knowledge and skill than before. But KCL persons have a great role and a great infruence to Common Lisp in Japan. So, technically, Mr. Yuasa or Mr. Hagiya is the best person to technical committee. I think I am the next to them for the technical matter. For steering and standardization, I think I am the best person to join. Last april AI Association of Japan was formed. in my view, this organization has a relation to Common Lisp as a user organization. There is also a standardization committee. I was asked by them to be a chair for the standardization committee. But it is not formed yet. I do not know whether this group will survive or no now. But as the result of our questionnair shows, AI application in Japan is 60% based on Lisp or more, and the most actually used Common Lisp implemetation is VAXlisp,then Symbolics Lisp, then KCL. We should watch what the user society want. 4) Object oriented facility for Common Lisp. I have been following CommonLoops. Last year, before PCL appeared, I designed an interpretation of CommonLoops and presented a paper on it. Last Feb, I stayed at Xerox PARC for one week. I have experienced and somewhat assisted them to improve PCL. Xerox lawyer permitted me to carry back PCL sources. Now, I play a role of re-distributor of PCL in Japan. I am now researching with PCL. Since 1984 fall, I followed the discussion of o-o-bboard with the permission of Ken Kahn. Since last summer, I directed some members of my committee to catch up which is the best for Common Lisp among CommonLoops, objectLisp,... I think we, japanese are ready to accept the function call generalization of message sending and defstruct based flavor and so on. Several researchers in japan, to my surprise, already presented papers for present Prolog like facility upon CommonLoops-like object oriented facility. 5) Subset. Personally, I have an opinion that there should be two levels of Lisp language specification. Our subset working group will present their polish up of my proposal at July 8th in Japan. This group will make a pilot version of the subset. This subset can not self-compile itself. BUt this subset is intended to be fully compatible to the super. I have several friends in Gold Hill computers. Last March, I presented our subset draft to Dr. Jerry Barber at his office. And discussed with him for one or two hours. I also informed Professor Pat. Winston at his office. I hope we can make peace with them. As to EuLisp, here is Dr. Jean Peer Briot from Paris who is now visiting Japan as a visiting scientist, who has a relation to Chaillox of LeLisp. I was phoned by him and we met in tokyo. He told me that he was directed to meet me by Chaillox. I gave several staffs to him. 6) kanji and character/string We will polish up our discussion. I formed a working group for it. members are from ETL, HItachi, NEC, Fujitsu, Xerox, Symbolics, I and some othe rpersons. I think we can have some more concrete opinion before I will goto USA. I do not think it will be integrated into the one and only one opinion immediately. I think it may need a voting or take a year or so. Masayuki Ida FAILFahlman [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Lisp standardization]<[AI.AI.MIT.EDU].56597.860614>NO-CLINOQCRFC733YN-!  \\g\ \g \\g\\g\$\g\,\g\4\g\<\g"\D\g&\L\g*\T\g.\\\g2\d\g6\l\g:\t\g>\|\gCp f\ 4 ] \\@H]   _M] ] t` HICip(000s,,Xx0HPb@ hc NC` f` f` Rece fromby pw(3.2/.2) A0145u, 1990 175 PDTe: Th Apr :24 Prom: r Ham Sender: BITNIC IBM-NETS List Comments: Warning -- original Sender: tag was hank%bitnic.BITNET@LILAC.BERKELEY.EDU From: Bob Pasker Subject: Re: TCP/IP Versus LU 6.2 For Building Client-Server To: "Robert L. Plouffe" Message-ID: <9004192032.aa19454@mintaka.lcs.mit.edu> walasek@hpcc01.UUCP (Arthur Walasek) writes: >Wayne Clark writes: >> HERE IS THE CATCH: The family jewels (i.e. DB2, CICS, DISOSS, ...) are >>accessible only through SNA. Now, I imagine your client-server application >>might want to get to a mainframe database at some point. If this is the case, >>look real hard at LU 6.2 and ask tough questions to IBM regarding their TCP/IP >>for MVS and VM. >LU6.2 also uses, I believe, a dedicated line - that is, you need one >physical line from the IBM to each PC wanting a connection. can you say "multi-dropped SDLC?" >There are many variables here, and Wayne was correct when he stated that >IBM's real advantage is in using the SNA protocol. Hopefully they will >improve on their TCP/IP implementation in the future. promises and hope are not very helpful when building real applications for NOW. you can sit around for years waiting for stuff be released and, uh, "field debugged." -- - bob ;----------------------------------------------------------------- ; Bob Pasker, San Francisco, CA | rbp@well.sf.ca.us ; +1 415-695-8741 | {apple|pacbell}!well!rbp FAILNET-ORIGIN<723136.900419@AI.AI.MIT.EDU>YN-!  X]X/X]X/ X]X/X]X/X]&X/X].X/X]6X/X]>X/#X]FX/'X]NX/+X]VX//X]^X/3X]fX/7X]nX/;X]vX/?X]~X/  +X] 6 XX]X]@HX' ZYyX{7 HXS`` H0@h x@ (H0 N``RCHIVSRAAlanPGSZvonaNTS-HEFUSEEQV-LUSER-NTS-AECENTPGSACCOURCHIVEQV-LUSER-EFAILED: taa at MINTAKA.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "taa@MINTAKA.LCS.MIT.EDU"} FAILED: CLR at MINTAKA.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "CLR@MINTAKA.LCS.MIT.EDU"} FAILED: ad0r@tb.cc.cmu.edu at MINTAKA.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "ad0r@tb.cc.cmu.edu"} Failed message follows: ------- Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 19 Apr 90 22:37:18 EDT Received: from BU.EDU by mintaka.lcs.mit.edu id aa23808; 19 Apr 90 22:32 EDT Received: from BU-IT.BU.EDU by BU.EDU (1.97) Thu, 19 Apr 90 22:31:46 EDT Received: by bu-it.bu.edu (12/20/89); Thu, 19 Apr 90 22:31:38 EDT Date: Thu, 19 Apr 90 22:31:38 EDT From: Phil Budne Message-Id: <9004200231.AA04513@bu-it.bu.edu> To: DIGEX%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, DOOMSDAY%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu Subject: Re: the future of ITS Cc: INFO-ITS%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, KS-OWNERS%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu I started on a '10 simulator, but never wrote the 36 bit math needed. If you figure a 10 times performance hit a DS3100 or a SPARC might yield performance at the KA/KS level. @bu.edu:budd@bu-it.bu.eduFAIL<723174.900419@AI.AI.MIT.EDU>Msg of Thursday, 19 April 1990 22:37-EDTCOMSATDate: Thu, 19 Apr 90 22:47:03 EDT From: Communications Satellite Subject: Msg of Thursday, 19 April 1990 22:37-EDT To: "@bu.edu:budd@bu-it.bu.edu"@MINTAKA.LCS.MIT.EDU Message-ID: <723174.900419@AI.AI.MIT.EDU> YN-!  `q`9`q`9 `q`9`q`9`q&`9`q.`9`q6`9`q>`9#`qF`9'`qN`9+`qV`9/`q^`93`qf`97`qn`9;`qv`9?`q~`9 `q  ``q`q@Ha`  dbHa`yy HI} H0P(L8   X xP xxq,@ N0 a`@P8`My4 t(E BABYLDEVONRFC733DEVONbrighid@HERN.MV.COMDANA@AIR-OPTIONCC I updated your address. Dana hasn't logged in since February.Date: Wed, 18 Apr 90 11:13:27 EDT From: think!ames!decwrl!decvax!hern.mv.com!brighid at eddie.mit.edu To: paganism-request at MC.lcs.mit.edu Re: please chnage my address MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Hi Dana! Please change my address for the paganism digest. It seems that crsfld is no longer going to call dartvax. You may have already gotten a bounce or two. Try changing it to brighid@hern.mv.com - that should be fine. You remember Computertown? Well, Friday they told all their tenants to be out by Monday afternoon. So when we went by Monday to help Bruce (Virgin Software) move, all that was left of computer town was stray coffee cups and foam peanuts. Life is never dull! Brighid brighid@hern.mv.com <723175.900419.DEVON@AI.AI.MIT.EDU>FAILgroff%csse32.dec@decNOSHOWDate: Thu, 19 Apr 90 22:47:15 EDT From: Devon Sean McCullough Subject: I updated your address. Dana hasn't logged in since February. To: "brighid@HERN.MV.COM"@MINTAKA.LCS.MIT.EDU cc: DANA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <723175.900419.DEVON@AI.AI.MIT.EDU> YN-!  `q`9`q`9 `q`9`q`9`q&`9`q.`9`q6`9`q>`9#`qF`9'`qN`9+`qV`9/`q^`93`qf`97`qn`9;`qv`9?`q~`9 3`q < ``q`q@HKQ  QP@K.zX HI~pp(h(q,Xx0'HP@ h N` 4# (P18 3`3`My4 t(E clipsend@jennings.lcs.mit.eduBORIS@ai.ai.mit.eduReceived: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 19 Apr 90 22:42:56 EDT Received: from JENNINGS.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa23923; 19 Apr 90 22:36 EDT Received: by jennings.LCS.MIT.EDU id AA18043; Thu, 19 Apr 90 22:39:30 EDT Date: Thu, 19 Apr 90 22:39:30 EDT From: Clipping Service Message-Id: <9004200239.AA18043@jennings.LCS.MIT.EDU> To: boris@ai.ai.mit.edu Reply-To: clip@jennings.lcs.mit.edu Subject: BC WORLD BRIEFS Matched Filter Line: (subject: world briefs) The following is copyright The New York Times. Do not forward or redistribute this information. type: NYT (Copyright 1990 The New York Times) priority: Urgent date: 04-19-90 2227EDT category: International News subject: BC WORLD BRIEFS title: GDANSK, Poland: austerity programs. text: ---- KREMLIN ECONOMY TALKS CONTINUE MOSCOW (NYT) -- The Gorbachev government continued its long and thus far inconclusive deliberations to form a long-term plan for overhauling the stagnant economy. After the latest in a series of private Kremlin meetings, President Mikhail S. Gorbachev said Thursday he was satisfied with the progress in discussing a range of options for shifting the nation gradually toward a limited free-market economy. But he said he still wanted ``additional fresh ideas'' from a variety of sources. ---- SOVIETS CUT SUPPLIES OF NATURAL GAS TO LITHUANIA MOSCOW (NYT) -- The Kremlin sharply increased its economic sanctions against Lithuania, slashing supplies of natural gas to the republic only hours after completely halting the flow of crude oil there. While using pressure as a tactic to force the defiant republic into rescinding its strongest independence legislation, Soviet President Mikhail S. Gorbachev tried to persuade Latvia and Estonia, Lithuania's Baltic neighbors, to remain within the Soviet Union by offering Latvians special status. Acting on its threat to halt crucial supplies to Lithuania, Moscow shut off three of the four natural gas pipelines serving the republic Thursday morning, officials of the Lithuanian Parliament said. This cut by more than 80 percent the republic's daily supply of natural gas, which is used for home heating and cooking and to generate electricity at a Lithuanian power plant. ---- MEXICO WARNS U.S. ON DRUGS IN WAKE OF SUSPECT'S APPREHENSION c.1990 N.Y. Times News Service The Mexican government warned it might curtail drug control operations with the United States as a result of the apprehension of a Mexican doctor who was brought to the United States this month to face charges in the 1985 slaying of an American drug agent. The apprehension of Dr. Humberto Alvarez Machain has created a diplomatic and political furor in Mexico after news reports in Mexico and the United States suggested he was kidnapped in Mexico and brought to the United States on April 3 by bounty hunters who were working with the Drug Enforcement Administration. In a statement released by the Mexican Embassy in Washington, Mexican Attorney General Enrique Alvarez del Castillo said Thursday that joint anti-drug efforts were ``at risk'' if it is determined the United States participated in the capture of the Mexican doctor. Alvarez, 42, is suspected of aiding in the February 1985 torture and murder of Enrique S. Camarena, a DEA agent who was based in Guadalajara, Mexico. ---- BUSH, MITTERRAND SAY SOVIET RELATIONS MORE IMPORTANT THAN LITHUANIA KEY LARGO, Fla. (NYT) -- President Bush and French President Francois Mitterrand indicated they put a higher value on improved relations with Moscow than on an immediate resolution of the situation in Lithuania. Although the administration has warned it was considering retaliatory steps if Moscow cracked down on Lithuania, Bush said Thursday he was still not ready to specify what steps he might take against the Soviet Union for its campaign of intimidation in Lithuania, despite Moscow's sharp cutbacks of oil and natural gas supplies to the Baltic republic. Speaking at a news conference after a three-hour meeting with Mitterrand, Bush said he could not say ``when the United States might do something.'' Like Bush, Mitterrand made it clear he put a higher value on France's ties with the Soviet Union than on Lithuania. ---- COMMONS APPROVES BILL OFFERING REFUGE TO 50,000 FROM HONG KONG LONDON (NYT) -- Despite a break in the ranks of the Conservatives, the House of Commons has approved, by a large margin, a government bill that would offer refuge in Great Britain to 50,000 of the most successful people in Hong Kong and their families before China takes over the Crown colony in 1997. As the debate made clear, the Labor party had favored the admission of even more people from Hong Kong while some Conservatives were pressing for a more restrictive quota than provided for in the bill. Despite the predictions of some political commentators who had earlier claimed the government faced a serious risk of a humiliating defeat over the bill at a time of increasing political vulnerability for Prime Minister Margaret Thatcher, it swept to victory with a 97-vote majority. The vote came after a six-hour debate in which opposition Labor leaders accused Cabinet ministers of racism and rebellious Conservatives accused the government of reneging on election promises of tight immigration controls. ---- ALBANIA SEEKING TO RE-ESTABLISH RELATIONS WITH WASHINGTON, MOSCOW c. 1990 N.Y. Times News Service The government of Albania, one of the last hard-line Communist regimes in the world, has signaled it is willing to take up relations with the United States and the Soviet Union. Reversing a public policy of hostility toward both Washington and Moscow that lasted three decades, President Ramiz Alia declared that as a result of recent international developments, ``the problem of the re-establishment of diplomatic relations with the United States of America and the Soviet Union is on the agenda.'' In a long speech on Tuesday to the Central Committee of the ruling Communist Party, which was made public Thursday, Alia took note of the ``wide gap'' that separated his country from the two superpowers, but he added that ``we meet friendship with friendship.'' FAILNET-ORIGIN<723176.900419@AI.AI.MIT.EDU>borisNOSHOWYN-!  ? ? ? ? %? -? 5? =? E? "M? &U? *]? .e? 2m? 6u? :}? > o ?  < ?)? ? @H1  q:b1~ HI" H P 8``x8 NP  0kN.,iP L8 $P@8``@IP)X@` 8T`T`EKFLKFLomen!caf@uunet.uu.netObesityKFLR-OPTIONCCcik@L.CC.PURDUE.EDUR-OPTIONCCmacleod%drivax.UUCP@UUNET.UU.NETR-OPTIONCCgeb@dsl.pitt.edu@MINTAKA.LCS.MIT.EDUR-OPTIONCC> I think the message you sent to me was to someone else since it > quotes test I did not write. I know. You were in the CC list. I CCd you since you had recently posted a message on the topic. This message is to you, and is CCing three others. > Your "myth" statement begs the question. A more accurate reading > of the research would say obesity is 90 per cent genetic. In what context? In cultures where little fat or low-fiber food is available, overweight is rare. But many of these people become fat if they move to the US. Similarly, one who has the genes for susceptibility would never get fat if they ate right in the first place, either because they just happened to eat that way, or because they sought to avoid gaining weight. Analogously, many people with high blood pressure can control it by eating little salt. They are still regarded as people with hypertension, however. But what about a person who just happened to eat very little salt? Yes, susceptibility to obesity is probably mostly genetic. So is the ability to grow long hair. But one can always get a haircut. It's interesting to read about people who *try* to get fat. They are pretty rare in modern western culture, but fairly common in historical times. There's a fairly continuous spectrum from those of us who will weigh a lot unless we work at not doing so, to those who can't get fat no matter how hard they try. Fortunately, physics ensures that weight loss, unlike gain, is *always* possible. > Can endomorhps lose weight permamently? Yes. Using that outmoded deterministic term ("endomorph") tends to beg the question. > ... their problem is an excessive number of fat cells. No currently > available weight loss techniques are available to reduce that number. Probably true, but irrelevant. > The fat cells of a hyperobese individual after weight reduction are > more starved than those of the most highly trained athletes. The cells do shrink. And this causes them to siphon up any stray fats. As I mentioned, this is actually a good side effect. It is not a form of starvation. It does mean that if you insist on getting many of your calories from fats, that you'll have to eat tiny unsatisfying portions, and may feel hungry most of the time. Either that or you'll regain the weight. While in a "normal" person, the excess fats end up getting burned off or excreted, possibly after doing mischief to the heart and arteries, and boosting the chance of cancer. I don't want to eat 3 ounce greasy overpriced "diet" TV dinners, or to drink that chemical waste called diet soda. I'd rather eat a quarter pound of bran cereal, followed by a banana, an apple, a couple large carrots, and half a cantaloupe. Or a large salad, containing mounds of lettuce, cucumber, tomato, carrot, bell pepper, onion, celery, cantaloupe, kale, brocolli, and honeydew, followed by a baked potato or two, and a shredded wheat biscuit. Or a six ounce bag of puffed rice, wheat, millet, or corn, followed by an orange. Two such meals a day (I don't eat breakfast since I'm never hungry in the morning), and a couple hours of walking, and I have no tendency to weigh more than 165, even though I had been overweight since infancy, and exceeded 300 by my early teens. > A few athletes such as Mary Decker can muster the fanaticism to > maintain extreme training for years; a few hyperobese individuals > can do the same, but 95 per cent cannot. I can't speak for Mary Decker, but I can tell you I'm no fanatic. At least not about food. (just don't get me started on politics! :-) I've heard various numbers from 80% to 100%. I believe none of them. The census forms don't ask about weight loss. So where do the numbers come from? I suspect they are from people who seek professional help to lose weight. Presumably, these are all people who attempted it on their own and failed. So all this is saying is that if you can't do it on your own, doctors can't help. This is hardly surprising. Many thin people you see used to be fat. Many fat people you see have no desire to lose weight. Or never tried, because they believe these bogus statistics. Actually, I know more people who used to be very fat than who currently are. -.. . -.- ..-. .-.. ...Keith<723204.900419.KFL@AI.AI.MIT.EDU>Date: Thu, 19 Apr 90 23:59:03 EDT From: "Keith F. Lynch" Subject: Obesity To: omen!caf@UUNET.UU.NET cc: KFL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, cik@L.CC.PURDUE.EDU, macleod%drivax.UUCP@UUNET.UU.NET, "geb@dsl.pitt.edu"@MINTAKA.LCS.MIT.EDU Message-ID: <723204.900419.KFL@AI.AI.MIT.EDU> YN-!  ? ? ? ? %? -? 5? =? E? "M? &U? *]? .e? 2m? 6u? :}? > ?   ?)? ? @HK : ދKY HI"%H P8 h @IP  \ 0kN.,iP X,(` N8@(`@(`)@TTEKFLKFLmaler@decvax.dec.comKFLR-OPTIONCCeli@haddock.ima.isc.comR-OPTIONCC> It's when the consumers use the law to persecute the producers that > the economy starts being dysfunctional. Ever read De Toqueville? > She's afraid she can't pay the bills, so she just ignores them and > hopes they'll sink back into the muck. Repeat after me: "It's a disease, not a character defect." :-) This assertion was made about alcoholism. But now it's spread to virtually every known characxxxx... "disease". Now that they've found the "alcoholism gene" (but note how low the correlation with alcoholism really is?) watch for them to find the "compulsive debter" gene, though the government may have to borrow quite a bit to fund that. What odds would you give on them finding the "compulsive gambler" gene? Maybe they'll even get around to finding the "procrastination gene"! "Don't panic - it's only As, Cs, Ts, and Gs." :-) > I have the same experience with tracking income and outgo. By the > time I try to log the transaction, I've already done any worrying > over what should be spent versus saved, so why write it down? The only reasons I can think of are (1) sheer curiosity, (2) outgo seems to be exceeding income, so I'd better find out why, or (3) because it's something you're "supposed to do". The first two sound like good reasons to me. Reasons *not* to are (1) why waste the time, (2) it'd be a pain to go through all that paper, (3) it might be seen by someone else and I'd prefer to keep it private, and (4) because it's something you're "supposed to do". The first three sound like good reasons to me. There's no limit to things one can keep track of, and graph through time. Did these light bulbs really last 1000 hours? Which brand of groceries are cheapest? Am I getting enough potassium in my diet? How long is my hair and how fast is it growing? What's the outdoor temperature today? What's the ratio of "public service announcements" to ads on the radio? When did I last do the laundry? How many pairs of socks do I have left, and how many of those need cleaning? How much netmail did I get today, and what's the cumulative total for this year? How far did I walk today, and what's the cumulative total for this year? Where are the Voyager probes right now, and how fast are they going? When did I last listen to this CD, and what CD have I not listened to for the longest? If I had a car, I could keep track of miles, gas mileage, gas costs, maintenance costs, and blue-book value. Taken to one extreme, I would have little idea what was going on in my life or in the world. Taken to the other extreme, I would be spending most of my time keeping track of things, and would generate reams of data too voluminous to ever actually look at. Like most people, I try to chart a middle course. ...Keith<723206.900419.KFL@AI.AI.MIT.EDU>Date: Thu, 19 Apr 90 23:59:51 EDT From: "Keith F. Lynch" To: maler@DECVAX.DEC.COM cc: KFL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, "eli@haddock.ima.isc.com"@MINTAKA.LCS.MIT.EDU Message-ID: <723206.900419.KFL@AI.AI.MIT.EDU> YN-! %K%K %K%K%%K%-K%5K%=K"%EK&%MK*%UK.%]K2%eK6%mK:%uK>%}K GJk 7%' e%%@He ٥:Xie{s HI H Pd80 8 *S!886 >t(8\( 8\(8\88<D/8 >88  898#08&"h"8)-%@%8,3(H'DO8/9+`` U82?._-85B1``a`84H'P3`;!7``Xk`>$:\ds`A'=``l{8E @``X@C DPo;` W`;` W`HKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~     !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~    EKFLKFL76060.1103@compuserve.comamck@emx.utexas.edubagwell@CAF.MIT.EDUC445585%UMCVMB.BITNET@MITVMA.MIT.EDUC451976%UMCVMB.BITNET@MITVMA.MIT.EDUC503024%UMCVMB.BITNET@MITVMA.MIT.EDUconsp10@bingvaxu.cc.binghamton.edudennis@cs.washington.edueafu011@orion.oac.uci.eduest@cs.nyu.edueli%zgavva.ima.isc.com@ima.ima.isc.comjarle@shibuya.cc.columbia.edujpbonsen@ATHENA.MIT.EDUmaler%decvax.uucp@uunet.uu.netmbr@larch.lcs.mit.edupng%cup.portal.com@UUNET.UU.NETRaymie@ATHENA.MIT.EDUsnark!eric@UUNET.UU.NETUC482529%UMCVMB.BITNET@MITVMA.MIT.EDUwb8y%vax5.cit.cornell.edu@UUNET.UU.NETwisner%hayes.fai.alaska.edu@uunet.uu.netDate: Fri, 6 Apr 90 23:34:06 EDT From: "Keith F. Lynch" To: "shava@retina.rad.unc.edu"@MINTAKA.LCS.MIT.EDU Subject: Re: talking polit{e|ical} blues >> Especially unsettling were the rotating eye-in-a-pyramid logos on >> their TV propaganda broadcasts. > Personally, I think the illuminati might object to the > identification...;-) Did you read Wilson and Shea's _Illuminatus_? > Afro-American was kicked around by some of these groups for a little > bit, but eventually it was "black is beautiful." Alan McKendree has since told me that "Afro-American" has been replaced by "people of color". I wonder where one gets this information. Is there a phone number you can call, as to find the time or weather? Or is it a subscription service, like those things which tell you how your stock is doing? In either case, is the penalty waived for someone whose manuscript is written when they're called one thing, but not published until they're called another? Is there an advance list available somewhere? Perhaps for major donors to NAACP or UNCF or something? Where do they get the new names? Is there a prize awarded? If so, here are my entries: Members of a non-white minority. Members of a non-honkey minority. Members of a non-white soon-to-be-majority. Adult Survivors of 19th century slavery. Persons of low albedo. People With Afros. People with goverment-mandated preference. People-who-check-the- "B"-box-for-race-on-government-forms. Alan sent me the following letter which he sent to his school newspaper: March 21, 1990 Editor, Daily Texan Dear Karen, Today, I would like to ask all people interested in continuing the struggle against the oppressive American overclass to join me in petitioning the administration of this University to give a persecuted and slandered minority their rightful recognition. As many of you will have realized by now, I am referring to Scottish-Americans. Scottish-Americans (or, as many of us prefer, "people of plaid") comprise fully 5% of modern American society, yet this administration is so far from appreciating the special needs of those whose ancestors lived north of England that there are actually no statistics kept on the percentage of such faculty or students here. Where are the minority recruitment and retention programs for these forgotten people? the Jumpstart outreach programs? the Gaelic Studies graduate programs? Today, it is actually possible to get an undergraduate degree at the University without ever hearing the word "haggis" or listening to bagpipe music! At the very least, we must relentlessly nag the administration until they agree to include Scottish culture in the mandatory cultural awareness classes currently being considered. [This is true!] If enough qualified Scots cannot be found, we must add them to the list of groups given preferential admission consideration until their proportion here at U.T. equals that of the larger American society; this is merely just compensation for the slurs of "tightwad" and "kilt-wearer" we have endured for centuries. Only when each of us can trade on blanket concessions made to our designated group can we reclaim our lost self-esteem and sense of individual worth. April 1-14 is Scottish Awareness Fortnight. _Tarbh-innear_[1]! Sincerely yours, Alan McKendree Liberal Arts staff 471-3181 [1] Gaelic, "bullshit". I had to go look it up. >> see the James Bovard editorial in the Wall Street Journal of 8/8/89. > What was the gist of it? They do give out block by block data. This was used during WWII to round up people of Japanese ancestry. (It's a great help to the authorities to know how many such households are on this block, and how many people are in each.) It's also been used, many times, to track down housing code violations. This is really hard on poor people since the number one source of low cost rental housing is illegal subletting. I don't recall if it was there or somewhere else, but I also read that the maximum sentence for refusing to fill out the thing out is a $100 fine, and that only one person was prosecuted for this in 1970 (I don't know about 1980). I hope that many people do refuse to fill it out, or only fill out the enumeration question (that being the only question necessary to fulfill the constitutional purpose for the census). If anything's certain, it's that the more government can intrude without lots of people resisting, the further they'll go. If there's little or no resistance, in a few years they'll have more frequent censuses, ask much more, and have fewer privacy guarantees. ...Keith ^_ Date: Mon, 9 Apr 90 01:21:42 EDT From: "Keith F. Lynch" To: dm@THINK.COM cc: anarchy-list%cwi.nl@UUNET.UU.NET Subject: Re: indigenous agriculture [ This message is part of the debate with anti-libertarians. ] > The libertarian idea of ``property rights'' makes it impossible to > hire someone who cares more about money than philosophy, does it? > And in the perfect workings of the marketplace, it can never happen > that someone who is _supposed_ to care about rights more than money > can be suborned with sufficient application of money? This is a problem with *any* society. The advantage of a market organization is that if one group is corrupt, people can patronize another. There's no such choice with governments, which can be appallingly corrupt for decades, and still don't go out of business. > Or do you find it surprising that a utopian philosophy might not > work as well when put into practice in the real world as it worked > in the dreams of its adherents? Libertarianism is not a utopian philosophy. It's the opposite of one. The utopian philosophies generally say that some individual or group (emperor, philosopher-king, priesthood, party, proletariat, master race, majority) is somehow able to rule others without being cruel, random, confused, biased, or corrupt. Libertarians don't believe this. > What surprises me is how easy it seems to be for propertarians to > turn their back on the obvious trampling of the property rights of > indigenous people. How many "propertarians" have you talked to? They'll tell you about how they deplore the Brazilian *government's* policies which are destroying the rain forest and interfering with its inhabitants. ...Keith ^_ Date: Mon, 9 Apr 90 01:22:30 EDT From: "Keith F. Lynch" To: "est@cs.nyu.edu"@MINTAKA.LCS.MIT.EDU I've received further mail from Eric R., Vickie F., Keith H. and others. Since you have access to ITS, instead of my continuing to dig it out, feel free to get it from my numbered mail files. Please don't look at the most recent (highest numbered) one, since it may contain a private message (I don't check until I get it downloaded to my PC). There's no great hurry, since I keep them around for a whole week. But you don't want to delay forever, since I only keep them around for a week. Search the files for "KFL" to find mail to or from me. (Unfortunately there is one list which stuffs KFL in all their messages. But I shouldn't complain, since I do the same thing on my own list.) Did my recent message to the Lojban list get through? I see you've been posting to the SubGenius list lately. I hope my recent forwards haven't overwhelmed you. Well, the next few days of remail will be something you've already seen, so that will give you a chance to catch up. When did you want to snarf those November files from Tide? Here's something short you might be interested in. Note who it's from: Date: 24 Mar 90 06:52:43 GMT From: dmr@alice.att.com To: misc-security@uunet.uu.net Subject: Re: Contest announcement My own contest is "Most appalling display of classlessness in dealing with a serious subject." The nominees are: 1) National Center for Computer Crime Data, Security Magazine, and Gene Spafford, for their "How High Shall We Hang Robert Morris?" contest. 2) Gene Spafford, for the most tasteless article ever to appear in CACM (special credits for the Jodie Foster joke). Dennis Ritchie ^_ Date: Mon, 9 Apr 90 01:23:00 EDT From: "Keith F. Lynch" To: king@KESTREL.EDU Subject: Re: Libernet > Please send me the qubic board position Gee, I was hoping you would be able to send it to me. :-) I suppose I could dig it out, with some effort. I still have it, since I never delete any interesting mail. On the other hand, I never delete any interesting mail, so it would be hard to find. Maybe it would be easier to start over? I see you found your way back to Libernet. Welcome back. ...Keith ^_ Date: Mon, 9 Apr 90 01:24:20 EDT From: "Keith F. Lynch" To: dennis@JUNE.CS.WASHINGTON.EDU > About "soi-disant", my guess was "so-called," which it turns out is > listed as a synonym for soi-disant. Yes. Eric Tiedemann corrected me on that, informing me that it really means "self-called", thus cannot reasonably be used to refer to rifles. I then decided to cheat a little bit, and change it to "so called" in the remail. (He caught it on anarchy-list.) But I forgot. I'm thankful for people who criticize my use of language. I prefer to be without error. > So you have some file describing your prison experiences, right? > I'd be interested in reading it, if you feel like sending me a copy. Now that I think about it, while I don't want it spread around everywhere (I had some bad experiences after mailing it to the old Bandykin list), there isn't anyone on my remail list whom I mind seeing it. Plus, I'm closer to caught up on my remail than I like. So I'll send it to my list. This will be the first thing sent to my list that I will ask not be spread around. > How old are you? (I'm 26). I'm 33. (I was 32 when you asked.) > What're the furthest East, West, North, and South that you've > travelled? Boston (various times from the 1950s up to this past January), La Jolla (near San Diego) (1984), Stellafane (Vermont) (1972), and Miami (1988). How about you? (My visit to Vermont, the furthest north I've been, coincidentally happened to be during the greatest auroral displays in my lifetime. So I got quite a show!) ...Keith ^_ Date: Mon, 9 Apr 90 20:41:28 EDT From: "Keith F. Lynch" To: mt@MEDIA-LAB.MEDIA.MIT.EDU cc: anarchy-list%cwi.nl@UUNET.UU.NET Subject: Illusion > This is not to say that real oppression does not occur in the name > of the state, but that the government exists only because people > believe in it. Very good. > The state is a concept which would very much like to be taken for > an accomplished fact, which is why it build all those imposing > buildings to project an aura of solidity. You got it. Here in the Washington DC area, they really overdo it. Acres of marble, columns, and stairs, all built as if in terror that the state was about to dissolve like a bad dream in the clear morning sunlight. Religion is the same way. > But in fact, the state is nothing more than a bunch of people, > together with their actions and beliefs. Exactly. > I believe that societies do organize themselves around certain > ideas, and ... But "society" is another such illusion. There isn't any society, and never could be. Only individuals exist. Only individuals can have ideas. Each individual decides for himself what ideas to take seriously. One of the illusions that government promulgates is paper money. If you believe in the government, you'll believe in their scrip. If not, you'll use it only to the extent that you expect others will continue to believe in it. The fact that it's lost half its value in the past decade is clear evidence that people are starting to wake up. And are starting to realize that others are doing the same. > People have certain ideas about themselves, ideas which are often > false or damaging and from which they need to free themselves. Yes. I've slowly and reluctantly come to the remarkable conclusion that there's no idea so bizarre and obviously false that nobody can come to believe it. This includes ideas about oneself. (For instance AA members all believe that they are unable not to drink alcohol - and some of them haven't drank any for years!) > The individualists among us picture the conflict as between single > persons and the state pictured as an individual, ... Not this individualist. I don't picture the state as an individual. ...Keith ^_ <723213.900420.KFL@AI.AI.MIT.EDU>Date: Fri, 20 Apr 90 00:03:03 EDT From: "Keith F. Lynch" To: mbr@LARCH.LCS.MIT.EDU, jpbonsen@ATHENA.MIT.EDU, Raymie@ATHENA.MIT.EDU, C445585%UMCVMB.BITNET@MITVMA.MIT.EDU, C451976%UMCVMB.BITNET@MITVMA.MIT.EDU, C503024%UMCVMB.BITNET@MITVMA.MIT.EDU, UC482529%UMCVMB.BITNET@MITVMA.MIT.EDU, amck@EMX.UTEXAS.EDU, dennis@JUNE.CS.WASHINGTON.EDU, eafu011@ORION.OAC.UCI.EDU, consp10@BINGVAXU.CC.BINGHAMTON.EDU, maler%decvax.uucp@UUNET.UU.NET, png%cup.portal.com@UUNET.UU.NET, snark!eric@UUNET.UU.NET, wb8y%vax5.cit.cornell.edu@UUNET.UU.NET, wisner%hayes.fai.alaska.edu@UUNET.UU.NET, "76060.1103@compuserve.com"@MINTAKA.LCS.MIT.EDU, "est@cs.nyu.edu"@MINTAKA.LCS.MIT.EDU, "eli%zgavva.ima.isc.com@ima.ima.isc.com"@MINTAKA.LCS.MIT.EDU, "jarle@shibuya.cc.columbia.edu"@MINTAKA.LCS.MIT.EDU, bagwell@CAF.MIT.EDU Message-ID: <723213.900420.KFL@AI.AI.MIT.EDU> YN-!  oCoCoC oC%oC-oC5oC=oCEoC"MoC&UoC*]oC.eoC2moC6uoC:}oC>  oC  ocoCoC@Hs  w.vs HI!Zp5(X ,X; 0 H( @ t  P` ")HP0 8  ` `@REAGAN.AI.MIT.EDU:jensting@rimfaxe.diku.dkED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 05:02:18 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8626; 20 Apr 90 04:59:45 EDT Received: from rimfaxe.diku.dk by life.ai.mit.edu (4.1/AI-4.10) id AA24839; Fri, 20 Apr 90 04:50:24 EDT Received: by rimfaxe.diku.dk (5.61++/IDA-1.2.8) id AA20746; Fri, 20 Apr 90 10:48:53 +0200 Date: Fri, 20 Apr 90 10:48:53 +0200 From: Jens Tingleff Message-Id: <9004200848.AA20746@rimfaxe.diku.dk> To: bug-gcc@prep.ai.mit.edu Subject: optimisation in GCC 1.37.1. Not bug repport but question. Sorry to mail this to the bug address, but our news system is down, so I can't post it in gnu.gcc. NOT A BUG REPORT, more like a question/request.. . SOFTWARE Atari GCC 1.37.1 port, straight out of dsrgsun.ces.cwru.edu runnning as cross-system on a Sun4. Command line cgcc -O -fstrength-reuce -S -m68881 .. In the following code piece, a matrix multiplication, GCC stores the partial result (the current value of c[i][j]) in EACH pass of the loop. The matrixes are declared as double[16][16], and initialized. c[][] is used in a printf(..) later. for(i=0; i<16; i++) { for(j=0; j<16; j++) { c[i][j] = 0.0; for(k=0; k<16; k++) { c[i][j] += a[i][k]*b[k][j]; } } } The assembler code looks like this moveq #0,d3 L33: moveq #0,d2 movel d3,d0 asll #7,d0 addl a6,d0 movel d0,a4 addw #-6144,a4 movel d0,d1 addl #-2048,d1 movel a4,a3 L32: clrl a3@ clrl a3@(4) movel d2,d4 asll #3,d4 movel d4,a2 movel d1,a0 lea a6@(-4096),a1 moveq #120,d0 addl d1,d0 L31: fmoved a0@+,fp0 fmuld a2@(a1:l),fp0 faddd a2@(a4:l),fp0 fmoved fp0,a2@(a4:l) | Ahh, no! addw #128,a1 cmpl a0,d0 jge L31 addqw #8,a3 addql #1,d2 moveq #15,d4 cmpl d2,d4 jge L32 addql #1,d3 cmpl d3,d4 jge L33 Using a simple temporary var `temp', like this : for(i=0; i<16; i++) { for(j=0; j<16; j++) { temp = 0.0; for(k=0; k<16; k++) { temp += a[i][k]*b[k][j]; } c[i][j] = temp; } } results in the assembler code moveq #0,d3 L33: moveq #0,d2 movel d3,d0 asll #7,d0 addl a6,d0 movel d0,d4 addl #-2048,d4 movel d0,a2 addw #-6144,a2 L32: fmovecr #0xf,fp1 movel d2,d1 asll #3,d1 movel d4,a0 lea a6@(-4096),a1 moveq #120,d0 addl d4,d0 L31: fmoved a0@+,fp0 fmuld a1@(d1:l),fp0 faddx fp0,fp1 | YES YES YES addw #128,a1 cmpl a0,d0 jge L31 fmoved fp1,a2@+ | This is great.. . addql #1,d2 moveq #15,d5 cmpl d2,d5 jge L32 addql #1,d3 cmpl d3,d5 jge L33 Question: Why can't the store of c[i][j] partial value be deferred ? The value stored is not read before the next store (apart from the very last time through..). [The rest of this letter used to be full of an explanation of why the address computations were inefficient. This was before I saw the -fstrength-reduce flag. I used to think that this was part of the -O option, but found out it wasn't. Why not ?] PS Using the three flags -fforce-addr -fforce-mem -fstrength-reduce produces a small effect, in that the busy loop (without the temp var) is rewritten as moveq #0,d3 L33: moveq #0,d2 movel d3,d0 asll #7,d0 addl a6,d0 movel d0,a3 addw #-6144,a3 movel d0,d1 addl #-2048,d1 movel a3,a4 L32: clrl a4@ clrl a4@(4) movel d2,d4 asll #3,d4 movel d4,a2 movel d1,a0 lea a6@(-4096),a1 moveq #120,d0 addl d1,d0 L31: fmoved a0@+,fp0 fmuld a2@(a1:l),fp0 faddd a2@(a3:l),fp0 fmoved fp0,a2@(a3:l) | An other reg, that's all. addw #128,a1 cmpl a0,d0 jge L31 addqw #8,a4 addql #1,d2 moveq #15,d4 cmpl d2,d4 jge L32 addql #1,d3 cmpl d3,d4 jge L33 Thanks for you time. Jens FAILNET-ORIGIN<723284.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  hhh h&h.h6h>hFh#Nh'Vh+^h/fh3nh7vh;~h?Cp  h & hh@H   (HH` HI!Zp5(X ,X; 0 H( @ t  P` ")HP0 8  ` `@REAGAN.AI.MIT.EDU:jensting@rimfaxe.diku.dkED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 05:02:18 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8626; 20 Apr 90 04:59:45 EDT Received: from rimfaxe.diku.dk by life.ai.mit.edu (4.1/AI-4.10) id AA24839; Fri, 20 Apr 90 04:50:24 EDT Received: by rimfaxe.diku.dk (5.61++/IDA-1.2.8) id AA20746; Fri, 20 Apr 90 10:48:53 +0200 Date: Fri, 20 Apr 90 10:48:53 +0200 From: Jens Tingleff Message-Id: <9004200848.AA20746@rimfaxe.diku.dk> To: bug-gcc@prep.ai.mit.edu Subject: optimisation in GCC 1.37.1. Not bug repport but question. Sorry to mail this to the bug address, but our news system is down, so I can't post it in gnu.gcc. NOT A BUG REPORT, more like a question/request.. . SOFTWARE Atari GCC 1.37.1 port, straight out of dsrgsun.ces.cwru.edu runnning as cross-system on a Sun4. Command line cgcc -O -fstrength-reuce -S -m68881 .. In the following code piece, a matrix multiplication, GCC stores the partial result (the current value of c[i][j]) in EACH pass of the loop. The matrixes are declared as double[16][16], and initialized. c[][] is used in a printf(..) later. for(i=0; i<16; i++) { for(j=0; j<16; j++) { c[i][j] = 0.0; for(k=0; k<16; k++) { c[i][j] += a[i][k]*b[k][j]; } } } The assembler code looks like this moveq #0,d3 L33: moveq #0,d2 movel d3,d0 asll #7,d0 addl a6,d0 movel d0,a4 addw #-6144,a4 movel d0,d1 addl #-2048,d1 movel a4,a3 L32: clrl a3@ clrl a3@(4) movel d2,d4 asll #3,d4 movel d4,a2 movel d1,a0 lea a6@(-4096),a1 moveq #120,d0 addl d1,d0 L31: fmoved a0@+,fp0 fmuld a2@(a1:l),fp0 faddd a2@(a4:l),fp0 fmoved fp0,a2@(a4:l) | Ahh, no! addw #128,a1 cmpl a0,d0 jge L31 addqw #8,a3 addql #1,d2 moveq #15,d4 cmpl d2,d4 jge L32 addql #1,d3 cmpl d3,d4 jge L33 Using a simple temporary var `temp', like this : for(i=0; i<16; i++) { for(j=0; j<16; j++) { temp = 0.0; for(k=0; k<16; k++) { temp += a[i][k]*b[k][j]; } c[i][j] = temp; } } results in the assembler code moveq #0,d3 L33: moveq #0,d2 movel d3,d0 asll #7,d0 addl a6,d0 movel d0,d4 addl #-2048,d4 movel d0,a2 addw #-6144,a2 L32: fmovecr #0xf,fp1 movel d2,d1 asll #3,d1 movel d4,a0 lea a6@(-4096),a1 moveq #120,d0 addl d4,d0 L31: fmoved a0@+,fp0 fmuld a1@(d1:l),fp0 faddx fp0,fp1 | YES YES YES addw #128,a1 cmpl a0,d0 jge L31 fmoved fp1,a2@+ | This is great.. . addql #1,d2 moveq #15,d5 cmpl d2,d5 jge L32 addql #1,d3 cmpl d3,d5 jge L33 Question: Why can't the store of c[i][j] partial value be deferred ? The value stored is not read before the next store (apart from the very last time through..). [The rest of this letter used to be full of an explanation of why the address computations were inefficient. This was before I saw the -fstrength-reduce flag. I used to think that this was part of the -O option, but found out it wasn't. Why not ?] PS Using the three flags -fforce-addr -fforce-mem -fstrength-reduce produces a small effect, in that the busy loop (without the temp var) is rewritten as moveq #0,d3 L33: moveq #0,d2 movel d3,d0 asll #7,d0 addl a6,d0 movel d0,a3 addw #-6144,a3 movel d0,d1 addl #-2048,d1 movel a3,a4 L32: clrl a4@ clrl a4@(4) movel d2,d4 asll #3,d4 movel d4,a2 movel d1,a0 lea a6@(-4096),a1 moveq #120,d0 addl d1,d0 L31: fmoved a0@+,fp0 fmuld a2@(a1:l),fp0 faddd a2@(a3:l),fp0 fmoved fp0,a2@(a3:l) | An other reg, that's all. addw #128,a1 cmpl a0,d0 jge L31 addqw #8,a4 addql #1,d2 moveq #15,d4 cmpl d2,d4 jge L32 addql #1,d3 cmpl d3,d4 jge L33 Thanks for you time. Jens FAILNET-ORIGIN<723284.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  (u(;(u (; (u(;(u(;(u$(;(u,(;(u4(;(u<(;"(uD(;&(uL(;*(uT(;.(u\(;2(ud(;6(ul(;:(ut(;>(u|(; N(u 2 ((u(u@H*L  ,l,3*W|f HI!- pY(h 0kN.,i, 0s,, 0s, ,X0HPJ@hKPE8 `8N`N` @MC.LCS.MIT.EDU:protocols-request@rutgers.eduKFL@AI.AI.MIT.EDUPLOUFF@AI.AI.MIT.EDUSTEVEH@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 20 Apr 90 06:09:36 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 06:07:45 EDT Received: from RUTGERS.EDU by mintaka.lcs.mit.edu id aa09589; 20 Apr 90 5:55 EDT Received: from ucbvax.Berkeley.EDU by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) id AA20107; Fri, 20 Apr 90 05:27:43 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18274; Fri, 20 Apr 90 02:26:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for protocols@rutgers.edu (protocols@rutgers.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 21:53:16 GMT From: Dan Germann Organization: Digital Biometrics Inc., Minneapolis, MN Subject: Looking for help: protocol information Message-Id: <1867@kksys.mn.org> Sender: protocols-request@rutgers.edu To: protocols@rutgers.edu I am in the process of putting together a list of data communication protocols which meet the following criteria. 1. provides guaranteed "error-free" end-to-end delivery 2. provides multiple logical data paths over a single physical link 3. is available on a wide variety of computer systems, in particular, UNIX and MS-DOS/PC-DOS based systems 4. is available in source form, so that the protocol can be ported to a "bare" system If anyone can lend me a hand, I'd certainly appreciate it. I already know about TCP/IP, and am looking for alternatives before we make a decision on what protocol to choose. If there are multiple choices, it's easier to push it through the front office :-) . Please reply via email. Thanks! -- Daniel E. Germann, Digital Biometrics, Inc. "Electronic Fingerprinting Systems" Mailers of the future: deg@kksys.MN.ORG Mailers of the past: ...!nic.MR.NET!bungia!kksys!deg ...!uunet.UU.NET!plains!umn-cs!kksys!deg FAILNET-ORIGIN<723301.900420@AI.AI.MIT.EDU>YN-!  ??? ? ?????$??,??4???|?Cp N? @=??@H@= 8 B}@=@=t` HI!- pY(h 0kN.,i, 0s,, 0s, ,X0HPJ@hKPE8 `8N`N` @MC.LCS.MIT.EDU:protocols-request@rutgers.eduKFL@AI.AI.MIT.EDUPLOUFF@AI.AI.MIT.EDUSTEVEH@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 20 Apr 90 06:09:36 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 06:07:45 EDT Received: from RUTGERS.EDU by mintaka.lcs.mit.edu id aa09589; 20 Apr 90 5:55 EDT Received: from ucbvax.Berkeley.EDU by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) id AA20107; Fri, 20 Apr 90 05:27:43 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18274; Fri, 20 Apr 90 02:26:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for protocols@rutgers.edu (protocols@rutgers.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 21:53:16 GMT From: Dan Germann Organization: Digital Biometrics Inc., Minneapolis, MN Subject: Looking for help: protocol information Message-Id: <1867@kksys.mn.org> Sender: protocols-request@rutgers.edu To: protocols@rutgers.edu I am in the process of putting together a list of data communication protocols which meet the following criteria. 1. provides guaranteed "error-free" end-to-end delivery 2. provides multiple logical data paths over a single physical link 3. is available on a wide variety of computer systems, in particular, UNIX and MS-DOS/PC-DOS based systems 4. is available in source form, so that the protocol can be ported to a "bare" system If anyone can lend me a hand, I'd certainly appreciate it. I already know about TCP/IP, and am looking for alternatives before we make a decision on what protocol to choose. If there are multiple choices, it's easier to push it through the front office :-) . Please reply via email. Thanks! -- Daniel E. Germann, Digital Biometrics, Inc. "Electronic Fingerprinting Systems" Mailers of the future: deg@kksys.MN.ORG Mailers of the past: ...!nic.MR.NET!bungia!kksys!deg ...!uunet.UU.NET!plains!umn-cs!kksys!deg FAILNET-ORIGIN<723301.900420@AI.AI.MIT.EDU>YN-!  ??? ? ?????$??,??4???|?Cp N? : @=??@H@=  B}@=@=t` HI!- pY(h 0kN.,i, 0s,, 0s, ,X0HPJ@hKPE8 `8N`N` @MC.LCS.MIT.EDU:protocols-request@rutgers.eduKFL@AI.AI.MIT.EDUPLOUFF@AI.AI.MIT.EDUSTEVEH@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 20 Apr 90 06:09:36 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 06:07:45 EDT Received: from RUTGERS.EDU by mintaka.lcs.mit.edu id aa09589; 20 Apr 90 5:55 EDT Received: from ucbvax.Berkeley.EDU by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) id AA20107; Fri, 20 Apr 90 05:27:43 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18274; Fri, 20 Apr 90 02:26:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for protocols@rutgers.edu (protocols@rutgers.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 21:53:16 GMT From: Dan Germann Organization: Digital Biometrics Inc., Minneapolis, MN Subject: Looking for help: protocol information Message-Id: <1867@kksys.mn.org> Sender: protocols-request@rutgers.edu To: protocols@rutgers.edu I am in the process of putting together a list of data communication protocols which meet the following criteria. 1. provides guaranteed "error-free" end-to-end delivery 2. provides multiple logical data paths over a single physical link 3. is available on a wide variety of computer systems, in particular, UNIX and MS-DOS/PC-DOS based systems 4. is available in source form, so that the protocol can be ported to a "bare" system If anyone can lend me a hand, I'd certainly appreciate it. I already know about TCP/IP, and am looking for alternatives before we make a decision on what protocol to choose. If there are multiple choices, it's easier to push it through the front office :-) . Please reply via email. Thanks! -- Daniel E. Germann, Digital Biometrics, Inc. "Electronic Fingerprinting Systems" Mailers of the future: deg@kksys.MN.ORG Mailers of the past: ...!nic.MR.NET!bungia!kksys!deg ...!uunet.UU.NET!plains!umn-cs!kksys!deg FAILNET-ORIGIN<723301.900420@AI.AI.MIT.EDU>YN-!  (u(;(u (; (u(;(u(;(u$(;(u,(;(u4(;(u<(;"(uD(;&(uL(;*(uT(;.(u\(;2(ud(;6(ul(;:(ut(;>(u|(; 3(u ( ((u(u@H*[ 2 ,+*i HI!=p5(X 3K,X 0 -H([@ t] P ` c")HP028 3`3`h{@REAGAN.AI.MIT.EDU:eru@tnvsu1.tele.nokia.fiED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 06:43:16 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8631; 20 Apr 90 06:40:58 EDT Received: from santra.hut.fi by life.ai.mit.edu (4.1/AI-4.10) id AA25660; Fri, 20 Apr 90 06:32:07 EDT Received: from tnvsu1.tele.nokia.fi by santra.hut.fi (5.61++/7.0/TeKoLa) id AA15731; Fri, 20 Apr 90 13:31:47 +0300 Received: by tele.nokia.fi (5.51.2/SMI-3.2) id AA07820; Fri, 20 Apr 90 13:19:38 +0200 Received: by tnvsu1. (5.57/SMI-4.0) id AA02442; Fri, 20 Apr 90 13:19:03 +0300 Date: Fri, 20 Apr 90 13:19:03 +0300 From: eru@tnvsu1.tele.nokia.fi (Erkki Ruohtula) Message-Id: <9004201019.AA02442@tnvsu1.> To: bug-gcc@prep.ai.mit.edu Subject: Preprocessor stringize problem If a macro that uses the ANSI stringize operator "#" is handed a parameter list that contains a backslash-escaped newline before an item that is to be stringized, the resulting string is wrong: it will begin with a backslash-space sequence. According to ANSI, the backslash-newline sequences must deleted before preprocessing tokens are recognized (2.1.1.2), and the string produced by "#" consists of the spelling of the argument preprocessing token sequence, without any preceding or trailing white space (3.8.3.2). An example (the machine is a VAXstation): 1:eru@tnvsu1: gcc -version gcc version 1.37 2:eru@tnvsu1: cat gccbug.c #define str(x) #x str(\ a) 3:eru@tnvsu1: gcc -E gccbug.c # 1 "gccbug.c" "\ a" 4:eru@tnvsu1: Erkki Ruohtula / Nokia Telecommunications ! eru@tele.nokia.fi / P.O. Box 33 SF-02601 Espoo, Finland ! FAILNET-ORIGIN<723305.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  @}@?@} @? @}@?@}@?@}$@?@},@?@}4@?@}<@?"@}D@?&@}L@?*@}T@?.@}\@?2@}d@?6@}l@?:@}t@?>@}|@?Cp N@}  @@}@}@H@ ( B@@t` HI!- pY(h 0kN.,i, 0s,, 0s, ,X0HPJ@hKPE8 `8N`N` @MC.LCS.MIT.EDU:protocols-request@rutgers.eduKFL@AI.AI.MIT.EDUPLOUFF@AI.AI.MIT.EDUSTEVEH@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 20 Apr 90 06:09:36 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 06:07:45 EDT Received: from RUTGERS.EDU by mintaka.lcs.mit.edu id aa09589; 20 Apr 90 5:55 EDT Received: from ucbvax.Berkeley.EDU by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) id AA20107; Fri, 20 Apr 90 05:27:43 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18274; Fri, 20 Apr 90 02:26:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for protocols@rutgers.edu (protocols@rutgers.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 21:53:16 GMT From: Dan Germann Organization: Digital Biometrics Inc., Minneapolis, MN Subject: Looking for help: protocol information Message-Id: <1867@kksys.mn.org> Sender: protocols-request@rutgers.edu To: protocols@rutgers.edu I am in the process of putting together a list of data communication protocols which meet the following criteria. 1. provides guaranteed "error-free" end-to-end delivery 2. provides multiple logical data paths over a single physical link 3. is available on a wide variety of computer systems, in particular, UNIX and MS-DOS/PC-DOS based systems 4. is available in source form, so that the protocol can be ported to a "bare" system If anyone can lend me a hand, I'd certainly appreciate it. I already know about TCP/IP, and am looking for alternatives before we make a decision on what protocol to choose. If there are multiple choices, it's easier to push it through the front office :-) . Please reply via email. Thanks! -- Daniel E. Germann, Digital Biometrics, Inc. "Electronic Fingerprinting Systems" Mailers of the future: deg@kksys.MN.ORG Mailers of the past: ...!nic.MR.NET!bungia!kksys!deg ...!uunet.UU.NET!plains!umn-cs!kksys!deg FAILNET-ORIGIN<723301.900420@AI.AI.MIT.EDU>YN-!  @}@?@} @? @}@?@}@?@}$@?@},@?@}4@?@}<@?"@}D@?&@}L@?*@}T@?.@}\@?2@}d@?6@}l@?:@}t@?>@}|@?Cp N@} 6 @@}@}@H@  B@@t` HI!- pY(h 0kN.,i, 0s,, 0s, ,X0HPJ@hKPE8 `8N`N` @MC.LCS.MIT.EDU:protocols-request@rutgers.eduKFL@AI.AI.MIT.EDUPLOUFF@AI.AI.MIT.EDUSTEVEH@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 20 Apr 90 06:09:36 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 06:07:45 EDT Received: from RUTGERS.EDU by mintaka.lcs.mit.edu id aa09589; 20 Apr 90 5:55 EDT Received: from ucbvax.Berkeley.EDU by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) id AA20107; Fri, 20 Apr 90 05:27:43 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18274; Fri, 20 Apr 90 02:26:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for protocols@rutgers.edu (protocols@rutgers.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 21:53:16 GMT From: Dan Germann Organization: Digital Biometrics Inc., Minneapolis, MN Subject: Looking for help: protocol information Message-Id: <1867@kksys.mn.org> Sender: protocols-request@rutgers.edu To: protocols@rutgers.edu I am in the process of putting together a list of data communication protocols which meet the following criteria. 1. provides guaranteed "error-free" end-to-end delivery 2. provides multiple logical data paths over a single physical link 3. is available on a wide variety of computer systems, in particular, UNIX and MS-DOS/PC-DOS based systems 4. is available in source form, so that the protocol can be ported to a "bare" system If anyone can lend me a hand, I'd certainly appreciate it. I already know about TCP/IP, and am looking for alternatives before we make a decision on what protocol to choose. If there are multiple choices, it's easier to push it through the front office :-) . Please reply via email. Thanks! -- Daniel E. Germann, Digital Biometrics, Inc. "Electronic Fingerprinting Systems" Mailers of the future: deg@kksys.MN.ORG Mailers of the past: ...!nic.MR.NET!bungia!kksys!deg ...!uunet.UU.NET!plains!umn-cs!kksys!deg FAILNET-ORIGIN<723301.900420@AI.AI.MIT.EDU>YN-!  @}@?@} @? @}@?@}@?@}$@?@},@?@}4@?@}<@?"@}D@?&@}L@?*@}T@?.@}\@?2@}d@?6@}l@?:@}t@?>@}|@?Cp N@}  @@}@}@H@ 0 B@@t` HI!- pY(h 0kN.,i, 0s,, 0s, ,X0HPJ@hKPE8 `8N`N` @MC.LCS.MIT.EDU:protocols-request@rutgers.eduKFL@AI.AI.MIT.EDUPLOUFF@AI.AI.MIT.EDUSTEVEH@AI.AI.MIT.EDUReceived: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 20 Apr 90 06:09:36 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 06:07:45 EDT Received: from RUTGERS.EDU by mintaka.lcs.mit.edu id aa09589; 20 Apr 90 5:55 EDT Received: from ucbvax.Berkeley.EDU by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) id AA20107; Fri, 20 Apr 90 05:27:43 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18274; Fri, 20 Apr 90 02:26:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for protocols@rutgers.edu (protocols@rutgers.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 21:53:16 GMT From: Dan Germann Organization: Digital Biometrics Inc., Minneapolis, MN Subject: Looking for help: protocol information Message-Id: <1867@kksys.mn.org> Sender: protocols-request@rutgers.edu To: protocols@rutgers.edu I am in the process of putting together a list of data communication protocols which meet the following criteria. 1. provides guaranteed "error-free" end-to-end delivery 2. provides multiple logical data paths over a single physical link 3. is available on a wide variety of computer systems, in particular, UNIX and MS-DOS/PC-DOS based systems 4. is available in source form, so that the protocol can be ported to a "bare" system If anyone can lend me a hand, I'd certainly appreciate it. I already know about TCP/IP, and am looking for alternatives before we make a decision on what protocol to choose. If there are multiple choices, it's easier to push it through the front office :-) . Please reply via email. Thanks! -- Daniel E. Germann, Digital Biometrics, Inc. "Electronic Fingerprinting Systems" Mailers of the future: deg@kksys.MN.ORG Mailers of the past: ...!nic.MR.NET!bungia!kksys!deg ...!uunet.UU.NET!plains!umn-cs!kksys!deg FAILNET-ORIGIN<723301.900420@AI.AI.MIT.EDU>YN-!  55 555%5-555="5E&5M*5U.5]25e65m:5u>5} 65  u55@H : 1E/ HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  h$Ih$Ih$ Ih$I%h$I-h$I5h$I=h$IEh$"IMh$&IUh$*I]h$.Ieh$2Imh$6Iuh$:I}h$>ICp 6h$  hDh$h$@H#-  %m#-#-t` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  III I&I.I6I>IFI#NI'VI+^I/fI3nI7vI;~I?Cp 6I 0 iII@Hi   HiHit` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!   &.6>F#N'V+^/f3n7v;~?Cp 6  .@H.  NH.H.t` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  ??? ? ?????$??,??4???|?Cp 6?' @=??@H@=  B}@=@=t` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!          &  .  6  >  F # N ' V + ^ / f 3 n 7 v ; ~ ? Cp 6  <  "  @H B > bH BH Bt` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  < >P?}8>nD4# hPC8BH4# 8PG0E8F6LIFPK8JAP4# `PO0J8N%T KPS8RmX| PW0M8VY\pNP[8Z!`4# |P_0T8^)dIUPc0W8bEhXPg0Z8fIl")HP[Pk0^8jQ(_Po$PpPq0axr0bPs0c8nadPv8uyXPz8x~4# P}8|( P0jP kxXP8b  P0n80I*(oP 8 UP qPP8 XP0t8o4# uP8. PHwXP0x8L`y"XP#8!M'4#  P&0|8%e}*XP+8)/h ( P.08-` 2XP381d7gP6085w;0I&<^P:89  >XP?08=CPPB0 8A# PFPGxH0 PI08ERLXPM8K=Q_ PP08O]PT#PU0xV0PW08S5 ZXP[+`Y_-I*P^08]cI*0Pb08a(Pf5Pg7xh0iXPj08etnޭ0Pm08lw qXPrA8p{vI* CPu0"8t(#yXPzG8x~ IP}0%8|&XPM8  OP0(8$ I*)P S8, UXP0+8 4,PY8< [XP0.8@H4X/P_8J aXP018N"H4X2P!e8 XgP%04P& 5x'k(XP)m8$\-;oP,088+k90XP1s8/s5NuP4w83{yP8 =P9{P:}87(=XP>8<PBCDPA0E8@0FFXPG0G8EK1(HPJ8I*PN JPO8M2PRPS0MTXPU0N8Q;Y50OPX0P8W?Q\XP]8[Da4#  P`0S8_H TPdPe8cP hXPi0W8gVm~}XPl8k^qUPp0Z8of [PtPuxv0]wXPx0^8sj8_{XP|0`8zy a@P0d8~}Y8eP0f8 g iP8 ` `9`DER-FRFC73EQV-LAlanDCPJTW SRA!Gumby"[KSHA#-ITS $FILE%N-DU-&EXPRE'EQV-L(@FILE)LEGIO*E]+LISP-,OMPLR-PEOPL.EQV-L/Alan0Y1Feinb2ymbol3GJC4GSB-N5GZ6JONL7KMP8S@DEE9UGHT.:DU;SAILBCMU.E?WGD@ucid.AMAILEBOR-OFCDAYDISTER-ERRF-THE-GCH-DREAIPERSJISTK-WISHLMIDASM-DREANEQV-LOMIDASP-LISTQ-WISHREQV-LSGZTKJBUGumbyV[GZ;MWIDEASXFILEYISTSZIST[ists@\ai.mi]NEWAG^HIVE_IST`;NEWAaCHVE]bIONcDdNL-KReISTf@CS.RgTER.EhNL-KRiREQUEjEQV-LkNICKl-MITmISTnINGRIoJEREMpTDWUqNICKr@medis.medit.eduuEQV-LvBJNwEAKxJNCyCHSNCzWIT M{FILE|NAGE}IST~NAGE@AGANEQV-LPAGANCIONISTISM-RTISTISM-R T@MC -Desi EQV-L @FILEt;DESIS]PCNetgn-ReEQV-LInfo--RequPCNetocolIST[PCNeTO DIFILE-ProtRequeEQV-LInfo--RequPCNetersMoon@stony-brook.scrc.symbolics.comUNIX-HATERS@AI.ai.mit.eduReceived: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 20 Apr 90 10:20:33 EDT Received: from [128.81.41.144] by mintaka.lcs.mit.edu id aa17954; 20 Apr 90 10:04 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 780758; 19 Apr 90 11:43:40 EDT Date: Thu, 19 Apr 90 11:49 EDT From: "David A. Moon" Subject: Invasion of the Mediocretins To: unix-haters@AI.ai.mit.edu In-Reply-To: <19900418230942.1.MT@OUROBOROS.MEDIA.MIT.EDU> Message-ID: <19900419154943.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Wed, 18 Apr 90 19:09 EDT From: Michael Travers This blatant effort at cultural pollution deserves a response from the unix-haters community. My entry for UNIX WEENIE is below; but surely we can do better. From: eric@snark.uu.net (Eric S. Raymond) Subject: The infamous JARGON FILE is being revised -- send us your slang Date: 12 Apr 90 17:33:03 GMT UNIX WEENIE (variant: WEENIX UNIE): a happy little pinhead who believes that 1) UNIX is the last word in operating systems and 2) this is a good thing. Unhappy nonpinheads who believe 1) but not 2) are called FATALISTS. and 3) takes over other people's projects and makes them his own, invariably ruining them in the process through not understanding their original purpose and not caring that he does not understand. FAILNET-ORIGIN<723354.900420@AI.AI.MIT.EDU>@FILE[GREGOR;WEENIX TEXT]FILENOSHOWbandyNOSHOWsterling@ics.comNOSHOWbudd-play@NOSHOWleichter%cs.yale.eduNOSHOWncramer@bbNOSHOW7thson%SLCS.SLB.COM@NOSHOWphilbin-jim@YalNOSHOWkelsey@CS.NOSHOWlanning.paNOSHOWPolen.osbunorthNOSHOWDillon@srcNOSHOWWeld@NOSHOWtiemann%Lurch.Stanford.EDU@wheNOSHOWRPS%Apollo.COM@NOSHOWKLH@SNOSHOWjudyh%PYRPS5.Pyramid.COM@NOSHOWEHL@DNOSHOWBeth@NOSHOWGreek%AITG.DEC@NOSHOWunix-haters-dist%spt.entity.com@wheNOSHOWbboard-unix-haters@SNOSHOWunix-haters-dist@LucNOSHOWunix-haters-redistribution@STONOSHOWZVONASMALL-CLINOQCAPPENDRFC733NOSHOWTKNOSHOWSTEVERNOSHOWstever@wheNOSHOWSRANO-CLINOQCRFC733NOSHOWSRA@XNOSHOWstrazNOSHOWRSNOQCNO-CLINOSHOWRPKNOSHOWrpk@wNOSHOWRDZSMALL-CLINOSHOWRDZ-STANFORDNOSHOWRDZ@WNOSHOWPGSNOSHOWpgs@aNOSHOWNICKNOSHOWnick@NOSHOWMTDNOSHOWMTNOSHOWmt%media-lab.media.mit.edu@minNOSHOWMLYno-clinoqcrfc733NOSHOWMBRNOSHOWmbr@lNOSHOWMAPNOQCAPPENDRFC733NOSHOWMARGNOSHOWMARGNOSHOWmariec@medNOSHOWMAEDANO-CLINOQCRFC733NOSHOWcmaeda@cs.NOSHOWKWHNOSHOWkwh@mNOSHOWKLOTZNOSHOWklotzNOSHOWJTWNOSHOWJTWNOSHOWjrd@MNOSHOWJNCNOSHOWjnc@lNOSHOWJARNOSHOWjar@zNOSHOWHALNOSHOWhal@zNOSHOWGUMBYNO-CLINOQCRFC733NOSHOWgumbyNOSHOWDLWNOSHOWodi!dlw@taNOSHOWDIGEXNOQCNO-CLINOSHOWDEVON-JUNKNOSHOWAPPEND[DEVON;JUNK MAIL]FILENOSHOWDANIELNOSHOWweiseNOSHOWCZNOQCNOSHOWCSTACYNOQCNO-CLINOSHOWCStacy@REANOSHOWCJLNOSHOWcjl@wNOSHOWCENTAPPENDNOSHOWDABNOSHOWdab@fNOSHOWAlan@NOSHOWALANNO-CLINOQCRFC733NOSHOWALAN-AINOSHOWFILE[ALAN;ALAN MAIL]FILENOSHOWAlan-MC@MCNOSHOW[CENTI;HATE UNIX]FILENOSHOWYN-!  FWF,FWF, FWF,FWF,FW&F,FW.F,FW6F,FW>F,#FWFF,'FWNF,+FWVF,/FW^F,3FWfF,7FWnF,;FWvF,?FW~F,Cp 6FW FFWFW@HF  HFFt` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!  FWF,FWF, FWF,FWF,FW&F,FW.F,FW6F,FW>F,#FWFF,'FWNF,+FWVF,/FW^F,3FWfF,7FWnF,;FWvF,?FW~F, FW  FFWFW@H6M < 87=6Yu HI")p(S,XD 0 tH(@ t Q)` @P8 HP0~8I*0P08`.EDUage-I2239018.DRAI.AI@inria.inria.fr:gautron@rxf.ibp.frHENRY@ai.ai.mit.eduReceived: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 20 Apr 90 10:33:51 EDT Received: from inria.inria.fr by mintaka.lcs.mit.edu id aa19358; 20 Apr 90 10:29 EDT Received: from litp.ibp.fr by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA26065; Fri, 20 Apr 90 16:28:46 +0200 (MET) Received: from douglas.ibp.fr by litp.ibp.fr with SMTP (5.61++/IDA-1.2.8) id AA17996; Fri, 20 Apr 90 16:28:30 +0200 Received: by rxf.ibp.fr (4.0/server.13-feb-87) id AA03495; Fri, 20 Apr 90 16:28:24 +0200 Date: Fri, 20 Apr 90 16:28:24 +0200 From: Philippe Gautron Message-Id: <9004201428.AA03495@rxf.ibp.fr> Organization: RXF-LITP, I.B.P., Universite Pierre et Marie Curie Paris 6, 4 place Jussieu, 75252 PARIS CEDEX 05, France telephone litp: +33 (1) 46-34-23-02, rxf: +33 (1) 47-62-11-39 fax litp: +33 (1) 46-34-27-97, rxf: +33 (1) 47-62-10-88 To: local-users@litp.ibp.fr Subject: imprimante L'imprimante marche de nouveau. Elle est reliee directement a douglas (machine de sylvie) ce qui est transaparent a vous autres utilisateurs. == Pg == FAILNET-ORIGIN<723360.900420@AI.AI.MIT.EDU>henry@rxf.ibp.frNOSHOW[HENRY;HENRY MAIL]FILENOSHOWlieber@medNOSHOWYN-!  ||M||M ||M||M|&|M|.|M|6|M|>|M#|F|M'|N|M+|V|M/|^|M3|f|M7|n|M;|v|M?|~|MCp H|  ||@H:  >::` HI""qp(,X,X]@0 H(9@ t; Q"8 rA ! #XPG8 8sIP0%8&P0(8  H)P0*8D 4#  +P0-8$2=8.P#0/`"(4# 0P'028&Z,X3P+i8*0 kP/m8.i44 t(oP3q82184 t<sP70;86-<@0<P;0=8:@> >P?}8>nD4# hPC8BH4# 8PG0E8F6LIFPK8JAP4# `PO0J8N%T KPS8RmX| PW0M8VY\pNP[8Z!`4# |P_0T8^)dIUPc0W8bEhXPg0Z8fIl")HP[Pk0^8jQ(_Po$PpPq0axr0bPs0c8nadPv8uyXPz8x~4# P}8|( P0jP kxXP8b  P0n80I*(oP 8 UP qPP8 XP0t8o4# uP8. PHwXP0x8L`y"XP#8!M'4#  P&0|8%e}*XP+8)/h ( P.08-` 2XP381d7gP6085w;0I&<^P:89  >XP?08=CPPB0 8A# PFPGxH0 PI08ERLXPM8K=Q_ PP08O]PT#PU0xV0PW08S5 ZXP[+`Y_-I*P^08]cI*0Pb08a(Pf5Pg7xh0iXPj08etnޭ0Pm08lw qXPrA8p{vI* CPu0"8t(#yXPzG8x~ IP}0%8|&XPM8  OP0(8$ I*)P S8, UXP0+8 4,PY8< [XP0.8@H4X/P_8J aXP018N"H4X2P!e8 XgP%04P& 5x'k(XP)m8$\-;oP,088+k90XP1s8/s5NuP4w83{yP8 =P9{P:}87(=XP>8<PBCDPA0E8@0FFXPG0G8EK1(HPJ8I*PN JPO8M2PRPS0MTXPU0N8Q;Y50OPX0P8W?Q\XP]8[Da4#  P`0S8_H TPdPe8cP hXPi0W8gVm~}XPl8k^qUPp0Z8of [PtPuxv0]wXPx0^8sj8_{XP|0`8zy a@P0d8~}Y8eP0f8 g iP8 ` `9`DER-FRFC73EQV-LAlanDCPJTW SRA!Gumby"[KSHA#-ITS $FILE%N-DU-&EXPRE'EQV-L(@FILE)LEGIO*E]+LISP-,OMPLR-PEOPL.EQV-L/Alan0Y1Feinb2ymbol3GJC4GSB-N5GZ6JONL7KMP8S@DEE9UGHT.:DU;SAILBCMU.E?WGD@ucid.AMAILEBOR-OFCDAYDISTER-ERRF-THE-GCH-DREAIPERSJISTK-WISHLMIDASM-DREANEQV-LOMIDASP-LISTQ-WISHREQV-LSGZTKJBUGumbyV[GZ;MWIDEASXFILEYISTSZIST[ists@\ai.mi]NEWAG^HIVE_IST`;NEWAaCHVE]bIONcDdNL-KReISTf@CS.RgTER.EhNL-KRiREQUEjEQV-LkNICKl-MITmISTnINGRIoJEREMpTDWUqNICKr@medis.medit.eduuEQV-LvBJNwEAKxJNCyCHSNCzWIT M{FILE|NAGE}IST~NAGE@AGANEQV-LPAGANCIONISTISM-RTISTISM-R T@MC -Desi EQV-L @FILEt;DESIS]PCNetgn-ReEQV-LInfo--RequPCNetocolIST[PCNeTO DIFILE-ProtRequeEQV-LInfo--RequPCNetersMoon@stony-brook.scrc.symbolics.comUNIX-HATERS@AI.ai.mit.eduReceived: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 20 Apr 90 10:20:33 EDT Received: from [128.81.41.144] by mintaka.lcs.mit.edu id aa17954; 20 Apr 90 10:04 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 780758; 19 Apr 90 11:43:40 EDT Date: Thu, 19 Apr 90 11:49 EDT From: "David A. Moon" Subject: Invasion of the Mediocretins To: unix-haters@AI.ai.mit.edu In-Reply-To: <19900418230942.1.MT@OUROBOROS.MEDIA.MIT.EDU> Message-ID: <19900419154943.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Wed, 18 Apr 90 19:09 EDT From: Michael Travers This blatant effort at cultural pollution deserves a response from the unix-haters community. My entry for UNIX WEENIE is below; but surely we can do better. From: eric@snark.uu.net (Eric S. Raymond) Subject: The infamous JARGON FILE is being revised -- send us your slang Date: 12 Apr 90 17:33:03 GMT UNIX WEENIE (variant: WEENIX UNIE): a happy little pinhead who believes that 1) UNIX is the last word in operating systems and 2) this is a good thing. Unhappy nonpinheads who believe 1) but not 2) are called FATALISTS. and 3) takes over other people's projects and makes them his own, invariably ruining them in the process through not understanding their original purpose and not caring that he does not understand. FAILNET-ORIGIN<723354.900420@AI.AI.MIT.EDU>@FILE[GREGOR;WEENIX TEXT]FILENOSHOWbandyNOSHOWsterling@ics.comNOSHOWbudd-play@NOSHOWleichter%cs.yale.eduNOSHOWncramer@bbNOSHOW7thson%SLCS.SLB.COM@NOSHOWphilbin-jim@YalNOSHOWkelsey@CS.NOSHOWlanning.paNOSHOWPolen.osbunorthNOSHOWDillon@srcNOSHOWWeld@NOSHOWtiemann%Lurch.Stanford.EDU@wheNOSHOWRPS%Apollo.COM@NOSHOWKLH@SNOSHOWjudyh%PYRPS5.Pyramid.COM@NOSHOWEHL@DNOSHOWBeth@NOSHOWGreek%AITG.DEC@NOSHOWunix-haters-dist%spt.entity.com@wheNOSHOWbboard-unix-haters@SNOSHOWunix-haters-dist@LucNOSHOWunix-haters-redistribution@STONOSHOWZVONASMALL-CLINOQCAPPENDRFC733NOSHOWTKNOSHOWSTEVERNOSHOWstever@wheNOSHOWSRANO-CLINOQCRFC733NOSHOWSRA@XNOSHOWstrazNOSHOWRSNOQCNO-CLINOSHOWRPKNOSHOWrpk@wNOSHOWRDZSMALL-CLINOSHOWRDZ-STANFORDNOSHOWRDZ@WNOSHOWPGSNOSHOWpgs@aNOSHOWNICKNOSHOWnick@NOSHOWMTDNOSHOWMTNOSHOWmt%media-lab.media.mit.edu@minNOSHOWMLYno-clinoqcrfc733NOSHOWMBRNOSHOWmbr@lNOSHOWMAPNOQCAPPENDRFC733NOSHOWMARGNOSHOWMARGNOSHOWmariec@medNOSHOWMAEDANO-CLINOQCRFC733NOSHOWcmaeda@cs.NOSHOWKWHNOSHOWkwh@mNOSHOWKLOTZNOSHOWklotzNOSHOWJTWNOSHOWJTWNOSHOWjrd@MNOSHOWJNCNOSHOWjnc@lNOSHOWJARNOSHOWjar@zNOSHOWHALNOSHOWhal@zNOSHOWGUMBYNO-CLINOQCRFC733NOSHOWgumbyNOSHOWDLWNOSHOWodi!dlw@taNOSHOWDIGEXNOQCNO-CLINOSHOWDEVON-JUNKNOSHOWAPPEND[DEVON;JUNK MAIL]FILENOSHOWDANIELNOSHOWweiseNOSHOWCZNOQCNOSHOWCSTACYNOQCNO-CLINOSHOWCStacy@REANOSHOWCJLNOSHOWcjl@wNOSHOWCENTAPPENDNOSHOWDABNOSHOWdab@fNOSHOWAlan@NOSHOWALANNO-CLINOQCRFC733NOSHOWALAN-AINOSHOWFILE[ALAN;ALAN MAIL]FILENOSHOWAlan-MC@MCNOSHOW[CENTI;HATE UNIX]FILENOSHOWYN-!  ttJt tJ ttJttJt$tJt,tJt4tJtt|tJCp Ht ( xtt@Hx  }xxӇ` HI""qp(,X,X]@0 H(9@ t; Q"8 rA ! #XPG8 8sIP0%8&P0(8  H)P0*8D 4#  +P0-8$2=8.P#0/8"(4# 0P'028&Z,X3P+i8*0 kP/m8.i44 t(oP3q82184 t<sP70;86-<@0<P;0=8:@> >P?}8>nD4# hPC8BH4# 8PG0E8F6LIFPK8JAP4# `PO0J8N%T KPS8RmX| PW0M8VY\pNP[8Z!`4# |P_0T8^)dIUPc0W8bEhXPg0Z8fIl")HP[Pk0^8jQ(_Po$PpPq0axr0bPs0c8nadPv8uyXPz8x~4# P}8|( P0jP kxXP8b  P0n80I*(oP 8 UP qPP8 XP0t8o4# uP8. PHwXP0x8L`y"XP#8!M'4#  P&0|8%e}*XP+8)/h ( P.08-` 2XP381d7gP6085w;0I&<^P:89  >XP?08=CPPB0 8A# PFPGxH0 PI08ERLXPM8K=Q_ PP08O]PT#PU0xV0PW08S5 ZXP[+`Y_-I*P^08]cI*0Pb08a(Pf5Pg7xh0iXPj08etnޭ0Pm08lw qXPrA8p{vI* CPu0"8t(#yXPzG8x~ IP}0%8|&XPM8  OP0(8$ I*)P S8, UXP0+8 4,PY8< [XP0.8@H4X/P_8J aXP018N"H4X2P!e8 XgP%04P& 5x'k(XP)m8$\-;oP,088+k90XP1s8/s5NuP4w83{yP8 =P9{P:}87(=XP>8<PBCDPA0E8@0FFXPG0G8EK1(HPJ8I*PN JPO8M2PRPS0MTXPU0N8Q;Y50OPX0P8W?Q\XP]8[Da4#  P`0S8_H TPdPe8cP hXPi0W8gVm~}XPl8k^qUPp0Z8of [PtPuxv0]wXPx0^8sj8_{XP|0`8zy a@P0d8~}Y8eP0f8 g iP8 ` `9`DER-FRFC73EQV-LAlanDCPJTW SRA!Gumby"[KSHA#-ITS $FILE%N-DU-&EXPRE'EQV-L(@FILE)LEGIO*E]+LISP-,OMPLR-PEOPL.EQV-L/Alan0Y1Feinb2ymbol3GJC4GSB-N5GZ6JONL7KMP8S@DEE9UGHT.:DU;SAILBCMU.E?WGD@ucid.AMAILEBOR-OFCDAYDISTER-ERRF-THE-GCH-DREAIPERSJISTK-WISHLMIDASM-DREANEQV-LOMIDASP-LISTQ-WISHREQV-LSGZTKJBUGumbyV[GZ;MWIDEASXFILEYISTSZIST[ists@\ai.mi]NEWAG^HIVE_IST`;NEWAaCHVE]bIONcDdNL-KReISTf@CS.RgTER.EhNL-KRiREQUEjEQV-LkNICKl-MITmISTnINGRIoJEREMpTDWUqNICKr@medis.medit.eduuEQV-LvBJNwEAKxJNCyCHSNCzWIT M{FILE|NAGE}IST~NAGE@AGANEQV-LPAGANCIONISTISM-RTISTISM-R T@MC -Desi EQV-L @FILEt;DESIS]PCNetgn-ReEQV-LInfo--RequPCNetocolIST[PCNeTO DIFILE-ProtRequeEQV-LInfo--RequPCNetersMoon@stony-brook.scrc.symbolics.comUNIX-HATERS@AI.ai.mit.eduReceived: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 20 Apr 90 10:20:33 EDT Received: from [128.81.41.144] by mintaka.lcs.mit.edu id aa17954; 20 Apr 90 10:04 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 780758; 19 Apr 90 11:43:40 EDT Date: Thu, 19 Apr 90 11:49 EDT From: "David A. Moon" Subject: Invasion of the Mediocretins To: unix-haters@AI.ai.mit.edu In-Reply-To: <19900418230942.1.MT@OUROBOROS.MEDIA.MIT.EDU> Message-ID: <19900419154943.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Wed, 18 Apr 90 19:09 EDT From: Michael Travers This blatant effort at cultural pollution deserves a response from the unix-haters community. My entry for UNIX WEENIE is below; but surely we can do better. From: eric@snark.uu.net (Eric S. Raymond) Subject: The infamous JARGON FILE is being revised -- send us your slang Date: 12 Apr 90 17:33:03 GMT UNIX WEENIE (variant: WEENIX UNIE): a happy little pinhead who believes that 1) UNIX is the last word in operating systems and 2) this is a good thing. Unhappy nonpinheads who believe 1) but not 2) are called FATALISTS. and 3) takes over other people's projects and makes them his own, invariably ruining them in the process through not understanding their original purpose and not caring that he does not understand. FAILNET-ORIGIN<723354.900420@AI.AI.MIT.EDU>@FILE[GREGOR;WEENIX TEXT]FILENOSHOWbandyNOSHOWsterling@ics.comNOSHOWbudd-play@NOSHOWleichter%cs.yale.eduNOSHOWncramer@bbNOSHOW7thson%SLCS.SLB.COM@NOSHOWphilbin-jim@YalNOSHOWkelsey@CS.NOSHOWlanning.paNOSHOWPolen.osbunorthNOSHOWDillon@srcNOSHOWWeld@NOSHOWtiemann%Lurch.Stanford.EDU@wheNOSHOWRPS%Apollo.COM@NOSHOWKLH@SNOSHOWjudyh%PYRPS5.Pyramid.COM@NOSHOWEHL@DNOSHOWBeth@NOSHOWGreek%AITG.DEC@NOSHOWunix-haters-dist%spt.entity.com@wheNOSHOWbboard-unix-haters@SNOSHOWunix-haters-dist@LucNOSHOWunix-haters-redistribution@STONOSHOWZVONASMALL-CLINOQCAPPENDRFC733NOSHOWTKNOSHOWSTEVERNOSHOWstever@wheNOSHOWSRANO-CLINOQCRFC733NOSHOWSRA@XNOSHOWstrazNOSHOWRSNOQCNO-CLINOSHOWRPKNOSHOWrpk@wNOSHOWRDZSMALL-CLINOSHOWRDZ-STANFORDNOSHOWRDZ@WNOSHOWPGSNOSHOWpgs@aNOSHOWNICKNOSHOWnick@NOSHOWMTDNOSHOWMTNOSHOWmt%media-lab.media.mit.edu@minNOSHOWMLYno-clinoqcrfc733NOSHOWMBRNOSHOWmbr@lNOSHOWMAPNOQCAPPENDRFC733NOSHOWMARGNOSHOWMARGNOSHOWmariec@medNOSHOWMAEDANO-CLINOQCRFC733NOSHOWcmaeda@cs.NOSHOWKWHNOSHOWkwh@mNOSHOWKLOTZNOSHOWklotzNOSHOWJTWNOSHOWJTWNOSHOWjrd@MNOSHOWJNCNOSHOWjnc@lNOSHOWJARNOSHOWjar@zNOSHOWHALNOSHOWhal@zNOSHOWGUMBYNO-CLINOQCRFC733NOSHOWgumbyNOSHOWDLWNOSHOWodi!dlw@taNOSHOWDIGEXNOQCNO-CLINOSHOWDEVON-JUNKNOSHOWAPPEND[DEVON;JUNK MAIL]FILENOSHOWDANIELNOSHOWweiseNOSHOWCZNOQCNOSHOWCSTACYNOQCNO-CLINOSHOWCStacy@REANOSHOWCJLNOSHOWcjl@wNOSHOWCENTAPPENDNOSHOWDABNOSHOWdab@fNOSHOWAlan@NOSHOWALANNO-CLINOQCRFC733NOSHOWALAN-AINOSHOWFILE[ALAN;ALAN MAIL]FILENOSHOWAlan-MC@MCNOSHOW[CENTI;HATE UNIX]FILENOSHOWYN-!  ttJt tJ ttJttJt$tJt,tJt4tJtt|tJCp 6t  ttt@Ht  wttӇt` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6`To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOWYN-!   i i  i i% i- i5 i= i"E i&M i*U i.] i2e i6m i:u i>} iCp 6 : @H  Qt` HI!v6p5((U,Xj 0 0H(a@ tc P` i")HP058 6`6` To: HAPY-BDTH-TA-BTH%AI.A.EDU@KA.LC.EDUage-I2239018.DRAI.AI@REAGAN.AI.MIT.EDU:jan@swi.psy.uva.nlED@AI.AI.MIT.EDUReceived: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 20 Apr 90 08:45:42 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8645; 20 Apr 90 08:41:34 EDT Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA26188; Fri, 20 Apr 90 08:12:09 EDT Received: by mcsun.EU.net with SMTP; Fri, 20 Apr 90 14:11:55 +0200 (MET) Received: from swi.psy.uva.nl by hp4nl.nluug.nl with SMTP id AA12127 (5.58.1.14/2.14); Fri, 20 Apr 90 14:13:29 MET Received: from swisun11 (swisun11.swi.psy.uva.nl) by swi.psy.uva.nl id AA16658; Fri, 20 Apr 90 14:11:20 +0200 Organisation: Sociaal Wetenschappelijke Informatica University of Amsterdam Herengracht 196 (from oct this will be : Roeterstraat) 1016 BS Amsterdam, The Netherlands Phone: +31 20 5252073 Fax: +31 20 5252347 Received: by swisun11 id AA15690; Fri, 20 Apr 90 14:11:16 +0200 Message-Id: <9004201211.AA15690@swisun11> Date: Fri, 20 Apr 90 14:11:16 +0200 From: jan@swi.psy.uva.nl (Jan Wielemaker) To: bug-gcc@prep.ai.mit.edu Subject: dbx(tool) code generation on SPARC Probably I'm reporting a known problem. I use gcc version 1.36 on a SUN sparc station, running SunOs 4.0.3. I'm very happy with gcc, but dbx does not seem to understand much of the symbol table gcc produces. dbx's next command generally is equivalent to `cont'; the stack trace definitely is not ok, etc. If you want me to produce an example, I'm happy to, but as I think its a known problem I won't right now. Has this been fixed in version 1.37? Are there plans to fix it? Thanks for any clues --- Jan FAILNET-ORIGIN<723330.900420@AI.AI.MIT.EDU>EDNOSHOW