I have read several threads discussing Lisp for coding AI, and believe
Lisp does offer a better method. More specifically though, what data
structures does Lisp do well with that C++ would not. Also, could
someone give an example of a complex problem that could be done easily
in Lisp, but not C++ or its relatives.
Given that I only know the C++ basics, and have yet to learn about the
STL, macros, and plenty of other stuff, I would probably be better off
learning Lisp.
"James Reiher" <·······@yahoo.com> wrote in message ································@posting.google.com...
> I have read several threads discussing Lisp for coding AI, and believe
> Lisp does offer a better method. More specifically though, what data
> structures does Lisp do well with that C++ would not.
With enough code you can create C++ data structures that are equivalent
to Lisp data structures. The problem is that you need an order of
magnitude more code in C++ to do so.
> Also, could
> someone give an example of a complex problem that could be done easily
> in Lisp, but not C++ or its relatives.
CHANGE-CLASS, changes an instance of an object to a new class.
Even simple things like multiple dispatch are painful in C++.
> Given that I only know the C++ basics, and have yet to learn about the
> STL, macros, and plenty of other stuff, I would probably be better off
> learning Lisp.
Definitely.
From: Tim Bradshaw
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <ey3adp3xt66.fsf@cley.com>
* James Reiher wrote:
> I have read several threads discussing Lisp for coding AI, and believe
> Lisp does offer a better method. More specifically though, what data
> structures does Lisp do well with that C++ would not. Also, could
> someone give an example of a complex problem that could be done easily
> in Lisp, but not C++ or its relatives.
Take a large system with very many classes, and many existing
instances of those classes. While this system is running,
incrementally load an object file which redefines some of those
classes (which can have extant instances). Have this work.
--tim
> With enough code you can create C++ data structures that are equivalent
> to Lisp data structures. The problem is that you need an order of
> magnitude more code in C++ to do so.
[by joe]
> Take a large system with very many classes, and many existing
> instances of those classes. While this system is running,
> incrementally load an object file which redefines some of those
> classes (which can have extant instances). Have this work.
>
> --tim
Thanks Joe and Tim. I bought a couple Lisp books from Amazon.com
today(technically yesterday) and will be sure to bug the forum when I
run into a tough issue :)
From: Hannah Schroeter
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <agbvel$op4$1@c3po.schlund.de>
Hello!
In article <····························@posting.google.com>,
James Reiher <·······@yahoo.com> wrote:
>[...]
>Thanks Joe and Tim. I bought a couple Lisp books from Amazon.com
>today(technically yesterday) and will be sure to bug the forum when I
>run into a tough issue :)
The prosel^Wconvincing arguments have worked again :-)
Feel free to ask your questions of course, and welcome to the wonders
of Lisp.
Kind regards,
Hannah.
"Hannah Schroeter" <······@schlund.de> wrote in message ·················@c3po.schlund.de...
> Hello!
>
> In article <····························@posting.google.com>,
> James Reiher <·······@yahoo.com> wrote:
> >[...]
>
> >Thanks Joe and Tim. I bought a couple Lisp books from Amazon.com
> >today(technically yesterday) and will be sure to bug the forum when I
> >run into a tough issue :)
>
> The prosel^Wconvincing arguments have worked again :-)
Would you care to take a free personality test?
From: Hannah Schroeter
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <agjvjt$som$1@c3po.schlund.de>
Hello!
In article <·······················@rwcrnsc51.ops.asp.att.net>,
Joe Marshall <·············@attbi.com> wrote:
>"Hannah Schroeter" <······@schlund.de> wrote in message
>·················@c3po.schlund.de...
>[...]
>> The prosel^Wconvincing arguments have worked again :-)
>Would you care to take a free personality test?
Why do you think I could care to take a personality test?
Kind regards,
Hannah.
"Hannah Schroeter" <······@schlund.de> wrote in message ·················@c3po.schlund.de...
> Hello!
>
> In article <·······················@rwcrnsc51.ops.asp.att.net>,
> Joe Marshall <·············@attbi.com> wrote:
>
> >"Hannah Schroeter" <······@schlund.de> wrote in message
> >·················@c3po.schlund.de...
> >[...]
>
> >> The prosel^Wconvincing arguments have worked again :-)
>
> >Would you care to take a free personality test?
>
> Why do you think I could care to take a personality test?
It's the opening line that Scientologists use for their proselytizing.
I had forgotten that Scientology is banned in Germany, so I guess
that it makes less sense as a joke.
Joe Marshall <·············@attbi.com> wrote:
> "Hannah Schroeter" <······@schlund.de> wrote in message
> ·················@c3po.schlund.de.
> > In article <·······················@rwcrnsc51.ops.asp.att.net>,
> > Joe Marshall <·············@attbi.com> wrote:
> > >"Hannah Schroeter" <······@schlund.de> wrote in message
> > >·················@c3po.schlund.de...
> > >> The prosel^Wconvincing arguments have worked again :-)
> > >Would you care to take a free personality test?
> > Why do you think I could care to take a personality test?
> It's the opening line that Scientologists use for their proselytizing.
I did not know that.
I thought it was a reference to the AI koan:
[from <http://www.tuxedo.org/~esr/jargon/html/Some-AI-Koans.html>]
A disciple of another sect once came to Drescher as he was eating
his morning meal.
"I would like to give you this personality test", said the outsider,
"because I want you to be happy."
Drescher took the paper that was offered him and put it into the
toaster, saying: "I wish the toaster to be happy, too."
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
"Michael Sullivan" <·······@bcect.com> wrote in message ····································@bcect.com...
> Joe Marshall <·············@attbi.com> wrote:
> > "Hannah Schroeter" <······@schlund.de> wrote in message
> > ·················@c3po.schlund.de.
> > > In article <·······················@rwcrnsc51.ops.asp.att.net>,
> > > Joe Marshall <·············@attbi.com> wrote:
> > > >"Hannah Schroeter" <······@schlund.de> wrote in message
> > > >·················@c3po.schlund.de...
>
> > > >> The prosel^Wconvincing arguments have worked again :-)
>
> > > >Would you care to take a free personality test?
>
> > > Why do you think I could care to take a personality test?
>
> > It's the opening line that Scientologists use for their proselytizing.
>
> I did not know that.
>
> I thought it was a reference to the AI koan:
> [from <http://www.tuxedo.org/~esr/jargon/html/Some-AI-Koans.html>]
>
> A disciple of another sect once came to Drescher as he was eating
> his morning meal.
>
> "I would like to give you this personality test", said the outsider,
> "because I want you to be happy."
>
> Drescher took the paper that was offered him and put it into the
> toaster, saying: "I wish the toaster to be happy, too."
>
In that AI Koan it is implied that the outsider is a Scientologist
proselytizer.
Joe Marshall <·············@attbi.com> wrote:
> "Michael Sullivan" <·······@bcect.com> wrote in message
> ····································@bcect.com...
> > Joe Marshall <·············@attbi.com> wrote:
> > > "Hannah Schroeter" <······@schlund.de> wrote in message
> > > ·················@c3po.schlund.de.
> > > > Why do you think I could care to take a personality test?
> > > It's the opening line that Scientologists use for their proselytizing.
> > I did not know that.
> > I thought it was a reference to the AI koan:
> > [from <http://www.tuxedo.org/~esr/jargon/html/Some-AI-Koans.html>]
> > A disciple of another sect once came to Drescher as he was eating
> > his morning meal.
> > "I would like to give you this personality test", said the outsider,
> > "because I want you to be happy."
> > Drescher took the paper that was offered him and put it into the
> > toaster, saying: "I wish the toaster to be happy, too."
> In that AI Koan it is implied that the outsider is a Scientologist
> proselytizer.
In my post it was implied that the knowledge shed some more light on
that koan. It's kind of depressing to think they've been around that
long.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
·······@bcect.com (Michael Sullivan) writes:
> In my post it was implied that the knowledge shed some more light on
> that koan. It's kind of depressing to think they've been around that
> long.
alas, passage of time does not make them any deeper than they ever were.
it is high time lisp community write some new koans. should not be too
difficult given the calibre of the personalities and the exchanges
that populate this newsgroup... 8-]
oz
---
The quality of mercy is not fkazji jkafl xi enkf -Monkey #5572.
"Joe Marshall" <·············@attbi.com> writes:
> "Hannah Schroeter" <······@schlund.de> wrote in message ·················@c3po.schlund.de...
> > In article <·······················@rwcrnsc51.ops.asp.att.net>,
> > Joe Marshall <·············@attbi.com> wrote:
> >
> > >"Hannah Schroeter" <······@schlund.de> wrote in message
> > >·················@c3po.schlund.de...
> > >[...]
> >
> > >> The prosel^Wconvincing arguments have worked again :-)
> >
> > >Would you care to take a free personality test?
> >
> > Why do you think I could care to take a personality test?
>
> It's the opening line that Scientologists use for their proselytizing.
>
> I had forgotten that Scientology is banned in Germany, so I guess
> that it makes less sense as a joke.
They are not ``banned'' in any way, and have people do their
``personality tests'' here just like in any other country. They are
just a bit upset because they have to pay taxes like every other
company, which is at a higher rate than, say, the catholic church
pays.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
"Nils Goesche" <······@cartan.de> wrote in message ···················@pc022.bln.elmeg.de...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > "Hannah Schroeter" <······@schlund.de> wrote in message ·················@c3po.schlund.de...
> > > In article <·······················@rwcrnsc51.ops.asp.att.net>,
> > > Joe Marshall <·············@attbi.com> wrote:
> > >
> > > >"Hannah Schroeter" <······@schlund.de> wrote in message
> > > >·················@c3po.schlund.de...
> > > >[...]
> > >
> > > >> The prosel^Wconvincing arguments have worked again :-)
> > >
> > > >Would you care to take a free personality test?
> > >
> > > Why do you think I could care to take a personality test?
> >
> > It's the opening line that Scientologists use for their proselytizing.
> >
> > I had forgotten that Scientology is banned in Germany, so I guess
> > that it makes less sense as a joke.
>
> They are not ``banned'' in any way, and have people do their
> ``personality tests'' here just like in any other country. They are
> just a bit upset because they have to pay taxes like every other
> company, which is at a higher rate than, say, the catholic church
> pays.
Not only had I forgotten, I had forgotten something that wasn't true!
Thanks for the clarification.
"Joe Marshall" <·············@attbi.com> wrote in message news:<······················@sccrnsc01>...
> > >Would you care to take a free personality test?
> >
> > Why do you think I could care to take a personality test?
>
> It's the opening line that Scientologists use for their
> proselytizing.
Here I thought it might be an Eliza reference. :)
······@schlund.de (Hannah Schroeter) writes:
> In article <·······················@rwcrnsc51.ops.asp.att.net>,
> Joe Marshall <·············@attbi.com> wrote:
>
> >"Hannah Schroeter" <······@schlund.de> wrote in message
> >·················@c3po.schlund.de...
> >[...]
>
> >> The prosel^Wconvincing arguments have worked again :-)
>
> >Would you care to take a free personality test?
>
> Why do you think I could care to take a personality test?
It's a joke. John Travolta has something to do with it... :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
·······@yahoo.com (James Reiher) writes:
> I have read several threads discussing Lisp for coding AI, and believe
> Lisp does offer a better method. More specifically though, what data
> structures does Lisp do well with that C++ would not.
functions (and closures).
> Also, could
> someone give an example of a complex problem that could be done easily
> in Lisp, but not C++ or its relatives.
consider the case where you have a function which takes another
function as an argument. for example, a root (zero) finding routine
like the secant method (it doesn't matter if this is a good algorithm,
just that you are passing a function). you set it up so that the root
finder takes a function of one parameter.
now consider having a function of two variables. you with to hold one
of the variables fixed and then feed the root finder. in lisp, you
can very easily use a closure
(let ((y something))
(secant-method #'(lambda (x) (foo x y)) 0.0 1.0))
doing this in C is painful. it's not any better in C++.
> Given that I only know the C++ basics, and have yet to learn about the
> STL, macros, and plenty of other stuff, I would probably be better off
> learning Lisp.
--
Johan KULLSTAM <··········@attbi.com> sysengr
From: Andreas Hinze
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D29A9E9.6E601EE7@smi.de>
Johan Kullstam wrote:
>
> ·······@yahoo.com (James Reiher) writes:
>
> > I have read several threads discussing Lisp for coding AI, and believe
> > Lisp does offer a better method. More specifically though, what data
> > structures does Lisp do well with that C++ would not.
>
> functions (and closures).
>
> > Also, could
> > someone give an example of a complex problem that could be done easily
> > in Lisp, but not C++ or its relatives.
>
If a simple problem also does then look at the following code snippet from
a logging tool that works with GTK:
defun create-gtk-logwindow ( title )
; INTERNAL
"Create a new logwindow named title and returns a logwindow struct"
(let* ((window (make-window :type :toplevel ;
:title title
:border-width 5
:visible t))
(text (text-new))
(logwindow (make-logwindow :name title :window window :text text)))
[cutted]
(signal-connect window 'destroy
#'(lambda ()
(logging-destroy-window logwindow)))
The interesting point is the last function. Signal-connect assigns the
function code that starts with #'(lambda to the destroy method of the window.
(Please note that i don't assign a named function.)
Logging-destroy-windows then make some book-keeping stuff. But look at the
parameter logwindow. This is a local variable of create-gtk-logwindow. But
you are still able to use it when logging-destroy-window is executed (and thats
typically much later as the creation). That means that the lambda expression
"remember" the context in which it is created and use the variable logwindow
of that context (that means the context of create-gtk-logwindow).
Of course there might be solutions for that in C/C++. But i fear it would be much more
complicated and needs more coding.
Best
AHz
On 7 Jul 2002 01:09:40 -0700, ·······@yahoo.com (James Reiher) wrote:
> I have read several threads discussing Lisp for coding AI, and believe
> Lisp does offer a better method. More specifically though, what data
> structures does Lisp do well with that C++ would not. Also, could
The topic of using Lisp for AI applications is extensively discussed by
Peter Norvig in the book "Paradigms of Artificial Intelligence Programming
- Case Studies in Common Lisp". If you are interested in learning Common
Lisp in more depth, the book is a valuable resource.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso <·······@mclink.it> writes:
> The topic of using Lisp for AI applications is extensively discussed
> by Peter Norvig in the book "Paradigms of Artificial Intelligence
> Programming - Case Studies in Common Lisp".
I'll second that recommendation. The book does an excellent job of
discussing the kinds of problems that AI programmers will face --
making it valuable even for AI programmers who use other languages --
and then deals with strategies for implementation that take advantage
of the features that Common Lisp offers. Seeing Common Lisp from this
perspective will certainly help the reader understand how to take
advantage of the language's facilities in his own programs.
--
Matt Curtin Interhack Corp +1 614 545 HACK http://web.interhack.com/
Author, Developing Trust: Online Privacy and Security (Apress, 2001)
Beer is proof that God loves us and wants us to be happy. -B. Franklin
·······@yahoo.com (James Reiher) wrote in message news:<···························@posting.google.com>...
> I have read several threads discussing Lisp for coding AI, and believe
> Lisp does offer a better method. More specifically though, what data
> structures does Lisp do well with that C++ would not. Also, could
> someone give an example of a complex problem that could be done easily
> in Lisp, but not C++ or its relatives.
>
> Given that I only know the C++ basics, and have yet to learn about the
> STL, macros, and plenty of other stuff, I would probably be better off
> learning Lisp.
Macros. Other may be (with MUCH pain) implemented using C/C++. But
Lisp macro facility may be emulated (paritaly, hardly working, clumsy
and buggy) using external prepocessing (such is TrollTech MOC, Meta
Object Compiler for C++ widget library).
Some time ago, I was a C zealot too. But C world is now forced to
migrate to C++. SDL with its bloated unneeded complexity, slowness and
huge code size forced me to seek refuge in some other language. I
found Lisp.
Anton N. Mescheryakov <······@ihed.ras.ru> wrote:
> Some time ago, I was a C zealot too. But C world is now forced to
> migrate to C++. SDL with its bloated unneeded complexity, slowness and
> huge code size forced me to seek refuge in some other language. I
> found Lisp.
I don't understand this comment. I can certainly see preferring lisp to
C++ or C. But in what way is a C programmer forced to migrate to C++
anymore than a lisp or smalltalk programmer is? There are probably more
pure C programs out there than lisp programs, more jobs for plain C
programmers, etc.
C++ is a superset of C. There's no particular reason you can't program
C on a C++ compiler with jackbooted warnings off. In C++, one uses STL,
etc. for the same reason you use various predefined functions in CL, so
that you don't have to write them.
The only reason I can see to abandon C in favor of C++ is that you want
to use features that are only available in C++.
If lack of popularity forces you to migrate away from C, I'm not sure
lisp is the answer.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
·······@bcect.com (Michael Sullivan) writes:
> C++ is a superset of C. There's no particular reason you can't program
> C on a C++ compiler with jackbooted warnings off. In C++, one uses STL,
> etc. for the same reason you use various predefined functions in CL, so
> that you don't have to write them.
No, C++ is not. There are incompatibilities between C and C++ (for
instance, regarding the type of NULL).
--
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess [only] as long as he
keeps it to himself.... -- Thomas Jefferson
Again, thanks for all the tips. I have noticed that C macros seem
bizarre though I can't really compare, and after reading an article
about how the developer of the Yahoo Stores software was able to jump
ahead of the competition because of quicker coding using Lisp,
especially Lisp macros, I was convinced to give it a try.
······@ihed.ras.ru (Anton N. Mescheryakov) wrote in message news:<····························@posting.google.com>...
> ·······@yahoo.com (James Reiher) wrote in message news:<···························@posting.google.com>...
> > I have read several threads discussing Lisp for coding AI, and believe
> > Lisp does offer a better method. More specifically though, what data
> > structures does Lisp do well with that C++ would not. Also, could
> > someone give an example of a complex problem that could be done easily
> > in Lisp, but not C++ or its relatives.
> >
> > Given that I only know the C++ basics, and have yet to learn about the
> > STL, macros, and plenty of other stuff, I would probably be better off
> > learning Lisp.
>
> Macros. Other may be (with MUCH pain) implemented using C/C++. But
> Lisp macro facility may be emulated (paritaly, hardly working, clumsy
> and buggy) using external prepocessing (such is TrollTech MOC, Meta
> Object Compiler for C++ widget library).
>
> Some time ago, I was a C zealot too. But C world is now forced to
> migrate to C++. SDL with its bloated unneeded complexity, slowness and
> huge code size forced me to seek refuge in some other language. I
> found Lisp.
From: Hannah Schroeter
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <agrk3u$o1i$2@c3po.schlund.de>
Hello!
In article <····························@posting.google.com>,
Anton N. Mescheryakov <······@ihed.ras.ru> wrote:
>[...]
>Macros. Other may be (with MUCH pain) implemented using C/C++. But
>Lisp macro facility may be emulated (paritaly, hardly working, clumsy
>and buggy) using external prepocessing (such is TrollTech MOC, Meta
>Object Compiler for C++ widget library).
Or things like lex/yacc. (lex/yacc each replace what could be a
single macro + supporting functions in Lisp)
Or something like OpenC++
http://www.csg.is.titech.ac.jp/~chiba/openc++.html
That's a preprocessor for C++ which uses metaprogram plugins to
define custom transformations on C++ code.
Still not of the same league as Lisp macros and other Lisp metaprogramming
facilities, but more than nothing.
>[...]
Kind regards,
Hannah.
Quoth ······@schlund.de (Hannah Schroeter):
> Hello!
>
> In article <····························@posting.google.com>,
> Anton N. Mescheryakov <······@ihed.ras.ru> wrote:
>>[...]
>
>>Macros. Other may be (with MUCH pain) implemented using C/C++. But
>>Lisp macro facility may be emulated (paritaly, hardly working, clumsy
>>and buggy) using external prepocessing (such is TrollTech MOC, Meta
>>Object Compiler for C++ widget library).
>
> Or things like lex/yacc. (lex/yacc each replace what could be a
> single macro + supporting functions in Lisp)
That idea, I think, strikes unreasoning fear into the hearts of most
that hear the suggestion.
My impression (and it _could_ be wrong, but I doubt it) is that many
would rather fritter away their time designing, debugging, and then
re-debugging the integration of an XML parser into their system rather
than to design a little language using Lex/Yacc.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.ntlug.org/~cbbrowne/oses.html
Rules of the Evil Overlord #207. "Employees will have conjugal visit
trailers which they may use provided they call in a replacement and
sign out on the timesheet. Given this, anyone caught making out in a
closet while leaving their station unmonitored will be shot."
<http://www.eviloverlord.com/>
From: Kaz Kylheku
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <agno63$b1r$2@luna.vcn.bc.ca>
In article <···························@posting.google.com>, James Reiher wrote:
> I have read several threads discussing Lisp for coding AI, and believe
> Lisp does offer a better method. More specifically though, what data
> structures does Lisp do well with that C++ would not.
Pretty much every data structure you can name, because Lisp is dynamically
typed and has automatic storage management. Even the manipulation of simple
linked lists is a chore in C++. C++ has a standard library now with
a class for representing lists, but that class treats lists as mere containers
for uniform objects; treating lists as structured objects in their
own right is awkward.
Lisp is used for AI programming not because it has special support for AI, but
because AI programming is a difficult software engineering task. AI requires a
programming tool in which one not only goes after a desired behavior, but also
has the ability to create new abstractions for expressing oneself in new
domains. Those abstractions appear in the form of new sublanguages.
One important data structure which is squarely out of reach of the
C++ programmer is that data structure which represents the source
code of a Lisp program. Whereas C++ programs have only one representation,
namely a grammar which describes a program as sequence of characters,
the representation of Lisp programs is divided into two levels. Like
in C++, there is a text representation, which conforms to the read syntax. That
representation is a notation which codes for a data structure. That data
structure in turn represents a program. This makes it possible for a program to
manipulate its own structure.
The read syntax of Lisp is so simple that you don't need a background in
compilers to understand it. The scanning of a Lisp program can be described in
terms of simple functions that are dispatched according to a character table.
In fact, Lisp allows the programmer to manipulate that table; you can bind
custom scanning actions, written as Lisp functions, to characters,
so that you can create your own customized lexical notations.
The data structure representing a Lisp program is very polymorphic: computer
programs contain diverse elements, symbols, strings, numeric constants and the
like. Handling this type of data structure in a convenient way requires dynamic
typing. Even if C++ had a standard representation for C++ programs which could
be subject to compiling and evaluation, that representation would be extremely
unwieldy to work with. It would probably be some horrible n-ary tree with
nodes that are classes representing ``symbol'' ``string'' and so on. These
classes would murder the ease of working with the program's representation,
turning it into a huge chore.
But as it is, C++ provides no access to the program. Or rather, the only
representation that can be manipulated by the programmer is the C++
preprocessor token sequence. This level of representation is not far
above raw text; it does not capture the nested structure of the program in any
way. Moreover, the language for manipulating tokens is very poor. Its power
is limited to: selecting portions of the program for translation based on the
results of constant expressions involving only integer operands; naming
headers and files for inclusion into the translation unit; substituting
tokens into replacement sequences (macro expansion); turning groups of tokens
into string literals; and catenating adjacent tokens.
By contrast, the Lisp programmer can apply the entire Lisp language
in writing a program that transforms pieces of itself. This means that
the programmer can invent new constructs that have arbitrary syntax and
semantics, and are automatically translated into other constructs that
implement those semantics. A language which doesn't have this feature
is so ridiculously impoverished as to appear nearly useless.
For that reason, languages like C and C++ should be only used for what they are
good at: writing the lowest level routines of a system, such as schedulers,
device drivers, rasterizing graphics, and so on. In other words, domains whose
abstractions correspond closely to the elements of hardware, and no higher
level of abstraction is required.
> Also, could
> someone give an example of a complex problem that could be done easily
> in Lisp, but not C++ or its relatives.
A good example would be the problem of developing a C++ compiler.
In Lisp, this would reduce to the problem of parsing the ugly, tortuous
grammar of C++ to produce some suitable Lisp data structure. Having that
structure, expressing the rest of the translation would be quite easy compared
to doing the same thing in C++. Walking trees, transforming trees, matching
patterns over trees: things like that can be neatly written in Lisp that is
actually human readable.
Moreover, the resulting compiler would be free of problems such as crashed due
to bad pointers or memory leaks. It would be easier to maintain and therefore
easier to optimize.
People who write compilers in C and C++ often end up cheating; knowing that a
compiler's run time is short-lived, they don't bother freeing dynamically
allocated objects. That approach will fail as soon as the compiler is embedded
into another program, from which it can be invoked repeatedly.
> Given that I only know the C++ basics, and have yet to learn about the
> STL, macros, and plenty of other stuff, I would probably be better off
> learning Lisp.
You will find that the features in one area of C++ are a workaround for
problems in some other area. When you cancel the features with their
workarounds, you are left with nothing much that is actually
intended for solving real problems that are not caused by the language
in the first place.
For example, in Lisp we don't need templates because objects are dynamically
typed, and if we need to generate code based on some parameters, we have
macros which are far, far more powerful than templates.
Templates are a workaround for static typing, which requires that a piece of
code must know everything about the low level representation of a type in order
to do any work with it, even to accept arguments of that type or pass values of
that type to lower level functions.
The static type system of C++ requires that the type of every variable
be declared, even in rarely executed code such as the main() function.
When you are programming in C++, you are expending an enormous effort
into optimizing every nook and cranny of your program.
C++ programmers don't realize it, because they are not aware that the purpose
of declaring types is to achieve execution speed. They have been duped into
believing a big lie: namely that the purpose of static typing is safety, which
in turn helps the programmer write error-free programs.
Indeed, if a piece of machine code assumes everything about the layout of an
object, which has no embedded information describing its type, the only safety
net is a static system for ensuring that the code is applied only to a
compatible type. This does not imply that static typing is necessary for
safety; only that it is necessary for safety in ``high level assembly
languages'' whose run-time performance is the primary concern, and to which
everything else takes a back seat, such as productively developing complex
software with fewer errors in less time.
In article <············@luna.vcn.bc.ca>, Kaz Kylheku wrote:
> In article <···························@posting.google.com>, James Reiher wrote:
>> I have read several threads discussing Lisp for coding AI, and believe
>> Lisp does offer a better method. More specifically though, what data
>> structures does Lisp do well with that C++ would not.
>
> For that reason, languages like C and C++ should be only used for what they are
> good at: writing the lowest level routines of a system, such as schedulers,
> device drivers, rasterizing graphics, and so on. In other words, domains whose
> abstractions correspond closely to the elements of hardware, and no higher
> level of abstraction is required.
C and C++ is not even good at that. Lowlevel routines require precise
control of how a type is represented, and there's no way do define
your own types that does. In practice you are compiler dependent, and
the common way of working around this problem is to use the preprocessor.
Also, the relatively weak typing of C is especially bas for lowlevel
tasks. If you index out of the array, wraps a number unintentonally
or have pointers pointing to the wrong place, that is much more
serious in lowlevel applications, than in higlevel systems. It
typically makes the system as a whole unstable. The types added
by C++ is really more for highlevel work, and don't help on this
level.
In fact the weaknesses of the C type system have cased severe
dameges in lowlevel programming. One example is that several
people got rosted by an x-ray machine programed in C. Usually the
problem is more of an economic problem. In critical applications,
so much bugfixing must be done before the system have a stable state,
and the total development costs of the systems becomes huge.
Now you could say that this is the curse of the lowlevel programmer,
but in fact there are languages designed to be safe for lowlevel
programming, like Ada, so the problem is C and not just lowlevel
programming in general
> The static type system of C++ requires that the type of every variable
> be declared, even in rarely executed code such as the main() function.
> When you are programming in C++, you are expending an enormous effort
> into optimizing every nook and cranny of your program.
>
> C++ programmers don't realize it, because they are not aware that the purpose
> of declaring types is to achieve execution speed. They have been duped into
> believing a big lie: namely that the purpose of static typing is safety, which
> in turn helps the programmer write error-free programs.
There is another possible reason for wanting a static type system,
and that is when you want to have precise control of how your types
are represented. In lowlevel programming you typically want that,
but you are right in general. The argument don't hold for C anyway
since you don't have control over the representation, despite of
the static typing.
--
Gisle S�lensminde ( ·····@ii.uib.no )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
Gisle:
> ... One example is that several
> people got rosted by an x-ray machine programed in C.
you are talking about the therac-25 linear accelerator incidents; those
accidents have to do with the failure to solve a subtle mutual exclusion
problem [1] and has really nothing to do with the programming language.
there are many lessons to learn from that incident, some of which are
spelled out in leveson/turner report [2]:
* Documentation should not be an afterthought.
* Software quality assurance practices and standards should be established.
* Designs should be kept simple.
* Ways to get information about errors -- for example, software audit
trails -- should be designed into the software from the beginning.
* The software should be subjected to extensive testing and formal
analysis at the module and software level; system testing alone is
not adequate.
this bites us all.
[if you program for a living, where the software you produce or contribute
to is used by countless others, you owe it to yourself to read the jackson
book, and leveson/turner report.]
oz
---
[1] Michael Jackson, "Software Requirements and Specifications: A Lexicon
of Practice, Principles and Prejudices," Addison Wesley, 1995
[2] Nancy Leveson and Clark S. Turner, "An Investigation of the Therac-25
Accidents" IEEE Computer, 26/7, July 1993. pp. 18-41.
[i have the original article; use google to locate one of several
online copies]
---
rigor is mortifying to most. - oz
Kaz Kylheku:
> A good example would be the problem of developing a C++ compiler.
> In Lisp, this would reduce to the problem of parsing the ugly, tortuous
> grammar of C++ to produce some suitable Lisp data structure. Having that
> structure, expressing the rest of the translation would be quite easy compared
> to doing the same thing in C++. Walking trees, transforming trees, matching
> patterns over trees: things like that can be neatly written in Lisp that is
> actually human readable.
yet, no production-quality compilers in daily use exist for any language
other than lisp written in lisp. i suppose this is merely because lispers
are so busy doing really abstract and important things, they never have the
time to think about writing compilers for other languages. of course they
are a necessity of computing,and everyone can benefit from compilers that
are [for example] extensible as in recent good work by Dawson Engler and
students amongst others. [http://citeseer.nj.nec.com/engler00checking.html]
oz
---
naturam expelles furca tamen usque recurret -- horace
In article <····························@posting.google.com>,
ozan s. yigit wrote:
> Kaz Kylheku:
>
>> A good example would be the problem of developing a C++ compiler.
>
>> In Lisp, this would reduce to the problem of parsing the ugly, tortuous
>> grammar of C++ to produce some suitable Lisp data structure. Having that
>> structure, expressing the rest of the translation would be quite easy compared
>> to doing the same thing in C++. Walking trees, transforming trees, matching
>> patterns over trees: things like that can be neatly written in Lisp that is
>> actually human readable.
>
> yet, no production-quality compilers in daily use exist for any language
> other than lisp written in lisp. i suppose this is merely because lispers
> are so busy doing really abstract and important things, they never have the
> time to think about writing compilers for other languages. of course they
So fund one, if you pay for it then the largest hurdle is jumped.
Building a commerical grade compiler takes a lot of time, from what
little I know it takes man years to get done. This includes adding
little things like bootstraping code, test suites, documentation and
the list goes on. Many of these thing are not what would generaly be
considdered fun to do. Also do not forget the domain specific knolege
needed to make it happen and that also takes time to learn. Then
there is the compatability issuse, people do not generaly junk a tool
that they have lots of time invested in for something new that may not
survive so you would need to make it a dropin replacement for gcc, for
example to have shot at it being used.
> are a necessity of computing,and everyone can benefit from compilers that
> are [for example] extensible as in recent good work by Dawson Engler and
> students amongst others. [http://citeseer.nj.nec.com/engler00checking.html]
>
And this was funded by someone.
marc
> oz
> ---
> naturam expelles furca tamen usque recurret -- horace
From: Paul F. Dietz
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D317534.C502E60F@dls.net>
Marc Spitzer wrote:
> Then
> there is the compatability issuse, people do not generaly junk a tool
> that they have lots of time invested in for something new that may not
> survive so you would need to make it a dropin replacement for gcc, for
> example to have shot at it being used.
I sometimes think that if gcc were being reimplemented today from
scratch, they'd decide to do it in Lisp. When gcc was started lisp
was arguably too heavyweight and slow, and the GPLed lisp (kcl/akcl/gcl)
wasn't very good.
Since gcc has now been modified to use conservative gc instead
of explicit deallocation I'm hoping they extend gcc's code generation
to add gc support (for example, enabling it to intelligently insert
card marking write barrier code to support generational collection.)
This could make using gcc's backend as a lisp compiler's backend more
practical.
> > are a necessity of computing,and everyone can benefit from compilers that
> > are [for example] extensible as in recent good work by Dawson Engler and
> > students amongst others. [http://citeseer.nj.nec.com/engler00checking.html]
> >
>
> And this was funded by someone.
Engler's group has been working recently on using their system to check
properties of C programs. Their system, CHECKER, has found many bugs
in the Linux kernel. I think this kind of program checker is a better
target for implementation in Lisp than a full-blown C compiler would be
at this time.
Paul
In article <·················@dls.net>, Paul F. Dietz wrote:
> Marc Spitzer wrote:
>
> Engler's group has been working recently on using their system to check
> properties of C programs. Their system, CHECKER, has found many bugs
> in the Linux kernel. I think this kind of program checker is a better
> target for implementation in Lisp than a full-blown C compiler would be
> at this time.
>
Well a super lint does sound doable. It would be an interesting thing
to do. Plug in an expert system for the actual bug detector engine,
build a parser and a treewalker. The trick would be getting people to
use it, much like lint.
marc
> Paul
From: Kaz Kylheku
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <agsgi9$l5r$2@luna.vcn.bc.ca>
In article <····················@oscar.eng.cv.net>, Marc Spitzer wrote:
> In article <·················@dls.net>, Paul F. Dietz wrote:
>> Marc Spitzer wrote:
>>
>> Engler's group has been working recently on using their system to check
>> properties of C programs. Their system, CHECKER, has found many bugs
>> in the Linux kernel. I think this kind of program checker is a better
>> target for implementation in Lisp than a full-blown C compiler would be
>> at this time.
>>
>
> Well a super lint does sound doable. It would be an interesting thing
> to do. Plug in an expert system for the actual bug detector engine,
> build a parser and a treewalker. The trick would be getting people to
> use it, much like lint.
Another trick would be to convince a typical C programmer that something
your program found is an error, even if it produces the right machine language
by fluke.
From: Paul F. Dietz
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D321B45.1BEF969D@dls.net>
Kaz Kylheku wrote:
> Another trick would be to convince a typical C programmer that something
> your program found is an error, even if it produces the right machine language
> by fluke.
His group's work finding bugs in the Linux kernel mostly elicited
expressions of consternation and gratitude. The bugs are usually
easy to fix, since the analysis finds the defective code, not just
a symptom.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Kaz Kylheku wrote:
>
> > Another trick would be to convince a typical C programmer that something
> > your program found is an error, even if it produces the right machine language
> > by fluke.
>
> His group's work finding bugs in the Linux kernel mostly elicited
> expressions of consternation and gratitude. The bugs are usually
> easy to fix, since the analysis finds the defective code, not just
> a symptom.
It's not quite as simple as that. There's a lot of false positives
spun up by those checkers, so they spend a fair amount of time needing
to hand-analyze the code to figure out whether it's actually a bug or
not.
--
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess [only] as long as he
keeps it to himself.... -- Thomas Jefferson
From: Paul F. Dietz
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D321AC2.35A63CEE@dls.net>
Marc Spitzer wrote:
> Well a super lint does sound doable. It would be an interesting thing
> to do. Plug in an expert system for the actual bug detector engine,
> build a parser and a treewalker. The trick would be getting people to
> use it, much like lint.
Checker does more than work on trees; it propagates assertions
about the program along the flow graph, if I understand correctly.
The information propagated is customizable for different kinds of
analyses.
Microsoft has at least one similar system (written in Scheme,
I think). I heard they were using it for checking programs
were 64 bit safe, among other things.
As for getting people to use the system: in Microsoft's case
I presume Bill Gates orders them to :); in the free software
case anyone is free to do so on the source, often with embarrassing
results.
Paul
In article <·················@dls.net>, "Paul F. Dietz" <·····@dls.net> wrote:
>Microsoft has at least one similar system (written in Scheme,
>I think). I heard they were using it for checking programs
>were 64 bit safe, among other things.
I would like to read more about this.
Do you have a URL or reference? Google had nothing to say.
From: Paul F. Dietz
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D3354CE.454E0024@dls.net>
sv0f wrote:
>
> In article <·················@dls.net>, "Paul F. Dietz" <·····@dls.net> wrote:
>
> >Microsoft has at least one similar system (written in Scheme,
> >I think). I heard they were using it for checking programs
> >were 64 bit safe, among other things.
>
> I would like to read more about this.
>
> Do you have a URL or reference? Google had nothing to say.
Sorry, it was in Prolog, not Scheme. I think it was the one
called 'PREfix'. PREfix reportedly found 'thousands' of problems
in the Windows 95 code.
Interesting fact found while searching for that: Microsoft products
often contain assert statements instrumented to send a bug report
to the company when they fail. They are getting close to 1 million
such reports *a day*.
Paul
Paul F. Dietz:
>> Do you have a URL or reference? Google had nothing to say.
> Sorry, it was in Prolog, not Scheme. I think it was the one
> called 'PREfix'. PREfix reportedly found 'thousands' of problems
> in the Windows 95 code.
i know one instance of such work from microsoft i made reference to in
another post: it is called astlog, which is a special variant of prolog
as an extension to a C/C++ compiler.
http://citeseer.nj.nec.com/crew97astlog.html.
oz
---
a nought, an ought, a knot, a not easily perceived distinction. -- t. duff
"Paul F. Dietz" wrote:
>
> Sorry, it was in Prolog, not Scheme. I think it was the one
> called 'PREfix'. PREfix reportedly found 'thousands' of problems
> in the Windows 95 code.
No bignum support, then?
> I sometimes think that if gcc were being reimplemented today from
> scratch, they'd decide to do it in Lisp. When gcc was started lisp
> was arguably too heavyweight and slow, and the GPLed lisp (kcl/akcl/gcl)
> wasn't very good.
>
Er. GCC internally uses a fiarly Lisp-like language called RTL to
represent programs is is compiling. That's why it's one compiler backend
with multiple frontends - all the languages are transformed into RTL, which
is then compiled.
Richard Stallman was a Lisper too, ya know.
http://gcc.gnu.org/onlinedocs/gccint/RTL.html
--
Don't eat yellow snow.
From: Paul F. Dietz
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D321BA4.C531C030@dls.net>
David Golden wrote:
> Er. GCC internally uses a fiarly Lisp-like language called RTL to
> represent programs is is compiling.
RTL is a *data representation* language, not something the
compiler executes. The compiler's code itself is written
in C.
Paul
"Paul F. Dietz"
> Engler's group has been working recently on using their system to check
> properties of C programs. Their system, CHECKER, has found many bugs
> in the Linux kernel. I think this kind of program checker is a better
> target for implementation in Lisp than a full-blown C compiler would be
> at this time.
if you are going to give up on a compiler written in lisp, you are looking
at interfacing with whatever gunk the compiler in question (let's say GCC for
argument's sake) uses internally for representing the program in the abstract,
and the power one would have obtained from a lisp-only implementation is
diminished. now, one would have to consider (say) attaching CMUCL to GCC.:)
an elephantine undertaking to be sure, but presumably not beyond a few
grad students and some supportive faculty, or some of the more excited
posters that frequent C.L.L...
oz
---
you take a banana, you get a lunar landscape. -- j. van wijk
From: Paul F. Dietz
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D3409EA.2CBD6883@dls.net>
"ozan s. yigit" wrote:
> if you are going to give up on a compiler written in lisp, you are looking
> at interfacing with whatever gunk the compiler in question (let's say GCC for
> argument's sake) uses internally for representing the program in the abstract,
> and the power one would have obtained from a lisp-only implementation is
> diminished.
I fail to follow the logic in this argument. If one is not implementing
a full compiler, one can still implement that more limited program entirely
in Lisp. Why should interfacing to any part of gcc (say) be necessary?
Paul
Paul F. Dietz:
> ... If one is not implementing
> a full compiler, one can still implement that more limited program entirely
> in Lisp. Why should interfacing to any part of gcc (say) be necessary?
the current work i referenced tends to be in the form of sometimes domain-
specific extensions to an existing compiler, and since kaz was playing up
the glory of structuring a compiler with lisp, the conversation went in that
direction. there are other ways, but some (like lint, splint) may be almost
as much work as writing a full compiler (original lint was in fact built out
of pcc parts :). you may be thinking of dump&grind approach (dump compiler's
internal representation of a program in some form and analyse) which a
friend of mine did using gcc&perl and that seems to work. [though such
analysers would probably suffer the same costly neglect lint has -
discipline in programming is in very short supply.]
oz
--
the most underused tool in the kitchen is the brain. -- alton brown
Sorry I am late...
Did anybody say
"Data = Programs"
yet?
gordo
From: Tim Josling
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D3331F5.1197A97A@melbpc.org.au>
"Paul F. Dietz" wrote:
> I sometimes think that if gcc were being reimplemented today from
> scratch, they'd decide to do it in Lisp. When gcc was started lisp
> was arguably too heavyweight and slow, and the GPLed lisp (kcl/akcl/gcl)
> wasn't very good.
Richard Stallman modelled GCC internals on lisp in many ways (compile a C
program with option -da and have a look at the dumps of the internal
structures for example).
But a bootstrap still takes 98 minutes on a PIII 1ghz machine, and I think
lisp would still be too slow.
Tim Josling
From: Basile STARYNKEVITCH
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <q5rfzyjlxbp.fsf@hector.lesours>
>>>>> "Tim" == Tim Josling <···@melbpc.org.au> writes:
Tim> "Paul F. Dietz" wrote:
Paul> I sometimes think that if gcc were being reimplemented today
Paul> from scratch, they'd decide to do it in Lisp. When gcc was
Paul> started lisp was arguably too heavyweight and slow, and the
Paul> GPLed lisp (kcl/akcl/gcl) wasn't very good.
Tim> Richard Stallman modelled GCC internals on lisp in many ways
Tim> (compile a C program with option -da and have a look at the
Tim> dumps of the internal structures for example).
For what it's worth, the Quick C-- compiler is implemented in Ocaml.
C-- is an intermediate language, aiming to supplement C as compiler
targets, with better support of garbage collection and tail
recursion. C-- is therefore a portable assembly language.
Ocaml is a functional language with static typing (and type
inference); it has also object oriented features (classes, multiple
inheritance).
See http://www.cminusminus.org/ and http://www.ocaml.org/ for details
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Fa�encerie, 92340 Bourg La Reine, France
From: Christopher C. Stacy
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <ur8i6hpis.fsf@grant.org>
>>>>> On 13 Jul 2002 20:11:39 -0700, ozan s yigit ("ozan") writes:
ozan> Kaz Kylheku:
>> A good example would be the problem of developing a C++ compiler.
>> In Lisp, this would reduce to the problem of parsing the ugly, tortuous
>> grammar of C++ to produce some suitable Lisp data structure. Having that
>> structure, expressing the rest of the translation would be quite easy compared
>> to doing the same thing in C++. Walking trees, transforming trees, matching
>> patterns over trees: things like that can be neatly written in Lisp that is
>> actually human readable.
ozan> yet, no production-quality compilers in daily use exist for any
ozan> language other than lisp written in lisp.
Symbolics had very good compilers for FORTRAN, ADA, PASCAL, C, PROLOG,
MACSYMA, and probably some others I have forgotten. (Not in daily use
since Symbolics went away, of course.) Some of those compilers and
their development environments were the best in the world at the time.
Maybe someday, progress will catch back up to 1986.
······@grant.org (Christopher C. Stacy) writes:
> ozan> yet, no production-quality compilers in daily use exist for any
> ozan> language other than lisp written in lisp.
> Symbolics had very good compilers for FORTRAN, ADA, PASCAL, C, PROLOG,
> MACSYMA, and probably some others I have forgotten.
was there a fortran and a C compiler in LMI's suite as well? i recall
looking for it in a lambda when i had one for a while in the department,
back in the eighties, but i don't remember if i found it. in any case,
who has the IP rights to old symbolics code? any of that still around
and can be open-sourced?
> Maybe someday, progress will catch back up to 1986.
it is hard to compare across decades, but i think it is very, very hard
to catch up with the kind of work (especially in optimization) that goes
into gcc or solaris compiler suites. on the other hand, these are boring
compilers that just generate fast code. dawson engler et al. [and others
like holzmann, corbett (bandera), crew (astlog)] have extended compilers
that can do very important checks, which is where compilers written in
lisp may be invaluable. too bad i cannot even get something as simple
as lcc equivalent in lisp to do research with...
oz
--
putting your fingers in your ears and humming does not constitute
a viable solution to an enduring problem. - rob pike
"ozan s yigit" <··@blue.cs.yorku.ca> wrote in message ····················@blue.cs.yorku.ca...
> ······@grant.org (Christopher C. Stacy) writes:
>
> > ozan> yet, no production-quality compilers in daily use exist for any
> > ozan> language other than lisp written in lisp.
>
> > Symbolics had very good compilers for FORTRAN, ADA, PASCAL, C, PROLOG,
> > MACSYMA, and probably some others I have forgotten.
>
> was there a fortran and a C compiler in LMI's suite as well?
Not one that I recall. If there was, it wasn't actively maintained.
(I was at LMI in 1986)
> in any case, who has the IP rights to old symbolics code?
The Massachusetts Institute of Technology has the rights to
the basic lisp machine. Symbolics Technology, Inc. has the
rights to the stuff Symbolics developed.
> any of that still around and can be open-sourced?
You can ask, but don't hold your breath.
ozan s yigit <··@blue.cs.yorku.ca> writes:
> was there a fortran and a C compiler in LMI's suite as well?
Well, Zeta-C may have run on the Lambda, but that doesn't count.
From: Hannah Schroeter
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <agrp55$9tb$1@c3po.schlund.de>
Hello!
In article <·············@grant.org>,
Christopher C. Stacy <······@grant.org> wrote:
>[...]
>Symbolics had very good compilers for FORTRAN, ADA, PASCAL, C, PROLOG,
>MACSYMA, and probably some others I have forgotten. (Not in daily use
>since Symbolics went away, of course.) Some of those compilers and
>their development environments were the best in the world at the time.
>Maybe someday, progress will catch back up to 1986.
Maybe it'd be nice to somehow have them available to the public,
be it by porting them to other CL systems and releasing them
commercially, maybe by open source releases (if they don't gain
any commercial revenue out of their code, it perhaps wouldn't
damage them [any more]).
Kind regards,
Hannah.
From: Tim Josling
Subject: Re: Specific advantages using Lisp, especially for AI
Date:
Message-ID: <3D309A13.ED14CDE9@melbpc.org.au>
Kaz Kylheku wrote:
> A good example would be the problem of developing a C++ compiler.
>
> In Lisp, this would reduce to the problem of parsing the ugly, tortuous
> grammar of C++ to produce some suitable Lisp data structure. Having that
> structure, expressing the rest of the translation would be quite easy compared
> to doing the same thing in C++. Walking trees, transforming trees, matching
> patterns over trees: things like that can be neatly written in Lisp that is
> actually human readable.
>
> Moreover, the resulting compiler would be free of problems such as crashed due
> to bad pointers or memory leaks. It would be easier to maintain and therefore
> easier to optimize.
>
> People who write compilers in C and C++ often end up cheating; knowing that a
> compiler's run time is short-lived, they don't bother freeing dynamically
> allocated objects. That approach will fail as soon as the compiler is embedded
> into another program, from which it can be invoked repeatedly.
>
> > Given that I only know the C++ basics, and have yet to learn about the
> > STL, macros, and plenty of other stuff, I would probably be better off
> > learning Lisp.
>
> You will find that the features in one area of C++ are a workaround for
> problems in some other area. When you cancel the features with their
> workarounds, you are left with nothing much that is actually
> intended for solving real problems that are not caused by the language
> in the first place.
>
It's interesting that the GCC compiler has recently implemented garbage
collection, and a lot of work is still going on to get it right (for example
automatic generation of GC routines from structure definitions). This is
consistent with the adage that any sufficiently large software system not
written in lisp will end up re-implementing significant parts of lisp.
Tim Josling
Kaz Kylheku wrote:
> But as it is, C++ provides no access to the program. Or rather, the only
> representation that can be manipulated by the programmer is the C++
> preprocessor token sequence. This level of representation is not far
> above raw text; it does not capture the nested structure of the program in any
> way.
That isn't really true. Templates work at a higher level than
tokens, and allow you to do many hairy things. (A lot of those
hairy things are either trivial or unnecessary in CL, to be
sure.)
> Moreover, the language for manipulating tokens is very poor. Its power
> is limited to: selecting portions of the program for translation based on the
> results of constant expressions involving only integer operands; naming
> headers and files for inclusion into the translation unit; substituting
> tokens into replacement sequences (macro expansion); turning groups of tokens
> into string literals; and catenating adjacent tokens.
Again, templates go way beyond this.
> In Lisp, this would reduce to the problem of parsing the ugly, tortuous
> grammar of C++ to produce some suitable Lisp data structure. Having that
> structure, expressing the rest of the translation would be quite easy compared
> to doing the same thing in C++. Walking trees, transforming trees, matching
> patterns over trees: things like that can be neatly written in Lisp that is
> actually human readable.
I'm sure it's easier to write a good compiler in CL than in C++
(assuming a similar level of expertise in the two languages),
but I think you exaggerate how easy it is to generate good
code once you have a friendly representation of the source.
Writing a really good compiler is difficult even in CL.
> People who write compilers in C and C++ often end up cheating; knowing that a
> compiler's run time is short-lived, they don't bother freeing dynamically
> allocated objects. That approach will fail as soon as the compiler is embedded
> into another program, from which it can be invoked repeatedly.
It's not much work -- especially in comparison with the work of
writing the compiler in the first place -- to arrange for it to
call memory management functions that allocate and deallocate
in a separate arena, which can be freed en bloc when the compiler
is finished.
> You will find that the features in one area of C++ are a workaround for
> problems in some other area. When you cancel the features with their
> workarounds, you are left with nothing much that is actually
> intended for solving real problems that are not caused by the language
> in the first place.
How true that is. :-)
> Templates are a workaround for static typing, which requires that
> a piece of code must know everything about the low level representation
> of a type in order to do any work with it, even to accept arguments
> of that type or pass values of that type to lower level functions.
It's probably true (I don't know for sure) that that was the
original motivation for templates. They can, however, do a great
deal more than working around static typing. Admittedly, most
of those things *are* an order of magnitude easier in a dynamically
typed language. :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) writes:
> Kaz Kylheku wrote:
> > ...
> > Templates are a workaround for static typing, which requires that
> > a piece of code must know everything about the low level representation
> > of a type in order to do any work with it, even to accept arguments
> > of that type or pass values of that type to lower level functions.
>
> It's probably true (I don't know for sure) that that was the
> original motivation for templates. They can, however, do a great
> deal more than working around static typing. Admittedly, most
> of those things *are* an order of magnitude easier in a dynamically
> typed language. :-)
What I would find interesting would be a MOP extension which uses
definitions for certain types/classes of parameters as template and
instantiates the method for all combinations of subtypes/subclasses
automatically. The compiler then could generate fast code for this
method because it knows the exact types of the parameters.
Does anyone know of work in that direction?
Nicolas.