············@yahoo.com (Venkat) writes:
> how to lock symbols in a particular package?
> that means others should not be able to redefine ,assign new values.
Some implementations provide this capability, some don't. Please consult
your implementation's documentation, and, if that's not enough, the help
forum for that implementation.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
Rahul> ············@yahoo.com (Venkat) writes:
>> how to lock symbols in a particular package?
>> that means others should not be able to redefine ,assign new values.
Rahul> Some implementations provide this capability, some
Rahul> don't. Please consult your implementation's documentation,
Rahul> and, if that's not enough, the help forum for that
Rahul> implementation.
Which implementations have the feature that you can lock a symbol
so as to prevent assigning a new value to a variable that it names,
or replacing its function definition?
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
>
> Rahul> ············@yahoo.com (Venkat) writes:
> >> how to lock symbols in a particular package?
> >> that means others should not be able to redefine ,assign new values.
>
> Rahul> Some implementations provide this capability, some
> Rahul> don't. Please consult your implementation's documentation,
> Rahul> and, if that's not enough, the help forum for that
> Rahul> implementation.
>
> Which implementations have the feature that you can lock a symbol
> so as to prevent assigning a new value to a variable that it names,
> or replacing its function definition?
CLISP, ACL, and CMUCL (since May) all have package locks.
MCL and SBCL don't.
I think LW and OpenMCL don't.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
>>>>> On 30 Dec 2003 11:57:52 -0800, Thomas F Burdick ("Thomas") writes:
Thomas> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
>>
Rahul> ············@yahoo.com (Venkat) writes:
>> >> how to lock symbols in a particular package?
>> >> that means others should not be able to redefine ,assign new values.
>>
Rahul> Some implementations provide this capability, some
Rahul> don't. Please consult your implementation's documentation,
Rahul> and, if that's not enough, the help forum for that
Rahul> implementation.
>>
>> Which implementations have the feature that you can lock a symbol
>> so as to prevent assigning a new value to a variable that it names,
>> or replacing its function definition?
Thomas> CLISP, ACL, and CMUCL (since May) all have package locks.
The OP is asking for two features, and the features that
you refer to provide at most half of what he wants.
The features that you're talking about allow a package to be
"locked" so that an error will be signalled if you attempt to
modify the package (for example, by changing its export list).
But that's not what he was asking for.
Those locking features look like they probably do provide half
of what he was asking for: an error will be signalled if you try
to change a symbol's function definition in a locked package.
Lisp programmers are accustomed to the idea that anything in the
program (that is, any Lisp code linked into the entire system,
regardless of where it came from) can be changed, if desired.
But other folks may not be. So, to be clear: in the end, there's
nothing that prevents someone from intruding into your package.
The programmer can still get around all that "locking" by
enclosing his offending forms in a WITHOUT-PACKAGE-LOCK form.
He is also free to simply unlock any package by doing:
(SETF (PACKAGE-LOCK (FIND-PACKAGE "P")) NIL)
So what that's all about, really, is amplifying the internal/external
symbol distinction that's already in the language. It does not make
it so that "others" are "not able to redefine" anything. I can't guess
whether that actually matters to him, but the philosophy may be alien.
It would be possible for someone to implement a Lisp that strictly
did all of what he was asking for.
The second thing that the OP asked for was to prevent people from
"assigning a new value". The cited Lisp implementations don't seem
to have that feature at all.
I am also unaware of any implementation that provides the
closely related "sealing" features that I mentioned
(which the OP didn't ask for).
Also note that even symbols in the COMMON-LISP package,
the implementation of Lisp itself, are not required by the
language standard to be "locked" or protected. If the programmer
attempts to redefine them, the consequences are undefined.
Also, none of these locking features (either imagined, or implemented
as implementation-specific extensions) are part of the ANSI Common
Lisp language standard. (Lots of useful things are not.)
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 30 Dec 2003 11:57:52 -0800, Thomas F Burdick ("Thomas") writes:
>
> Thomas> ······@news.dtpq.com (Christopher C. Stacy) writes:
> >> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
> >>
> Rahul> ············@yahoo.com (Venkat) writes:
> >> >> how to lock symbols in a particular package?
> >> >> that means others should not be able to redefine ,assign new values.
> >>
> Rahul> Some implementations provide this capability, some
> Rahul> don't. Please consult your implementation's documentation,
> Rahul> and, if that's not enough, the help forum for that
> Rahul> implementation.
> >>
> >> Which implementations have the feature that you can lock a symbol
> >> so as to prevent assigning a new value to a variable that it names,
> >> or replacing its function definition?
>
> Thomas> CLISP, ACL, and CMUCL (since May) all have package locks.
>
> The OP is asking for two features, and the features that
> you refer to provide at most half of what he wants.
>
> The features that you're talking about allow a package to be
> "locked" so that an error will be signalled if you attempt to
> modify the package (for example, by changing its export list).
> But that's not what he was asking for.
>
> Those locking features look like they probably do provide half
> of what he was asking for: an error will be signalled if you try
> to change a symbol's function definition in a locked package.
I think that the distinction between function and value bindings
as "definitions" is probably due to the nature of the warnings
against redefinition in the CL spec (which you allude to below).
It is not undefined to assign a new value to a variable that is
not a constant, and so it seems ludicrous to define "redefinition"
to include reassignment of values.
Allegro CL defined package locking (i.e. locking against structural
changes in the language) and package definiton locking (locking
against definitional changes to symbols in the locked package,
e.g giving it new function, macro, class, or type definitions).
> Lisp programmers are accustomed to the idea that anything in the
> program (that is, any Lisp code linked into the entire system,
> regardless of where it came from) can be changed, if desired.
> But other folks may not be. So, to be clear: in the end, there's
> nothing that prevents someone from intruding into your package.
> The programmer can still get around all that "locking" by
> enclosing his offending forms in a WITHOUT-PACKAGE-LOCK form.
> He is also free to simply unlock any package by doing:
>
> (SETF (PACKAGE-LOCK (FIND-PACKAGE "P")) NIL)
>
> So what that's all about, really, is amplifying the internal/external
> symbol distinction that's already in the language. It does not make
> it so that "others" are "not able to redefine" anything. I can't guess
> whether that actually matters to him, but the philosophy may be alien.
> It would be possible for someone to implement a Lisp that strictly
> did all of what he was asking for.
>
> The second thing that the OP asked for was to prevent people from
> "assigning a new value". The cited Lisp implementations don't seem
> to have that feature at all.
And I view this lack of feature itself as a feature. It is the
same philosophy that causes CL not to have hidden names (i.e. a
symbol may not be exported, but it can still be accessed; just
qualify it with the package and two colons) and also why CLOS
doesn't define private slots (i.e. slot-value can be used rather
than an accessor). The whole point of CL is openness, and anyone
who wants it different is looking at the wrong language.
> I am also unaware of any implementation that provides the
> closely related "sealing" features that I mentioned
> (which the OP didn't ask for).
Right; I'd love to get the chance to do this, also.
> Also note that even symbols in the COMMON-LISP package,
> the implementation of Lisp itself, are not required by the
> language standard to be "locked" or protected. If the programmer
> attempts to redefine them, the consequences are undefined.
Openness, again. Supply rope and tree, stand out of the way...
> Also, none of these locking features (either imagined, or implemented
> as implementation-specific extensions) are part of the ANSI Common
> Lisp language standard. (Lots of useful things are not.)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Tue, 30 Dec 2003 16:28:42 -0800, Duane Rettig wrote:
>> The second thing that the OP asked for was to prevent people from
>> "assigning a new value". The cited Lisp implementations don't seem
>> to have that feature at all.
>
> And I view this lack of feature itself as a feature. It is the
> same philosophy that causes CL not to have hidden names (i.e. a
> symbol may not be exported, but it can still be accessed; just
> qualify it with the package and two colons) and also why CLOS
> doesn't define private slots (i.e. slot-value can be used rather
> than an accessor). The whole point of CL is openness, and anyone
> who wants it different is looking at the wrong language.
Ability to redefine doesn't apply to the COMMON-LISP package. Is having
special rights for the standard library also a part of the CL philosophy? :-)
When functions definitions are mutable, especially if you are allowed to
bind first-class closures to globally visible names, it's hard to have
separate compilation together with efficient calling of functions. In
ISLISP function bindings are immutable.
>> Also note that even symbols in the COMMON-LISP package,
>> the implementation of Lisp itself, are not required by the
>> language standard to be "locked" or protected. If the programmer
>> attempts to redefine them, the consequences are undefined.
>
> Openness, again. Supply rope and tree, stand out of the way...
Undefined behavior means openness? Interesting...
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Ability to redefine doesn't apply to the COMMON-LISP package. Is having
> special rights for the standard library also a part of the CL philosophy? :-)
No, that's a restriction, which means that you can do less. A special
right would be to be able to do more.
Which is, btw, naturally the case for special operators. No matter how
meta-circular you can get in theory, in practice you have to have a base
somewhere that you can start from.
> Undefined behavior means openness? Interesting...
Yes, as per 1.6 "Language Extensions" of the HyperSpec:
"A language extension is any documented implementation-defined behavior
of a defined name in this standard that varies from the behavior
described in this standard, or a documented consequence of a situation
that the standard specifies as undefined, unspecified, or extendable by
the implementation."
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 30 Dec 2003 11:57:52 -0800, Thomas F Burdick ("Thomas") writes:
>
> Thomas> ······@news.dtpq.com (Christopher C. Stacy) writes:
> >> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
> >>
> Rahul> ············@yahoo.com (Venkat) writes:
> >> >> how to lock symbols in a particular package?
> >> >> that means others should not be able to redefine ,assign new values.
> >>
> Rahul> Some implementations provide this capability, some
> Rahul> don't. Please consult your implementation's documentation,
> Rahul> and, if that's not enough, the help forum for that
> Rahul> implementation.
> >>
> >> Which implementations have the feature that you can lock a symbol
> >> so as to prevent assigning a new value to a variable that it names,
> >> or replacing its function definition?
>
> Thomas> CLISP, ACL, and CMUCL (since May) all have package locks.
>
> The OP is asking for two features, and the features that
> you refer to provide at most half of what he wants.
I'm not sure, but I think they all provide continuable errors on
function or class redefinition. As for variables, I assumed (maybe
erroneously) that the OP just wanted constants, which we have in CL.
CMUCL and SBCL won't set or bind them. In fact, in CMUCL, you can
make a variable a constant using EXT:INFO, which might be exactly what
was desired. Eg:
(defvar *dont-bind* "constant value")
(defun call-with-bound-var (newval continuation)
(check-type *dont-bind* string) ; or whatever
(let ((*dont-bind* newval))
(funcall continuation)))
(compile 'call-with-bound-var)
(setf (ext:info variable kind '*dont-bind*) :constant)
Now, any attempts to set or bind *dont-bind* will fail, but
call-with-bound-var will still work:
(setf *dont-bind* "new value")
=> <error>
(let ((*dont-bind* "bound value")) ...)
=> <error>
(call-with-bound-var "bound value" (lambda () *dont-bind*))
=> "bound value"
(call-with-vound-var 0 ...)
=> <error>
> Lisp programmers are accustomed to the idea that anything in the
> program (that is, any Lisp code linked into the entire system,
> regardless of where it came from) can be changed, if desired.
> But other folks may not be. So, to be clear: in the end, there's
> nothing that prevents someone from intruding into your package.
Good point. The above CMUCL hackery could be used to prevent
accidental changes to *dont-bind*, but there's nothing to prevent me
from setting it back to a regular special variable, or unlocking a
package. Hell, I can even dig inside closures, if I want to. Nothing
in the Lisp image is hidden from a determined hacker (cue ominous music).
> The programmer can still get around all that "locking" by
> enclosing his offending forms in a WITHOUT-PACKAGE-LOCK form.
> He is also free to simply unlock any package by doing:
>
> (SETF (PACKAGE-LOCK (FIND-PACKAGE "P")) NIL)
>
> So what that's all about, really, is amplifying the internal/external
> symbol distinction that's already in the language. It does not make
> it so that "others" are "not able to redefine" anything. I can't guess
> whether that actually matters to him, but the philosophy may be alien.
> It would be possible for someone to implement a Lisp that strictly
> did all of what he was asking for.
It would probably be possible to modify an existing Lisp to do this.
Even then, a determined hacker could peek and poke at the appropriate
bits in memory.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
>
> Rahul> ············@yahoo.com (Venkat) writes:
> >> how to lock symbols in a particular package?
> >> that means others should not be able to redefine ,assign new values.
>
> Rahul> Some implementations provide this capability, some
> Rahul> don't. Please consult your implementation's documentation,
> Rahul> and, if that's not enough, the help forum for that
> Rahul> implementation.
>
> Which implementations have the feature that you can lock a symbol
> so as to prevent assigning a new value to a variable that it names,
> or replacing its function definition?
Incidentally, unless I'm misremembering, the term "package locking" was
created on the Lisp Machines first and did not mean "locking the value
or function cell", but rather "telling the package that new symbols
couldn't be added or removed". Even that, oddly enough, was technically
a nonconformance since it would inhibit CL-defined functions from working
right.
Package locking is important, though, because some people don't
realize how irritatingly awful it is once you've released a package
with a known set of symbols and then you later re-release the package
with changes to the set of exported symbols. Package locks make you
have to really stop and think before changing a package interface,
since most of the times you really shouldn't do it--that is, you never
should have released the package in the first place until you were
pretty sure that future changes would not be needed. The minor pain the
developer endures in dealing with these locks helps foreshadow
the major pain that users will inflict on them if changes end up
being made...
I don't know what symbol locking is, but it sounds even more
ill-defined and non-conforming. A symbol is really just an identity
useful as a key. Functions and values are explicitly NOT slots in
symbols. It is a permissible implementation to do something like
the following (UNTESTED--just sketching aloud):
(defvar *unbound* '(*unbound*))
(defun symbol-value-cell (symbol-name)
(or (gethash symbol-name *symbol-value-cells*)
(setf (gethash symbol-name *symbol-value-cells*)
(cons symbol-name *unbound*))))
(defun cell-ref (value-cell &optional (error-type 'cell-error))
(let ((value (cdr value-cell)))
(if (eq value *unbound*)
(error error-type :name (car value-cell))
value)))
(defun (setf cell-ref) (new value-cell)
(setf (cdr value-cell) new))
(defun symbol-value (symbol)
(cell-ref (symbol-value-cell symbol) 'unbound-variable))
(define-compiler-macro symbol-value (&whole form arg-form)
(cond ((constantp arg-form)
`(cell-ref (load-time-value (symbol-value-cell ',(eval arg-form)))
'unbound-variable))
(t form)))
(defun (setf symbol-value) (new-value symbol)
(setf (cell-ref (symbol-value-cell symbol))))
So the question is just exactly what is being locked when you are locking
"the symbol"?
Were I going to be an implementation with this idea, I might want to call
it "lock-symbol-value" or "lock-symbol-function" or just "lock-value-cell".
I should probably jump in here, being the person who actually first
added `package-locking' to Allegro.
As has been realized on this thread, package locking has two facets.
One is the structure of the package -- its contents and exports.
etc. The other is the various definitions bound to its symbols.
The ANS provides some justification for both facets. See in the
packages chapter the various restrictions placed on implementations
and applications against placing definitions upon symbols in the
standardized packages. The common-lisp package was one of very few
(about 4?) standardized packages, but the notion that a package needs
protection against subsequent modification by other authors. I was
impractical to codify this in the standard (more below) but it would
be better if a comprehensive mechanism could have been acomplished.
The immediate motivation for package locking came about around 1991
or so, when the Allegro implementation of streams changed from an
opaque builtin object class to a standard-class. One of the standard
cliches in basic programming examples is to define a "class" and an
"instance". Innocent beginners, and many not-so-innocent gurus, were
prone to execute code like:
(defstruct instance ...)
Now, it isn't obvious until one thinks about it critically that
defstruct does filthy name concatenation, creating new symbols out
of naming noise. ("Filthy" is a synonym for "nonhygienetic" but
with implication of excessive sliminess.) Some of X3J13 were
actually in favor of name concatenation for setf functions (as an
alternative to the adopted list syntax) but fortunately they did not
prevail. But defstruct was too entrenched to be changed.
Somwe reader will by now have realized that (defstruct instance ...)
causes make-instance to be redefined. A baaaad thing to do, but as
especially baaaaad thing to do in an implementation that needs
make-instance to create a stream with which to report an error...
Souvenir du chat Schroedinger. (Everyone ponders whether this cat
is alive or dead, but no one wonders about its sex, which has
equal uncertainty, therefore whether the poor beast should be
addressed as "chat" or "chatte".)
Therefore it was merely a convenience (perhaps more to product
support than to users) to warn when package definition violations
were committed. It catches application programmer violations of
ANS. I believe locking against definitinal changes is an important
aid to modularity and system integration, and should be codified in
the official language. (We explicitly recommended leaving Packages
in Chapter 11 of the ANS -- perhaps we should make whatever small
motions to correct thay bankruptcy.)
ANS Sections 11.1.2.1.1 and 11.1.2.1.2 respectively define the
limitations respectively on implementations and applications on
making definitions in the common-lisp package, but they don't go far
enough on at least two counts. Before I ennumerate them, understand
the premise that a CL `world' these days will have any number of
independently-written modules -- some not yet written -- which need
both to interact with the exported facilities of one another but not
clobber each other's definitions.
The language should define a standard mechanism whereby a package
(or module?) could be locked against inadvertent changes by
unrelated code. (Corollary: The package system is in chapter 11.)
The language should tighten the circumstances that qualify as a
modularity violation. In particular, X3J13 considered but gave up
on defining what should be allowed on defining symbol properties
with regard to symbol and indicator properties. The current ANS
only prohibits the _implementation_ from placing
potentially-promiscuous properties on symbols in the CL package.
The prohibition on symbol properties seems like it should be simple,
but nailing it down correctly was surprisingly difficult, and the
committee didn't want to codify something that was incorrect...
I think that symbols should be owned by implementation
packages/modules, and that definitions and bindnigs should be
allowed only by the module that `owns' the symbol. For the case
of properties, establishing a property should be permitted only
of one pf the symbol or indicator is owned by the module. But
this restriction is hard to reconcile with the terminology in the
current ANS. I'll be happy to rip to shreds anyone who thinks it
would be easy...
In practical terms, I'd like to note that locking of packages
against changes to export structure etc. has proven to be
unimportant. What is important is protection against accidental
(aka promiscuous) redefinition. These are the kinds of inadvertent
clashes that plague real applications.
By the way, Allegro generally checks for violations in defmumble
forms, but not in setf defmumble forms. defmumble forms usually
occur at compile and load times, not run times, while setf forms
occur at run time. The cost of checking package lock violations
at compile and/or load time is trivial, but the cost of checking
every silly store operation at run time wuold be unacceptable.
Fortunately, nearly all modularity violations are detectable in
practice at compile and/or load time.
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
>
> Rahul> ············@yahoo.com (Venkat) writes:
> >> how to lock symbols in a particular package?
> >> that means others should not be able to redefine ,assign new values.
>
> Rahul> Some implementations provide this capability, some
> Rahul> don't. Please consult your implementation's documentation,
> Rahul> and, if that's not enough, the help forum for that
> Rahul> implementation.
>
> Which implementations have the feature that you can lock a symbol
> so as to prevent assigning a new value to a variable that it names,
> or replacing its function definition?
As for function definitions, CMUCL qualifies (and its changelog
suggests that this feature is inspired by Allegro CL). Of course, it
doesn't really "prevent"; it still allows you to do all kinds of weird
things if you really want to, but makes their weirdness more obvious
than :: does.
| CL-USER> (defpackage :foo)
| #<The FOO package, 0/9 internal, 0/2 external>
| CL-USER> (defun foo::fun () :original)
| FOO::FUN
| CL-USER> (setf (package-definition-lock (find-package :foo)) t)
| T
| CL-USER> (defun foo::fun () :changed)
|
| Attempt to modify the locked package FOO, by redefining function FUN
| [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: [UNLOCK-ALL] Disable all package locks, then continue
| 3: [ABORT] Return to Top-Level.
|
You can still setq variables in locked packages, as far as I know.
In article <·············@news.dtpq.com>,
······@news.dtpq.com (Christopher C. Stacy) wrote:
> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
>
> Rahul> ············@yahoo.com (Venkat) writes:
> >> how to lock symbols in a particular package?
> >> that means others should not be able to redefine ,assign new values.
>
> Rahul> Some implementations provide this capability, some
> Rahul> don't. Please consult your implementation's documentation,
> Rahul> and, if that's not enough, the help forum for that
> Rahul> implementation.
>
> Which implementations have the feature that you can lock a symbol
> so as to prevent assigning a new value to a variable that it names,
> or replacing its function definition?
Symbolics Common Lisp has it. Locked symbols have an associated
pathname; if the symbol is redefined, an error is signalled unless it's
during loading of that file or while loading patches.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
>>>>> On Tue, 30 Dec 2003 21:48:58 GMT, Barry Margolin ("Barry") writes:
Barry> In article <·············@news.dtpq.com>,
Barry> ······@news.dtpq.com (Christopher C. Stacy) wrote:
>> >>>>> On Tue, 30 Dec 2003 02:46:40 -0500, Rahul Jain ("Rahul") writes:
>>
Rahul> ············@yahoo.com (Venkat) writes:
>> >> how to lock symbols in a particular package?
>> >> that means others should not be able to redefine ,assign new values.
>>
Rahul> Some implementations provide this capability, some
Rahul> don't. Please consult your implementation's documentation,
Rahul> and, if that's not enough, the help forum for that
Rahul> implementation.
>>
>> Which implementations have the feature that you can lock a symbol
>> so as to prevent assigning a new value to a variable that it names,
>> or replacing its function definition?
Barry> Symbolics Common Lisp has it. Locked symbols have an associated
Barry> pathname; if the symbol is redefined, an error is signalled unless it's
Barry> during loading of that file or while loading patches.
You're telling me that if someone does (SETQ FOO 69) where FOO
is one of these locked symbols, that an error is signalled?
(I don't remember any such feature; perhaps I just forgot, though?)
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Tue, 30 Dec 2003 21:48:58 GMT, Barry Margolin ("Barry") writes:
> Rahul> Some implementations provide this capability, some
> Rahul> don't. Please consult your implementation's documentation,
> Rahul> and, if that's not enough, the help forum for that
> Rahul> implementation.
> >>
> >> Which implementations have the feature that you can lock a symbol
> >> so as to prevent assigning a new value to a variable that it names,
> >> or replacing its function definition?
>
> Barry> Symbolics Common Lisp has it. Locked symbols have an associated
> Barry> pathname; if the symbol is redefined, an error is signalled unless it's
> Barry> during loading of that file or while loading patches.
>
> You're telling me that if someone does (SETQ FOO 69) where FOO
> is one of these locked symbols, that an error is signalled?
>
> (I don't remember any such feature; perhaps I just forgot, though?)
Not setq, but defun defun-itely. In Allegro CL:
CL-USER(1): (defpackage :foo)
#<The FOO package>
CL-USER(2): (defun foo::foobar (x) (1+ x))
FOO::FOOBAR
CL-USER(3): (foo::foobar 10)
11
CL-USER(4): (setf (excl:package-definition-lock (find-package :foo)) t)
T
CL-USER(5): (defun foo::foobar (x) (1- x))
Error: Attempt to make a FUNCTION definition for the name FOO::FOOBAR.
This name is in the FOO package and redefining it is a violation
for portable programs. Replacing the current definition of
#<Interpreted Function FOOBAR> may be dangerous. The package
FOO 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 FOO::FOOBAR anyway.
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this process.
[1c] CL-USER(6):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
>>>>> On 29 Dec 2003 22:04:11 -0800, Venkat ("Venkat") writes:
Venkat> how to lock symbols in a particular package? that means
Venkat> others should not be able to redefine ,assign new values.
Symbols are associated with "packages" and a fully-qualified symbol
name includes a package-name prefix. APIs are, at some level,
specified by "exporting" a symbol from a package, which makes the
symbol available for referencing by the syntax P:S.
For example, MY-APPLICATION:INITIALIZE.
Programmers may violate this abstraction freely by using
the syntax P::S, such as MY-SECRET-INTERNALS::INITIALIZE-PART-1.
References to symbols are unrestricted: new objects may be associated
with the symbol at any time, using forms such as SETQ, SYMBOL-VALUE,
SYMBOL-FUNCTION, etc. Also, new symbols may be constructed, and
packages manipulated, using forms such as INTERN and EXPORT.
Common Lisp does not have a way to "lock" a package that would
prevent such intrusions, hence no way to prevent someone from
redefining a symbol's functional or variable value, or from
inserting new symbols into the package, or importing symbols
(even though they were not exported by the donor package).
The "::" syntax is intended to be an aesthetically unpleasing marker
that clearly indicates that the programmer knows he is misbehaving.
Similarly, there is no way to "seal" a class so that new subclasses
can be derived from it, nor a way to prevent methods from being
overridden or new methods added.
All these things have worked out just fine in some very large systems
that included millions of lines of code, many unknown programmers,
and many years; but that doesn't necessarily mean that such locking
and sealing features wouldn't be worthwhile. But there hasn't been
much of a demand for them.
The Dylan language has a slightly different model of the relationship
between symbols and the language elements they denote, and it does
have sealing. This allows for certain compile-time optimizations.
············@yahoo.com (Venkat) writes:
> how to lock symbols in a particular package?
> that means others should not be able to redefine ,assign new values.
As explained, that's not a capability of the packages.
However you can define a symbol and _lock_ it, not inside a package,
but inside a closure:
[202]> (let ((sym (gensym)))
(set sym nil)
(defun get-value (password)
(if (string= password "secret")
(symbol-value sym)
(error "Bad password")))
(defun set-value (password value)
(if (string= password "secret")
(set sym value)
(error "Bad password"))))
SET-VALUE
[203]> (get-value "secret")
NIL
[204]> (set-value "secret" :forty-two)
:FORTY-TWO
[205]> (get-value "secret")
:FORTY-TWO
[206]>
Since the symbol is not interned, it can never be recovered and its
value slot (and its other slots) can only manipulated in controled
fashion by the closures defined inside the let.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/