(A more refined version)
Let's say a theologist and an astrologist, collaborating on the
same Lisp project, are working in Lisp packages "theos" and
"aster", respectively. Oblivious to trigonometry, the
theologist defines a function called SIN,
(make-package "theos" :use '(common-lisp))
(in-package "theos")
(defun sin(x)
"Number of sinners as a function of the number
of preachers per square mile"
(/ 666 X))
while the astrologist gets `curious' results:
(make-package "aster" :use '(common-lisp))
(in-package "aster")
(sin 3.14) => 212.1
Is this something that could have been prevented by defining
packages in an unorthodox manner? Can you use a "subset of
Lisp" without being dangerous to others?
P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
SHADOWING-IMPORT and UNINTERN would be useful. You probably
did not understand the problem: the theologist does not know
he is supposed to shadow SIN, he assumes SIN is his invention.
········@ziplip.com" <·······@ziplip.com> wrote in message news:<········································@ziplip.com>...
> P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
> SHADOWING-IMPORT and UNINTERN would be useful. You probably
> did not understand the problem: the theologist does not know
> he is supposed to shadow SIN, he assumes SIN is his invention.
That's the real issue. Why doesn't he know?
Because he's using a Common Lisp implementation
that doesn't warn him? The obvious way to fix
this problem is to fix that CL implementation
to make it warn him. Every time I ever made a
mistake like that, I was warned by whatever CL
implementation I happened to be using at the
time. Which specific CL implementations don't
warn about it?
In article <········································@ziplip.com>,
·······@ziplip.com <·······@ziplip.com> wrote:
>P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
>SHADOWING-IMPORT and UNINTERN would be useful. You probably
>did not understand the problem: the theologist does not know
>he is supposed to shadow SIN, he assumes SIN is his invention.
When you :USE a package, it's your responsibility to familiarize yourself
with the symbols that it exports.
However, to assist you in this, many Lisp implementations will warn you if
you try to redefine a function that was originally defined by the system or
in another source file.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, 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.
········@ziplip.com" <·······@ziplip.com> writes:
> P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
> SHADOWING-IMPORT and UNINTERN would be useful. You probably did not
> understand the problem: the theologist does not know he is supposed
> to shadow SIN, he assumes SIN is his invention.
On LispWorks:
CL-USER 6 > (defun sin (x)
(+ x 42))
Error: Redefining function SIN visible from package COMMON-LISP.
1 (continue) Redefine it anyway.
2 (abort) Return to level 0.
3 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 7 : 1 >
Check if your Lisp implementation has a similar feature.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
········@ziplip.com" <·······@ziplip.com> writes:
> P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
> SHADOWING-IMPORT and UNINTERN would be useful. You probably did not
> understand the problem: the theologist does not know he is supposed
> to shadow SIN, he assumes SIN is his invention.
So the real "mistake" was including (:use '(common-lisp)) in his
MAKE-PACKAGE expression package without a full knowledge of all of the
977 symbols exported by COMMON-LISP.
If the theologist really wanted to avoid the possibility of this kind
of problem without having to memorize all the symbols in COMMON-LISP
(assuming for the moment that he's using a Lisp implementation that
doesn't warn him about illegally redefining the functions named by
symbols in the COMMON-LISP package) he could not use the COMMON-LISP
package and do one of the following:
- Explicitly qualify all symbols from COMMON-LISP. Given the nickname
of CL that wouldn't be too horrendous but it's pretty annoying.
- Explicitly import only those symbols that he needs from COMMON-LISP
into his own package (THEOS).
- Create a new package or packages that each import and reexport a
subset of the symbols from COMMON-LISP and then USE-PACKAGE those
into THEOS. You could even imagine making a set of packages that each
provides a cohesive subset of symbols from COMMON-LISP (probably
divided along much the same lines as the chapters of the language
standard). Then he could use, for example,
"COMMON-LISP-DATA-AND-CONTROL-FLOW" and "COMMON-LISP-CONSES" but not
"COMMON-LISP-NUMBERS-TRIGONOMETRY" and get the symbols he probably
does need and not the ones he doesn't.
Of course all of these approaches would, by making it easy for the
theologist to create his own symbol SIN, would introduce a bit of pain
for the first programmer who wanted to combine use the THEOS package
*and* CL:SIN (assuming THEOS:SIN is exported.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
········@ziplip.com" <·······@ziplip.com> writes:
> Let's say a theologist and an astrologist, collaborating on the
> same Lisp project, are working in Lisp packages "theos" and
> "aster", respectively. Oblivious to trigonometry, the
> theologist defines a function called SIN,
>
> (make-package "theos" :use '(common-lisp))
> (in-package "theos")
>
> (defun sin(x)
> "Number of sinners as a function of the number
> of preachers per square mile"
> (/ 666 X))
That's illegal: you're redefining a symbol in the COMMON-LISP
package, and as soon as you do that the system is within its
rights to define it as asked, to leave it unchanged, to
redefine every other function in the system to return 666,
to crash, or to replace your CPU with a small piece of
Swiss cheese.
> while the astrologist gets `curious' results:
>
> (make-package "aster" :use '(common-lisp))
> (in-package "aster")
>
> (sin 3.14) => 212.1
>
> Is this something that could have been prevented by defining
> packages in an unorthodox manner? Can you use a "subset of
> Lisp" without being dangerous to others?
It could have been prevented by not redefining a symbol
from the COMMON-LISP package.
> P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
> SHADOWING-IMPORT and UNINTERN would be useful. You probably
> did not understand the problem: the theologist does not know
> he is supposed to shadow SIN, he assumes SIN is his invention.
If the theologian (which, btw, is the correct word; and
"astrologer") doesn't know that SIN is already defined,
and behaves as if it isn't, then bad consequences will
ensue.
Likewise, if he doesn't know that the effects of quoting
the Bible to his Lisp system instead of writing actual
Lisp code aren't defined to be good, he may be disappointed.
Your question seems to boil down to this: "If someone does
something that's explicitly forbidden by the language
definition, then it may not have the effect he intends.
Can you fix this without needing him to use the language
correctly?".
Allow me to quote from Charles Babbage.
| On two occasions, I have been asked [by members of Parliament],
| 'Pray, Mr. Babbage, if you put into the machine wrong figures,
| will the right answers come out?' I am not able to rightly
| apprehend the kind of confusion of ideas that could provoke
| such a question.
--
Gareth McCaughan
On Mon, 28 Jul 2003 09:57:58 -0700 (PDT), ········@ziplip.com"
<·······@ziplip.com> wrote:
> P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
> SHADOWING-IMPORT and UNINTERN would be useful. You probably
> did not understand the problem: the theologist does not know
> he is supposed to shadow SIN, he assumes SIN is his invention.
Then he is an idiot.
Common Lisp was designed for experienced computer professionals dealing
with complex and challenging problems, not for dummies. If the theologist
doesn't know about symbol shadowing, he should learn more Lisp or use a
simpler language.
Paolo
--
Paolo Amoroso <·······@mclink.it>
>>>>> "Paolo" == Paolo Amoroso <·······@mclink.it> writes:
Paolo> On Mon, 28 Jul 2003 09:57:58 -0700 (PDT), ········@ziplip.com"
Paolo> <·······@ziplip.com> wrote:
>> P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
>> SHADOWING-IMPORT and UNINTERN would be useful. You probably
>> did not understand the problem: the theologist does not know
>> he is supposed to shadow SIN, he assumes SIN is his invention.
Paolo> Then he is an idiot.
Paolo> Common Lisp was designed for experienced computer professionals dealing
Paolo> with complex and challenging problems, not for dummies. If the theologist
Paolo> doesn't know about symbol shadowing, he should learn more Lisp or use a
Paolo> simpler language.
Indeed. And suppose the theologist decides that Lisp sucks and C
would be better. What is he going to do when he wants a function
named float to see if angels can float?
If you're going to use a computer language, you have to learn about
the computer language. There's no way around it.
Ray
········@ziplip.com" <·······@ziplip.com> writes:
> (A more refined version)
>
> Let's say a theologist and an astrologist, collaborating on the
> same Lisp project, are working in Lisp packages "theos" and
> "aster", respectively. Oblivious to trigonometry, the
> theologist defines a function called SIN,
>
> (make-package "theos" :use '(common-lisp))
^^^^^^^^^^^^^^^^^^^
This, of course, it the source of your problem. If the erstwhile
Theologist doesn't want to have to know what symbols have function
definitions in the CL package, then he should not :USE that package.
There are two solutions for this. Option A is to not use any other
package and just package qualify those parts of Common Lisp that he
wants to use. Option B is to explicitly import the symbols that are
needed. I will also switch to DEFPACKAGE, since that is a slightly
nicer choice than MAKE-PACKAGE. I will also change the package name to
uppercase so that one will not need to use vertical bars around it.
A: (defpackage "THEOS" (:use))
B: (defpackage "THEOS" (:use)
(:import-from "COMMON-LISP" "DEFUN" "/" "IN-PACKAGE"))
> (in-package "theos")
>
> (defun sin(x)
> "Number of sinners as a function of the number
> of preachers per square mile"
> (/ 666 X))
A: (cl:defun sin(x)
"Number of sinners..."
(cl:/ 666 X))
B: (defun sin (x)
"Number of sinners..."
(/ 666 X))
> while the astrologist gets `curious' results:
>
> (make-package "aster" :use '(common-lisp))
> (in-package "aster")
>
> (sin 3.14) => 212.1
Fixed under both options.
> Is this something that could have been prevented by defining
> packages in an unorthodox manner? Can you use a "subset of
> Lisp" without being dangerous to others?
Yes. If you want to use a subset, you either need to explicitly
package-qualify those CL symbols you want to use each time you use them,
or you need to explicitly identify the subset of CL symbols you wish to
use and import them into your package.
In the latter case, if you want to develop multiple projects using the
same subset of CL, you can always create your own mini-lisp package that
just imports and exports the subset:
(defpackage "MINI-LISP" (:use)
(:import-from "COMMON-LISP" "DEFUN" "FIRST" "REST" "CONS" "IN-PACKAGE" "/" ....)
(:export "DEFUN" "FIRST" "REST" "CONS" "IN-PACKAGE" "/" ....))
(defpackage "THEOS" (:use "MINI-LISP"))
> P.S. Pascal, I do not think SHADOW, SHADOWING-IMPORT-FROM,
> SHADOWING-IMPORT and UNINTERN would be useful. You probably
> did not understand the problem: the theologist does not know
> he is supposed to shadow SIN, he assumes SIN is his invention.
The real problem is that :USE is a potentially very dangerous package
inclusion operator, especially if you :USE a package other than
COMMON-LISP. That is because the :USE package building option gives you
a dynamic import of the external symbols of the package you are using.
So that means that even if things once worked, the addition of a new
exported symbol to the package you are using can cause things to fail in
the future, without any changes to your code. That is why, although
convenient, some Lisp programmers advise not using :USE but instead
always explicitly importing the symbols of packages other than
COMMON-LISP.
Now, some Lisp implementations (MCL and ACL come to mind) will normally
detect an attempt to redefine a function whose name is in the CL package
and signal an error. (MCL will let you define a function on such a
symbol if it doesn't have one already. ACL also complains in this
case). This feature is present precisely to handle the situation of
inadvertently doing what the theologian does in this example.
--
Thomas A. Russ, USC/Information Sciences Institute