Think I saw it in the separate 'demo2' files at the ftp site,
which isn't in the python1.0 release file.
> > Well, I've at times been a part of that community (I used to dabble
> > in Prolog implementations),
>
> No no no no no. _Real_ AI people wouldn't touch Prolog with a New Year's
> resolution <wink>.
Hmmm; nope, not gonna bite on that one [apart from saying our friends
across-the-pond may differ] :-)
> > and I would suggest that Python can be an excellent symbol-
> > processing language. ...
> > Python's already got most of what you need. For example,
> > we've got Lisp and Prolog lists/cons-cells as tuple-trees:
> >
> > (car, cdr) <<- cons(car, cdr), [car|cdr]
>
> But, Mark! An object of amrit@xvt.com's C-coded CELL type takes 40 bytes
> on the KSR system (exclusive of malloc overhead; this is a 64-bit
> machine, BTW), well over twice as large as an implementation of a native
> Lisp cons cell _should_ take here. And a 2-tuple takes 48 bytes (again
> exclusive of malloc overhead). Python will never compete with
> Lisp/Prolog on this _style_ of coding for that reason alone; Python is
> much happier with "big" operations on "big" data structures. Lisp and
> Prolog are already real good at what they do; Python needs its own niche.
Maybe. In most symbol processing programs I've seen (in Lisp
or <blush> Prolog), you really don't build huge lists anyhow--
you usually build and massage alot of relatively small lists, and
traverse/construct them recursively. Given that Python garbage
collects our 'cons-cell' equivalents asap anyhow, I'm not sure
the 'space' difference is a valid concern. You just won't normally
have many huge lists in core at the same time (if you did, you'd
be taxing the capabilities of _any_ symbol-processing language).
Absolutely-- Python won't compete with a heavily-optimized Lisp
system on list processing, possibly running on special-purpose
hardware. But there aren't alot of people "blessed" enough to
work in such an environment; and even those guys would have
trouble building an N-million node list...
Perhaps the most important measure of an AI language is how
dynamic and flexible it is. Python passes this test as well
as Lisp (IMHO). That's not to say that Python would ever compete
with a good Lisp performance-wise; but again, performance doesn't
always matter as much to AI hackers, as it does to others (since
most AI work is rediculously cpu-intensive anyhow).
Mark Lutz