Hello, All!
what is common way to resolve such conflicts - for example, both packages
odcl and cl-ppcre export split function, and i want function from cl-ppcre..
i've done it in such way:
(defpackage :lispyserver
(:shadow split)
(:use :common-lisp :cl-ppre :odcl :uncommonsql :lml2))
(in-package :lispyserver)
(defun split (&rest args)
(apply #'cl-ppre:split args))
is there a better way?
With best regards, Alex Mizrahi.
Hi Alex Mizrahi,
> Hello, All!
>
> what is common way to resolve such conflicts - for example, both
> packages odcl and cl-ppcre export split function, and i want function
> from cl-ppcre.
You have not described a conflict. Exported symbols do not conflict.
What you have indirectly done is also USE-PACKAGE on everything. Best
advice is to stop indiscriminately interning all symbols in CL-USER. What
is wrong with referring to odcl:split or cl-ppcre:split within your code?
Or even referring to shorter nicknames instead such as re:split?
The package system is virtually useless if the aim is to intern everything
in CL-USER (in fact we would be better off without it as authors would
choose different names for their functions such as odcl-split and
re-split). But this is not its aim and I'd advise against fighting it this
way. If you keep package prefixes within your code then you will only
encounter an issue if two packages use the same package name.
Regards,
Adam
On Mon, 06 Oct 2003 13:39:32 +1300, Adam Warner <······@consulting.net.nz> wrote:
> > what is common way to resolve such conflicts - for example, both
> > packages odcl and cl-ppcre export split function, and i want
> > function from cl-ppcre.
>
> You have not described a conflict. Exported symbols do not conflict.
AllegroCL, LispWorks, CMUCL, SBCL, and CLISP all call it a conflict,
so the compiler writers don't seem to agree with your terminology.
> What you have indirectly done is also USE-PACKAGE on
> everything. Best advice is to stop indiscriminately interning all
> symbols in CL-USER.
The OP didn't "indiscriminately" intern all symbols in CL-USER. He
created his own package and used the :USE option of DEFPACKAGE. You
seem to imply that this should not be done. Why?
> What is wrong with referring to odcl:split or cl-ppcre:split within
> your code?
Much more typing.
> The package system is virtually useless if the aim is to intern
> everything in CL-USER (in fact we would be better off without it as
> authors would choose different names for their functions such as
> odcl-split and re-split).
So we should all fall back to C-style programming and pretend the
package system isn't there? "Hey, your 'Apache' library prefixes all
symbols with 'ap_' but my 'AdvancedPathnames' library also does
that. Now we have to functions named 'ap_get_content_length'. Bummer!"
To the OP: You might want to look at Tim Bradshaw's "Conduit" system:
<http://www.tfeb.org/lisp/hax.html#CONDUITS>
Edi.
Hi Edi Weitz,
>> > what is common way to resolve such conflicts - for example, both
>> > packages odcl and cl-ppcre export split function, and i want function
>> > from cl-ppcre.
>>
>> You have not described a conflict. Exported symbols do not conflict.
>
> AllegroCL, LispWorks, CMUCL, SBCL, and CLISP all call it a conflict, so
> the compiler writers don't seem to agree with your terminology.
I'm sorry I believe I've confused external and exported symbol
terminology. If I evaluate (export 'symbol) is SYMBOL not an exported
symbol?
You seem to be stating that external symbols must be inherited to be
exported. It was my understanding that exporting a symbol make it
accessible via one colon instead of two (i.e. the symbol becomes
accessible as an external symbol instead of an internal symbol) and that's
it unless one further attempts to inherit the symbol as an internal symbol
within another package.
That is, if ODCL and CL-PPCRE export the SPLIT function then SPLIT is
accessible as ODCL:SPLIT and CL-PPCRE:SPLIT respectively. If one wants the
function from CL-PPCRE then one can access it as CL-PPCRE:SPLIT. The
exported(?) symbols do not conflict.
Regards,
Adam
On Tue, 07 Oct 2003 00:26:01 +1300, Adam Warner <······@consulting.net.nz> wrote:
> >> > what is common way to resolve such conflicts - for example,
> >> > both packages odcl and cl-ppcre export split function, and i
> >> > want function from cl-ppcre.
> >>
> >> You have not described a conflict. Exported symbols do not
> >> conflict.
> >
> > AllegroCL, LispWorks, CMUCL, SBCL, and CLISP all call it a
> > conflict, so the compiler writers don't seem to agree with your
> > terminology.
>
> I'm sorry I believe I've confused external and exported symbol
> terminology. If I evaluate (export 'symbol) is SYMBOL not an
> exported symbol?
>
> You seem to be stating that external symbols must be inherited to be
> exported. It was my understanding that exporting a symbol make it
> accessible via one colon instead of two (i.e. the symbol becomes
> accessible as an external symbol instead of an internal symbol) and
> that's it unless one further attempts to inherit the symbol as an
> internal symbol within another package.
>
> That is, if ODCL and CL-PPCRE export the SPLIT function then SPLIT
> is accessible as ODCL:SPLIT and CL-PPCRE:SPLIT respectively. If one
> wants the function from CL-PPCRE then one can access it as
> CL-PPCRE:SPLIT. The exported(?) symbols do not conflict.
I was referring to your first sentence, not to the second one. It is
true that the exported symbols do not conflict as long as they aren't
interned but I don't understand why you stated that the OP hadn't
described a conflict (not in the part you quoted but in his original
message).
Edi.
even if a.warner does not want to admit it, he is correct. the o.p. was
what is common way to resolve such conflicts - for example, both
packages odcl and cl-ppcre export [a] split function, and i want
[the] function from cl-ppcre..
i've done it in such way:
(defpackage :lispyserver
(:shadow split)
(:use :common-lisp :cl-ppre :odcl :uncommonsql :lml2))
(in-package :lispyserver)
(defun split (&rest args)
(apply #'cl-ppre:split args))
is there a better way?
if you go back to steele, the term is defined as
a _name conflict_ is said to occur when there is more than one candidate
symbol and it is not obvious which one to choose.
from which it follows, that a conflict arises neither from the existence of a
symbol, nor from its presence among the external symbols in a given package. a
conflict is not inherent in a symbol, but a consequence of perspective. they
arise entirely as a consequence of assertions made in the process of
inheriting or interning symbols.
the difference in emphasis matters.
that is, the o.p. did not describe a conflict. neither in the statement that
"both packages odcl and cl-ppcre export [a] split function" nor in the
proposed definition of the :lispyserver package.
one does surmise that they intended to have said that they would like to
define a package with reference to which it is possible to use exported
symbols from both the cl-ppre and odcl packages without using package
qualifiers. and that they are aware that, were they to simply rely on
inheritance to accomplish this and to simply specify the inheritance by using
the respective packages, then a conflict would arise.
given which, from the perspective of constructing a view, it is clear that the
answer is to use shadowing-import-from. as in
(defpackage :one (:export :a :b))
(defpackage :two (:export :b :c))
(defpackage :three (:shadowing-import-from :one :b)
(:use :one :two))
(let ((*package* (find-package :three))) (read-from-string "(A B C)"))
=>
(ONE:A ONE:B TWO:C)
...
Hi Edi Weitz,
> On Tue, 07 Oct 2003 00:26:01 +1300, Adam Warner
> <······@consulting.net.nz> wrote:
>
>> >> > what is common way to resolve such conflicts - for example, both
>> >> > packages odcl and cl-ppcre export split function, and i want
>> >> > function from cl-ppcre.
>> >>
>> >> You have not described a conflict. Exported symbols do not conflict.
>> >
>> > AllegroCL, LispWorks, CMUCL, SBCL, and CLISP all call it a conflict,
>> > so the compiler writers don't seem to agree with your terminology.
>>
>> I'm sorry I believe I've confused external and exported symbol
>> terminology. If I evaluate (export 'symbol) is SYMBOL not an exported
>> symbol?
>>
>> You seem to be stating that external symbols must be inherited to be
>> exported. It was my understanding that exporting a symbol make it
>> accessible via one colon instead of two (i.e. the symbol becomes
>> accessible as an external symbol instead of an internal symbol) and
>> that's it unless one further attempts to inherit the symbol as an
>> internal symbol within another package.
>>
>> That is, if ODCL and CL-PPCRE export the SPLIT function then SPLIT is
>> accessible as ODCL:SPLIT and CL-PPCRE:SPLIT respectively. If one wants
>> the function from CL-PPCRE then one can access it as CL-PPCRE:SPLIT.
>> The exported(?) symbols do not conflict.
>
> I was referring to your first sentence, not to the second one. It is
> true that the exported symbols do not conflict as long as they aren't
> interned but I don't understand why you stated that the OP hadn't
> described a conflict (not in the part you quoted but in his original
> message).
Edi, I wasn't referring to the code. I was referring to the word
description of the code. It's unfortunate I was so unclear. My "better
way" was a suggestion to avoid symbol conflicts by simply not inheriting
so many symbols. The point I was trying to belabour is that using a
package should be an explicit decision. Any type of symbol conflict would
be very rare if MISUSE-PACKAGE (or :MISUSE) was used less expansively.
The final point I was making in my original reply is that annoying
inheritance conflicts should be expected if a package has been constructed
_to take advantage of the package system_. With the CL package system one
can export very generic names without creating any conflicts. Conflicts
only arise if one tries to USE-PACKAGE. USE-PACKAGE fights against the
package system and should be used sparingly.
You inverted my position by potentially characterising it as "we should
all fall back to C-style programming and pretend the package system isn't
there". Remember I was the one suggesting that more use be made of
explicit package prefixes. One can pretend the package system isn't
there by making provision for USE-PACKAGE without the likelihood of
conflicts. And then the exported symbols in a package may look something
like this (CMUCL, :invert readtable mode):
* (do-external-symbols (symbol "UNIX")
(let ((string (symbol-name symbol)))
(when (and (>= (length string) 4)
(string= (subseq string 0 4) "UNIX"))
(print symbol))))
unix:unix-mmap
unix:unix-connect
unix:unix-sigsetmask
unix:unix-errno
unix:unix-fd
unix:unix-fstat
unix:unix-chdir
unix:unix-symlink
unix:unix-access
unix:unix-tcflush
unix:unix-ftruncate
unix:unix-select
unix:unix-close
unix:unix-getgrgid
unix:unix-kill
unix:unix-gethostid
unix:unix-fork
unix:unix-killpg
unix:unix-link
unix:unix-isatty
unix:unix-getgid
unix:unix-getpid
unix:unix-getuid
unix:unix-setsockopt
unix:unix-setitimer
unix:unix-chmod
unix:unix-cfgetospeed
unix:unix-fast-getrusage
unix:unix-fchown
unix:unix-file-kind
unix:unix-setregid
unix:unix-getpgrp
unix:unix-tcflow
unix:unix-dup2
unix:unix-getegid
unix:unix-readlink
unix:unix-cfsetispeed
unix:unix-cfgetispeed
unix:unix-setgid
unix:unix-exit
unix:unix-write
unix:unix-current-directory
unix:unix-getpagesize
unix:unix-tcsetattr
unix:unix-signal-description
unix:unix-tcgetattr
unix:unix-tcdrain
unix:unix-times
unix:unix-lseek
unix:unix-pathname
unix:unix-fchmod
unix:unix-rmdir
unix:unix-sigpause
unix:unix-read
unix:unix-getsockname
unix:unix-resolve-links
unix:unix-setreuid
unix:unix-uname
unix:unix-sync
unix:unix-unlink
unix:unix-dup
unix:unix-socket
unix:unix-lockf
unix:unix-mkdir
unix:unix-open
unix:unix-execve
unix:unix-recv
unix:unix-ioctl
unix:unix-pipe
unix:unix-setpgrp
unix:unix-bind
unix:unix-setuid
unix:unix-signal-name
unix:unix-pid
unix:unix-munmap
unix:unix-fast-select
unix:unix-getrusage
unix:unix-stat
unix:unix-gethostname
unix:unix-truncate
unix:unix-file-mode
unix:unix-sched-yield
unix:unix-ttyname
unix:unix-accept
unix:unix-getpeername
unix:unix-getppid
unix:unix-tcsendbreak
unix:unix-getsockopt
unix:unix-gid
unix:unix-send
unix:unix-getpwuid
unix:unix-gettimeofday
unix:unix-simplify-pathname
unix:unix-creat
unix:unix-getpwnam
unix:unix-utimes
unix:unix-lstat
unix:unix-maybe-prepend-current-directory
unix:unix-cfsetospeed
unix:unix-setpgid
unix:unix-fcntl
unix:unix-getdtablesize
unix:unix-msync
unix:unix-rename
unix:unix-sigblock
unix:unix-uid
unix:unix-getgrnam
unix:unix-listen
unix:unix-getitimer
unix:unix-signal-number
unix:unix-fsync
unix:unix-chown
Regards,
Adam
In article <······························@consulting.net.nz>,
Adam Warner <······@consulting.net.nz> wrote:
>Edi, I wasn't referring to the code. I was referring to the word
>description of the code. It's unfortunate I was so unclear. My "better
>way" was a suggestion to avoid symbol conflicts by simply not inheriting
>so many symbols.
The main benefit of exporting symbols, IMHO, is for the purpose of
inheriting them. Yes, it also allows you to refer to the symbol explicitly
using one colon instead of two, but that's a minor difference. Your answer
is basically:
Patient: Doctor, it hurts when I do this.
Doctor: Don't do that.
The answer to the OP's issue, I think, is to use the :SHADOWING-IMPORT-FROM
option for the symbol name that exists in both packages. This allows you
to specify which of the two should be used in the new package.
--
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.
(message (Hello 'Adam)
(you :wrote :on '(Mon, 06 Oct 2003 13:39:32 +1300))
(
>> what is common way to resolve such conflicts - for example, both
>> packages odcl and cl-ppcre export split function, and i want function
>> from cl-ppcre.
AW> You have not described a conflict. Exported symbols do not conflict.
cmucl reported conflict when i've :used both packages w/o shadowing. i've
thought it's quite easy to deduce where the conflict was..
btw, if i use lispworks i could not ask this question - it offers
'shadowing-import the conflicting symbol' among restarts, when cmucl, as i
remember, offers only 'uninterning conflicting symbol from it's home
package'.
AW> What you have indirectly done is also USE-PACKAGE on everything.
AW> Best advice is to stop indiscriminately interning all symbols in
AW> CL-USER.
i've made package in which i can refer to symbols which i believe i'll use
frequently w/o package name. it has nothing with cl-user.
AW> What is wrong with referring to odcl:split or cl-ppcre:split within
AW> your code? Or even referring to shorter nicknames instead such as
AW> re:split?
it's unclean code. i hate when there are parts in code that do not describe
algorithm but some insignificant technical details. it consumes time when
typing, it consumes time when reading, debugging..
well, possibly re:split is ok, but odcl:split as well as other functions
like odcl:ensure-string look very bad in my opinion.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
Alex Mizrahi wrote:
>
> (message (Hello 'Adam)
> (you :wrote :on '(Mon, 06 Oct 2003 13:39:32 +1300))
> (
>
> >> what is common way to resolve such conflicts - for example, both
> >> packages odcl and cl-ppcre export split function, and i want function
> >> from cl-ppcre.
>
> AW> You have not described a conflict. Exported symbols do not conflict.
>
> cmucl reported conflict when i've :used both packages w/o shadowing. i've
> thought it's quite easy to deduce where the conflict was..
if you deduced that the conflict was between the respective definitions for
:odcl and :cl-ppcre you made an error. it may be a fine point, but it
evidently makes a difference as to how one approaches rectifying a conflict
which arises by _importing_ symbols with equal names from distinct packages or
_using_ distinct packages which export symbols which fall into that category.
> btw, if i use lispworks i could not ask this question - it offers
> 'shadowing-import the conflicting symbol' among restarts, when cmucl, as i
> remember, offers only 'uninterning conflicting symbol from it's home
> package'.
the former of which is a clue, that the answer is to be found in the
definition for :lispyserver. that is, it needs to use :shadowing-import-from.
>
> ...
>
> AW> What is wrong with referring to odcl:split or cl-ppcre:split within
> AW> your code? Or even referring to shorter nicknames instead such as
> AW> re:split?
>
> it's unclean code. i hate when there are parts in code that do not describe
> algorithm but some insignificant technical details. it consumes time when
> typing, it consumes time when reading, debugging..
> well, possibly re:split is ok, but odcl:split as well as other functions
> like odcl:ensure-string look very bad in my opinion.
one concern is that they not only "look bad", but produces multiple points in
the source where the implementation with respect to the :lispyserver package
depends on definitions a packaged named :odcl. where the package definition
(or definition file(s)) express(es) this dependancy, there is a single point
where it can be changed.
defpackage is your friend. use it well.
...
james anderson <··············@setf.de> writes:
> one concern is that they not only "look bad", but produces multiple points in
> the source where the implementation with respect to the :lispyserver package
> depends on definitions a packaged named :odcl. where the package definition
> (or definition file(s)) express(es) this dependancy, there is a single point
> where it can be changed.
This reminds me of something I have been wondering about. Is there a
way to give a package a nickname without doing any intrusive changes
in the package code itself? Ie, if I want to use a 3rd party package
"regular-expression", can I nickname it "re" without changing anything
about the code of that package itself? If so, it would both enable me
to use short, appropriate names for 3rd party packages, as well as
solving the problem you mention above, since then the actual package
name would only be mentioned in one place, and can thus be easily
changed.
I suppose one way would be to just create a new package "re" which in
turn is using "regular-expression". Is there any drawback to such a
method?
Bj�rn
Bj�rn Lindberg wrote:
> james anderson <··············@setf.de> writes:
>
>
>>one concern is that they not only "look bad", but produces multiple points in
>>the source where the implementation with respect to the :lispyserver package
>>depends on definitions a packaged named :odcl. where the package definition
>>(or definition file(s)) express(es) this dependancy, there is a single point
>>where it can be changed.
>
>
> This reminds me of something I have been wondering about. Is there a
> way to give a package a nickname without doing any intrusive changes
> in the package code itself? Ie, if I want to use a 3rd party package
> "regular-expression", can I nickname it "re" without changing anything
> about the code of that package itself? If so, it would both enable me
> to use short, appropriate names for 3rd party packages, as well as
> solving the problem you mention above, since then the actual package
> name would only be mentioned in one place, and can thus be easily
> changed.
>
> I suppose one way would be to just create a new package "re" which in
> turn is using "regular-expression". Is there any drawback to such a
> method?
don't know, but what about rename-package? it also works on nicknames...
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Marco Baringer
Subject: Re: name conflicts in packages
Date:
Message-ID: <m28ynxf502.fsf@bese.it>
·······@nada.kth.se (Bj�rn Lindberg) writes:
> This reminds me of something I have been wondering about. Is there a
> way to give a package a nickname without doing any intrusive changes
> in the package code itself?
rename-package
? (make-package "REALLY-LONG-NAME")
#<Package "REALLY-LONG-NAME">
? (defvar really-long-name::a 'bob!)
REALLY-LONG-NAME::A
? (rename-package "REALLY-LONG-NAME" "REALLY-LONG-NAME" (list "RE"))
#<Package "REALLY-LONG-NAME">
? RE::A
BOB!
If you want to be carefull and make sure that old nicknames continue
to exist you'll need to do something like:
(rename-package "REALLY-LONG-NAME" "REALLY-LONG-NAME"
(append (package-nicknames "REALLY-LONG-NAME")
(list "RE")))
> I suppose one way would be to just create a new package "re" which in
> turn is using "regular-expression". Is there any drawback to such a
> method?
but then you have to manually re-export the symbols
regular-expression exports from re.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
> ...
>
> If you want to be carefull and make sure that old nicknames continue
> to exist you'll need to do something like:
>
> (rename-package "REALLY-LONG-NAME" "REALLY-LONG-NAME"
> (append (package-nicknames "REALLY-LONG-NAME")
> (list "RE")))
>
> > I suppose one way would be to just create a new package "re" which in
> > turn is using "regular-expression". Is there any drawback to such a
> > method?
>
> but then you have to manually re-export the symbols
> regular-expression exports from re.
>
if you know what you want to do, it need not be manual. i recall that cl-http
does some of this. you can also look at http://www.cl-xml.org/library/de/setf/utility/package.lisp.
...
if you look back through the c.l.l archives you may find some posts from
k.pitman which described ways to load multiple versions of a given thing by
renaming packages.
...
Bj�rn Lindberg wrote:
>
> ...
>
> This reminds me of something I have been wondering about. Is there a
> way to give a package a nickname without doing any intrusive changes
> in the package code itself?
rename-package
> Ie, if I want to use a 3rd party package
> "regular-expression", can I nickname it "re" without changing anything
> about the code of that package itself?
"the code of that package itself" is a strange term. in a strict sense that
code is limited to the respective defpackage (and related) form(s).
i suspect the intended meaning was "the definitions named with symbols which
are accessible with reference to that package." neither a symbol's home
package, nor the packages with respect to which it is visible are related to
the things to which it can be bound. in some senses, modulo keywords, but then note:
? (defparameter *asdf* :asdf)
*ASDF*
? (type-of *asdf*)
KEYWORD
? (unintern :asdf :keyword)
T
? (type-of *asdf*)
SYMBOL
? (set *asdf* 1)
> Error: Can't redefine constant #:ASDF .
> While executing: SET
> Type Command-. to abort.
See the Restarts� menu item for further choices.
1 > (symbol-package *asdf*)
NIL
1 >
Aborted
?
that is, it is not clear whether the relation between constancy, the keyword
package, the keyword type, and a symbol is completely specified.
> If so, it would both enable me
> to use short, appropriate names for 3rd party packages, as well as
> solving the problem you mention above, since then the actual package
> name would only be mentioned in one place, and can thus be easily
> changed.
>
> I suppose one way would be to just create a new package "re" which in
> turn is using "regular-expression". Is there any drawback to such a
> method?
symbols are first class, as are packages. if you know what you want to do, and
know what you are doing, you can move them around to your hearts content.
>
> Bj�rn
james anderson <··············@setf.de> writes:
> if you look back through the c.l.l archives you may find some posts from
> k.pitman which described ways to load multiple versions of a given thing by
> renaming packages.
> ...
>
> Bj�rn Lindberg wrote:
> >
> > ...
> >
> > This reminds me of something I have been wondering about. Is there a
> > way to give a package a nickname without doing any intrusive changes
> > in the package code itself?
>
> rename-package
Thanks, I didn't know about rename-package. It solves the problem nicely.
> > Ie, if I want to use a 3rd party package
> > "regular-expression", can I nickname it "re" without changing anything
> > about the code of that package itself?
>
> "the code of that package itself" is a strange term. in a strict sense that
> code is limited to the respective defpackage (and related) form(s).
I know, it came out a little strange. What I wanted to rule out was to
change the actual defpackage form of the package in question. Ie, if I
have the source to the package "regular-expression", I can of course
give it another nickname simply by adding it in the defpackage
form. My strange formulation was really only to imply that I was
looking for a solution that needn't touch the source files of the
package (or RE library in this case).
<snip>
> symbols are first class, as are packages. if you know what you want
> to do, and know what you are doing, you can move them around to your
> hearts content.
That is what I am eventually getting used to. :-)
Bj�rn
Bj�rn Lindberg wrote:
>
> ...
>
> I know, it came out a little strange. What I wanted to rule out was to
> change the actual defpackage form of the package in question. Ie, if I
> have the source to the package "regular-expression", I can of course
> give it another nickname simply by adding it in the defpackage
> form. My strange formulation was really only to imply that I was
> looking for a solution that needn't touch the source files of the
> package (or RE library in this case).
>
? (defpackage :regular-expression
(:export :match))
#<Package "REGULAR-EXPRESSION">
? (defun regular-expression:match (? exp) (rest (assoc ? exp)))
REGULAR-EXPRESSION:MATCH
? (regular-expression:match 'a '((1 . 2) (a . b)))
B
? (rename-package :regular-expression :re)
#<Package "RE">
? (re:match 1 '((1 . 2) (a . b)))
2
? (find-package :regular-expression)
NIL
?
Hi Alex Mizrahi,
> i've made package in which i can refer to symbols which i believe i'll
> use frequently w/o package name. it has nothing with cl-user.
Indeed my mentioning of "CL-USER" was a mistake, sorry. You were interning
all the exported symbols from the packages "COMMON-LISP" (naturally),
"CL-PPRE", "ODCL", "UNCOMMONSQL" and "LML2" in "LISPYSERVER".
Good luck,
Adam
"Alex Mizrahi" <·········@xhotmail.com> writes:
> Hello, All!
>
> what is common way to resolve such conflicts - for example, both packages
> odcl and cl-ppcre export split function, and i want function from cl-ppcre..
>
> i've done it in such way:
>
> (defpackage :lispyserver
> (:shadow split)
> (:use :common-lisp :cl-ppre :odcl :uncommonsql :lml2))
> (in-package :lispyserver)
>
> (defun split (&rest args)
> (apply #'cl-ppre:split args))
>
> is there a better way?
Well, I would have done
(defmacro split (&rest args)
`(cl-ppre:split ,@args))
instead.
In any case it is probably better still to use SHADOWING-INPORT. See
http://www.lispworks.com/reference/HyperSpec/Body/f_shdw_i.htm
Regards,
Mario.
"Alex Mizrahi" <·········@xhotmail.com> writes:
> Hello, All!
>
> what is common way to resolve such conflicts - for example, both packages
> odcl and cl-ppcre export split function, and i want function from cl-ppcre..
>
> i've done it in such way:
>
> (defpackage :lispyserver
> (:shadow split)
> (:use :common-lisp :cl-ppre :odcl :uncommonsql :lml2))
I would have done:
(defpackage :lispyserver
(:shadowing-import-from :cl-ppre "SPLIT")
(:use :common-lisp :cl-ppre :odcl :uncommonsql :lml2))
This gets you the symbol you want directly.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <··············@cupid.igpm.rwth-aachen.de>,
Mario S. Mommer <········@yahoo.com> wrote:
>"Alex Mizrahi" <·········@xhotmail.com> writes:
>> (defun split (&rest args)
>> (apply #'cl-ppre:split args))
>>
>> is there a better way?
>
>Well, I would have done
>
>(defmacro split (&rest args)
> `(cl-ppre:split ,@args))
>
>instead.
That would break (funcall/apply #'split ...). If the extra apply is
causing a performance problem you could use a compiler optimizer.
--
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.