LAWS@SRI-AI.ARPA (07/14/85)
From: AIList Moderator Kenneth Laws <AIList-REQUEST@SRI-AI> AIList Digest Sunday, 14 Jul 1985 Volume 3 : Issue 93 Today's Topics: Games - Progress in Chess, Learning - Forgetting, AI Tools - Interlisp Comments, Natural Language - Aymara FAB Lab ---------------------------------------------------------------------- Date: Fri 5 Jul 85 19:28:02-EDT From: Fred Hapgood <SIDNEY.G.HAPGOOD%MIT-OZ@MIT-MC.ARPA> Subject: Progress in Chess It is my recollection that the first good chess program, Northwestern's CHESS 3.0, had earned a USCF rating of about 2100 in 1973. In the subsequent twelve years quite impressive advances have been made both in chess programs and the hardware running them. Yet apparently all that this progress has bought has been a measly 100 rating points. What conclusions might be drawn from these facts? One, surely, is that it might take much longer than any of us think to build a machine that plays even 2400 chess, let alone at world champion level. ------------------------------ Date: Sun, 7 Jul 85 16:03:56 PDT From: Richard K. Jennings <jennings@AEROSPACE.ARPA> Subject: Falling Away; re Furth's message. > From: "furth john%d.mfenet" >Subject: The Best Chess Program > To attain an independent and useful intelligence, the learner > must be able to discard significant portions of the means by which > it has arrived at its present level of ability. The original hub > of its actions must *fall away* and a new one be generated. > So the adult forgets the involvements of childhood and the state > the cares of its early days. With whatever vestiges remain, the > organism must take on a whole new orientation to meet new > needs with a closer approach to the optimum. It is better to > forget the past than to live there. The best chess program > will forget most everything its author ever told it to do. This is certainly true for persons in general. The recent TV series & book entitled 'The Brain' talked about people who didn't seem to be able to forget very well, and the problems they had in normal life. Along these lines, it is possible to develop some rather interesting perspectives 'on the meaning of it all'. Suppose for a moment, one of the key features of our species is that regardless of how important person an person thinks he or she is, they 'fall away' (read die) after a rather short period of time (on the cosmic scale). If immortality could be achieved, this would not occur and the 'intelligence' of the species by Furth's implicit definition would be reduced. Consequently, the immortality quest is ephemeral at best, and certainly not a quest that should be funded by the entire race. Rich. ------------------------------ Date: Sun, 7 Jul 85 19:27:40 PDT From: Steve Crocker <crocker@AEROSPACE.ARPA> Subject: Interlisp comments are first class citizens I must have missed the first flame about comments in Interlisp, but I'll jump in anyway. I have used Interlisp for a decade and it's a sheer delight to see how many good ideas have been implemented and are just sitting there waiting for the semi-experienced user to discover them. The method of handling comments is one of the minor delights, but a delight nonetheless. As has been noted, comments in Interlisp are simply functions that don't have any useful value. The "*" is used as the function symbol, and that works fine, although any other symbol such as ";" or "comment" could have been used as well. Once you get the idea that comments are simply "useless" functions, I find it hard to understand why there's much trouble placing them correctly. The prettyprinter always prints them out in an identifiable way, and the compiler and/or DWIM package catch the majority of errors you might make. No similar service exists is most other languages, including most dialects of Lisp. One of the neat things we were able to do with Interlisp comments is adopt a convention that each function definition contain a comment that describes its purpose, inputs and output as its first "action." (The compiler knows enough to generate nothing when it sees a comment, so it doesn't take up either time or space in the object code.) Using the Masterscope system, we built some tools that generate documentation for a file full of functions. This documentation includes all of the Masterscope goodies -- who calls the function, what variables are referenced, etc. -- and the initial comment for the function. All of this information is collected in a Scribe file and turned into a substantial document. This kind of thing is not necessary for the programmer who's debugging a couple of functions in a context he knows intimately, but it sure does help the next programmer or the same programmer a year later. This kind of tool was almost trivial to build because comments are part of the code and not incidental frosting lost at the first turn of the lexical analyzer. (Anybody who thinks he has a natural language parser that handles metaphors is invited to try that last sentence!) There are always alternative ways of doing things and differences and taste and style, but most of the criticisms of Lisp in general and Interlisp in particular come from people who grew up (?) with batch compilers of line-oriented, statement-oriented languages. I think those are three of the worst things that ever happened in computing, and will continue to haunt us for another several decades. Steve Crocker ------------------------------ Date: Mon, 8 Jul 85 09:50:16 edt From: Eric Nyberg <ehn0%gte-labs.csnet@csnet-relay.arpa> Subject: Re: Interlisp Comments In reply to Steven Tepper's comments in AIList #86, I would like to make the following points about commenting Interlisp programs. Placing a comment in the "wrong" place may result in a comment value being used by a function in an undesirable way. During compilation, the compiler issues a warning whenever this sort of situation is noticed (VALUE OF COMMENT USED). The printing of comments as "**COMMENT**" during pretty printing is the system default. Mr. Tepper was too quick to flamethrow before checking his Interlisp manual on this. There is a variable called **COMMENT**FLG which controls this behaviour. If **COMMENT**FLG is NIL, comments are printed. Otherwise, the value of **COMMENT**FLG is printed (initially set to "**COMMENT**"). There is also a function called PP* {nlambda*} which performs a PP with all comments expanded. I refer Mr. Tepper and others interested in reading about the comment facility to Sections 6.8.1 - 6.8.4 in the Interlisp-D manual (I'm afraid my comments don't apply to older versions of Interlisp). For info on how to change the font used for comments, see section 6.8.5. The rest of Steven's complaints about the position and font used for comments can all be remedied by resetting various parameters that control the format of comments (see the above sections). If one takes the extra time to set up his/her programming environment the way he/she likes it, it is possible to have the comments just about anywhere (and any size). It seems that there are many user "hooks" in Interlisp-D that allow this sort of customization. It is too bad that the documentation is sometimes very difficult to understand, even when tracked down. I disagree with Steven's conclusion that Interlisp "discourages" comments. The *default environment* handles comments in a discouraging way, but a few lines of code in the init file can remedy the situation. Eric Nyberg GTE Laboratories ehn0@gte-labs.CSNET ------------------------------ Date: Tue 9 Jul 85 02:51:46-CDT From: Werner Uhrig <CMP.WERNER@UTEXAS-20.ARPA> Subject: A visit to the Aymara FAB Lab [DDJ July 85] [ from Dr. Dobb's Journal, July 1985 - "Of Interest" by Michael Swaine] A VISIT to the FAB Lab ======================= --- A blip of 'deja vu' struck as I read in the March IEEE Software about IVAN GUZMAN DE ROJAS and his plan for doing natural-language translation via the peculiarly algebraic Andean Indean language Aymara. Yes, trivial recall was working perfectly; halfway down the Andean peak of press releases on my desk I found the announcement of the opening of the AYAMARA FAB LAB in Sunnyvale. A coincidence worthy of a drive down the peninsula. DEAN NORMAN, director of the lab, ... explained that Guzman, discovering the Aymara, lacking irregular verbs and gender, was an unprecedentedly logical language (although its logic was not standard two-valued logic), had succeeded in codifying the algorithmic structure of it syntax. For the first time, someone had expressed a natural language in software. Wasn't Guzman, I asked, considering the application of his achievement in the design of translation machines, the notion being that computerized Aymara could serve as the bridge in a multilanguage translation system? Right, Norman answered, although at AFL they were taking the process in a somewhat different direction. Did I recall the Sapir-Whorf hypothesis from linguistics? I did, more or less: that language delimited the thinkable thoughts, and thus our culture and perceptions. Under normal conditions we see only those distinctions for which we have words. In cultures in which green is not a major linguistic division of the spectrum, it is also not a primary perceptual division. Norman nodded. The principle can be applied to any language-processing system, natural or artificial. Curious as it might sound, the Aymara- speaking software would, to a certain extend, think like an Aymaran. With it's multi-valued logic, it would make distinctions that would never occur to a New York stock-broker; with its lack of grammatical gender, it would fail to make distinctions the stockbroker would unconsciously make. And Aymaran is only the easiest language, not the only one, to which the principle can be applied. Employing Guzman's translation techniques, it would be possible to develop front-end packages that, with the proper filtering out of Aymaran values and perceptions, would embody pure upper-class British perceptions or ancient Greek thought processes. We could examine the way judges in ancient Sumeria examined evidence. That, Norman explained, was what they were up to at AFL: just as the developers of expert systems were trying to capture the knowledge of selected individuals in software, AFL was trying to capture the style of thinking, the intellectual spirit of whole cultures. I mulled that over. Wouldn't there be a great advantage, I asked, in combining the two approaches, developiong a system with a specifiable style of thinking? Couldn't one develop, say, a machine with the knowledge of a high-energy physicist and the spirit of a 12th-century Mandarin? Or the knowledge of a modern statesman and the intellectual style of the first Continental Congress? But Norman suddenly looked uncomfortable and said that he couldn't discuss details of ongoing projects. [given that I quote verbatim a large junk of text here, I feel it proper to make a plug for DDJ, one of the very few worthwhile commercial computer magazines: DDJ appears monthly, subscription is $25/year, airmail Canada $46, other countries $62 and if your technical newsstand doesn't have it you should ask for it. DDJ, PO Box 27809, Sand Diego, CA 92128 call (800)321-3333 and (619)485-9623 or 566-6947 for subscription problems (not having one is a problem, right? ;-) disclaimers galore - Werner ] ------------------------------ End of AIList Digest ********************
shebs@bcsaic.UUCP (stan shebs) (07/16/85)
>From: Steve Crocker <crocker@AEROSPACE.ARPA> >Subject: Interlisp comments are first class citizens > >As has been noted, comments in Interlisp are simply functions that don't >have any useful value. The "*" is used as the function symbol, and that >works fine, although any other symbol such as ";" or "comment" could have >been used as well. Once you get the idea that comments are simply "useless" >functions, I find it hard to understand why there's much trouble placing >them correctly. I believe that one of the original complaints was that "comments as functions" doesn't work well in a purely functional language. Interlisp has never pretended to be particularly functional (pun unintentional), so there's lots of places to put comment "functions" - namely, any place where a side-effecting function call would go. If your programs have progns all over the place, it's easy; if (like myself) you try to make things more functional, the choices dwindle rapidly. My best solution to this problem involves treating comments as s-expressions and then having another level of preprocessing built into the interpreter and compiler that flushes comments, yielding a valid program. Not elegant, but it would work in a purely functional language. stan shebs