Hello all,
I have another problem with my decent recursive parser library.
The package of this library exports a few symbols, one of these being the
"conc" symbol.
This symbol is only used as a marker for the make-parser macro.
I need to use this make-parser in a web application in order to define a
grammar for url parsing. So i have this kind of declaration :
(defpackage :web-app-gui
(:use :common-lisp :cl-who :tbnl :cl-drp :web-app-dal))
As you can see, the web application is using the cl-who library (from Edi
Weitz) as well, which is exporting a symbol (a function really) with the
same symbol name "conc". So you guessed it, there is a naming conflict with
these two symbols.
I could change the name of this symbol in my parser library, but this
doesn't teach me anything.
Or maybe not "use-package" the library and use fully qualified symbol names.
But now i'm bound to use very long symbol names in the production rules of
my parser, which really doesn't make sense.
The conc symbol means concatenation and is used like this :
(defrule a "a")
(defrule b "b")
(defrule c "c")
(defrule a-then-b-then-c (conc a b c))
-> matches "abc"
I can't imagine writing
(defrule a-then-b-then-c (cl-drp:conc a b c))
Not that bad on this single rule, but when you get a couple pages of these,
it gets rather hard to read.
How would you old-timers solve this problem ?
Thanks in advance,
Sacha
Sacha wrote:
> Hello all,
>
> I have another problem with my decent recursive parser library.
> The package of this library exports a few symbols, one of these being the
> "conc" symbol.
> This symbol is only used as a marker for the make-parser macro.
>
> I need to use this make-parser in a web application in order to define a
> grammar for url parsing. So i have this kind of declaration :
>
> (defpackage :web-app-gui
> (:use :common-lisp :cl-who :tbnl :cl-drp :web-app-dal))
>
> As you can see, the web application is using the cl-who library (from Edi
> Weitz) as well, which is exporting a symbol (a function really) with the
> same symbol name "conc". So you guessed it, there is a naming conflict with
> these two symbols.
Choose the symbol you'll be using most often using
:shadowing-import-from in your defpackage-form, then use the qualified
name when you need the other symbol.
--
mvh, Lars Rune Nøstdal
http://lars.nostdal.org/
>"Lars Rune N�stdal" <···········@gmail.com> wrote in message
>·····························@75g2000cwc.googlegroups.com...
>
>Choose the symbol you'll be using most often using
>:shadowing-import-from in your defpackage-form, then use the qualified
>name when you need the other symbol.
Thanks you, this worked right away.
Sacha
Sacha wrote:
> Hello all,
>
> I have another problem with my decent recursive parser library.
> The package of this library exports a few symbols, one of these being the
> "conc" symbol.
Uhm, or if you want to create a new symbol `conc' in your own
library/package use :shadow .. (see `defpackage' in the hyperspec).
--
mvh, Lars Rune Nøstdal
http://lars.nostdal.org/
Sacha wrote:
> I need to use this make-parser in a web application in order to define a
> grammar for url parsing. So i have this kind of declaration :
>
> (defpackage :web-app-gui
> (:use :common-lisp :cl-who :tbnl :cl-drp :web-app-dal))
Note that USE-PACKAGE and the related :USE syntax in the DEFPACKAGE
macro are a crude tool. When you USE a package, you are
indiscriminately bringing in all of its exported symbols. So yes,
clashes can happen, because people often think of the same symbols.
This is particularly true when people use packages, because then they
(rightly) think they are free to use short simple names.
Even if there are no conflicts now, they can arise in the future, when
a code maintainer upgrades to new versions of some or all of the
packages! Some packages are particularly dangerous, like the various
extension packages provided by a Lisp implementation. Their contents
tend to churn in between releases.
Today, everything my be cool, but tomorrow, MYPACKAGE might get a CONC
symbol that is exported, and so might YOURPACKAGE.
Today everything loads, tomorrow it breaks.
It might be a good idea to implement package versioning. Instead of
blindly changing the contents of a package in between software
releases, make new versions of a package, e.g.
FOO-PACKAGE-1-0
FOO-PACKAGE-1-1
FOO-PACKAGE-1-2
FOO-PACKAGE-CURRENT
FOO-PACKAGE-CURRENT is where the latest churning is taking place. The
other packages import only the correct historic symbols from the
current one, and re-export them. So a program depending on just the 1-0
interface can readily :USE the FOO-PACKAGE-1-0, and know that it won't
be pulling in any new crap from FOO-PACKAGE-CURRENT.
> As you can see, the web application is using the cl-who library (from Edi
> Weitz) as well, which is exporting a symbol (a function really) with the
> same symbol name "conc". So you guessed it, there is a naming conflict with
> these two symbols.
>
> I could change the name of this symbol in my parser library, but this
> doesn't teach me anything.
> Or maybe not "use-package" the library and use fully qualified symbol names.
Or, better yet, specify the precise list of symbols that you want to
import from a package.
:import-from <package> <symbol> ...
:shadowing-import-from <package> <symbol> ...
Typically, :use is just used for some base package like COMMON-LISP.
You :use CL, and then from everything else you do a shadowing-import of
the specific symbols that you want.
The shadowing part takes care of any future clashes.
Say that from package FOO you shadowing-import the FROBOZZ symbol. If
the contents of the CL package change in the future so that CL exports
FROBOZZ, you are covered. The shadowing-import ensures that the
FOO:FROBOZZ silently wins over the CL one. A regular import will
complain about the conflict.
> But now i'm bound to use very long symbol names in the production rules of
> my parser, which really doesn't make sense.
Well, you do have to use a long name for /one/ of the two CONC's if you
have to refer to both of them in the same context. You have to pick.
> I can't imagine writing
> (defrule a-then-b-then-c (cl-drp:conc a b c))
Okay, then it's settled: it's your CONC that has to win. Do not import
the CONC symbol from Edi's package: refer to that as CL-WHO:CONC when
you need it.
There are other tricks you can pull, based on the semantics of that
symbol. For instance if CL-WHO:CONC names a function, you could create
an inline function with a different name in your package which calls
that one:
(defun wconc (&rest args) (apply #'cl-who:conc args))
If it's a constant, you could make your own constant which inherits its
value. Etc.
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| Sacha wrote:
| > I need to use this make-parser in a web application in order to define a
| > grammar for url parsing. So i have this kind of declaration :
| > (defpackage :web-app-gui
| > (:use :common-lisp :cl-who :tbnl :cl-drp :web-app-dal))
|
| Note that USE-PACKAGE and the related :USE syntax in the DEFPACKAGE
| macro are a crude tool. When you USE a package, you are
| indiscriminately bringing in all of its exported symbols. So yes,
| clashes can happen, because people often think of the same symbols.
...
| Or, better yet, specify the precise list of symbols that you want to
| import from a package.
| :import-from <package> <symbol> ...
| :shadowing-import-from <package> <symbol> ...
| Typically, :use is just used for some base package like COMMON-LISP.
| You :use CL, and then from everything else you do a shadowing-import of
| the specific symbols that you want.
+---------------
But one can still do all that in DEFPACKAGE, which supports :SHADOW
and :SHADOWING-IMPORT-FROM and explicitly defines the order of those
with respect to :USE as being what you normally want:
Macro DEFPACKAGE
...
The order in which the options appear in a defpackage form is
irrelevant. The order in which they are executed is as follows:
1. :shadow and :shadowing-import-from.
2. :use.
3. :import-from and :intern.
4. :export.
Shadows are established first, since they might be necessary to
block spurious name conflicts when the :use option is processed.
The :use option is executed next so that :intern and :export options
can refer to normally inherited symbols. The :export option is
executed last so that it can refer to symbols created by any of
the other options; in particular, shadowing symbols and imported
symbols can be made external.
So assuming a conflict between, say, WEB-APP-GUI:FOO and
WEB-APP-DAL:FOO, the following DEFPACKAGE will reliably avoid
the conflict, giving preference to the package being defined:
(defpackage :web-app-gui
(:use :common-lisp :cl-who :tbnl :cl-drp :web-app-dal)
(:shadow foo))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Thomas A. Russ
Subject: Re: same symbol name in 2 different packages
Date:
Message-ID: <ymimzb5z93f.fsf@sevak.isi.edu>
Summarizing:
Using multiple packages can cause name conflicts.
Explicitly importing (or shadowing-importing) can solve this.
So can explicit shadow, for local symbols.
Use package is often best used for system-level packages (in dispute)
My observation:
In general, for convenience using :USE makes things easier than the
explicit enumeration. But for maintenance, the explicit list makes life
easier.
The problem with :USE is future evoluation of the packages can introduce
new name conflicts where none existed before. It can even lead to the
inadvertent sabotage of new features in included packages if they
suddenly add a new function definition to a symbol with the same name as
one that you use. The :USE will change the symbol from the local one in
your package to the newly imported one from the used package.
Explicit lists avoid such problems, but if extensive use of most symbols
in a package is made, the lists can get unwieldy.
--
Thomas A. Russ, USC/Information Sciences Institute
> Note that USE-PACKAGE and the related :USE syntax in the DEFPACKAGE
> macro are a crude tool.
> When you USE a package, you are
> indiscriminately bringing in all of its exported symbols. So yes,
> clashes can happen, because people often think of the same symbols.
> This is particularly true when people use packages, because then they
> (rightly) think they are free to use short simple names.
>
> Even if there are no conflicts now, they can arise in the future, when
> a code maintainer upgrades to new versions of some or all of the
> packages! Some packages are particularly dangerous, like the various
> extension packages provided by a Lisp implementation. Their contents
> tend to churn in between releases.
<snip very long and interesting stuff>
Allright ! Hand-picking the imported symbols seems the way to go.
I didn't realize that.
I'll import specific symbols for now... and archive your input for future
reference on
this versioning problem.
Thanks a lot for your very complete explanation, I learned a lot reading it
!
The Symbols concept is powerfull, but it also creates its own problems,
I'll have to learn living with that.
Sacha