From: William Deakin
Subject: Problems with Paradigms of AI Programming: symbol
Date:
Message-ID: <37CE5A08.C109DD26@pindar.com>
Having downloaded the code for PAIP, I was looking at the auxfns.lisp
file. When I load this file running acl 4.3 for spac R1 it barfs at a
number of points. In particular when the code tries to defun symbol.
Firstly, I would like to learn more about SYMBOL. Why can you not defun
it? I can see why this is a very bad idea in a confusing-naming kind of
way. And anyway this wasn't my idea in the first place :-) But if you
are daft enough, why can you not alter the value?
Secondly, I would like to get the relevant bits of the code to work. Is
there an ANSI cl version of the PAIP or PAIP-like code available for my
education and edification? In particular, any examples on the cannonical
mini-macsyma and natural-language processing systems would be gratefully
appreciated.
Best Regards,
:-) will
Will,
I can't help you about the later parts (mini-macsyma, etc.) since I
haven't gotten that far in the book myself, but the auxfns.lisp part
worked for me on ACL 5.0.1 personal on Linux after the following
modification near the top of the file:
(eval-when (eval compile load)
;; Make it ok to place a function definition on a built-in LISP symbol.
#+EXCL
(dolist (pkg '(excl common-lisp))
;; MEZ
;;(setf (package-lock-fdefinitions (find-package pkg)) nil))
(setf (package-definition-lock (find-package pkg)) nil))
.
.
. )
On Thu, 02 Sep 1999 12:05:44 +0100, William Deakin <·····@pindar.com> wrote:
> Having downloaded the code for PAIP, I was looking at the auxfns.lisp
> file. When I load this file running acl 4.3 for spac R1 it barfs at a
> number of points. In particular when the code tries to defun symbol.
>
> Firstly, I would like to learn more about SYMBOL. Why can you not defun
> it? I can see why this is a very bad idea in a confusing-naming kind of
> way. And anyway this wasn't my idea in the first place :-) But if you
> are daft enough, why can you not alter the value?
>
> Secondly, I would like to get the relevant bits of the code to work. Is
> there an ANSI cl version of the PAIP or PAIP-like code available for my
> education and edification? In particular, any examples on the cannonical
> mini-macsyma and natural-language processing systems would be gratefully
> appreciated.
Mike
--
Dr. Michael Zawrotny
Howard Hughes Medical Institute at UMBC
1000 Hilltop Circle | email: ········@hhmi.umbc.edu
Baltimore, MD 21250 | phone: (410) 455-6347
From: William Deakin
Subject: Re: Problems with Paradigms of AI Programming: symbol
Date:
Message-ID: <37CFAF73.B142066@pindar.com>
I've tried this and it works with Allegro 4.3 also. Thank you very much.
Best Regards,
:-) will
From: Barry Margolin
Subject: Re: Problems with Paradigms of AI Programming: symbol
Date:
Message-ID: <DKDz3.688$m84.20823@burlma1-snr2>
In article <·················@pindar.com>,
William Deakin <········@pindar.com> wrote:
>Having downloaded the code for PAIP, I was looking at the auxfns.lisp
>file. When I load this file running acl 4.3 for spac R1 it barfs at a
>number of points. In particular when the code tries to defun symbol.
>
>Firstly, I would like to learn more about SYMBOL. Why can you not defun
>it?
You're not allowed to define functions named with any of the symbols in the
COMMON-LISP package. This is because you would get a conflict if two
programs both did this and you tried to load them both into the same Lisp
image.
> I can see why this is a very bad idea in a confusing-naming kind of
>way. And anyway this wasn't my idea in the first place :-) But if you
>are daft enough, why can you not alter the value?
The standard just says that the consequences are undefined if you do this;
if you end up with the conflict described above, the standard doesn't say
what the result will be (in most cases, one of the programs will work
properly, while the other one won't, and the standard says that's OK). The
folks at Franz have apparently chosen to protect you from yourself by
signalling an error when you try to load a definition that could
potentially have a conflict like this.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: William Deakin
Subject: Re: Problems with Paradigms of AI Programming: symbol
Date:
Message-ID: <37CFB050.29DB0C39@pindar.com>
Barry Margolin wrote:
> The folks at Franz have apparently chosen to protect you from yourself by
> signalling an error when you try to load a definition that could potentially have
> a conflict like this.
Thank you for your help.
I loaded the code up using CMUCL and it carped but didn't barf like acl. From this
it seems that you can override the the definition using: (setf
(package-lock-fdefinitions (find-package pkg)) nil)) in cmucl.
I then tried the (setf (package-definition-lock (find-package pkg)) nil)), kindly
suggested by Mike Zawrotny, in Allegro. This also allow these definitions to be
overloaded.
I take it that these are 'additional features?' as I cannot find either of these
functions discussed in cltl2 or the Hyperspec.
Best Regards,
:-) will
From: Duane Rettig
Subject: Re: Problems with Paradigms of AI Programming: symbol
Date:
Message-ID: <4u2pcnilr.fsf@beta.franz.com>
William Deakin <·····@pindar.com> writes:
> Barry Margolin wrote:
>
> > The folks at Franz have apparently chosen to protect you from yourself by
> > signalling an error when you try to load a definition that could potentially have
> > a conflict like this.
>
> Thank you for your help.
>
> I loaded the code up using CMUCL and it carped but didn't barf like acl. From this
> it seems that you can override the the definition using: (setf
> (package-lock-fdefinitions (find-package pkg)) nil)) in cmucl.
> I then tried the (setf (package-definition-lock (find-package pkg)) nil)), kindly
> suggested by Mike Zawrotny, in Allegro. This also allow these definitions to be
> overloaded.
Please note that in Allegro CL the error is continuable, with a
restart that allows you to make the change anyway, so I wouldn't
consider it "barfing".
Also, if you know that particular definitions are going to be made on
symbols in a locked package, all this package-munging is not
necessary in Allegro CL; you can just wrap the problem definitions in
(excl:without-package-locks ...)
> I take it that these are 'additional features?' as I cannot find either of these
> functions discussed in cltl2 or the Hyperspec.
For each product, you should read its respective user manual. Neither CLtL2
nor the hyperspec constitute a user manual.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: William Deakin
Subject: Re: Problems with Paradigms of AI Programming: symbol
Date:
Message-ID: <37CFEB54.BBDD66F7@pindar.com>
Duane Rettig wrote:
> Please note that in Allegro CL the error is continuable, with a restart that allows you
> to make the change anyway, so I wouldn't consider it "barfing".
Please accept my humble appologies. I did not mean to imply any critism of Allegro CL.
Having looked at this further, the reasons for the "barf" were in fact nothing to do with
this problem. But to do with some rather stupid hacking that I had done two lines later.
> For each product, you should read its respective user manual. Neither CLtL2 nor the
> hyperspec constitute a user manual.
You are very polite. In similar circumstances I would have said RTFM. Thank you for your
patience.
Best Regards,
:-) will
* Duane Rettig wrote:
> Please note that in Allegro CL the error is continuable, with a
> restart that allows you to make the change anyway, so I wouldn't
> consider it "barfing".
But in any case, you *want* the system to tell you when you do things
to symbols in the CL package, if it's possible. Otherwise you end up
in some remote part of the code wondering why things are failing to
work in strange and mysterious ways which you have no easy way of
detecting, because #'CL:PRINT is now a different function than it used
to be.
--tim