LAWS@SRI-AI.ARPA (06/18/85)
From: AIList Moderator Kenneth Laws <AIList-REQUEST@SRI-AI>
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 <RICHER@SUMEX-AIM.ARPA>
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
********************