LAWS@SRI-AI.ARPA (07/03/85)
From: AIList Moderator Kenneth Laws <AIList-REQUEST@SRI-AI>
AIList Digest Wednesday, 3 Jul 1985 Volume 3 : Issue 86
Today's Topics:
Administrivia - Addresses of Seminar Presenters,
Queries - Statistics of Syntactic Structures & Spatial Reasoning &
UNIVAC 1100 LISP & Symbolics's User Interface,
Expert Systems - Validation,
AI Tools - Interlisp Comments & C vs. LISP
----------------------------------------------------------------------
Date: Monday, 1 Jul 1985 20:49-EST
From: munnari!psych.uq.oz!ross@seismo.ARPA
Subject: addresses of seminar presenters
Being from out of town I find it a little difficult to get to most of the
seminars advertised in the AIList. However, there are some I would like a
little more information on by contacting the presenter to get a copy of the
talk or, more likely, a related paper or report.
Unfortunately, most of the seminar announcements give no network address for
the presenter and an inadequately specified postal address. Would it be
possible to exhort seminar hosts to put complete addresses in the announcements
or at least make sure that they ask the presenter for an address so that
others may find out from the host?
-- Ross
------------------------------
Date: Tue, 2 Jul 85 10:26:31 EDT
From: "Ben P. Yuhas" <yuhas@hopkins-eecs-bravo.ARPA>
Subject: Read My Lips
Here at the Sensory Aids Lab, we are beginning to explore
some of the strategies used by lip readers to decode the visual
speech signal. One of the questions we want to answer is to what
degree does syntactic structure influence a sentence's lip read-
ability.
In developing a data base of test sentences on laserdisk,
we began to wonder whether anyone had ever attempted to find
the statistical distribution of syntactic structures in spoken
English. I realize this distribution might vary greatly from
group to group. If there are any computational linguists with
references or thoughts on this matter I would appreciate hearing
from you.
yuhas@hopkins-eecs-bravo
Snailmail: Ben Yuhas
Dept EECS
Johns Hopkins University
Baltimore, MD 21218
------------------------------
Date: 2 Jul 85 08:27:00 EDT
From: " CUGINI, JOHN" <cugini@nbs-vms>
Subject: spatial reasoning
Can anyone suggest a good survey article or textbook that covers
AI for spatial reasoning, especially for 3-D? I have in mind
things like, "will this refrigerator fit thru that door", etc.
Thanks for any help.
John Cugini <Cugini@NBS-VMS>
Institute for Computer Sciences and Technology
National Bureau of Standards
Bldg 225 Room A-265
Gaithersburg, MD 20899
phone: (301) 921-2431
------------------------------
Date: Mon, 1 Jul 85 11:51:36 EDT
From: Marty Hall <hall@hopkins-eecs-bravo.ARPA>
Subject: UNIVAC 1100 Series LISP
I am trying to find where I can find documentation or info on the
Univac 1100 LISP. We are referring to a system that was written in
that dialect, and converting it to Common LISP. However, there are two
functions that appear that are found in neither MACLISP or LISP 1.5
(which this LSP was supposed to be), that we can't find out what they
do. The functions are "AMB" and "STACK". They are used:
(setq <var> (amb (stack <var2>)))
We have called lots of people, including the local Sperry Corp folks,
and no one seems to know. Any suggestions on where to look or who
to call/send to ?
-Marty Hall
hall@hopkins
aplvax!m2lab!hall@maryland
------------------------------
Date: Tue, 2 Jul 85 11:26 EDT
From: susan watkins <chaowatkins@SCRC-STONY-BROOK.ARPA>
Subject: Symbolics's application user interface
I'm working as a developer at Symbolics, Inc. in Cambridge, Ma.
I would like to get opinions, reactions, problems encountered,
constraints the system s/w imposes, etc. from programmers who have
use the Symbolics s/w to develop a reasonably sized product. e.g. what
problems they have run into trying to use the window system. I'll be at
IJCAI, so I'll more than happy to meet and talk with anyone who is
interested. My mail-stop is chaowatkins@SCRC-STONY-BROOK.ARPA.
------------------------------
Date: Mon 1 Jul 85 09:54:22-PDT
From: Bruce Buchanan <BUCHANAN@SUMEX-AIM.ARPA>
Subject: validation of expert systems
Ted Shortliffe & I tried to address the issues surrounding evaluation
of expert systems in chapter 30 of RULE-BASED EXPERT SYSTEMS. We
did not specifically talk about what to do in the case of very large
knowledge bases built by multiple experts, but chapter 8 does discuss
some knowledge-base editing facilities that should help.
I would like to know of work on these problems.
B.Buchanan
------------------------------
Date: 26 Jun 1985 1215-PDT (Wednesday)
From: Steven Tepper <greep@Camelot>
Subject: Putting comments in Interlisp programs (flame)
[Forwarded from the Stanford bboard by Laws@SRI-AI. This is
part of an exchange on hacking and software engineering.]
I didn't say that comments are impossible in Interlisp -- merely that it's
painful to put them in.
For the edification of those who have not had the privilege of being
subjected to Interlisp's slavish adherence to the principle that it
should constitute an entire programming environment (as opposed to being
just another programming language living on a general purpose computer
system), one of the concomitant requirements of this philosophy is that all
operations, including editing, be done on Lisp objects. This means that
comments (which are handled by a function called * that does not evaluate
its arguments) are a part of the running program. Thus, extreme care is
required in the placement of comments. For example, the following function
fails:
(DEFINEQ (FOO (LAMBDA (X Y)
(COND ((GREATERP X Y) X) (* Return the maximum value)
(T Y]
because the comment is treated as a clause to the COND. Similarly, a
comment placed as the last form in a function (Interlisp provides an
implicit PROGN in function definitions) will return the first word of the
comment as the value of the function. In fact, because Lisp is largely a
functional language, there are relatively few safe places to put comments.
A further indication of the low repute with which comments are held in
Interlisp is the fact that the common way of displaying a function at
the top level, PP (pretty-print), replaces all comments with the symbol
**COMMENT**. To me, this is backwards -- if anything, the comments should
be given prominence over the Lisp code. Similarly, in the display editor
on Interlisp-D, comments are kept as far away from the executable code
as possible (on the same line) and displayed in a font which is considerably
less readable than that used for non-comments.
This is the basis on which I justify my earlier claim that Interlisp
"discourages" comments, which I consider an undesirable goal.
------------------------------
Date: Thu 27 Jun 85 11:47:41-PDT
From: Liam Peyton <PEYTON@SU-SUSHI.ARPA>
Subject: Interlisp
[Forwarded from the Stanford bboard by Laws@SRI-AI.]
If Interlisp's approach to comments prevents one from inserting mindless
comments like the following:
(DEFINEQ (FOO (LAMBDA (X Y)
(COND ((GREATERP X Y) X) (* Return the maximum value)
(T Y)))))
then it should be praised not criticized. A step by step translation
is not helpful commenting and certainly does not give the comments more
prominence than the actual code. (if anything it reduces the relevance of
comments). A short summary before the cond explaining what the code is
doing is far neater and more useful.
Why would one ever want to have a comment in the last line of a PROG?
(* comment: this is the end of the prog)
This is not to say by any means that Interlisp has the ideal means of
handling comments or that Interlisp doesn't have its problems. It
does, but they are certainly not a basis for rejecting it as a
programming environment.
Some of the things that result from "Interlisp's slavish adherence to
the principle that it should constitute an entire programming environment"
are incremental execution for debugging purposes, sophisticated mouse
and window system with interactions between windows, online text processing,
and online graphics.
A general purpose computer is a computer that can do anything painfully.
------------------------------
Date: Mon, 1 Jul 85 21:46:21 PDT
From: Richard K. Jennings <jennings@AEROSPACE.ARPA>
Subject: C vs LISP
We have continuing debates about that subject all the time,
and I think for us we have come to the conclusion (for now) that
C is better than LISP.
Currently we have MS-DOS 2.0, XLISP 2.0, and Lattice C
compiler version 2.0. A new man (fish@aerospace) was given
the simple task to write a plotter driver. He did this by
first writing a plot spooler of sorts in assembly language (after
failing miserably in basic). At this point, he was a virgin
programmer, save some fortran programming on large machines.
He then started on another program to help people interactively
develop a 'plotter language' file which his plot spooler could plot.
At this point he was manually generating the plotter language, to
produce vu-graphs (as I said he was *the* new man). Using a copy
of Winston's Lisp text, he set out with XLISP to produce this
translator. After a month or so, his incentive to write an
interactive translator (to get him out of the vu-graph making loop)
dissipated.
About a month ago, he went to NARDAC and attended a 1-day
C tutorial. Then he brought up the C compiler, and now is just
about done. There is no doubt in my mind that he prefers Lattice
C to XLISP.
Before all the LISP people flame let me make a few comments. I
am familliar with both C and XLISP, and have programmed in each. Both
are pretty basic, but in my opinion I would chose XLISP to write the
basic program, and then recode it to C if it was going to be maintained.
During this effort I acted as the trouble shooter, and let me say that
if I was going to supervise a programming team, THEY WOULD USE C. In
fact, from the management level, I think Lisp is only marginally better
than assembly language: perhaps.
By September we should be using PC-AT's with GC-LISP, and the
new Microsoft C compiler. By December we will probably have our
Symbolics, without a C compiler (although the salesman evidently has
one to sell which ought to say something). So shoot me a note about
Jan and I may have changed my tune.
To conclude, if you have a one man project, and the lisp environment
you plan to use has a lot of functionality you need in you application
built-in, lisp can probably be justified. The source libraries now
available in C (or Pascal, real soon now for Ada) will be increasing
difficult to beat, especially in the context to C interpreters and
incremental compilers, and the fact C runs on *everything*. If you
are starting from scratch -- common Lisp -- (even XLISP is extended to
support object oriented programming) ***good luck***!
Richard Jennings
AFSCF/XRP
Sunnyvale ARPA: jennings@aerospace
->standard disclaimer applies<-
------------------------------
End of AIList Digest
********************shebs@bcsaic.UUCP (stan shebs) (07/08/85)
>From: Richard K. Jennings <jennings@AEROSPACE.ARPA> >Subject: C vs LISP > > We have continuing debates about that subject all the time, >and I think for us we have come to the conclusion (for now) that >C is better than LISP. > Currently we have MS-DOS 2.0, XLISP 2.0, and Lattice C >compiler version 2.0. XLISP is about the poorest dialect of Lisp that I know of, while Lattice C is good (so I hear). To put things on the other shoe, try comparing tiny-C to Zetalisp or Common Lisp. >Using a copy >of Winston's Lisp text, he set out with XLISP to produce this >translator. Worse and worse - especially if it was the first edition. And the second edition is Common Lisp-based! It's sort of like trying to use an Ada manual to write Pascal programs. >There is no doubt in my mind that he prefers Lattice C to XLISP. I'm a confirmed Lisp hacker, but I also prefer C to XLISP. > By September we should be using PC-AT's with GC-LISP, and the >new Microsoft C compiler. GC-LISP is only a marginal improvement over XLISP. The quotes I've seen from the AI experts are always to the effect that GC-LISP is good "for educational purposes" or for "training" - nothing about how it's adequate for production software. >The source libraries now >available in C (or Pascal, real soon now for Ada) will be increasing >difficult to beat... This is interesting - I haven't seen any evidence of C libraries that come anywhere close to what even "small" Lisps like PSL and Franz come with, let alone Zetalisp or Interlisp. Full Lisp implementations (as opposed to XLISP) come with parser generators (yacc in a library?!), very fancy iteration macros, OOP packages, pattern matchers/unifiers, elaborate interaction/debugging facilities, graphics packages (sadly nonstandardized though), sophisticated implementations of useful datatypes, and so forth. How can C or Pascal possibly get the datatype polymorphism that Lispers take for granted, and that most of these packages depend on for their usefulness? Don't judge a language by the feeble implementations that have been done for micros! stan shebs