In article
<····································@d45g2000hsc.googlegroups.com>,
budden <········@mtu-net.ru> wrote:
> Hallo, group!
>
> Yes, I have read CL standard. But I think standard is not well defined
> in that:
>
> (defpackage :p1 (:exports :sym :sym1))
> (defpackage :p2 (:exports :sym :sym2))
> (use-package :p1)
> (use-package :p2) ; error occurs here
>
> 'sym ; but read error should occur here instead
Hmm, I would like to get the error as early as possible.
>
> Let us compare lisp's behaviour to that of SQL:
>
> create table p1 (sym int, sym1 int)
> create table p2 (sym int, sym2 int)
>
> select sym1, sym2 from p1 inner join p2 on sym1=sym2 -- no error!
>
> select sym from p1 inner join p2 on sym1=sym2 -- error: sym is
> ambigious
I'm not sure one can compare that.
>
> This behavior is more convinient and it still protects from error;
>
> I've seen http://www.tfeb.org/lisp/hax.html#CONDUITS by Tim Bradshaw
> and even tried them. Yes, it was possible to make :iterate package to
> live aside with "collecting" macro (synonyms were used too).
> But I don't think this is simple enough. In fact, it requires
> redefining of large amount of packages. It is especially difficult
> when you are trying to install complex system containing from several
> packages of different vendors (e.g. I had trouble with (:use-
> package :symbolicweb)).
>
> If we'd modified lisp behavior in the way I suggested, things would be
> much better, I guess.
>
> What do you think about that? Would such a modification popular if it
> were made as a patch similar to "conduits"?
What Tim describes seems useful.
Thinking about programming style:
I would think it is good to have different packages, but in
my software I try to avoid using packages with USE-PACKAGE,
unless that is really what I want. For example
if I'd write a drawing program, i prefer to have
in my SKETCH package source files calls to (graphics:draw-rectangle ...)
instead of just (draw-rectangle ...). It helps me when
reading the source to identify where the symbols are
coming from - sometimes the opposite is the goal.
Then I want symbols to look like 'built-in' symbols.
But I usually use that only for the core language I'm
programming in - everything that is more library like,
I prefer to have the package prefix.
--
http://lispm.dyndns.org/
> Hmm, I would like to get the error as early as possible.
Partially it can be considered as a matter of style, but not
completely.
Suppose that I use both p1 and p2, but use only sym1 and sym2 and
never use sym in my
program. Why should I care of this conflict? It does not matter for me
at all. So, if error is
deferred, it may not occur at all unless I have (read) trying to
(intern "SYM"). It gives just
more flexibility.
> I'm not sure one can compare that.
Each database table involved in a select statement is like a package.
It creates one's own namespace of
its fields. When you join two tables, it looks like creating new
namespace from joining field namespaces from both
tables. I used to write large database application, about 100 tables.
Each table have its own "id"
column. If SQL were as strict as lisp according to name conflicts, I
was unable to have equally named columns
in any two distinct tables.
> Thinking about programming style:
Again, I'd like to mention symbolicweb. In fact, it is a language
combined from several packages and
several DSL's. It uses hunchentoot, cl-who, cl-utilities, and
symbolicweb itself. How should its use
to be organized?
1. Symbolicweb's author suggests a package where only symbolicweb
symbols are exported. This way, I need to learn
all packages it relies upon. If there are symbol clashes, I need to
resolve them at install time. How would I do that if I
am new to that system. I need to remember which symbol is from which
package. My code gets much longer if I don't import
that packages, e.g. cl-who.
2. Symbolicweb's author suggsets an integral package where required
symbols from hunchentoot, cl-who, etc.
This way, I have symbolicweb as an integral system, and I have to
learn it as a whole. So we use now not a "just CL", but a "CL extended
for web". I need to import just only one package. If I want to know
where the symbol come from, I use "go to source" command from my
development environment.
Are you sure that first way is definitely preferreable one? On my
opinion, it contradicts to idea of DSL, which should be something new
whole thing.
And, if someone do not like to "use packages", one is free not to use
them independently of either symbol clash error is deferred or not.
Topic discussed is absolutely orthogonal to that stylystic
preference.
In article
<····································@t41g2000hsc.googlegroups.com>,
budden <········@mtu-net.ru> wrote:
> > Hmm, I would like to get the error as early as possible.
> Partially it can be considered as a matter of style, but not
> completely.
> Suppose that I use both p1 and p2, but use only sym1 and sym2 and
> never use sym in my
> program. Why should I care of this conflict? It does not matter for me
> at all. So, if error is
> deferred, it may not occur at all unless I have (read) trying to
> (intern "SYM"). It gives just
> more flexibility.
Common Lisp packages try to avoid these conflicts
upfront. If you look up a symbol in a package,
there are exactly two situations: a) the symbol is
in the package or b) the symbol is not in
the package. There is no c) the symbol is in the package,
but we don't know which symbol it is, because there
might be more than one. I certainly don't want programs
to ask me every time a conflict arises
at runtime which symbol I want.
Remember: packages are not modules for programs.
Packages are namespaces for symbols. Symbols have
many uses in Lisp.
If I make a declarative statements about the namespace
and the there is obvious problem with one of these statements,
I want to know that. Solving package problems at runtime
is even less fun than solving package problems
at declaration time.
>
> > I'm not sure one can compare that.
> Each database table involved in a select statement is like a package.
> It creates one's own namespace of
> its fields. When you join two tables, it looks like creating new
> namespace from joining field namespaces from both
> tables. I used to write large database application, about 100 tables.
> Each table have its own "id"
> column. If SQL were as strict as lisp according to name conflicts, I
> was unable to have equally named columns
> in any two distinct tables.
I don't buy that. If identifiers are in different packages
that's fine. The conflict arises when you want to use
different identifiers with the same name in one namespace
or when you refer to different identifiers in different
namespaces with just the name.
Example: In Common Lisp you can use identifiers with the
same name for slot values in different classes without
problems.
> > Thinking about programming style:
> Again, I'd like to mention symbolicweb. In fact, it is a language
> combined from several packages and
> several DSL's. It uses hunchentoot, cl-who, cl-utilities, and
> symbolicweb itself. How should its use
> to be organized?
>
> 1. Symbolicweb's author suggests a package where only symbolicweb
> symbols are exported. This way, I need to learn
> all packages it relies upon. If there are symbol clashes, I need to
> resolve them at install time. How would I do that if I
> am new to that system. I need to remember which symbol is from which
> package. My code gets much longer if I don't import
> that packages, e.g. cl-who.
You can program that. You don't have to remember which
symbol is from which package - you can ask packages
about their symbols.
In my personal experience 1. is easier to maintain in the
long run.
> 2. Symbolicweb's author suggsets an integral package where required
> symbols from hunchentoot, cl-who, etc.
> This way, I have symbolicweb as an integral system, and I have to
> learn it as a whole. So we use now not a "just CL", but a "CL extended
> for web". I need to import just only one package. If I want to know
> where the symbol come from, I use "go to source" command from my
> development environment.
Sure, it is a bit of a pain. Usually one would not
construct packages by combining packages on a user level.
The user would use a package that has been provided
by the library writer. I would the just use "COMMON-LISP"
+ "HTML" in my package "RJCLH" (or what ever never I like).
If I want to combine arbitrary packages into one, I have
to resolve the conflicts. I can do that manually
or programmatically. Both are a pain. But I feel
if you really want to resolve conflicts, than there
is no way around it.
I simply don't think that deferring resolving conflicts
to FIND-SYMBOL is the answer.
As I said, having packages with all kinds of symbols from
different domains may not be a good idea in the end.
What use are packages
to divide the namespace when one at the end imports lots
of those symbols again into one package?
To find out about a symbol there are several ways:
(symbol-package 'foo)
(describe 'foo)
(documentation 'foo 'function)
The development environment will provide some of the
above on editor commands.
>
> Are you sure that first way is definitely preferreable one? On my
> opinion, it contradicts to idea of DSL, which should be something new
> whole thing.
>
> And, if someone do not like to "use packages", one is free not to use
> them independently of either symbol clash error is deferred or not.
> Topic discussed is absolutely orthogonal to that stylystic
> preference.
--
http://lispm.dyndns.org/