Per this earlier thread:
http://groups.google.com.ua/group/comp.lang.lisp/browse_thread/thread/0d153c516b0ee506
it was stated that a certain function could not be defined because it
is a built-in function in common-lisp.
I am having the same issue. I want to define floor within my own
package, but am getting
Lock on package COMMON-LISP violated when setting fdefinition of
FLOOR.
but to my mind, if I define the floor function within my package, why
should it conflict?
(in-package :redick)
(defconstant floor-rank 0
"The floor verb operates on atoms, so its default rank is 0" )
(defun floor-core (num)
"Given a number, get its floor"
(cl:floor num))
(defun floor (noun)
"Apply floor-core to NOUN considering floor-rank"
(monad-apply #'floor-core noun floor-rank))
On 2007-12-12 21:45:11 -0500, "metaperl.com" <········@gmail.com> said:
> but to my mind, if I define the floor function within my package, why
> should it conflict?
You need to shadow floor:
<http://www.lisp.org/HyperSpec/Body/fun_shadow.html>
or in your package definition:
<http://www.lisp.org/HyperSpec/Body/mac_defpackage.html>
? (defun floor () (print "not the ceiling, duh!"))
> Error: The function FLOOR is predefined in OpenMCL.
> While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process Listener(182).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Replace the definition of FLOOR.
> Type :? for other options.
1> :pop
? (defpackage "MESS-WITH-CL-SYMBOLS" (:nicknames "MESS") (:use
"COMMON-LISP") (:shadow "FLOOR"))
#<Package "MESS-WITH-CL-SYMBOLS">
? (in-package :mess)
#<Package "MESS-WITH-CL-SYMBOLS">
? (defun floor () (print "not the ceiling, duh!"))
FLOOR
? (floor)
"not the ceiling, duh!"
"not the ceiling, duh!"
?
From: Kent M Pitman
Subject: Re: Lisp built in functions and packages
Date:
Message-ID: <uhcinuquu.fsf@nhplace.com>
"metaperl.com" <········@gmail.com> writes:
> but to my mind, if I define the floor function within my package, why
> should it conflict?
Symbols are used as identifiers in a package. They are not themselves
variables, but they name global variables and functions. When you get
a package, you inherit (meaning you have a pointer to) those
identifiers that come from CL. When you (re)define inherited symbols,
the redefinition is shared. It does not create a new symbol, it just
does something to that shared symbol.
I'm guessing you're imagining a world in which the CL set of names has
new cells created that are initialized as copies from the CL package
itself, or you're imagining that global variables are stored in a
newly allocated table that is per-package. But that's not right.
If it helps, think of this: You are never really "in" a package. All
you're ever in is the state that *package* instantaneously has a value
and any operations on packages that happen at that instant without
naming a package will use that value. But the compiler doesn't
compile into some global lexical environment in the sense that it
creates a lexical environment when it compiles a form. Globally,
there is no object that represents an environment that you are
coherently in or not in. Consider the value of program1 after you do:
(setq program1 '(defun foo (x) (+ x y)))
If you do (compile nil program1), you won't get any different behavior
than if you do (let ((*package* (MAKE-package "BLAHBLAH"))) (compile
nil program1)). The latter form will not cause the compilation to go
into some BLAHBLAH package because it occurs after all forms have been
read. There is no more interning. There are only the global pointers to
symbols. And what makes DEFUN be that symbol and not some symbol you made
up is not its name, but its very identity in the CL package. Likewise,
if you redefine FLOOR, you're redefining the symbol in the CL package whether
or not the current package is anything in particular.
Does this help or just make it more confusing?
metaperl.com wrote:
> Per this earlier thread:
>
http://groups.google.com.ua/group/comp.lang.lisp/browse_thread/thread/0d153c516b0ee506
>
> it was stated that a certain function could not be defined because it
> is a built-in function in common-lisp.
>
> I am having the same issue. I want to define floor within my own
> package, but am getting
> Lock on package COMMON-LISP violated when setting fdefinition of
> FLOOR.
>
> but to my mind, if I define the floor function within my package, why
> should it conflict?
>
> (in-package :redick)
>
Er. the defpackage form you used to create redick would be informative.
Lisp packages organise symbols themselves. Confusing, because many
modern module/package systems work rather differently - when
you "import blah" in many languages, you're importing what blah is
bound to, and then rebinding it (possibly to a similar-looking but
distinct name "blah" unless you do "import blah as bloo"). In lisp,
the symbol object itself is what is imported (and it's bound to
whatever it's bound to) You can develop pretty much all of a "modern"
module system in lisp, but none have really caught on- packages
are "good enough" and what are conventional, even if kind of odd. Just
remember packages organise the symbols themselves, and work out the
consequences from that.
Try:
; some people don't like using keyword symbols as string designators
; in package forms. But meh, means less uppercase.
(defpackage :redick
(:use :common-lisp)
(:shadow :floor))
(in-package :redick)
(defun floor ()
:dummy)
On Dec 12, 10:15 pm, David Golden <············@oceanfree.net> wrote:
>
> Er. the defpackage form you used to create redick would be informative.
>
the defpackage is here in the main load.lsp of my program:
http://hg.metaperl.com/redick?f=bfb6548f1b98;file=lisp/load.lsp;style=gitweb
and the file with the floor function is here:
http://hg.metaperl.com/redick?f=c44398941095;file=lisp/monad/floor.lsp;style=gitweb
I tried to write floor-core using
(setf (fdefinition floor-core) #'cl:floor)
but that failed... I will revert to this more concise method after I
get this first problem fixed.
In article
<····································@e10g2000prf.googlegroups.com>,
"metaperl.com" <········@gmail.com> wrote:
> On Dec 12, 10:15 pm, David Golden <············@oceanfree.net> wrote:
>
> >
> > Er. the defpackage form you used to create redick would be informative.
> >
>
> the defpackage is here in the main load.lsp of my program:
> http://hg.metaperl.com/redick?f=bfb6548f1b98;file=lisp/load.lsp;style=gitweb
Symbols in Common Lisp are UPPER CASE by default.
See the result of (symbol-name 'cl:floor)
? (symbol-name 'cl:floor)
"FLOOR"
So, in DEFPACKAGE, EXPORT etc. you need to upcase those strings which
are symbol names.
>
> and the file with the floor function is here:
> http://hg.metaperl.com/redick?f=c44398941095;file=lisp/monad/floor.lsp;style=gitweb
>
> I tried to write floor-core using
> (setf (fdefinition floor-core) #'cl:floor)
>
> but that failed... I will revert to this more concise method after I
> get this first problem fixed.
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> wrote:
+---------------
| "metaperl.com" <········@gmail.com> wrote:
| > the defpackage is here in the main load.lsp of my program:
| > http://hg.metaperl.com/redick?f=bfb6548f1b98;file=lisp/load.lsp;style=gitweb
|
| Symbols in Common Lisp are UPPER CASE by default.
| See the result of (symbol-name 'cl:floor)
| ? (symbol-name 'cl:floor)
| "FLOOR"
| So, in DEFPACKAGE, EXPORT etc. you need to upcase those strings which
| are symbol names.
+---------------
Or use uninterned symbols, as a number of us lazy folks do... ;-}
(defpackage :redick
(:use :common-lisp)
(:shadow #:floor)
(:export #:double #:floor)
...[trimmed]...)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article
<····································@i12g2000prf.googlegroups.com>,
"metaperl.com" <········@gmail.com> wrote:
> Per this earlier thread:
> http://groups.google.com.ua/group/comp.lang.lisp/browse_thread/thread/0d153c516b0ee506
>
> it was stated that a certain function could not be defined because it
> is a built-in function in common-lisp.
>
> I am having the same issue. I want to define floor within my own
> package, but am getting
> Lock on package COMMON-LISP violated when setting fdefinition of
> FLOOR.
>
> but to my mind, if I define the floor function within my package, why
> should it conflict?
Because your package uses the COMMON-LISP package, maybe?
Show your DEFPACKAGE form.
Remember, when you don't have a :USE option, an implementation dependent
list of packages will be USED.
>
> (in-package :redick)
>
>
> (defconstant floor-rank 0
> "The floor verb operates on atoms, so its default rank is 0" )
>
> (defun floor-core (num)
> "Given a number, get its floor"
> (cl:floor num))
>
> (defun floor (noun)
> "Apply floor-core to NOUN considering floor-rank"
> (monad-apply #'floor-core noun floor-rank))
So, how is the package REDICK defined? Does it use COMMON-LISP.
Do a (describe (find-package "REDICK")) and see what is says.
If you want to have your own symbols with names that are already used in
the COMMON-LISP package you can
a) not import the COMMON-LISP package in your package
(and selectively import the symbols you want to use)
b) SHADOW symbols from packages that you use. You can import all
symbols, with the exception of the ones you shadow.
? (defpackage "FOO" (:use "COMMON-LISP") (:shadow "FLOOR"))
#<Package "FOO">
? (in-package "FOO")
#<Package "FOO">
? (describe 'floor)
Symbol: FLOOR
INTERNAL in package: #<Package "FOO">
Print name: "FLOOR"
Value: #<Unbound>
Function: #<Unbound>
Plist: NIL
? (describe 'cl:floor)
Symbol: COMMON-LISP:FLOOR
Function
EXTERNAL in package: #<Package "COMMON-LISP">
Print name: "FLOOR"
Value: #<Unbound>
Function: #<Compiled-function COMMON-LISP:FLOOR #x300040082F2F>
Arglist: (NUMBER &OPTIONAL CCL::DIVISOR)
Plist: NIL
? (defun floor () 'foo)
FLOOR
--
http://lispm.dyndns.org/
metaperl.com wrote:
> Per this earlier thread:
> http://groups.google.com.ua/group/comp.lang.lisp/browse_thread/thread/0d153c516b0ee506
>
> it was stated that a certain function could not be defined because it
> is a built-in function in common-lisp.
That your implementation prevents your from redefining bindings of
common-lisp package symbols, or symbols in other implementation
packages, is not required behavior. But it is a really good idea.
SFAIK I was the first implementor of package locking (in Allegro, about
two decades ago) which has since been copied by other implementations.
There have been a number of replies that concentrate on package
manipulation to avoid this error. i think these are misdirected, which
is particularly disconcerting because the most recent posting as of my
writing was from friend Kent P. During the X3J13 festivities Kent was
always eloquent that language definition was not solely about
expressivity, consistency, and power. He always maintained that it was
important that code be readable -- that operator syntax and naming be
such that a cl-literate programmer would know what the operator does
without recourse to idiosyncratic details of documentation. I agree
with Kent on this.
You want to define an operator the does "floor" with somewhat different
behavior than common-lisp:floor. This is fine, but why are you obsessed
with the need to define it on the name "floor". Any Common Lisp
programmer reading your code and seeing the unqualified name "floor"
will assume the behavior of common-lisp:floor.
i suggest you would be much better off defining your function as
something like "monad-floor" and using that function-naming symbol in
your calls. That's certainly what I would like to see if someday I have
to read your code.
Steven M. Haflich wrote:
>
> There have been a number of replies that concentrate on package
> manipulation to avoid this error. i think these are misdirected,
Well, guilty as charged there. :-(
I should have also noted that e.g. David Wallis' nlisp (cough
significant project overlap cough) uses a convention of prefixing its
array operations with "." to solve the clash. nlisp's array floor op
is called ".floor", it's array + ".+" and so on. Underneath, one-arg*
variants are called .foo1 and two arg .foo2 (exposed n-arg .foo
functions auto-reduce with the .foo2 version for n > 2).
* Beware that "monadic" and "dyadic" pretty much just mean one- and two-
arg in APL land. "monad" is used in a different context (from category
theory) in FP land (very often in haskell...), and the FP sense
is the sense than some lispers might be most used to.