Subject: From: AIList Moderator Kenneth Laws <AIList-REQUEST@SRI-AI>

From: [email-masked]
Date: Fri, 21 Jun 85 04:09:35 edt

Received: from sri-ai.arpa by csnet-relay.arpa id a028741; 18 Jun 85 2:03 EDT
Date: Mon 17 Jun 1985 22:30-PDT
Reply-to: AIList@SRI-AI
US-Mail: SRI Int., 333 Ravenswood Ave., Menlo Park, CA  94025
Phone: (415) 859-6467
Subject: AIList Digest   V3 #79
To: AIList@SRI-AI
Received: from rand-relay by vpi; Fri, 21 Jun 85 04:01 EST

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 <[email-masked]>
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: [email-masked]
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: [email-masked] (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: [email-masked]
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
********************