Asp Forum - CCL: The funcion GET is predefined in Clozure CL. What?

Frank GOENNINGER

4/30/2016 4:58:00 PM

Hi !

I do:

(defpackage frgo
(:use :cl))

(in-package frgo)
(defun get ())

Compiling this make CCL unhappy =>

The function GET is predefined in Clozure CL.
[Condition of type SIMPLE-ERROR]

What am I doing wrong ? Thx for pointing me into the right direction!

Regards
Frank

8 Answers

Pascal J. Bourguignon

4/30/2016 5:26:00 PM

Frank DG1SBG <dg1sbg@googlemail.com> writes:

> Hi !
>
> I do:
>
> (defpackage frgo
> (:use :cl))
>
> (in-package frgo)
> (defun get ())
>
> Compiling this make CCL unhappy =>
>
> The function GET is predefined in Clozure CL.
> [Condition of type SIMPLE-ERROR]
>
> What am I doing wrong ?

You're trying to define a function named with the symbol
COMMON-LISP:GET.

> Thx for pointing me into the right direction!

Hard to say, since the right direction would depend on what you want to
do.

If you want a function named by a symbol named "GET", but distinct from
COMMON-LISP:GET, then you could shadow COMMON-LISP:GET.

(defpackage "FRGO"
(:use "COMMON-LISP")
(:shadow "GET"))
(in-package "FRGO")
(defun get ()) ; |FRGP|::|GET|, not |COMMON-LISP|:|GET|

If you just want a function named by a random symbol, you could try
GET-FRGO or MY-GET.

(defpackage "FRGO"
(:use "COMMON-LISP"))
(in-package "FRGO")
(defun get-frgo ()) ; |FRGO|::|GET-FRGO| not |COMMON-LISP|:|GET|

If you don't care about "GET" but would be happy with "get", you could
set (read-table-case *readtable*) to :preserve. I'd favor the later,
but other lispers don't like case sensitivity.

(EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(SETF *READTABLE* (COPY-READTABLE NIL))
(SETF (READTABLE-CASE *READTABLE*) :PRESERVE))

(DEFPACKAGE "FRGO"
(:USE "COMMON-LISP"))
(IN-PACKAGE "FRGO")
(DEFUN get ()) ; |FRGP|::|get|, not |COMMON-LISP|:|GET|

;; See how nice it is:

(DEFUN example (x y)
(get)
(PRINT (LIST (GET 'y 'x) (get) (+ x y)))
(IF (= 0 x)
(get)
(example (- x 1) y)))

(example 3 100)
prints:
(NIL NIL 103)
(NIL NIL 102)
(NIL NIL 101)
(NIL NIL 100)
--> NIL

--
__Pascal Bourguignon__ http://www.informat...
â??The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.â? -- Carl Bass CEO Autodesk

Kaz Kylheku

4/30/2016 5:27:00 PM

On 2016-04-30, Frank DG1SBG <dg1sbg@googlemail.com> wrote:
> Hi !
>
> I do:
>
> (defpackage frgo
> (:use :cl))
>
> (in-package frgo)
> (defun get ())
>
> Compiling this make CCL unhappy =>
>
> The function GET is predefined in Clozure CL.
> [Condition of type SIMPLE-ERROR]
>
> What am I doing wrong ? Thx for pointing me into the right direction!

You're trying to change the function binding of the symbol
cl:get which is visible in your package via the use relationship
established by (:use :cl).

The function and variable bindings (and other such properties)
of a symbol in Common Lisp are not package-specific.

In some programming languages, packages are namespaces which contain
associations of symbols to entities.

A Lisp package is a namespace which maps character strings to symbols.

In your package, the character string "GET" maps to the symbol get in
the Commmon-Lisp package: the same object that you get when you read
CL::GET in any package. It has not become a different symbol FRGO::GET
with a binding that you can redefine.

If you want your own FRGO::GET, you have to create a mapping for the
"GET" string in your package which hides the mapping that is visible
via the use-relationship. This is called "shadowing".

(defpackage frgo
(:shadow :get)
(:use :cl))

The order of the :use and :shadow doesn't matter.

The :use essentially installs a "tunnel" from your package to the CL
package. When the reader looks up a string like "GET" in your package,
it looks not only there but also in any "tunneled" packages.

Note that package use is not a fallback mechanism. That is to say,
package lookup does *not* simply look in the package first and then in
the used packages.

An ambiguous situation in which a name resolves in more than one way is
actually erroneous, and prevented.

If you have a package which already has a "GET" symbol and then you
use one (creating a "tunnel" to it) which also has a "GET" symbol,
this is identified as a clash.

Likewise, if you try to use two packages (create two "tunnels") and
it so happens that they have some symbols with the same names, that
is also erroneous.

Clashes are resolved by shadowing symbols.

Each package has a list (possibly empty) of shadowing symbols. This list
resolves clashes by asserting that each shadowed symbol simply
takes precedence over any clashing ones.

So when we evaluate:

(defpackage frgo
(:shadow :get)
(:use :cl))

we create a package "FRGO" which:

* uses cl (has a "tunnel" to it)
* has a local symbol called "GET" present in it
* that symbol is in the shadowing list, resolving the clash
against CL:GET that would otherwise exist in the "FRGO" package.

Frank GOENNINGER

4/30/2016 6:00:00 PM

Frank DG1SBG <dg1sbg@googlemail.com> writes:

> Hi !
>
> I do:
>
> (defpackage frgo
> (:use :cl))
>
> (in-package frgo)
> (defun get ())

Kaz, Pascal, thanks - actually I made an "mistake" in code shown above:
It should read:

(defpackage frgo)

(in-package frgo)

(defun get ())

My understanding of visibility of functions outside of a package is that
symbols only clash if they are exported from the package ... Which isn't
the case here...

Could you please comment again? Thx!

;; Frank

Pascal J. Bourguignon

4/30/2016 6:50:00 PM

Frank DG1SBG <dg1sbg@googlemail.com> writes:

> Frank DG1SBG <dg1sbg@googlemail.com> writes:
>
>> Hi !
>>
>> I do:
>>
>> (defpackage frgo
>> (:use :cl))
>>
>> (in-package frgo)
>> (defun get ())
>
> Kaz, Pascal, thanks - actually I made an "mistake" in code shown
> above:
> It should read:
>
> (defpackage frgo)
>
> (in-package frgo)
>
> (defun get ())

This code is not conforming, because (defpackage frgo) is implementation
dependant.
More precisely, the default use list in defpackage is. If you don't
want to use anything, you must explicitely say so:

(defpackage "FRGO"
(:use))

Furthermore, if you create a package without any symbol, then of course,
you won't have any symbol in it! So after in-package, you will have to
qualify all the symbols you want to read from other packages:

(defpackage "FRGO"
(:use))
(in-package "FRGO")
(cl:defun get ())

> My understanding of visibility of functions outside of a package is
> that
> symbols only clash if they are exported from the package ... Which
> isn't
> the case here...

Kaz explained it nicely. Read again his answer.

--
__Pascal Bourguignon__ http://www.informat...
â??The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.â? -- Carl Bass CEO Autodesk

Kaz Kylheku

4/30/2016 7:49:00 PM

On 2016-04-30, Frank DG1SBG <dg1sbg@googlemail.com> wrote:
> My understanding of visibility of functions outside of a package is that

There is no concept of *function* visibility in relation to a package.

Functions are objects, and as such are only visible/accessible through
the value that represents them.

These objects can be tied to symbols via function bindings. Functions
bindings can be "top level" in the global/dynamic namespace, of which
there is only one, or they can be lexical. Those are the two namespaces,
period.

What's visible in a package are "bindings" of *character string* names
to symbol objects, which have nothing to do with what those symbol
objects are used for, such as function or variable binding.

> symbols only clash if they are exported from the package ... Which isn't
> the case here...

Symbols that are not exported from a package are protected from creating
clashes in *other* packages by virtue of not being made visible in other
packages by the package use "tunnel" mechanism.

The CL:GET symbol is certainly exported from CL. Thus when you use CL in
your own package, CL:GET is one of the symbols that becomes visible. At
that point, it potentially clashes with anything else that is visible or
present in the using package, including a local symbol which is not exported.

[1]> (defpackage :foo (:use)) ;; empty use to suppress default use of CL
#<PACKAGE FOO>
[2]> (in-package :foo)
#<PACKAGE FOO>

Now we're in a package in which we have nothing! If we try to use +,
it's actually FOO::+:

FOO[3]> (+ a b)

*** - COMMON-LISP:EVAL: undefined function +
The following restarts are available:
[...]

Now let's create FOO::GET:

FOO[5]> 'get ;; mention GET to have it interned in FOO
GET

At this point we have two symbols in FOO, FOO::+ and FOO::GET. Let's
bring in the CL package via use:

FOO[6]> (cl:use-package :cl)

*** - (COMMON-LISP:USE-PACKAGE (#<PACKAGE COMMON-LISP>) #<PACKAGE FOO>): 2
name conflicts remain
Which symbol with name "GET" should be accessible in #<PACKAGE FOO>?

See? Conflict between exported CL:GET and unexported FOO::GET.

Also note how the error refers to the name "GET": a character string.

It's not asking "which function GET would you like?"

Frank GOENNINGER

4/30/2016 8:07:00 PM

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Frank DG1SBG <dg1sbg@googlemail.com> writes:
>
>> Frank DG1SBG <dg1sbg@googlemail.com> writes:
>>
>> It should read:
>>
>> (defpackage frgo)
>>
>> (in-package frgo)
>>
>> (defun get ())
>
> This code is not conforming, because (defpackage frgo) is implementation
> dependant.
> More precisely, the default use list in defpackage is. If you don't
> want to use anything, you must explicitely say so:
>
> (defpackage "FRGO"
> (:use))
>
>
> Furthermore, if you create a package without any symbol, then of course,
> you won't have any symbol in it! So after in-package, you will have to
> qualify all the symbols you want to read from other packages:
>
> (defpackage "FRGO"
> (:use))
> (in-package "FRGO")
> (cl:defun get ())
>
>
>> My understanding of visibility of functions outside of a package is
>> that
>> symbols only clash if they are exported from the package ... Which
>> isn't
>> the case here...
>
> Kaz explained it nicely. Read again his answer.

Yes, I did. The error came from not declaring (:use) - didn't know that
I have to explicitely say this to exclude any package from being used by
default.

Thanks for pointing out!

Regards
Frank

Barry Margolin

4/30/2016 9:16:00 PM

In article <m2r3dmrhcr.fsf@googlemail.com>,
Frank DG1SBG <dg1sbg@googlemail.com> wrote:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
> > Frank DG1SBG <dg1sbg@googlemail.com> writes:
> >
> >> Frank DG1SBG <dg1sbg@googlemail.com> writes:
> >>
> >> It should read:
> >>
> >> (defpackage frgo)
> >>
> >> (in-package frgo)
> >>
> >> (defun get ())
> >
> > This code is not conforming, because (defpackage frgo) is implementation
> > dependant.
> > More precisely, the default use list in defpackage is. If you don't
> > want to use anything, you must explicitely say so:
> >
> > (defpackage "FRGO"
> > (:use))
> >
> >
> > Furthermore, if you create a package without any symbol, then of course,
> > you won't have any symbol in it! So after in-package, you will have to
> > qualify all the symbols you want to read from other packages:
> >
> > (defpackage "FRGO"
> > (:use))
> > (in-package "FRGO")
> > (cl:defun get ())
> >
> >
> >> My understanding of visibility of functions outside of a package is
> >> that
> >> symbols only clash if they are exported from the package ... Which
> >> isn't
> >> the case here...
> >
> > Kaz explained it nicely. Read again his answer.
>
> Yes, I did. The error came from not declaring (:use) - didn't know that
> I have to explicitely say this to exclude any package from being used by
> default.

How did you expect DEFUN to be found if it didn't use the CL package? If
you thought it wouldn't automatically use CL, why didn't you write
cl:defun?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Pascal J. Bourguignon

5/1/2016 10:09:00 AM

Kaz Kylheku <545-066-4921@kylheku.com> writes:

> On 2016-04-30, Frank DG1SBG <dg1sbg@googlemail.com> wrote:
>> My understanding of visibility of functions outside of a package is that
>
> There is no concept of *function* visibility in relation to a package.
>
> Functions are objects, and as such are only visible/accessible through
> the value that represents them.
>
> These objects can be tied to symbols via function bindings. Functions
> bindings can be "top level" in the global/dynamic namespace, of which
> there is only one, or they can be lexical. Those are the two namespaces,
> period.

And these function objects can be tied to symbols via VALUE bindings as
well, and via PLIST bindings too. Some of these function objects can be
tied to symbols via MACRO bindings, but it's not entirely orthogonal to
the FUNCTION bindings).

And you can also bind these functions to any place (not declared to be
of a type excluding functions), such as slots in structures or CLOS
instances, arrays, hash-tables, etc.

So you can see that it's entirely unrelated to the notion of package.

> What's visible in a package are "bindings" of *character string* names
> to symbol objects, which have nothing to do with what those symbol
> objects are used for, such as function or variable binding.
>
>> symbols only clash if they are exported from the package ... Which isn't
>> the case here...
>
> Symbols that are not exported from a package are protected from creating
> clashes in *other* packages by virtue of not being made visible in other
> packages by the package use "tunnel" mechanism.

But this doesn't mean that you cannot make them clash if you insist on
it:

(defpackage "P" (:use) (:intern "I"))
(defpackage "Q" (:use) (:intern "I"))
(defpackage "R" (:use) (:import-from "P" "I") (:import-from "Q" "I"))
==> Name "I", used in :import-from option, is already used in a conflicting option .

(defpackage "P" (:use) (:export "I"))
(defpackage "Q" (:use) (:intern "I"))
(defpackage "R" (:use "P") (:import-from "Q" "I"))
==> Importing q::i to #<Package "R"> would conflict with inherited symbol p:i .

again, one solution may be to shadow one set of symbols by another
symbol:

(defpackage "P" (:use) (:export "I"))
(defpackage "Q" (:use) (:intern "I"))
(defpackage "R" (:use "P") (:shadowing-import-from "Q" "I"))
--> #<Package "R">
;; works if Q::I is exported too.

> The CL:GET symbol is certainly exported from CL. Thus when you use CL in
> your own package, CL:GET is one of the symbols that becomes visible. At
> that point, it potentially clashes with anything else that is visible or
> present in the using package, including a local symbol which is not exported.
>
> [1]> (defpackage :foo (:use)) ;; empty use to suppress default use
> of CL

Nope. The default is not to use CL, it's to use an implementation
dependant set of packages!!!

clhs make-package
use---a list of package designators. The default is implementation-defined.

> #<PACKAGE FOO>
> [2]> (in-package :foo)
> #<PACKAGE FOO>
>
> Now we're in a package in which we have nothing! If we try to use +,
> it's actually FOO::+:
>
> FOO[3]> (+ a b)
>
> *** - COMMON-LISP:EVAL: undefined function +
> The following restarts are available:
> [...]
>
> Now let's create FOO::GET:
>
> FOO[5]> 'get ;; mention GET to have it interned in FOO
> GET
>
> At this point we have two symbols in FOO, FOO::+ and FOO::GET. Let's
> bring in the CL package via use:
>
> FOO[6]> (cl:use-package :cl)
>
> *** - (COMMON-LISP:USE-PACKAGE (#<PACKAGE COMMON-LISP>) #<PACKAGE FOO>): 2
> name conflicts remain
> Which symbol with name "GET" should be accessible in #<PACKAGE FOO>?
>
> See? Conflict between exported CL:GET and unexported FOO::GET.
>
> Also note how the error refers to the name "GET": a character string.
>
> It's not asking "which function GET would you like?"

--
__Pascal Bourguignon__ http://www.informat...
â??The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.â? -- Carl Bass CEO Autodesk

comp.lang.lisp

CCL: The funcion GET is predefined in Clozure CL. What?

Frank GOENNINGER

Pascal J. Bourguignon

Kaz Kylheku

Frank GOENNINGER

Pascal J. Bourguignon

Kaz Kylheku

Frank GOENNINGER

Barry Margolin

Pascal J. Bourguignon

x Login to ForumsZone