Hello. It seems everyone believes that Lisp-like languages are
better than proceedural languages like C for AI. Why is that?
I suspect that recursion plays a part, but could use specific
examples. Recursion is also possible in C, but not to the same
degree or with the same ease, perhaps? Also, the distinctions
between "live" processes and "dead" data have been said to be
less clear in dialects of Lisp. Does this imply some valuable
sorcery not easily wielded in C yet essential to AI advances?
Examples and natural-language responses would be appreciated.
Perhaps a discussion of what's essential to AI and what's not
(with respect to programming techniques and paradigms) is the
thing I crave, something beyond the many FAQ-level responses.
--
·······@silver.ucs.indiana.edu or simply ·······@ucs.indiana.edu will
appreciate your intelligent suggestions, anecdotes, comments & offers.
From: Kenrick Mock
Subject: Re: Lisp, Scheme better than C for AI?
Date:
Message-ID: <14857@ucdavis.ucdavis.edu>
In article <······················@bronze.ucs.indiana.edu> ·······@silver.ucs.indiana.edu (Brad Taplin) writes:
>Hello. It seems everyone believes that Lisp-like languages are
>better than proceedural languages like C for AI. Why is that?
>
>I suspect that recursion plays a part, but could use specific
>examples.
Lisp-like languages are certainly useful for recursion, but I think
the nicest property is the symbolic processing. For something like
natural language processing, it's certainly much easier to deal with a
list of symbols than to have to create an array of strings to represent
a sentence, which would be necessary in a language like C. This
doesn't mean that Lisp is more powerful in this respect, but it does
result in cleaner and shorter code (with the exception of a bunch of
parentheses everywhere :)
Also, since Lisp is an interpreted language, you can do some things
that you can't really do in C. In Lisp, the program can create some
Lisp expressions and then execute this statement via "eval" or "apply"
and have the program sort of "program itself." There isn't a
convenient equivalent to eval or apply in C.
Finally, since I am doing some work in genetic programming, the simple
syntax of Lisp makes it quite attractive. It's much easier to create
valid Lisp s-expressions via genetic operators such as crossover or
mutation since all s-expressions are in the same format (any program
can be turned into a tree, barring recursion). To apply genetic
programming to C would be a nightmare due to all of the complexities
in syntax. John Koza has a number of interesting papers on genetic
programming in the Artificial Life and Animat Conference proceedings.
--
------------------------------------------------------------------------------
GEnie : K.MOCK Net : ····@madrone.eecs.ucdavis.edu
"Don't worry about the world ending today, it's already tomorrow in
Australia..." - CMS
In article <······················@bronze.ucs.indiana.edu> ·······@silver.ucs.indiana.edu (Brad Taplin) writes:
Hello. It seems everyone believes that Lisp-like languages are
better than proceedural languages like C for AI. Why is that?
I suspect that recursion plays a part, but could use specific
examples. Recursion is also possible in C, but not to the same
degree or with the same ease, perhaps? Also, the distinctions
between "live" processes and "dead" data have been said to be
less clear in dialects of Lisp. Does this imply some valuable
sorcery not easily wielded in C yet essential to AI advances?
Examples and natural-language responses would be appreciated.
I suspect it has little to do with recursion and more to do with:
* Syntactic flexibility (powerful macros).
* Good programming environments for rapid development.
* Large and powerful libraries with good support for common data
abstractions.
* Easy definition of new datatypes.
* Automatic memory management.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
In article <······················@bronze.ucs.indiana.edu>, ·······@silver.ucs.indiana.edu (Brad Taplin) writes:
: Hello. It seems everyone believes that Lisp-like languages are
: better than proceedural languages like C for AI. Why is that?
:
: I suspect that recursion plays a part, but could use specific
: examples. Recursion is also possible in C, but not to the same
: degree or with the same ease, perhaps? Also, the distinctions
: between "live" processes and "dead" data have been said to be
: less clear in dialects of Lisp. Does this imply some valuable
: sorcery not easily wielded in C yet essential to AI advances?
: Examples and natural-language responses would be appreciated.
:
: Perhaps a discussion of what's essential to AI and what's not
: (with respect to programming techniques and paradigms) is the
: thing I crave, something beyond the many FAQ-level responses.
: --
: ·······@silver.ucs.indiana.edu or simply ·······@ucs.indiana.edu will
: appreciate your intelligent suggestions, anecdotes, comments & offers.
I think there are 3 main points:
- regular syntax (see Kenrick Mock)
- automatic memory management
- self programming capability
This last one is not only possible through eval. You can use functions
just like other objects: so that you can create combine, etc... during
execution, depending on entry data for example. I think the notion
of closure is the main concept of the LISP language ! it is so powerful
that you can do (almost) whatever you want with it: lazy-evaluation,
OOP, ... !
AI has to cope with a dynamic real environment: a dynamic language is
of course more appropriate !
-- Stefan Monnier --
-------------------------------------------------------------
----- Alors voila, Clyde a une p'tite amie ! -----
----- Elle est belle et son prenom c'est .. Bonnie ! -----
----- ... -----
In article <······················@bronze.ucs.indiana.edu> ·······@silver.ucs.indiana.edu (Brad Taplin) writes:
Hello. It seems everyone believes that Lisp-like languages are
better than proceedural languages like C for AI. Why is that?
A couple of reasons, primarily:
- support for "experimental" and/or "evolutionary" programming, i.e
programming where you don't know exactly what the final specs you need
to implement are. The interactive programming style of lisp and the
programming environments in lisp are a key part of this, but so are
things like the built-in ability to do i/o on most data types,
including structured data types, and the fact that functions are first
class data types, which makes it easier to do things like data-driven
programming (use the data as a key and do a lookup in a database to
get the actual code to process the data).
- support for symbolic and pointer-based data types, e.g. built in
symbols, lists, etc, and automatic storage management (including
garbage collection). In addition to making it easier to write, e.g.,
symbolic reasoners in lisp, this has made it easier to build
interpreters for OTHER languages in lisp; one approach to solving AI
problems is to design and implement a specialized language for a given
class of problems, e.g. OPS5.
Secondarily:
- the ease of transforming data into code and visa versa. Note that
in addition to supporting certain kinds of self-referential systems,
this feature of lisp has supported both the early development of
programming environments for list and things like data-driven
programming
--
Lou Steinberg
uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
internet: ···@cs.rutgers.edu
>>>>> "Brad" == Brad Taplin <·······@silver.ucs.indiana.edu> writes:
Brad> Hello. It seems everyone believes that Lisp-like languages are
Brad> better than proceedural languages like C for AI. Why is that?
[stuff deleted]
Brad> Perhaps a discussion of what's essential to AI and what's not
Brad> (with respect to programming techniques and paradigms) is the
Brad> thing I crave, something beyond the many FAQ-level responses.
Sounds like you want Peter Norvig's :
"Paradigms of AI Programming: Case Studies in Common Lisp"
Morgan Kaufmann, 1992. 946 pages. ISBN 1-55860-191-0.
Beg, borrow, or steal this book and read the preface. It even has a clearly
marked section "Why Lisp? Why Common Lisp?".
--
····@cork.Berkeley.EDU Fiiiive Thousand Boomin Watts...... -The JBeez
They can't come on and play me in prime time, | Free Millipede coin op
Cause I know the time, cause I'm gettin' mine. | and House music at my
I get on the mix late in the night... -Public Enemy | place! Drop by sometime.
Another very nice discussion of "Why Lisp" is contained in the Lucid brochure
(comic book :-), "Lisp at a Glance." It's probably a little bit dated by now,
but I really like its use of graphics to convey the key ideas. The wiggly
line diagram two pages from the end really conveys how Lisp programming can
be used for "rapid prototypes" which evolve into finished production code.
(I'd like to congratulate the graphic artists).
Call your local Lucid marketing rep for a copy. It has a price on it ($9.50),
but I'm sure you can talk Lucid out of one.
Mike Wirth
cs.rice.edu
PS: The copyright on the brochure is 1987. Lucid, are you going to do an
update?
In article <······················@bronze.ucs.indiana.edu> Brad Taplin
<·······@silver.ucs.indiana.edu> writes:
> Hello. It seems everyone believes that Lisp-like languages are
> better than proceedural languages like C for AI. Why is that?
>
I'll name you one important reason: SYMBOLS.
People who implement AI-like programs in C, usually are either wasting
space and time using strings as symbol replacements, or they have to
reinvent symbols (which they may do once and for all, of course).
--------------------------------------------------------------
Espen J. Vestre, ·····@coli.uni-sb.de
Universitaet des Saarlandes,
Computerlinguistik, Gebaeude 17.2
Im Stadtwald,
D-6600 SAARBRUECKEN, Germany tel. +49 (681) 302 4501
--------------------------------------------------------------
In article <·····················@coli.uni-sb.de>, ·····@coli (Espen J. Vestre) writes:
>In article <······················@bronze.ucs.indiana.edu> Brad Taplin
><·······@silver.ucs.indiana.edu> writes:
>> Hello. It seems everyone believes that Lisp-like languages are
>> better than proceedural languages like C for AI. Why is that?
>>
>
>I'll name you one important reason: SYMBOLS.
>
>People who implement AI-like programs in C, usually are either wasting
>space and time using strings as symbol replacements, or they have to
>reinvent symbols (which they may do once and for all, of course).
Along with a built-in dynamic data type (lists, natch), with a large library
of routines including built-in garbage collection. Given lists, many
important dynamic structures can be had by defining an appropriate
interface: linked lists, n-way trees, stacks (queues too, but they'd be a bit
trickier than stacks), and even hash tables (via property lists) can be had
with just a few lines of code. Also, since the list is the "standard data
type", it makes designing coherent function interfaces much easier.
Together, all of this makes Lisp an excellent rapid-prototyping language,
which means you have less chance of getting bogged down in (what should be,
anyway) trivial details, and instead concentrating on high-level design (which
would be essential, I think, in any kind of AI application).
I've never done any work in AI, but it seems to me that Lisp's first class
functions could also be a powerful tool in this area.
--
What signature?
In article <······················@organpipe.uug.arizona.edu>, ····@cs.arizona.edu (Dave Schaumann) writes:
............[ lots deleted ]
> I've never done any work in AI, but it seems to me that Lisp's first class
> functions could also be a powerful tool in this area.
For my 1986 MSCS, I used a flat space of LISP plist "templates" containing
keywords, pruning predicates, var-lists, and lambdas; a common-emitter gain
stage was one template; a transformer was another; a supervisory template
existed to management the design of multistage amplifiers; the only constraint
between stages were their input/output impedances.
The design "recipes" in each template (so annointed by Jack Mostow) were
chunks of "Pascal" style code to provide READABILITY; for execution, after
reading the files containing these templates (can you say objects?)
the "recipes" were parsed into LISP Prefix, the embedded variables detected,
a path up towards the root of a scoping TREE was searched to provide bindings,
an lambda wrapped about the newly generated chunk of Prefix and the new
bindings, (how to do this in COMMON LISP, Mr Gabriel?), and the chunk executed.
Actually designed interesting amplifiers.
The recipes provide an ordered computation of constraint satisfaction,
electronic component computation, determining operating points, and testing
for design failure. Any failures were PASSED UP TO THE PARENT, hopefully
to cause a revision in the subtree specification, leading to local design
success upon reinvocation of the chunk.
SURE.......could have been done in "C", but I only needed 5000 lines of
LISP (BERKELEY FRANZ), and did it in 4 months.
Allen Sullivan
PhD CS student Arizona State Univ
designing RF/video circuits for GO-Video
From: George J. Carrette
Subject: Re: Lisp, Scheme better than C for AI?
Date:
Message-ID: <1927@mitech.com>
In article <······················@bronze.ucs.indiana.edu>, Brad Taplin <·······@silver.ucs.indiana.edu> writes:
> Hello. It seems everyone believes that Lisp-like languages are
> better than proceedural languages like C for AI. Why is that?
Given the existence of dynamic linking and even interpreted C environments,
and the ability to do arbitrary things with C preprocessors, and
the various tricks of Garbage Collectors for C environments, the only
difference I can see between C and LISP is the *potential* that
a LISP implementation (compiler and runtime) could be a good deal more
efficient than a C language implementation of the same straightforward
symbolic manipulation program, and that LISP programs should be a
lot more portable than C programs, requiring significantly less #ifdef
kind of hair for a given level of performance.
This bears out in practice. For example, in a version of Macsyma supported by
Paradigm Associates, which is at least a three hundred thousand line program,
and a good deal more if you consider the "user contributed" librarys,
there is not a single line of code that needs to be different or conditionalized
between a VAX version or a CRAY version.
Compare that to what goes on inside the sources to another MIT product
of approximately 20 years later, the X-Window system.
In X there is some of the most extensive macrology and "makeology" and other
fooling around with pointer, library, and systemic differences that you
are likely to see in a published program. (Not even counting the X Server,
which of course must be very low-level, device-dependant, and hairy).
I'm just talking about basic symbolic manipulation stuff like Xt and XLIB.
-gjc
historical note:
You may want to investigate the use and characteristics of
a language called SAIL, "Stanford AI Language" when considering
what an AI language that is not LISP might behave like.
···@mitech.com (George J. Carrette) writes:
>This bears out in practice. For example, in a version of Macsyma supported by
>Compare that to what goes on inside the sources to another MIT product
>of approximately 20 years later, the X-Window system.
Not really fair, since Macsyma doesn't really deal directly with any
devices and X-windows does. That is, there is not that much which is
machine dependent in Macsyma (except for the numerical formats which
Lisp does a nice job of hiding).
From: George J. Carrette
Subject: Re: Lisp, Scheme better than C for AI?
Date:
Message-ID: <1937@mitech.com>
In article <·····················@kronos.arc.nasa.gov>, ·······@kronos.arc.nasa.gov (Eric A. Raymond) writes:
> ···@mitech.com (George J. Carrette) writes:
>>This bears out in practice. For example, in a version of Macsyma supported by
>
>>Compare that to what goes on inside the sources to another MIT product
>>of approximately 20 years later, the X-Window system.
>
> Not really fair, since Macsyma doesn't really deal directly with any
> devices and X-windows does. That is, there is not that much which is
> machine dependent in Macsyma (except for the numerical formats which
> Lisp does a nice job of hiding).
You didn't read my whole message, which is not FAIR to you.
Specifically, I said that I was not counting the DEVICE-LEVEL parts of
X-Window, e.g. the server.
I pointed out that the "Xt" part of X, which is a purely symbolic/object
kind of programming, was sufficient to investigate to see what I was
talking about. That is to say, all of "Xt" is about DATA FORMAT's and
data manipulation.
And I'm saying that C is a weak tool compared with lisp (or COBOL for
that matter) for writing portable codes that deal with data manipulation.
-gjc
In article <····@mitech.com> ···@mitech.com (George J. Carrette) writes:
>I pointed out that the "Xt" part of X, which is a purely symbolic/object
>kind of programming, was sufficient to investigate to see what I was
>talking about. That is to say, all of "Xt" is about DATA FORMAT's and
>data manipulation.
I grepped for all the #ifdef's (and similar stuff) in Xt. Most of them are
simply compilation options having nothing to do with system dependencies
(mostly "#ifdef DEBUG" type's of things). Among those that weren't, many
are for compatibility with old, non-standard compilers (for instance,
before ANSI C, different systems had some different string-handling
functions (e.g. index() vs. strchr())). There are a few OS-dependencies,
such as in the routines that access the file system (ANSI C doesn't provide
a layer that insulates you from the differences between Unix and VMS file
names, for instance); I'm sure there are some OS-dependencies in Macsyma's
file system interfaces as well (I know for a fact that Common Lisp's
attempt at system-independence falls short of its lofty goals in this
regard), timers, etc.
I saw very few system dependencies in the parts of Xt that implement its
object-oriented paradigm and manipulate the data.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
From: George J. Carrette
Subject: Re: Lisp, Scheme better than C for AI?
Date:
Message-ID: <1943@mitech.com>
In article <············@early-bird.think.com>, ······@think.com (Barry Margolin) writes:
> I saw very few system dependencies in the parts of Xt that implement its
> object-oriented paradigm and manipulate the data.
Great, "very few". But you saw "some."
Also, the MIT distributed code doesn't have much in it for the stranger
machine architectures like CRAY or INTEL. (It does have some for CRAY).
Also, how about the hair having to do with ALLOCA?
e.g.
* warning: mips alloca is unsuitable in the server, do not use.
* Some System V boxes extract alloca.o from /lib/libPW.a; if you
None of this kind of stuff would come up in lisp.
-gjc
In article <····@mitech.com> ···@mitech.com (George J. Carrette) writes:
>In article <············@early-bird.think.com>, ······@think.com (Barry Margolin) writes:
>> I saw very few system dependencies in the parts of Xt that implement its
>> object-oriented paradigm and manipulate the data.
>
>Great, "very few". But you saw "some."
...
>None of this kind of stuff would come up in lisp.
Yeah, right.
Try doing anything that manipulates pathnames without system conditionals
any #+/#-.
I just grepped for #+ and #- in the X11R5 CLX sources. Excluding *dep*.l
(which is where I'd expect system dependencies such as network access to be
hidden) there were 350 matches. And 1/6 of the lines in CLX are in *dep*.l.
Admittedly, many of these are #+clx-ansi-common-lisp, which are used to
conditionalize on whether the new ANSI features are available (it looks
like someone went around putting in lots of DYNAMIC-EXTENT declarations,
perhaps forgetting that they could simply (proclaim '(declaration
dynamic-extent))), much as Xt conditionalizes on __ANSI__ (or whatever it
is). But there are also quite a few system dependencies, some just for
optimization purposes.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <············@early-bird.think.com> ······@think.com (Barry
Margolin) writes:
I just grepped for #+ and #- in the X11R5 CLX sources. Excluding
*dep*.l (which is where I'd expect system dependencies such as
network access to be hidden) there were 350 matches. And 1/6 of
the lines in CLX are in *dep*.l.
Admittedly, many of these are #+clx-ansi-common-lisp, [...] But
there are also quite a few system dependencies, some just for
optimization purposes.
Your point is well taken, but for fairness one should (also) compare
libraries at a comparable level of abstraction, e.g. CLX vs. Xlib and
CLUE vs. Xt. Xlib has 504 #ifn?def's, Xt has 172, but CLUE has just
90 #+/#- (and 35 of them in the defsystem, due to pathname differences).
If you look at the sources of CLUE and Xt, or CLIO and Xaw, or a CLUE
application and a Toolkit application, you will notice that the Lisp
code is *much* more compact, while the C code contains lots of
uninteresting "boilerplate" which makes it somewhat hard to read.
This has of course nothing to do with portability, but with the fact
that Xt has to cruft its own object system, while CLUE can use CLOS.
Hopefully the main uses of #+/#- will disappear in the future: the
pathname conditionals because all CL vendors implement X3J13 logical
pathnames, and the performance conditionals because all CL vendors
implement optimizing compilers which generate proper BITBLT code for
something like (SETF (SUBSEQ ...) ...) with the appropriate type
decorations. A standardized CL network API would also be useful.
--
Simon.
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
In article <····@mitech.com> ···@mitech.com (George J. Carrette) writes:
>In article <············@early-bird.think.com>, ······@think.com (Barry Margolin) writes:
>> I saw very few system dependencies in the parts of Xt that implement its
>> object-oriented paradigm and manipulate the data.
>
>Great, "very few". But you saw "some."
...
>None of this kind of stuff would come up in lisp.
Yeah, right.
Try doing anything that manipulates pathnames without system conditionals
any #+/#-.
I just grepped for #+ and #- in the X11R5 CLX sources. Excluding *dep*.l
(which is where I'd expect system dependencies such as network access to be
hidden) there were 350 matches. And 1/6 of the lines in CLX are in *dep*.l.
Admittedly, many of these are #+clx-ansi-common-lisp, which are used to
conditionalize on whether the new ANSI features are available (it looks
like someone went around putting in lots of DYNAMIC-EXTENT declarations,
perhaps forgetting that they could simply (proclaim '(declaration
dynamic-extent))), much as Xt conditionalizes on __ANSI__ (or whatever it
is). But there are also quite a few system dependencies, some just for
optimization purposes.
I'll second Barry's statement. CL is really nice for system
independent code, but once you want performance (performance? from
LISP?) then you end up with conditionalized code. Alot of the
conditionalized code in CLX is around the I/O code. CL I/O is
pretty non-optimal for a wire protocol like X.
Another area that CL falls down is in the pathname handling.
Although there is a well thought out system for parsing and
contructing pathnames, it misses a few important pieces of
information for contructing defsystem (for example) like the
file suffix convensions for a binary and source lisp file.
Writing serious LISP code can quickly move you from the
abstract perfect level where data type sizes don't matter
to declaring (unsigned-byte 16) arrays to pack an image.
--
Douglas S. Rand <·····@osf.org> OSF/Motif Dev.
Snail: 11 Cambridge Center, Cambridge, MA 02142
Disclaimer: I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ
In article <··················@spinner.osf.org> ·····@spinner.osf.org (Douglas Rand) wrote:
>
> Try doing anything that manipulates pathnames without system conditionals
> any #+/#-.
>
> Another area that CL falls down is in the pathname handling. Although
> there is a well thought out system for parsing and contructing pathnames,
> it misses a few important pieces of information for contructing defsystem
> (for example) like the file suffix convensions for a binary and source lisp
> file.
I would hardly say that it "falls down." I wrote a defsystem in Common Lisp
that only had about ten sets of implementation conditionalizations in
roughly 1500 lines of code. Only three sets had anything to do with
handling pathnames. One was to specify the traditional source and binary
file extensions, one was for performance, and one was to work around a bug
in a particular implementation.
I think that the Common Lisp pathname-handling primitives are quite complete.
Whether they are generally used correctly is another issue entirely.
(Just about all of the other conditionalizations were not strictly necessary,
but made certain things work more cleanly. One conditionalization was for
efficiency, and, shockingly enough, it was useful only on Lispms. The
portable CL way of doing this particular thing was fast enough under unix.)
-- Jamie
In article <······················@bronze.ucs.indiana.edu>, Brad Taplin <·······@silver.ucs.indiana.edu> writes:
> Hello. It seems everyone believes that Lisp-like languages are
> better than proceedural languages like C for AI. Why is that?
A language is more than a technology for running programs, it is also
a way of communicating algorithms to people. The AI community
appears to speak Lisp, thus if you want to have access to the rich
library of AI experience, Lisp will give it to you.
If you have something to share then Lisp will help other AI people
to understand it. When in Rome...
Bill
--
Bill Birch | ·······@hemel.bull.co.uk
Bull Info. Sys. Ltd. |
Maxted Road, | Imp: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884367
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
nil desperandum..
In article <·····················@hemel.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
A language is more than a technology for running programs, it is also
a way of communicating algorithms to people. The AI community
appears to speak Lisp, thus if you want to have access to the rich
library of AI experience, Lisp will give it to you.
I once saw the term "conceptual impedance", used in a similar sense
electrical engineers use "impedance". If you want to hook a
loudspeaker to an amplifier, they should have the same impedance to
work properly together. The same way, if you have a problem, your
programming language should be able to express concepts from the
problem domain as easily as possible. It seems to me that Lisp and AI
problems have a good conceptual impedance match.
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of TeXnology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
Date: Wed, 1 Jul 1992 12:39:49 GMT
From: ··@cs.tut.fi (Kellom{ki Pertti)
It seems to me that Lisp and AI
problems have a good conceptual impedance match.
Ah, now I understand why there used to be a lisp vendor called Impediment!
Date: Wed, 1 Jul 1992 08:39 EDT
From: Kellom{ki Pertti <··@cs.tut.fi>
In article <·····················@hemel.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
A language is more than a technology for running programs, it is also
a way of communicating algorithms to people. The AI community
appears to speak Lisp, thus if you want to have access to the rich
library of AI experience, Lisp will give it to you.
I once saw the term "conceptual impedance", used in a similar sense
electrical engineers use "impedance". If you want to hook a
loudspeaker to an amplifier, they should have the same impedance to
work properly together. The same way, if you have a problem, your
programming language should be able to express concepts from the
problem domain as easily as possible. It seems to me that Lisp and AI
problems have a good conceptual impedance match.
That's a good analogy. However, what gives Lisp a "good conceptual
impedance match" with AI programming is Lisp's ability to support
syntactic extensions that provide for domain-specific languages. What
this means is that when Lisp itself does not already provide a good
conceptual impedance match for a particular problem domain, it is easy
for programmers to write a new language within Lisp that provides it.
Another way to put it is, whereas most modern languages provide only
data abstraction, Lisp also provides "control abstraction".
In article <····@mitech.com> ···@mitech.com (George J. Carrette) writes:
Given the existence of dynamic linking and even interpreted C environments,
and the ability to do arbitrary things with C preprocessors, and
the various tricks of Garbage Collectors for C environments, the only
difference I can see between C and LISP is the *potential* that
a LISP implementation (compiler and runtime) could be a good deal more
efficient than a C language implementation of the same straightforward
symbolic manipulation program, and that LISP programs should be a
lot more portable than C programs, requiring significantly less #ifdef
kind of hair for a given level of performance.
Your inclusion of "arbitrary things with C preprocessors," "tricks of
garbage collectors for C environments," etc., would allow the use of a
Draft ANSI Common Lisp implementation that happens to employ a C
compiler as a back-end to be considered "programming in C." Thus,
your statement as written is essentially a tautology.
A more realistic comparison would have to be either:
1) The "best current practice" in the C/C++ culture vs. the "best
current practice" in the (Draft ANSI) Common Lisp culture.
2) Inherent characteristics and philosophy of each language's design;
i.e., attributes without which "X would not be X." For example, C/C++
inherently includes forced static typing, pointer arithmetic, and
minimal guaranteed runtime support; Common Lisp inherently includes
dynamic typing, symbolic processing, and garbage collection.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
From: Steve Knight
Subject: Re: Lisp, Scheme better than C for AI?
Date:
Message-ID: <1350039@otter.hpl.hp.com>
> Hello. It seems everyone believes that Lisp-like languages are
> better than procedural languages like C for AI. Why is that?
What a provocative question -- I've really enjoyed reading the discussion.
(One nit-pick though, Lisp is a procedural language just as much as C.)
My short answer would be (1) automatic store management and (2) dynamic
typing and (3) full lexical binding with nested procedures.
> I suspect that recursion plays a part, but could use specific
> examples. Recursion is also possible in C, but not to the same
> degree or with the same ease, perhaps?
I don't think so. What makes recursion so prevalent in Lisp is the use
of recursive datatypes; lists are the obvious example. When a
recursive datatype is processed it is natural to use recursive procedures.
C is every bit as good at procedural recursion. However, recursive
datatypes are a good deal less convenient and consequently play a reduced
role.
> Also, the distinctions
> between "live" processes and "dead" data have been said to be
> less clear in dialects of Lisp. Does this imply some valuable
> sorcery not easily wielded in C yet essential to AI advances?
> Examples and natural-language responses would be appreciated.
The virtue of this capability (i.e. eval) is widely overstated, in
my view. If you have "eval" in the language then a number of
powerful programming idioms become easily available. For example,
if you want to write a program to solve cryptarithmetic problems
such as
ABCD + EAC = DDDD [I made this up -- don't try it]
then one neat technique is to write a program that itself writes
a little program with the right number of for-loops, corresponding
to the possible substitutions for the numbers in the problem, and
then execute it.
This is neat -- but you don't need eval to do this. This effect can
equally be achieved by using lexical closures. However, since C
does not support either eval or lexical closures, then it is fair to
say that there are a range of programming idioms that are very difficult
to program in C.
[That these two techniques are different can be seen by inspecting
languages such as SML which supports full lexical binding but not
eval.]
Another point that is raised is the heavy use of "symbols" in Lisp.
These are string pointers whose strings are entered into a symbol
table so that equal strings are assigned identical pointers. The
ONLY differences between strings and symbols, from a programmers
viewpoint, is that symbols cannot have their characters changed and
that symbols can be compared for equality extremely fast.
In other words, you could easily implement a symbol table in C (it is
a matter of half an hour or so) and therefore reap the functional
benefit of symbols in C. However, there would be 2 problems. Firstly,
the performance of the C symbols would be as good as your programming
skills in the somewhat specialist area of building symbol tables.
Secondly, you'll have to figure out an efficient way of writing
symbol literals in your C program.
However, this argument boils down to an efficiency issue. Symbols are
more convenient and are very efficient in Lisp. They are more useful
than strings for AI programming.
The big differences between Lisp and C are, as I mentioned above, garbage
collection and dynamic typing. If you add symbols and garbage collection
to C then you are moving in the direction of modern languages such as
SML and Eiffel. However, very little AI programming languages have been
done in them because they are strongly typed languages.
[A brief digression for a definition of terms. The terms "strong typing"
and "dynamic typing" aren't formal terms, alas, so I need to be precise.
In this letter, "strong typing" means that every variable is assigned
a type which every assignment to that variable must satisfy. The term
"dynamic typing" means that values have distinct types but variables
are alllowed to be bound to values of different types during their
lifetime.]
The strong vs dynamic typing argument occasionally rages around the
lisp world. I have no strong feelings about this debate. However, the
situations where strong typing is helpful -- when you are writing
professional, straightforward software, for example -- aren't so
relevant in researching AI. The virtue of dynamic typing is that, when
prototyping, programming is more direct, less verbose, and more
productive. There's a trade-off in adopting a language with strong
typing. In AI, this trade-off favours dynamic typing significantly.
I hope these quick comments add to the discussion.
Steve
Date: Wed, 1 Jul 1992 18:31 EDT
From: Steve Knight <···@otter.hpl.hp.com>
[A brief digression for a definition of terms. The terms "strong typing"
and "dynamic typing" aren't formal terms, alas, so I need to be precise.
In this letter, "strong typing" means that every variable is assigned
a type which every assignment to that variable must satisfy. The term
"dynamic typing" means that values have distinct types but variables
are alllowed to be bound to values of different types during their
lifetime.]
The strong vs dynamic typing argument occasionally rages around the
lisp world. I have no strong feelings about this debate. However, the
situations where strong typing is helpful -- when you are writing
professional, straightforward software, for example -- aren't so
relevant in researching AI. The virtue of dynamic typing is that, when
prototyping, programming is more direct, less verbose, and more
productive. There's a trade-off in adopting a language with strong
typing. In AI, this trade-off favours dynamic typing significantly.
I myself prefer the terms "static typing" vs. "dynamic typing" because
it removes the unwarranted honorific connotation provided by the
adjective "strong", which immediately invites the comparison "weak".
Note that Lisp (the language) provides for type declarations, which
various Lisp implementations are free to use or ignore. Unfortunately,
most Lisp implementations ignore most type declarations, except for the
few obvious ones such as fixnum, single-float, and simple-vector. The
exception to this is the excellent Python compiler from CMU, which has a
spohisticated type inferencing system that it uses produce very good
code. Compilers such as Python give you the best of both worlds:
dynamic typing when it is convenient, and the advantages of static
typing when you want it (such as being able to detect type mismatches at
compile time, and producing better code).
The only reason I mention all this is, there really shouldn't be any
raging debate these days. Sometimes dynamic typing is good, sometimes
static typing is good. Lisp is one of the few languages that lets you
have it both ways.
In article <······················@bronze.ucs.indiana.edu>, Brad Taplin
writes:
> Hello. It seems everyone believes that Lisp-like languages are
> better than proceedural languages like C for AI. Why is that?
......
A number of the other respondents have hit upon many of the important
features that Lisp provides for Artificial Intelligence. I would like to
expand upon these earlier points and provide a unifying concept:
Artificail Intelligence is the process of capturing Human reasoning and
putting it into software. Languages such as C provide effective tools
for representing numbers, strings and memory locations (pointers). However
Human reasoning is composed of far more that just these structures.
Lisp provides effective tools for other important structures that humans use for
reasoning. These include:
Symbols - numbers and letters are not the only basic pieces of data that humans
reason with.
Structures (Interconnections between data) - Lists and other data structuring
tools allow the knowlege contained in our conceptual interconnections of data
to be effectively represented and manipulated.
Functions - Lisp allows functions to be manipulated, constructed and run. Much
of human knowledge is that of procedures of how to do things, it is essential
for a langauge that attempts to capture human knowledge to be able to
effectively reason about such knowledge. The only other language that I know of
that does this is prolog (See "Computer Languages" 1993, Vol 18, #1 for
an article I authored on this subject).
Control Sturctures - There is a large amount of knowledge in the running of a
program (or the running of a reasoning system). This includes temporary
results created in the running of the program along with information of what
steps to take next in the reasoning process. All of this knowldge is
contained in the control structure. Current research in the Lisp family
of languages centers on developing language constructs for manipulating
and accessing this knowledge. In particular the most predominant
of these are the "continuations" of Scheme. I feel that "continuations"
confound control knowledge with functions and thus am currently
working on constructs that manipulates control knowldge without representing
the control knowledge as functions (This allows for things such as
recursive lambdas).
Interpreters - Human beings also create reasoning systems. Thus there
must be ways for to reason about reasoning systems. This is one of the
hotbeds of research in Lisplike, Logic, and Object Oriented
languages and is called "reflection". Here programs have the ability to
manipulate their own interpreters. One of the biggest puzzles in this
field is what to manipulate the interpreters into. In my own research
I have found that by representing Lisp's control knowldge to be represented
as other that functions (i.e. other than "continuations") recursive
function calling can be breadth or best-first as well as the current
depth-first.
Thus the unifying theme underlying Lisp's advantages for AI seems to be
the ability to effectively represent many types of human knowledge that
are ill-represented in C or not accessible at all - such as function, control or
interpreter knowledge.
(For further information on the above classification scheme of symbols,
structures, functions, control structures, and interpreters or on the
subject of reflection you may be interested in my Dissertation "A Descriptive-
Operational Semantics for prescribing Programming Languages with 'Reflective'
Capabilities" UMI order # 9124800)
Justin Coven
Computer Science Department
Bellarmine College
Louisville, KY 40206
········@ulkyvx.louisville.edu
In article <·················@ulkyvx.louisville.edu> ········@ulkyvx.louisville.edu writes:
Artificail Intelligence is the process of capturing Human reasoning and
putting it into software. Languages such as C provide effective tools
for representing numbers, strings and memory locations (pointers). However
Human reasoning is composed of far more that just these structures.
Powerful string manipulation requires garbage collection--the Bell
Labs designers of SNOBOL realized that back in the '60s, before C was
born--so I do not consider C to adequately support strings. C also
has no built-in knowledge of rational numbers, complex numbers, or
very large integers, so I would say it supports only fixed-size
integers (fixnums) and floating-point numbers (flonums) adequately.
Thus, if you want to manipulate fixnums, flonums, or memory addresses,
use C; otherwise, Common Lisp is more appropriate.
Thus the unifying theme underlying Lisp's advantages for AI seems to be
the ability to effectively represent many types of human knowledge that
are ill-represented in C or not accessible at all - such as function, control or
interpreter knowledge.
Exactly. Common Lisp lets the programmer manipulate the same kinds of
information people work with in everyday life; C always requires an
explicit programmer-written mapping into fixnums, flonums, and memory
addresses.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
Date: Mon, 6 Jul 1992 12:40 EDT
From: "lawrence.g.mayka" <···@cbnewsc.att.com>
Exactly. Common Lisp lets the programmer manipulate the same kinds of
information people work with in everyday life; C always requires an
explicit programmer-written mapping into fixnums, flonums, and memory
addresses.
One way I often state one philosophical difference between C and Lisp is
that in C the programmer must directly confront many of the problems of
software engineering as soon as s/he sits down to write a program. In
Lisp, the programmer can simply sit down and write the initial cut of a
program without worrying about engineering details.
Of course, in both Lisp and C there is a process of turning the initial
code into a final product. It may be that this process takes the same
amount of time in Lisp and in C, but my guess is that it may actually
take longer in Lisp where there are more hidden costs than in C.
What this means is that, for problems that are well specified and well
understood in advance, and whose requirements are unlikely to change, C
may be a better implementation language. For problems that are poorly
specified and less well understood, Lisp is definitely the better
choice. For problems where no final engineering needs to be done (such
as happens in pure research and proof-of-concept), Lisp is also probably
the better choice.
AI is certainly one area in which the problems are less well understood
(and this suited for using Lisp), but there are other areas as well.
Date: Mon, 6 Jul 1992 11:15 CDT
From: Scott McKay <···@STONY-BROOK.SCRC.Symbolics.COM>
Of course, in both Lisp and C there is a process of turning the initial
code into a final product. It may be that this process takes the same
amount of time in Lisp and in C, but my guess is that it may actually
take longer in Lisp where there are more hidden costs than in C.
In the sense that in order to get a C/C++ program running at all, it
typically has to be closer to production quality than an equivalent
Common Lisp program, which typically starts running much earlier in its
lifecycle.
What this means is that, for problems that are well specified and well
understood in advance, and whose requirements are unlikely to change, C
may be a better implementation language. For problems that are poorly
specified and less well understood, Lisp is definitely the better
choice. For problems where no final engineering needs to be done (such
as happens in pure research and proof-of-concept), Lisp is also probably
the better choice.
With the stipulation that almost by definition, large software systems
are *not* well specified or well understood in advance, and their
requirements *are* likely to change, unless restrictions have been
deliberately put in place for other reasons (universal standardization
with no need for evolution, absolute-top execution speed at the cost of
every other consideration, etc.).
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.