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,
(DEFUN SIN (X)
"Number of sinners as a function of the number of preachers per square mile"
;;;;;;;;;;;;;;;
(+ 10 (/ 100 X)))
while the astrologist gets `curious' results.
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?
········@ziplip.com" wrote:
>
> 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,
>
> (DEFUN SIN (X)
> "Number of sinners as a function of the number of preachers per square mile"
> ;;;;;;;;;;;;;;;
> (+ 10 (/ 100 X)))
>
> while the astrologist gets `curious' results.
>
> 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?
If the symbol is the same in both packages, it must have been inherited
somehow. Don't do that. If the symbol is really CL:SIN then conforming
programs are not supposed to redefine it anyway.
Paul
·······@ziplip.com wrote:
> 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,
>
> (DEFUN SIN (X)
> "Number of sinners as a function of the number of preachers per square mile"
> ;;;;;;;;;;;;;;;
> (+ 10 (/ 100 X)))
>
> while the astrologist gets `curious' results.
>
> 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, you can - this is what packages have been designed for.
By default, a new package inherits all the symbols from the package
COMMON-LISP. You can change that behavior by making use of shadowing
declarations, or a combination of shadow, shadowing-import and unintern.
Please look up the details in the HyperSpec or CLtL2.
There is the conduits system by Tim Bradshaw that simplifies these
things. See http://www.tfeb.org/lisp/hax.html#CONDUITS for a description
and examples.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
>>>>> "mc" == ·······@ziplip com <·······@ziplip.com> writes:
mc> (DEFUN SIN (X)
mc> (+ 10 (/ 100 X)))
mc> Is this something that could have been prevented by defining
mc> packages in an unorthodox manner? Can you use a "subset of Lisp"
mc> without being dangerous to others?
the theologist should be using SHADOWING-IMPORT-FROM in order to use
his personal definition of sin. CLtS states that the consequences of
redefining symbols in the COMMON-LISP package are undefined (you can
interpret that as being a sin, if you like).
To protect you against unintentional redefinitions of this sort,
most Common Lisp implementations support the notion of locked
packages. Any attempt to change the meaning of a symbol in a locked
package will lead to a (probably continuable) error being signalled.
Here are sample interactions with a number of different
implementations:
,---- Allegro CL 6.2 --
| CL-USER(1): (defun sin (x) (* x 100))
| Error: Attempt to make a FUNCTION definition for the name SIN. This
| name is in the COMMON-LISP package and redefining it is a
| violation for portable programs. Replacing the current
| definition of #<Function SIN> may be dangerous. The package
| COMMON-LISP has PACKAGE-DEFINITION-LOCK set, which causes the
| system to signal this violation.
| [condition type: PACKAGE-LOCKED-ERROR]
| Restart actions (select using :continue):
| 0: Set the FUNCTION definition of the name SIN anyway.
| 1: Return to Top Level (an "abort" restart).
| 2: Abort entirely from this process.
`----
,---- CLISP 2.30 --
| [1]> (defun sin (x) (* x 100))
| ** - Continuable Error
| DEFUN/DEFMACRO(SIN): #<PACKAGE COMMON-LISP> is locked
| If you continue (by typing 'continue'): Ignore the lock and proceed
`----
,---- CMUCL from CVS --
| CL-USER> (defun sin (x) (* x 100))
| Attempt to modify the locked package COMMON-LISP, by redefining function sin
| [Condition of type lisp::package-locked-error]
| Restarts:
| 0: [continue ] Ignore the lock and continue
| 1: [unlock-package] Disable package's definition-lock then continue
| 2: [abort ] Return to Top-Level.
`----
,---- OpenMCL 0.13.6 --
| ? (defun sin (x) (* x 100))
| > Error: The function SIN is predefined in OpenMCL.
| > While executing: CCL::REDEFINE-KERNEL-FUNCTION
| > Type :GO to continue, :POP to abort.
| > If continued: Replace the definition of SIN.
| Type :? for other options.
`----
,---- Lispworks 4.2 --
| CL-USER 1 > (defun sin (x) (* x 100))
| 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
`----
The implementations don't provide the same level of protection /
irritation: some of them won't complain if you define a symbol macro
or a type on SIN, but others will. They also provide various mostly
incompatible ways of working around package locks:
CMUCL, Allegro CL: macro (WITHOUT-PACKAGE-LOCKS forms)
CLISP: macro (EXT:WITHOUT-PACKAGE-LOCK (package-list) forms)
OpenMCL: special variable CCL::*WARN-IF-REDEFINE-KERNEL*
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
In article <········································@ziplip.com>,
········@ziplip.com" <·······@ziplip.com> wrote:
>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,
[...]
>Is this something that could have been prevented by defining packages in an
>unorthodox manner?
The theologist should always use packages in an orthodox manner.
The astrologist is likely more comfortable in the shadows.