Hey everyone,
Packages have a mechanism for controlling access to symbols (export
and unexport). However, there seems to be no way to control the usage
of those symbols. Once you have access to a package's "foo" symbol,
you can use both the variable and the function named "foo".
So, is there any way to allow access to only the variable or the
function but not both?
The answer seems to be a trivial "no" as packages only control access
to symbols. In either case, I'd appreciate some feedback regarding
the below questions.
Do you view this to be a limitation of the Lisp package system?
Have you ever wanted to be able to control access in this way?
Is there another Lisp-like language that you think got packages right?
(or at least more right...)
Thanks a lot everyone.
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> Hey everyone,
>
> Packages have a mechanism for controlling access to symbols (export
> and unexport). However, there seems to be no way to control the usage
> of those symbols. Once you have access to a package's "foo" symbol,
> you can use both the variable and the function named "foo".
>
> So, is there any way to allow access to only the variable or the
> function but not both?
>
> The answer seems to be a trivial "no" as packages only control access
> to symbols. In either case, I'd appreciate some feedback regarding
> the below questions.
>
> Do you view this to be a limitation of the Lisp package system?
> Have you ever wanted to be able to control access in this way?
> Is there another Lisp-like language that you think got packages right?
> (or at least more right...)
Compile-time access control (if that is what you are thinking about)
is antithetical to dynamic typing. This is a fundamental point.
In Lisp, many consider comments to be sufficient expressions of what
is public vs. private vs. protected, to use C++ parlance.
--
John M. Adams
In article <····························@posting.google.com>,
Justin Dubs <······@eos.ncsu.edu> wrote:
>Hey everyone,
>
>Packages have a mechanism for controlling access to symbols (export
>and unexport). However, there seems to be no way to control the usage
>of those symbols. Once you have access to a package's "foo" symbol,
>you can use both the variable and the function named "foo".
>
>So, is there any way to allow access to only the variable or the
>function but not both?
No. The package system is not a module system.
>The answer seems to be a trivial "no" as packages only control access
>to symbols. In either case, I'd appreciate some feedback regarding
>the below questions.
>
>Do you view this to be a limitation of the Lisp package system?
Not a significant one. It's pretty rare that functions have the same names
as global variables, especially because of the *name* naming convention for
special variables.
Note that the package system doesn't even prevent you from using internal
symbols from another package. You can access anything using the ::
syntax. It's not like many languages' module systems, which implement
strict limits on what you can access from outside the module.
Lisp has never had a philosophy of putting the programmer in a
straightjacket. You have access to everything, and are trusted not to use
what you don't need.
--
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.
In article <···············@news.level3.com>, Barry Margolin
<··············@level3.com> wrote:
> In article <····························@posting.google.com>,
> Justin Dubs <······@eos.ncsu.edu> wrote:
> >Hey everyone,
> >
> >Packages have a mechanism for controlling access to symbols (export
> >and unexport). However, there seems to be no way to control the usage
> >of those symbols. Once you have access to a package's "foo" symbol,
> >you can use both the variable and the function named "foo".
> >
> >So, is there any way to allow access to only the variable or the
> >function but not both?
>
> No. The package system is not a module system.
If you want a module system it's not hard to write one. See
http://www.flownet.com/gat/locales.pdf for one way to do it.
E.
······@eos.ncsu.edu (Justin Dubs) writes:
> So, is there any way to allow access to only the variable or the
> function but not both?
If you name your variables with *'s around them and your functions
without that, this never comes up in practice.
Kent M Pitman <······@world.std.com> writes:
> ······@eos.ncsu.edu (Justin Dubs) writes:
>
>> So, is there any way to allow access to only the variable or the
>> function but not both?
>
> If you name your variables with *'s around them and your functions
> without that, this never comes up in practice.
What does come up in practice, though, is the name of a function and
the name of a slot, or of a condition type, or of a restart, or of a
type.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Joe Marshall
Subject: Re: the Common Lisp package system
Date:
Message-ID: <vfu9nr9t.fsf@ccs.neu.edu>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ······@eos.ncsu.edu (Justin Dubs) writes:
> >
> >> So, is there any way to allow access to only the variable or the
> >> function but not both?
> >
> > If you name your variables with *'s around them and your functions
> > without that, this never comes up in practice.
>
> What does come up in practice, though, is the name of a function and
> the name of a slot, or of a condition type, or of a restart, or of a
> type.
Maybe we should adopt `Hungarian notation'. Is Franz planning a
Post-Modern Lisp?
Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.jcn.srcf.net>...
> Kent M Pitman <······@world.std.com> writes:
>
> > ······@eos.ncsu.edu (Justin Dubs) writes:
> >
> >> So, is there any way to allow access to only the variable or the
> >> function but not both?
> >
> > If you name your variables with *'s around them and your functions
> > without that, this never comes up in practice.
>
> What does come up in practice, though, is the name of a function and
> the name of a slot, or of a condition type, or of a restart, or of a
> type.
>
So, what do you do when this kind of thing comes up in practice?
Do you just allow access to all of them even though that wasn't your
intention?
Do you force yourself to rename some of them to avoid it?
I'm glad that I'm not the only person who saw this as a drawback of
the current package system. Or, do you not see it as a drawback at
all?
Thanks for the responses everyone. Especially for the link to the
Locales pdf.
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.jcn.srcf.net>...
>
> > What does come up in practice, though, is the name of a function and
> > the name of a slot, or of a condition type, or of a restart, or of a
> > type.
>
> So, what do you do when this kind of thing comes up in practice?
In the unusual case that you want to export one but not the other,
I usually rename something.
> Do you just allow access to all of them even though that wasn't your
> intention?
I bet this sometimes happens. I personally rely more on advertised
interfaces than on undocumented ones. I don't call things just because
I find them exported.
> Do you force yourself to rename some of them to avoid it?
Usually. What do usually name loop counter variables? I usually call
them I. But I rename them when there is already an outer I that I
need, usually to J. Is this question fundamentally any different than
that one?
> I'm glad that I'm not the only person who saw this as a drawback of
> the current package system. Or, do you not see it as a drawback at
> all?
A drawback? That when a name is already in use you have to choose another?
The package system does not do what you think it does. It separates
symbols. It is not a module system. It happens to take on many roles
of module systems, but it is not part of the lexical fabric of the system.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> ······@eos.ncsu.edu (Justin Dubs) writes:
> > I'm glad that I'm not the only person who saw this as a drawback of
> > the current package system. Or, do you not see it as a drawback at
> > all?
>
> A drawback? That when a name is already in use you have to choose another?
That you have to choose another name, even though the two values will
reside in separate namespaces, just because you don't have control
over which namespaces you make visible to the outside world. That I
call a drawback, but, only because of ...
> The package system does not do what you think it does. It separates
> symbols. It is not a module system. It happens to take on many roles
> of module systems, but it is not part of the lexical fabric of the system.
... the fact that I am trying to make the package system do more then
it was intended to do. You are exactly correct and this was the point
that I needed hammered home. Thank you.
Thanks again for the help everyone.
Justin Dubs
In article <···························@posting.google.com>,
Justin Dubs <······@eos.ncsu.edu> wrote:
>Christophe Rhodes <·····@cam.ac.uk> wrote in message
>news:<··············@lambda.jcn.srcf.net>...
>> Kent M Pitman <······@world.std.com> writes:
>>
>> > ······@eos.ncsu.edu (Justin Dubs) writes:
>> >
>> >> So, is there any way to allow access to only the variable or the
>> >> function but not both?
>> >
>> > If you name your variables with *'s around them and your functions
>> > without that, this never comes up in practice.
>>
>> What does come up in practice, though, is the name of a function and
>> the name of a slot, or of a condition type, or of a restart, or of a
>> type.
>>
>
>So, what do you do when this kind of thing comes up in practice?
>
>Do you just allow access to all of them even though that wasn't your
>intention?
I don't think it's usually a problem. Often when these things have the
same names, it's because they're closely related. For instance, it's
common to use the slot name as the accessor function name in CLOS, and a
type may have the same name as the function used to create objects of that
type (e.g. CONS).
>Do you force yourself to rename some of them to avoid it?
If the above causes problems for your design, that's probably the best
solution.
>I'm glad that I'm not the only person who saw this as a drawback of
>the current package system. Or, do you not see it as a drawback at
>all?
What kinds of problems do you encounter due to these name collisions?
The primary goal of the package system was simple: to prevent conflicts
when you load software that comes from different sources into the same Lisp
image. If you see this issue as a problem or drawback, then I think you're
trying to make the package system solve problems that it was never intended
to solve, like *hiding* internals of other applications rather than
preventing unintended name conflicts.
--
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.
I don't see this as a drawback at all.
In Common Lisp you can always get access to any globally defined value.
Even if you don't export the symbol FOO from package BAR, you can still
refer to it as foo::bar instead of foo:bar. So, access isn't an issue.
Why do you think it should be a problem if someone has access to, say, a
class or condition name in addition to a function? The only place I can
see it causing trouble is if you USE the symbol in your package and then
inadvertently redefine the class with the shared name. If this is a
major concern, then the appropriate step to prevent it is to not USE
another packge, but rather to import the symbols and not define anything
with that name. Or else to just use package-qualified names for those
functions.
The basic philosophy of CL is to trust the programmers not to do
blatantly stupid things. This makes it much easier to reuse and adapt
existing code.
This is also one of the advantages of the CLOS object model with
methods. You can create new functions that work with someone else's
classes. This goes very much against the encapsulation philosophy of
the currently dominant Object-Oriented model. In the dominant model,
you would not, for example, be able to use a hammer to hold down a table
cloth because hammers don't have a hold-down (or should that be holdDown?
:) method and if you aren't the Hammer class author you can't do it.
--
Thomas A. Russ, USC/Information Sciences Institute
······@eos.ncsu.edu (Justin Dubs) writes:
> So, what do you do when this kind of thing comes up in practice?
>
> Do you just allow access to all of them even though that wasn't your
> intention?
> Do you force yourself to rename some of them to avoid it?
>
> I'm glad that I'm not the only person who saw this as a drawback of
> the current package system. Or, do you not see it as a drawback at
> all?
It's a minor annoyance. I say minor because although the system
forces you to export all functionality named by the same thing, in
general one _wants_ to export all things named by some name, because
as a programmer I choose names with care, so if two things are named
the same there's a fair probability that they're tightly coupled.
If there's something that definitely doesn't want to be exported, the
traditional thing is to put a percent sign in front of the name of the
internal stuff. Otherwise, easiest is to go with the flow.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Justin Dubs wrote:
> Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.jcn.srcf.net>...
>
>>Kent M Pitman <······@world.std.com> writes:
>>
>>
>>>······@eos.ncsu.edu (Justin Dubs) writes:
>>>
>>>
>>>>So, is there any way to allow access to only the variable or the
>>>>function but not both?
>>>
>>>If you name your variables with *'s around them and your functions
>>>without that, this never comes up in practice.
>>
>>What does come up in practice, though, is the name of a function and
>>the name of a slot, or of a condition type, or of a restart, or of a
>>type.
>
> So, what do you do when this kind of thing comes up in practice?
>
> Do you just allow access to all of them even though that wasn't your
> intention?
> Do you force yourself to rename some of them to avoid it?
It depends on the problem you want to solve. First of all, if you want
to export a symbol because it is the name of a slot and notice that it
already appears in the list of exported symbols, you have the chance to
make the necessary renamings. Or you simply don't care (which I think is
fine).
The "dangerous" case seems to be that someone might use an exported
symbol in uninteded ways. However:
- Hopefully you have documented the code so that it is clear what the
intended uses of the symbols are.
- I think it is unlikely that someone accidentally uses a symbol for a
purpose not intended.
- The package system is not intended as barrier against malicious
programmers. Everyone can have acces to any symbol in any package if
they want to.
I think it is more honest that the language doesn't try to impose
security barriers on the language level. For example, the
public/protected/private keywords seem to prevent programmers from
malicious abuse but in fact they don't either. Solving security issues
is more complicated than putting annotations in the right places.
> I'm glad that I'm not the only person who saw this as a drawback of
> the current package system. Or, do you not see it as a drawback at
> all?
I don't see it as a drawback. The package system solves a relatively
well-defined problem and doesn't mix it up with other isssues. In
general, I think that it is a good idea not to mix up different design
goals.
What you could see as a drawback is that Common Lisp doesn't provide a
module system and/or component model. But that's a different issue IMHO.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ······@eos.ncsu.edu (Justin Dubs) writes:
> >
> >> So, is there any way to allow access to only the variable or the
> >> function but not both?
> >
> > If you name your variables with *'s around them and your functions
> > without that, this never comes up in practice.
>
> What does come up in practice, though, is the name of a function and
> the name of a slot, or of a condition type, or of a restart, or of a
> type.
Ah, yes, this is certainly so. Although, in my experience, these usually
want to be done anyway. Can you offer an example where this is not the
case so that we can speak more concretely?
Kent M Pitman <······@world.std.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> What does come up in practice, though, is the name of a function and
>> the name of a slot, or of a condition type, or of a restart, or of a
>> type.
>
> Ah, yes, this is certainly so. Although, in my experience, these usually
> want to be done anyway. Can you offer an example where this is not the
> case so that we can speak more concretely?
The example that came up recently for me was in my recent work in
increasing use of conditions in SBCL's compiler messages.
Historically, a function named by SB-C::COMPILER-NOTE issued a
compiler note, which it printed directly. Motivated by users wishing
to customize the compiler messages more than was currently possible, I
introduced a condition to be signalled from this function and an
associated MUFFLE-WARNING restart. The natural name for this kind of
condition was COMPILER-NOTE, so that's what I called it. But for
COMPILER-NOTE conditions to be handlable by the user, it by convention
has to be exported from some public package (our extension package,
SB-EXT). But I don't want to guarantee stability of the COMPILER-NOTE
_function_ interface; in fact, it's almost guaranteed to change
significantly as the use of conditions is made more pervasive.
I got round it by renaming the function SB-C::COMPILER-NOTIFY, by
analogy with WARNING (condition)/WARN (function), but it's not 100%
satisfactory, because there's a potential misreading of
COMPILER-NOTIFY as "something that notifies the compiler" rather than
"emission of notes by the compiler".
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <··············@lambda.jcn.srcf.net>,
Christophe Rhodes <·····@cam.ac.uk> wrote:
>The example that came up recently for me was in my recent work in
>increasing use of conditions in SBCL's compiler messages.
>Historically, a function named by SB-C::COMPILER-NOTE issued a
>compiler note, which it printed directly. Motivated by users wishing
>to customize the compiler messages more than was currently possible, I
>introduced a condition to be signalled from this function and an
>associated MUFFLE-WARNING restart. The natural name for this kind of
>condition was COMPILER-NOTE, so that's what I called it. But for
>COMPILER-NOTE conditions to be handlable by the user, it by convention
>has to be exported from some public package (our extension package,
>SB-EXT). But I don't want to guarantee stability of the COMPILER-NOTE
>_function_ interface; in fact, it's almost guaranteed to change
>significantly as the use of conditions is made more pervasive.
The API of an application should be defined by the documentation, not the
exported symbols. If the only aspect of this symbol that you document for
outside users is its use as a condition type, that's all they should
depend on.
--
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.