Hi out there!
The following occurs in my environment:
In file src1.lisp:
(eval-when (:load-toplevel :compile-toplevel :execute)
(defpackage :frgo
(:use :common-lisp :common-lisp-user)
(:export frgo-function))
)
(in-package :frgo)
(defun frgo-function (x)
(print x))
In Lisp Listener:
CL-USER(1): (load "~/src/src1.lisp")
; Loading /home/frgo/src/src1.lisp
T
CL-USER(2): (use-package :frgo)
T
CL-USER(3): (frgo-function "hallo")
Error: attempt to call `FRGO-FUNCTION' which is an undefined function.
[condition type: UNDEFINED-FUNCTION]
Restart actions (select using :continue):
0: Try calling FRGO-FUNCTION again.
1: Try calling FRGO::FRGO-FUNCTION instead.
2: Return a value instead of calling FRGO-FUNCTION.
3: Try calling a function other than FRGO-FUNCTION.
4: Setf the symbol-function of FRGO-FUNCTION and call it again.
5: Return to Top Level (an "abort" restart).
6: Abort entirely from this process.
[1] CL-USER(4):
Hmmmm - From CLHS I understood that
(use-package :frgo)
let's one treat all exported symbols from package :frgo as internal
symbols in the current package...
From various code examples on the Net I see the same usage of
the package functions, so - what am I doing wrong?
Any hints very welcome.
BTW, answering :cont 1 succeeds.
Thanks a lot guys!
Regards,
Frank
In article <············@stargate.de.goenninger.com>, Frank Goenninger
<················@goenninger.com> wrote:
>Hi out there!
>
>The following occurs in my environment:
>
>In file src1.lisp:
>
>(eval-when (:load-toplevel :compile-toplevel :execute)
> (defpackage :frgo
> (:use :common-lisp :common-lisp-user)
> (:export frgo-function))
>)
When the Lisp reader reads this defpackage form, it's
in cl-user. So
(:export frgo-function)
created a frgo-function symbol in cl-user.
>
>(in-package :frgo)
>
>(defun frgo-function (x)
> (print x))
>
>In Lisp Listener:
>
>CL-USER(1): (load "~/src/src1.lisp")
>; Loading /home/frgo/src/src1.lisp
>T
>CL-USER(2): (use-package :frgo)
>T
In Macintosh CL, this use-package causes a name conflict.
Not sure why it doesn't in your environment.
>CL-USER(3): (frgo-function "hallo")
>Error: attempt to call `FRGO-FUNCTION' which is an undefined function.
Yep. There's a symbol frgo-function in cl-user and it
doesn't have any definition.
Use something like this:
(eval-when (:load-toplevel :compile-toplevel :execute)
(defpackage :frgo
(:use :common-lisp :common-lisp-user)
(:export #:frgo-function))
Or, if you don't care about supporting Allegro's non-ANSI
modern mode, you can use
(:export "FRGO-FUNCTION")
In article <············@stargate.de.goenninger.com>,
Frank Goenninger <················@goenninger.com> wrote:
>Hi out there!
>
>The following occurs in my environment:
>
>In file src1.lisp:
>
>(eval-when (:load-toplevel :compile-toplevel :execute)
> (defpackage :frgo
> (:use :common-lisp :common-lisp-user)
> (:export frgo-function))
>)
>
>(in-package :frgo)
>
>(defun frgo-function (x)
> (print x))
>
>In Lisp Listener:
>
>CL-USER(1): (load "~/src/src1.lisp")
>; Loading /home/frgo/src/src1.lisp
>T
>CL-USER(2): (use-package :frgo)
>T
>CL-USER(3): (frgo-function "hallo")
>Error: attempt to call `FRGO-FUNCTION' which is an undefined function.
> [condition type: UNDEFINED-FUNCTION]
Try changing the DEFPACKAGE to contain:
(:export :frgo-function)
The problem is that when the EVAL-WHEN expression was read in by LOAD, the
symbol FRGO-FUNCTION was interned in the current package. Internal symbols
always override inherited symbols.
By using a keyword in the DEFPACKAGE expression, you avoid interning
anything in the current package, and then the inherited symbol will be used.
--
Barry Margolin, ······@genuity.com
Genuity Managed Services, 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.
From: Larry Clapp
Subject: Re: (use-package) does not intern symbols ? ACL 6.2 Trial
Date:
Message-ID: <ltvr1b.v1d.ln@theclapp.ddts.net>
In article <·················@paloalto-snr1.gtei.net>, Barry Margolin wrote:
> In article <············@stargate.de.goenninger.com>,
> Frank Goenninger <················@goenninger.com> wrote:
>>The following occurs in my environment:
>>
>>In file src1.lisp:
>>
>>(eval-when (:load-toplevel :compile-toplevel :execute)
>> (defpackage :frgo
>> (:use :common-lisp :common-lisp-user)
>> (:export frgo-function))
>>)
>>
>>(in-package :frgo)
>>
>>(defun frgo-function (x)
>> (print x))
>>
>>In Lisp Listener:
>>
>>CL-USER(1): (load "~/src/src1.lisp")
>>; Loading /home/frgo/src/src1.lisp
>>T
>>CL-USER(2): (use-package :frgo)
>>T
>>CL-USER(3): (frgo-function "hallo")
>>Error: attempt to call `FRGO-FUNCTION' which is an undefined function.
>> [condition type: UNDEFINED-FUNCTION]
>
> Try changing the DEFPACKAGE to contain:
>
> (:export :frgo-function)
>
> The problem is that when the EVAL-WHEN expression was read in by
> LOAD, the symbol FRGO-FUNCTION was interned in the current package.
> Internal symbols always override inherited symbols.
>
> By using a keyword in the DEFPACKAGE expression, you avoid interning
> anything in the current package, and then the inherited symbol will
> be used.
Or
(:export "FRGO-FUNCTION")
which doesn't intern anything anywhere.
>> Restart actions (select using :continue):
>> 0: Try calling FRGO-FUNCTION again.
>> 1: Try calling FRGO::FRGO-FUNCTION instead.
^^ This ...
<snip>
>> BTW, answering :cont 1 succeeds.
... and this should have hinted to you that you'd done something wrong
exporting FRGO-FUNCTION.
--
Larry Clapp / ·····@theclapp.org
Use Lisp from Vim: VILisp: http://vim.sourceforge.net/script.php?script_id=221
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <·············@theclapp.ddts.net>,
Larry Clapp <·····@theclapp.org> wrote:
>Or
>
> (:export "FRGO-FUNCTION")
>
>which doesn't intern anything anywhere.
But you could run into trouble in some ACL configurations, which default to
:DOWNCASE. Using keywords means it will work with any READTABLE-CASE
setting.
--
Barry Margolin, ······@genuity.com
Genuity Managed Services, 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.
Barry Margolin <······@genuity.net> writes:
> In article <·············@theclapp.ddts.net>,
> Larry Clapp <·····@theclapp.org> wrote:
> >Or
> >
> > (:export "FRGO-FUNCTION")
> >
> >which doesn't intern anything anywhere.
>
> But you could run into trouble in some ACL configurations, which default to
> :DOWNCASE. Using keywords means it will work with any READTABLE-CASE
> setting.
And if interning is a concern, one can use
(:export #:frgo-function)
for those that don't know (and I know that you do, Barry).
From: Joe Marshall
Subject: Re: (use-package) does not intern symbols ? ACL 6.2 Trial
Date:
Message-ID: <k7gegzls.fsf@ccs.neu.edu>
Barry Margolin <······@genuity.net> writes:
> In article <·············@theclapp.ddts.net>,
> Larry Clapp <·····@theclapp.org> wrote:
> >Or
> >
> > (:export "FRGO-FUNCTION")
> >
> >which doesn't intern anything anywhere.
>
> But you could run into trouble in some ACL configurations, which default to
> :DOWNCASE. Using keywords means it will work with any READTABLE-CASE
> setting.
These would be the non-conforming configurations, though. Using an
uppercase string should work on any conforming configuration.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> In article <·············@theclapp.ddts.net>,
>> Larry Clapp <·····@theclapp.org> wrote:
>> >Or
>> >
>> > (:export "FRGO-FUNCTION")
>> >
>> >which doesn't intern anything anywhere.
>>
>> But you could run into trouble in some ACL configurations, which default to
>> :DOWNCASE. Using keywords means it will work with any READTABLE-CASE
>> setting.
>
>These would be the non-conforming configurations, though. Using an
>uppercase string should work on any conforming configuration.
True, but that configuration is often encountered. What's wrong with
accomodating all configurations when it's so trivial to do so?
--
Barry Margolin, ······@genuity.com
Genuity Managed Services, 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.
Barry Margolin <······@genuity.net> writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> >Barry Margolin <······@genuity.net> writes:
> >
...
> >These would be the non-conforming configurations, though. Using an
> >uppercase string should work on any conforming configuration.
>
> True, but that configuration is often encountered. What's wrong with
> accomodating all configurations when it's so trivial to do so?
Since you asked...
1. As indicated in my other post, it's not so trivial to do.
2. Accomodating Franz is not the same as accomodating "all".
3. It's highly unaesthetic, both because you're accomodating non-CL
but also because you're interning symbols in a random package where
you don't need them.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>> >Barry Margolin <······@genuity.net> writes:
>> >
>...
>> >These would be the non-conforming configurations, though. Using an
>> >uppercase string should work on any conforming configuration.
>>
>> True, but that configuration is often encountered. What's wrong with
>> accomodating all configurations when it's so trivial to do so?
>
>Since you asked...
>
>1. As indicated in my other post, it's not so trivial to do.
What's non-trivial about (:export #:frgo-function)? Ugly I grant.
I don't understand your point in that post that said it would
have to be (:EXPORT ...) in CL.
>2. Accomodating Franz is not the same as accomodating "all".
But not accommodating Franz in modern mode does mean not accomodating
a very common variant.
I have users of my ANSI-compliant code that have to use the
Allegro "modern" to use the Java and XML code. It'd be counterproductive
for me to avoid code that works for both ANSI and Allegro modern.
>3. It's highly unaesthetic, both because you're accomodating non-CL
> but also because you're interning symbols in a random package where
> you don't need them.
But (:export #:frgo-function) doesn't do that second part.
From: Duane Rettig
Subject: Re: (use-package) does not intern symbols ? ACL 6.2 Trial
Date:
Message-ID: <4el6mnltm.fsf@beta.franz.com>
Chris Riesbeck <········@cs.northwestern.edu> writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> >1. As indicated in my other post, it's not so trivial to do.
>
> What's non-trivial about (:export #:frgo-function)? Ugly I grant.
Actually, although your solution is a good one, and will guarantee
that unwanted symbols are never interned, you can also use
a solution that can be trivial _and_ non-ugly, depending on your
requirements. To understand this, recall that defpackage is a
macro, and thus has an expansion which can be looked at via the
magic (pprint (macroexpand ...)). As such, if I start out with
a definition in a file and manipulate it in the compiling lisp:
CL-USER(1): (shell "cat pack.cl")
(defpackage :foo
(:export goob gooc good))
(in-package :foo)
0
CL-USER(2): (pprint (macroexpand '(defpackage :foo (:export goob gooc good))))
(EVAL-WHEN (COMPILE EVAL LOAD)
(EXCL::DEFPACKAGE-1 ':FOO '((:EXPORT #:GOOB #:GOOC #:GOOD))))
CL-USER(3): (compile-file "pack.cl")
;;; Compiling file pack.cl
;;; Writing fasl file pack.fasl
;;; Fasl write complete
#p"pack.fasl"
NIL
NIL
CL-USER(4):
Note that the compiling lisp does have the extra unwanted symbols,
due to the processing that resulted from the reads before the
macroexpansion:
CL-USER(4): (apropos "GOO")
GOOD
GOOB
GOOC
FOO:GOOD
FOO:GOOB
FOO:GOOC
CL-USER(5):
However, if I now exit and restart the lisp, and load only the fasl
file:
CL-USER(1): (load "pack.fasl")
; Fast loading [...] pack.fasl
CL-USER(2): (apropos "GOO")
FOO:GOOD
FOO:GOOB
FOO:GOOC
CL-USER(3):
Only the desired symbols are interned in the lisp.
--
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
In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
>Chris Riesbeck <········@cs.northwestern.edu> writes:
>
>> In article <···············@shell01.TheWorld.com>, Kent M Pitman
>> <······@world.std.com> wrote:
>>
>> >1. As indicated in my other post, it's not so trivial to do.
>>
>> What's non-trivial about (:export #:frgo-function)? Ugly I grant.
>
>Actually, although your solution is a good one, and will guarantee
>that unwanted symbols are never interned, you can also use
>a solution that can be trivial _and_ non-ugly, depending on your
>requirements. ...
>
>CL-USER(2): (pprint (macroexpand '(defpackage :foo (:export goob gooc good))))
>
>(EVAL-WHEN (COMPILE EVAL LOAD)
> (EXCL::DEFPACKAGE-1 ':FOO '((:EXPORT #:GOOB #:GOOC #:GOOD))))
But this expansion isn't required, is it? It doesn't seem
to be from the description of :export in defpackage in
the Hyperspec. So I can't count on (:export goob) not
stuffing goob into the current package in an ANSI compliant
Lisp. That was the cause of the problem the original poster had.
I actually saw (:export #:goob) in some Franz code, and
said "ah, that's how to satisfy (almost?) everyone" without
polluting any packages.
From: Duane Rettig
Subject: Re: (use-package) does not intern symbols ? ACL 6.2 Trial
Date:
Message-ID: <4ptq5oz95.fsf@beta.franz.com>
Chris Riesbeck <········@cs.northwestern.edu> writes:
> In article <·············@beta.franz.com>, Duane Rettig
> <·····@franz.com> wrote:
>
> >Chris Riesbeck <········@cs.northwestern.edu> writes:
> >
> >> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> >> <······@world.std.com> wrote:
> >>
> >> >1. As indicated in my other post, it's not so trivial to do.
> >>
> >> What's non-trivial about (:export #:frgo-function)? Ugly I grant.
> >
> >Actually, although your solution is a good one, and will guarantee
> >that unwanted symbols are never interned, you can also use
> >a solution that can be trivial _and_ non-ugly, depending on your
> >requirements. ...
> >
> >CL-USER(2): (pprint (macroexpand '(defpackage :foo (:export goob gooc good))))
> >
> >(EVAL-WHEN (COMPILE EVAL LOAD)
> > (EXCL::DEFPACKAGE-1 ':FOO '((:EXPORT #:GOOB #:GOOC #:GOOD))))
>
> But this expansion isn't required, is it?
Correct.
> It doesn't seem
> to be from the description of :export in defpackage in
> the Hyperspec. So I can't count on (:export goob) not
> stuffing goob into the current package in an ANSI compliant
> Lisp.
Correct again. The non-interning behavior can't be counted on
to be portable. It's more of a comptetitive thing.
> That was the cause of the problem the original poster had.
Not really. The original poster had loaded the source file
instead of loading a precompiled fasl file, so the reader
was involved.
> I actually saw (:export #:goob) in some Franz code, and
> said "ah, that's how to satisfy (almost?) everyone" without
> polluting any packages.
Correct. If you don't mind the ugliness that you granted, above,
then the #: syntax is the most portable. And as I stated above,
the desirability of the modified solution I gave depends on your
requirements. If you want less ugliness, and are willing to:
1. Only use implementations which provide make-symbol
macroexpansions for defpackage like in the example I showed, and
2. Separate the compilation of your system from its build (i.e.
loading in of the fasl files),
then you can get the similar results with less ugly specification.
--
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
In article <······························@news.it.nwu.edu>,
Chris Riesbeck <········@cs.northwestern.edu> wrote:
>In article <·············@beta.franz.com>, Duane Rettig
><·····@franz.com> wrote:
>
>>Chris Riesbeck <········@cs.northwestern.edu> writes:
>>
>>> In article <···············@shell01.TheWorld.com>, Kent M Pitman
>>> <······@world.std.com> wrote:
>>>
>>> >1. As indicated in my other post, it's not so trivial to do.
>>>
>>> What's non-trivial about (:export #:frgo-function)? Ugly I grant.
>>
>>Actually, although your solution is a good one, and will guarantee
>>that unwanted symbols are never interned, you can also use
>>a solution that can be trivial _and_ non-ugly, depending on your
>>requirements. ...
>>
>>CL-USER(2): (pprint (macroexpand '(defpackage :foo (:export goob gooc good))))
>>
>>(EVAL-WHEN (COMPILE EVAL LOAD)
>> (EXCL::DEFPACKAGE-1 ':FOO '((:EXPORT #:GOOB #:GOOC #:GOOD))))
>
>But this expansion isn't required, is it? It doesn't seem
>to be from the description of :export in defpackage in
>the Hyperspec. So I can't count on (:export goob) not
>stuffing goob into the current package in an ANSI compliant
>Lisp. That was the cause of the problem the original poster had.
The original poster's problem had nothing to do with how the macro expands,
since the symbol was being interned at *read* time, not expansion time.
--
Barry Margolin, ······@genuity.com
Genuity Managed Services, 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.
Chris Riesbeck <········@cs.northwestern.edu> writes:
> >1. As indicated in my other post, it's not so trivial to do.
>
> What's non-trivial about (:export #:frgo-function)? Ugly I grant.
>
> I don't understand your point in that post that said it would
> have to be (:EXPORT ...) in CL.
Because Barry had remarked about how (:export :foo) accomodates other
settings of readtable-case, but it doesn't really. |DEFPACKAGE|
doesn't understand a :|export| keyword, only a :|EXPORT| keyword.
(Maybe |defmacro| is something provided by some nonstandard Lisp, but
then we're out of range...)
> >2. Accomodating Franz is not the same as accomodating "all".
>
> But not accommodating Franz in modern mode does mean not accomodating
> a very common variant.
That's fine. I specifically just wanted to point out that this doesn't make
the code universal. It was the specific use of "all" that bugged me.
"all" does not denote "ANSI + Franz in modern mode".
> I have users of my ANSI-compliant code that have to use the
> Allegro "modern" to use the Java and XML code. It'd be counterproductive
> for me to avoid code that works for both ANSI and Allegro modern.
>
> >3. It's highly unaesthetic, both because you're accomodating non-CL
> > but also because you're interning symbols in a random package where
> > you don't need them.
>
> But (:export #:frgo-function) doesn't do that second part.
It does still implement "non-aesthetic" though. ;)
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>Chris Riesbeck <········@cs.northwestern.edu> writes:
>
>> >1. As indicated in my other post, it's not so trivial to do.
>>
>> What's non-trivial about (:export #:frgo-function)? Ugly I grant.
>>
>> I don't understand your point in that post that said it would
>> have to be (:EXPORT ...) in CL.
>
>Because Barry had remarked about how (:export :foo) accomodates other
>settings of readtable-case, but it doesn't really. |DEFPACKAGE|
>doesn't understand a :|export| keyword, only a :|EXPORT| keyword.
>(Maybe |defmacro| is something provided by some nonstandard Lisp, but
>then we're out of range...)
Who said anything about :|export|? I said (:export :frgo-function). This
will work properly if the implementation's default mode is :UPCASE and
symbols normally have uppercase names, or its default mode is :DOWNCASE and
they normally have lowercase names. AFAIK, those are the only common
variants.
>> >2. Accomodating Franz is not the same as accomodating "all".
>>
>> But not accommodating Franz in modern mode does mean not accomodating
>> a very common variant.
>
>That's fine. I specifically just wanted to point out that this doesn't make
>the code universal. It was the specific use of "all" that bugged me.
>"all" does not denote "ANSI + Franz in modern mode".
Sorry I wasn't mathematically precise in my use of informal English.
>
>> I have users of my ANSI-compliant code that have to use the
>> Allegro "modern" to use the Java and XML code. It'd be counterproductive
>> for me to avoid code that works for both ANSI and Allegro modern.
>>
>> >3. It's highly unaesthetic, both because you're accomodating non-CL
>> > but also because you're interning symbols in a random package where
>> > you don't need them.
>>
>> But (:export #:frgo-function) doesn't do that second part.
>
>It does still implement "non-aesthetic" though. ;)
I happen to agree that using uninterned symbols is unappealing. But I have
no problem with keywords. The keyword package is not some random package,
it's a standard package that's well-suited for this use. Random symbols
are interned there all the time.
--
Barry Margolin, ······@genuity.com
Genuity Managed Services, 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.
Barry Margolin <······@genuity.net> writes:
> In article <·············@theclapp.ddts.net>,
> Larry Clapp <·····@theclapp.org> wrote:
> >Or
> >
> > (:export "FRGO-FUNCTION")
> >
> >which doesn't intern anything anywhere.
>
> But you could run into trouble in some ACL configurations, which default to
> :DOWNCASE.
Although as I understand it they are busy fixing this...?
> Using keywords means it will work with any READTABLE-CASE
> setting.
I don't agree, since :export will only be recognized in uppercase.
You must, at minimum, do
(:EXPORT :frgo-function)
or else you are expecting some non-CL version of DEFPACKAGE to do the
managing with any READTABLE-CASE. Once you're not working with CL,
who knows what to expect...
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> In article <·············@theclapp.ddts.net>,
>> Larry Clapp <·····@theclapp.org> wrote:
>> >Or
>> >
>> > (:export "FRGO-FUNCTION")
>> >
>> >which doesn't intern anything anywhere.
>>
>> But you could run into trouble in some ACL configurations, which default to
>> :DOWNCASE.
>
>Although as I understand it they are busy fixing this...?
>
>> Using keywords means it will work with any READTABLE-CASE
>> setting.
>
>I don't agree, since :export will only be recognized in uppercase.
>You must, at minimum, do
>
> (:EXPORT :frgo-function)
The configuration that defaults to :DOWNCASE also has lowercase names for
all the standard symbols, I believe. Franz has never, to my knowledge,
required programmers to write everything in uppercase.
--
Barry Margolin, ······@genuity.com
Genuity Managed Services, 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.
Frank Goenninger <················@goenninger.com> writes:
> (eval-when (:load-toplevel :compile-toplevel :execute)
> (defpackage :frgo
> (:use :common-lisp :common-lisp-user)
> (:export frgo-function))
> )
When Lisp reads this form, it interns frgo-function in the
current package, which is presumably COMMON-LISP-USER. In CMUCL,
SBCL and CLISP at least, this causes a symbol conflict error
later when trying to (use-package :frgo) from COMMON-LISP-USER.
(:export :frgo-function) would not have this problem.