Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!LAWS From: LAWS@SRI-AI.ARPA Newsgroups: net.ai Subject: AIList Digest V3 #79 Message-ID: <8257@ucbvax.ARPA> Date: Tue, 18-Jun-85 01:59:20 EDT Article-I.D.: ucbvax.8257 Posted: Tue Jun 18 01:59:20 1985 Date-Received: Wed, 19-Jun-85 02:29:05 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 224 From: AIList Moderator Kenneth Laws AIList Digest Tuesday, 18 Jun 1985 Volume 3 : Issue 79 Today's Topics: Education - Proposal for IJCAI ICAI Meeting, Psychology - Cooperation, Information Display - Typography, AI Tools - Lisp User Survey & Scheme ---------------------------------------------------------------------- Date: Fri 14 Jun 85 13:59:39-PDT From: Mark Richer Subject: proposal for ijcai ICAI meeting I have suddenly gotten an urge to find out who is interested in applications of AI to educational computing. That would include knowledge based tutoring systems, interactive encyclopedias, etc. Is there a bboard on the net that discusses such issues? I was speaking with someone who is also interested in this area and It occurred to me that it would be neat to have an interest group meeting at IJCAI this august. Is anyone out there interested? Does anyone know who to contact about setting up such a meeting at IJCAI? (someone involved with setting up the conference). It would be nice to have a time and place to meet and an advance announcement about it in some form. Perhaps, 1 or more people want to volunteer to be discussion leaders. mark ------------------------------ Date: 17 Jun 85 08:44 EDT From: WAnderson.wbst@Xerox.ARPA Subject: Re: Animal Predation The two papers that I remember reading that refer to sharing commons are "The Tragedy of the Commons," by Garrett Hardin, and "Tragedy of the Commons Revisited" (I'm not sure of the author of this one). Both appeared in SCIENCE, Hardin's paper came out in the late 1960's or early 1970's, "The Tragedy ... Revisited" later in the 1970's. If anyone needs the exact references, I can dig them up at home upon request. Bill Anderson ------------------------------ Date: Sun, 16 Jun 85 15:15:22 edt From: hal%gvax@Cornell.ARPA (Hal Perkins) Subject: Typography [...] I don't want to start a holy war about typography in the digest, but ... > Personally, I like all caps (except for AIList). -- KIL Actually, an initial capital and small caps, or all caps in a slightly smaller size looks much better than all caps (in my non-expert opinion). All-caps is awfully obtrusive. ------------------------------ Date: Mon, 17 Jun 85 13:39:36 CDT From: marick@GSWD-VMS Subject: Lisp user survey -- Results Here's a summary of my survey of what users want from Lisp systems. I've also produced a longer document containing the full text of each question together with the relevant text from each response. Send me mail (ARPANET: MARICK@GSWD-VMS; USENET: ihnp4!uiucdcs!ccvaxa!marick) if you want it. Nine people responded; all of them were from the ARPANET. (No one on the USENET uses Lisp?) If anyone wants to send more responses, I'll take them and incorporate them. I hope I've summarized people's responses adequately. If you have more than a passing interest in the issues, please send for the full report. 1. Lisp machines vs. general-purpose workstations vs. timeshared "mainframes". For development purposes, Lisp machines or general-purpose workstations are the clear favorite. The argument is that people are very expensive compared to hardware, and that the productivity gain of a personal computer offsets the hardware cost. There is a counter-argument that the productivity gain is not necessarily due to features unique to Lisp machines, but which happen to be available only on Lisp machines. For delivery purposes, the obvious answer is "it depends". Dumb question. However, it's not clear that developers have considered delivery carefully enough. 2. Calling functions written in another language. A majority finds this feature necessary. It is less necessary on the Lisp machines, but there is still the need to use foreign code. People need to be able to invoke both canned packages and one-of-a-kind functions. 3. Embedded editor vs. external editor Most people don't care, provided the editor provides a good enough connection to LISP. The definition of "good enough" varies, and it's of course easier to provide if the editor is internal. 4. Creating as-small-as-possible stand-alone "application programs". No particular consensus. Some people would like it, some don't care, and some don't think as-small-as-possible is particularly small. 5. Object-oriented programming. Object-oriented programming is important. The right system has yet to be invented. 6. Speed. Speed is very important. Both the speed of the development system when doing development tasks and the speed of the final compiled code are important. 7. How adequate are the standard debugging tools? Most people think they're adequate, but could be better. (One person thought they were quite insufficient; one thought they were overkill.) The use of embedded languages creates the need to debug at the level of those languages. 8. Other important things. Tight integration, consistency of user interface, good documentation, availability of understandable source code, a standard dialect for portability, access to external devices, large address space, source code control. ------------------------------ Date: Sun, 16 Jun 1985 23:19 PDT From: DAVIES@SU-SIERRA.ARPA Subject: Scheme [Forwarded from the Stanford bboard by Laws@SRI-AI.] The following is Hal Abelson's response to my request for information about what's good about Scheme: The following description of Scheme is taken from the "Chez Scheme Manual" by Kent Dybvig, with some editing by Hal Abelson: Scheme is an applicative-order, lexically-scoped, and block-structured dialect of Lisp. Like almost all Lisp dialects, Scheme is an interactive language with automatic storage management for data objects, including lists, strings, various numeric datatypes, and symbols. Because of this, Scheme is ideally suited to symbolic and dynamic computation. Because Scheme is interactive, it is easy to learn Scheme by experimenting with it. Scheme also employs lexical scoping and block structure. In this way, it is similar to Algol 60 and Pascal and unlike traditional (dynamically-scoped) Lisp dialects. But Scheme goes beyond either traditional Lisp or Algol-like languages by providing procedures as "first-class" data objects. A Scheme procedure may be passed as an argument, returned as a value, made part of a compostive data structure, and stored indefinitely while still retaining the environment of its definition. Like Scheme, Common Lisp also provides lexical scoping and first-class procedures. However, Common Lisp does not treat procedures and data in a uniform manner: Procedure identifiers are separate from data identifiers, evaluation of the operator position of a combination follows different rules than evaluation of the operand positions, and procedures must be "quoted" in a special way if they are to be treated as data. Scheme really does treat procedures and data uniformly, greatly simplifying evaluation rules and cutting down namespaces, and gaining expressive power with no loss of efficiency. Another difference between Scheme and Common Lisp is that Scheme is specified to be tail-recursive -- procedure calls can be evaluated without building up space for "control stack." This permits the definition of a wide variety of "imperative" constructs (such as loops and other iterators) purely in terms of procedure application. Additionally, Scheme does not prescribe the order of argument evaluation (as does Common Lisp) so there is more freedom for the Scheme implementor to rearrange programs for optimization or for parallel evaluation. As a consequence of lexical scoping and tail recursion, Scheme encourages functional (side-effect free) programming. The higher-order procedures that a Scheme programmer can easily construct and use provide alternative and more elegant ways to perform most of the computations that are usually accomplished with side-effects. Another feature of Scheme places it beyond other Lisp dialects, and most other programming languages as well. This is the provision for continuations, a general control facility based on solid semantic principles. Continuations allow the implementation of control structures such as coroutines, non-blind backtracking, and multiple tasks. These semantic attributes of Scheme help the programmer to create clear, concise, and maintainable programs and program systems. However, the most important attribute of Scheme supporting this goal is its simplicity. The Scheme community has staunchly resisited the addition of new language features that have not proven themselves to be general engough to warrant making the language larger. As a result, Scheme is a fairly small language that relies on a small set of underlying concepts, which once mastered, provide more power than the less general mechanisms found in other programming languages. A complete description of Scheme can be found in the "Revised Revised Report on Scheme," edited by Will Clinger. This is published as a joint technical report of the Indiana University Computer Science Department and the MIT Artificial Intelligence Laboratory (June 1985). ------------------------------ End of AIList Digest ********************