From: Kaz Kylheku
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <20081024161717.965@gmail.com>
On 2008-10-24, budden <········@mtu-net.ru> wrote:
> 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
By the way, if this is really SQL, it's being pitifully idiotic here.
I mean, what part of "SYM FROM P1" is not clear???
The "FROM P1" clause removes any ambiguity. There is a field SYM in P1 and
there is a field SYM in P2. We are joining both tables, but we specifically
asked for SYM from P1.
Are you sure this is correct SQL? Or maybe it's a bug in your SQL
implementation? It just seems too dumb to be true.
> This behavior is more convinient and it still protects from error;
But when you do get the error, how do you make it go away? We already said "SYM
FROM P1".
What else must you write to convince SQL that you really want SYm from table
P1?
Hallo, group!
I replied to the topic, but my message didn't appear. Don't know if
it is a bug or moderation?
> I'm not sure one can compare that.
Each sql table defines a namespace where every its field presents as a
symbol.
Joining two tables is equavalent to (locally) using both namespaces at
one time.
> Not well-defined means you don't know where the error should occur. Are you
sure what ``well-defined'' means?
Sorry for my English. Maybe "poorly designed" is more correct.
> Hmm, I would like to get the error as early as possible.
(defpackage :p1 (:exports :sym :sym1))
(defpackage :p2 (:exports :sym :sym2))
(use-package :p1)
(use-package :p2)
(print 'sym1)
; end of file
Does this program contain an error? Not in CL standard sence, in
common sence.
E.g. consider
you: We'll be talking about walrus and oysters
me: Package error: symbol 'eye' clashed
vs
you: We'll be talking about walrus and oysters
me: ok
you: first lets talk about a tusks
me: (have read tusk as walrus:tusk) ok
you: then about their eyes
me: (read error: symbol 'eye' clashes)
What conversation seem to be more adequate? Note that not only SQL
does so. Multiple inheritance in C++ shows symbol clash upon symbol
use, not upon
namespace merging. Namespace system in Pascal, $PATH feature in unix
shell silently ignore clashes and
give some random (or first found) occurance of symbol. C linker (as I
could recall) issues a warning.
And only the CL is so "smart" that it does not allow us to work
further until we resolve the conflict.
> I try to avoid using packages with USE-PACKAGE
It is just orthogonal to the topic discussed. If you don't use-
package, you have no symbol clashes anyway, are you? I prefer to have
my sources to be more short, hence I use-package.
> The "FROM P1" clause removes any ambiguity.
No, from clause is "from p1 inner join p2 on ...". Fields from both p1
and p2 are considered. I usually use MS SQL and Firebird.
but I think it is a standard behaviour. So there _is_ an ambiguity.
You see error is found at compile-time (as it should be).
When I get this error, I change my query to
"select p1.sym from p1 inner join p2 ..."
> What if symbol "SYM" is interned at run time? Maybe it occurs in a data
file which the running software will load.
Yes, we'll get a problem there. But package system might issue
warning, not an error while using-package.
Warning is sufficient for careful user. Not all programs read
something at run time. What if it is known
that we'll never intern "SYM" at run time? Why should we care this
conflict if it does not really
matter for us indeed? And we even _never_ going to use sym in our
application?
In article
<····································@h60g2000hsg.googlegroups.com>,
budden <········@mtu-net.ru> wrote:
> Hallo, group!
> I replied to the topic, but my message didn't appear. Don't know if
> it is a bug or moderation?
>
> > I'm not sure one can compare that.
> Each sql table defines a namespace where every its field presents as a
> symbol.
> Joining two tables is equavalent to (locally) using both namespaces at
> one time.
>
> > Not well-defined means you don't know where the error should occur. Are you
> sure what ``well-defined'' means?
> Sorry for my English. Maybe "poorly designed" is more correct.
>
> > Hmm, I would like to get the error as early as possible.
> (defpackage :p1 (:exports :sym :sym1))
> (defpackage :p2 (:exports :sym :sym2))
> (use-package :p1)
> (use-package :p2)
> (print 'sym1)
> ; end of file
>
> Does this program contain an error? Not in CL standard sence, in
> common sence.
To me it is totally clear, two symbols with the same name
imported into the same package -> error. What could be more clear?
>
> E.g. consider
>
> you: We'll be talking about walrus and oysters
> me: Package error: symbol 'eye' clashed
>
> vs
>
> you: We'll be talking about walrus and oysters
> me: ok
> you: first lets talk about a tusks
> me: (have read tusk as walrus:tusk) ok
> you: then about their eyes
> me: (read error: symbol 'eye' clashes)
I don't think human communication is a particular good
comparison. Common Lisp is not an 'artificial intelligence'
in itself.
>
> What conversation seem to be more adequate? Note that not only SQL
> does so. Multiple inheritance in C++ shows symbol clash upon symbol
> use, not upon
> namespace merging. Namespace system in Pascal, $PATH feature in unix
> shell silently ignore clashes and
> give some random (or first found) occurance of symbol. C linker (as I
> could recall) issues a warning.
> And only the CL is so "smart" that it does not allow us to work
> further until we resolve the conflict.
>
> > I try to avoid using packages with USE-PACKAGE
> It is just orthogonal to the topic discussed. If you don't use-
> package, you have no symbol clashes anyway, are you? I prefer to have
> my sources to be more short, hence I use-package.
>
> > The "FROM P1" clause removes any ambiguity.
> No, from clause is "from p1 inner join p2 on ...". Fields from both p1
> and p2 are considered. I usually use MS SQL and Firebird.
> but I think it is a standard behaviour. So there _is_ an ambiguity.
>
> You see error is found at compile-time (as it should be).
> When I get this error, I change my query to
> "select p1.sym from p1 inner join p2 ..."
>
> > What if symbol "SYM" is interned at run time? Maybe it occurs in a data
> file which the running software will load.
>
> Yes, we'll get a problem there. But package system might issue
> warning, not an error while using-package.
> Warning is sufficient for careful user. Not all programs read
> something at run time. What if it is known
> that we'll never intern "SYM" at run time? Why should we care this
> conflict if it does not really
> matter for us indeed? And we even _never_ going to use sym in our
> application?
I has nothing to do with READ. All software that will try to
look up a symbol (and that is more than just the software that
uses READ or loads code) would have lazy namespace clashes -
in a dynamic language open to all kinds of runtime changes.
That would not be a good idea.
LispWorks for example provides me with the following restarts
when USE-PACKAGE detects a symbol clash:
HTTP-USER 65 : 1 > :error
Error: Using package P1 results in a name conflict for this symbol: SYM.
1 (continue) Unintern the conflicting symbol from its home package.
2 Shadow the conflicting symbols.
3 Shadowing-import the conflicting symbol already visible in HTTP-USER.
4 Shadowing-import the conflicting symbol from P1.
5 Skip using P1 by HTTP-USER.
6 (abort) Return to level 0.
7 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
NIL
HTTP-USER 66 : 1 > :cc
#<CONDITIONS:SYMBOL-NAME-CONFLICT 42B056320B>
HTTP-USER 67 : 1 > (describe *)
#<CONDITIONS:SYMBOL-NAME-CONFLICT 42B056320B> is a CONDITIONS:SYMBOL-NAME-CONFLICT
REPORTER-FUNCTION #<Function 1 subfunction of (DEFINE-CONDITION CONDITIONS:SYMBOL-NAME-CONFLICT) 4110963D44>
SYMBOL-LIST (SYM)
PACKAGE "P1"
So there is also a condition class for that and the condition
has some slots with information about the problem.
So one can write error handling code.
The thing what ANSI CL lacks is more standardized condition
classes.
--
http://lispm.dyndns.org/
ïk, I see there is some delay until message occurs in a group. Sorry
for duplicate messages.
Behavior I desire can be achieved when use-package would do the
following:
i) if current package is a home package for one of conflicting
symbols, this symbol is kept and other is not interned.
ii) if both symbols are not of current package, they both are
unimported.
What this would lead to? I would have more "dirty" state of package
system then "well bred" lispers. I'll be able to use all packages even
if they have conflicts. I would use unqualified names for non-
conflicting symbols and full names for conflicting ones. So, I would
be able to use any lisp code, but my code won't be usable by "well
bred" lispers.
Why do I think such possibility is important?
It is as I'd like to massively use a read-macro based construct
#with-package(designator-for-list-of-packages &body body)
Tim Bradshaw has something like this: http://www.tfeb.org/lisp/hax.html#READ-PACKAGES
This #with-package would read its body with packages temporarily used.
This way, I'll be able to make my program consising of hundreds and
even thousand packages. What does it mean?
In "modern" OO languages such as C++ or Java, each class in fact
introduces its own namespace. When you use a slot/method of a class in
a definition of other method, you are into that namespace, so you
don't need to fully qualify slots/members of that class. It is
reasonable as class might encapsulate many or most of the data
required for method definition. This leads to shorter, more easily
reading code. In Perl, class is distinctly bound to namespace. Pascal
has a with construct which joins namespaces from several records. SQL
implies namespace merging in its "select" statement. I think, this
approach is good. Surely my esthetic taste appeals me to get rid of
that ugly code like that:
(let ((foo (make-foo))
(print (foo-a foo) (foo-b foo)))
Human reader is clever enough to catch a "context". It is annoying to
read that repeating foo-. Look at human conversation. It is a good
style in a human communication not to repeat the same word too
frequently. And it is reasonable, as text with less repeating words
brings more information (in strict mathematical sence). If we really
need to repeat some words, it occurs that they are short (as "it",
"me", "let's", "and" etc). Context are used by human readers/writers
instead of repeating the same word again and again. Lisp violates both
that rules and I think it is mostly due to weakness of package system.
Compare code from swank:
(defstruct (arglist (:conc-name arglist.))
required-args ; list of the required arguments
optional-args ; list of the optional arguments
key-p ; whether &key appeared
keyword-args ; list of the keywords
rest ; name of the &rest or &body argument (if any)
body-p ; whether the rest argument is a &body
allow-other-keys-p ; whether &allow-other-keys appeared
aux-args ; list of &aux variables
known-junk ; &whole, &environment
unknown-junk) ; unparsed stuff
(defun encode-arglist (decoded-arglist)
(append (arglist.required-args decoded-arglist)
(when (arglist.optional-args decoded-arglist)
'(&optional))
(mapcar #'encode-optional-arg (arglist.optional-args decoded-
arglist))
(when (arglist.key-p decoded-arglist)
'(&key))
(mapcar #'encode-keyword-arg (arglist.keyword-args decoded-
arglist))
(when (arglist.allow-other-keys-p decoded-arglist)
'(&allow-other-keys))
(cond ((not (arglist.rest decoded-arglist))
'())
((arglist.body-p decoded-arglist)
`(&body ,(arglist.rest decoded-arglist)))
(t
`(&rest ,(arglist.rest decoded-arglist))))
(when (arglist.aux-args decoded-arglist)
`(&aux ,(arglist.aux-args decoded-arglist)))
(arglist.known-junk decoded-arglist)
(arglist.unknown-junk decoded-arglist)))
To hypothetical
(defpackage :arglist (:export :arglist :d-a))
#with-packages((:arglist)
(defstruct-exporting-slots (arglist (:conc-name ""))
required-args ; list of the required arguments
optional-args ; list of the optional arguments
key-p ; whether &key appeared
keyword-args ; list of the keywords
rest ; name of the &rest or &body argument (if
any)
body-p ; whether the rest argument is a &body
allow-other-keys-p ; whether &allow-other-keys appeared
aux-args ; list of &aux variables
known-junk ; &whole, &environment
unknown-junk) ; unparsed stuff
(defun encode-arglist (d-a) ; d-a is decoded-arglist
(append (required-args d-a)
(when (optional-args d-a)
'(&optional))
(mapcar #'encode-optional-arg (optional-args d-a))
(when (key-p d-a)
'(&key))
(mapcar #'encode-keyword-arg (keyword-args d-a))
(when (allow-other-keys-p d-a)
'(&allow-other-keys))
(cond ((not (rest d-a))
'())
((body-p d-a)
`(&body ,(rest d-a)))
(t
`(&rest ,(rest d-a))))
(when (aux-args d-a)
`(&aux ,(aux-args d-a)))
(known-junk d-a)
(unknown-junk d-a)))
)
Do you agree that the second code is much easier to read?
But if I try to combine this approach to CL standard "conflict free"
package system state, this becomes practically unusable due to symbol
clashes. I think lisp loses there in a competition to modern
languages.
From: Thomas A. Russ
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <ymi63ndhpvb.fsf@blackcat.isi.edu>
budden <········@mtu-net.ru> writes:
> ��k, I see there is some delay until message occurs in a group. Sorry
> for duplicate messages.
>
> Behavior I desire can be achieved when use-package would do the
> following:
> i) if current package is a home package for one of conflicting
> symbols, this symbol is kept and other is not interned.
> ii) if both symbols are not of current package, they both are
> unimported.
>
> What this would lead to?
Chaos. Especially item "ii", since implementing that would have the
effect of unimporting a symbol that you might have already read.
Consider the following snippet:
(import :pkg1)
(.... sym ....)
(import :pkg2)
(.... sym ....)
Now, suddenly, SYM is no longer the same, because it has been
unimported, so when the reader gets to the second SYM, it has to create
a NEW symbol in the current package.
But it gets even worse, even if you do things all together in a
DEFPACKAGE form, rather than using the individual IMPORT statements:
(defpackage my-pkg (:use pkg1 pkg2))
(... sym ...)
Now, suppose that pkg1 exports SYM1 and pkg2 exports SYM2 and SYM.
There is no conflict, and the reader will happily use PKG2:SYM when it
encounters "sym". But what happens when the author of PKG1 decides to
extend it and now exports SYM as well. Suddenly, without warning from
the package system, the meaning of SYM in your code changes because
suddenly PKG2:SYM is no longer imported.
What you will find is that most of the time, when there is an attempt to
implement DWIM (Do What I Mean) behavior in programming languages, you
will get really strange behavior that is very difficult to debug.
--
Thomas A. Russ, USC/Information Sciences Institute
In article
<····································@u75g2000hsf.googlegroups.com>,
budden <········@mtu-net.ru> wrote:
> �k, I see there is some delay until message occurs in a group. Sorry
> for duplicate messages.
>
> Behavior I desire can be achieved when use-package would do the
> following:
> i) if current package is a home package for one of conflicting
> symbols, this symbol is kept and other is not interned.
> ii) if both symbols are not of current package, they both are
> unimported.
>
> What this would lead to? I would have more "dirty" state of package
> system then "well bred" lispers. I'll be able to use all packages even
> if they have conflicts. I would use unqualified names for non-
> conflicting symbols and full names for conflicting ones. So, I would
> be able to use any lisp code, but my code won't be usable by "well
> bred" lispers.
How do I know that there is a conflict? What thing would
tell me a development time that there is a conflict so that
I have to write foo:bar? Whether there is a conflict or
not depends on the packages and on the runtime state
of some Lisp program. Same problem, it just looks a bit differently.
> Why do I think such possibility is important?
>
> It is as I'd like to massively use a read-macro based construct
> #with-package(designator-for-list-of-packages &body body)
>
> Tim Bradshaw has something like this: http://www.tfeb.org/lisp/hax.html#READ-PACKAGES
That's some thing Lisp Machine Lisp had. It allows one to tell the default
package by expression.
> This #with-package would read its body with packages temporarily used.
> This way, I'll be able to make my program consising of hundreds and
> even thousand packages. What does it mean?
>
> In "modern" OO languages such as C++ or Java,
Well, C++ appeared in 1983 before the first Common Lisp book was
published (1984). C++ was based on developments from 1979
(C with classes). Java appeared in 1995 and was a very conservative
design, introducing not much new at the language level.
I don't think there is that much 'modern' to C++ and Java (the language).
Java now has a lot of stuff, but the designers are still thinking if closures
are worth to add and in what form. Go figure.
>each class in fact
> introduces its own namespace. When you use a slot/method of a class in
> a definition of other method, you are into that namespace, so you
> don't need to fully qualify slots/members of that class. It is
> reasonable as class might encapsulate many or most of the data
> required for method definition. This leads to shorter, more easily
> reading code. In Perl, class is distinctly bound to namespace. Pascal
> has a with construct which joins namespaces from several records. SQL
> implies namespace merging in its "select" statement. I think, this
> approach is good. Surely my esthetic taste appeals me to get rid of
> that ugly code like that:
Common Lisp tries not to mix all kinds of orthogonal business (classes,
namespaces, modules) into one base construct. If you look at the
base of Common Lisp, it goes exactly the other way. For example:
there are a few special forms - not many and a lot can be built on top.
This classes are modules are namespaces is not that popular in
the Lisp world. It is also a bit painful to use in interactive environments.
The Dylan language derived from Common Lisp and Scheme, also does
not go that route.
>
> (let ((foo (make-foo))
> (print (foo-a foo) (foo-b foo)))
>
> Human reader is clever enough to catch a "context".
The question is where that context comes from. If you are used
to non-interactive text-based environments, then you have
just one context: the text. In Lisp you work interactively
and additionally code is data - so the context can be quite different
and very non-obvious.
...
> (defun encode-arglist (decoded-arglist)
> (append (arglist.required-args decoded-arglist)
> (when (arglist.optional-args decoded-arglist)
> '(&optional))
> (mapcar #'encode-optional-arg (arglist.optional-args decoded-
> arglist))
> (when (arglist.key-p decoded-arglist)
> '(&key))
> (mapcar #'encode-keyword-arg (arglist.keyword-args decoded-
> arglist))
> (when (arglist.allow-other-keys-p decoded-arglist)
> '(&allow-other-keys))
> (cond ((not (arglist.rest decoded-arglist))
> '())
> ((arglist.body-p decoded-arglist)
> `(&body ,(arglist.rest decoded-arglist)))
> (t
> `(&rest ,(arglist.rest decoded-arglist))))
> (when (arglist.aux-args decoded-arglist)
> `(&aux ,(arglist.aux-args decoded-arglist)))
> (arglist.known-junk decoded-arglist)
> (arglist.unknown-junk decoded-arglist)))
See WITH-SLOTS and WITH-ACCESSORS in Common Lisp / CLOS. It helps
to keep things shorter in some situations.
An example of WITH-ACCESSORS from McCLIM:
(defun presentation-history-next (history ptype)
"Go to the next input (forward in time) in `history' that is a
presentation-subtype of `ptype', respective to the pointer in
`history'. Returns two values: the found object and its
presentation type, both of which will be NIL if no applicable
object can be found."
(with-accessors ((pointer presentation-history-pointer)
(array presentation-history-array)) history
;; If no navigation has been performed, we have no object to go
;; forwards to.
(if (or (null pointer) (>= (1+ pointer) (length array)))
(values nil nil)
(progn
(incf pointer)
(destructuring-bind (object . object-ptype)
(aref array pointer)
(if object-ptype
(if (presentation-subtypep object-ptype ptype)
(values object object-ptype)
(presentation-history-next history ptype))
(values nil nil)))))))
...
> (defun encode-arglist (d-a) ; d-a is decoded-arglist
> (append (required-args d-a)
> (when (optional-args d-a)
> '(&optional))
> (mapcar #'encode-optional-arg (optional-args d-a))
> (when (key-p d-a)
> '(&key))
> (mapcar #'encode-keyword-arg (keyword-args d-a))
> (when (allow-other-keys-p d-a)
> '(&allow-other-keys))
> (cond ((not (rest d-a))
> '())
> ((body-p d-a)
> `(&body ,(rest d-a)))
> (t
> `(&rest ,(rest d-a))))
> (when (aux-args d-a)
> `(&aux ,(aux-args d-a)))
> (known-junk d-a)
> (unknown-junk d-a)))
> )
Well, short notations are preferred by some (see Paul Graham's 'Arc language),
but not by me. I like code where the variable and function names are not
obfuscated. I'm not good in decrypting source code. Goethe could
have also abbreviated his works.
c=charlotte, w=werther, a=albert
One fine evening in winter, when the weather seemed inclined to
thaw, c and a were returning home together. The
former looked from time to time about her, as if she missed w's
company. A began to speak of him, and censured him for his
prejudices. He alluded to his unfortunate attachment, and wished
it were possible to discontinue his acquaintance. "I desire it on
our own account," he added; "and I request you will compel him to
alter his deportment toward you, and to visit you less frequently.
The world is censorious, and I know that here and there we are
spoken of." C made no reply, and A seemed to feel
her silence. At least, from that time he never again spoke of
W; and, when she introduced the subject, he allowed the
conversation to die away, or else he directed the discourse into
another channel.
There are opportunities for even more compression...
> Do you agree that the second code is much easier to read?
Not at all.
> But if I try to combine this approach to CL standard "conflict free"
> package system state, this becomes practically unusable due to symbol
> clashes. I think lisp loses there in a competition to modern
> languages.
Which of these 'modern languages' you think of is designed to be use
fully interactively and dynamic? Definitely not Java and not C++.
My advice:
* don't fight the language
* understand that Lisp is different (interactive, dynamic, introspective,
reflective, ...) and thus difficult to compare to static
language designed for batch use (C++, Java, ...)
* try to find out what the built-in way is to write shorter code
* write self-documenting code
* if you really want to write shorter code on a micro level
switch to another programming language
* if you want shorter code on a 'macro' level, stay with Lisp
* check out the style guide from Pitman/Norvig
http://lispm.dyndns.org/documents/Common%20Lisp/norvig-lisp-style.pdf
--
http://lispm.dyndns.org/
From: Kaz Kylheku
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <20081027134446.491@gmail.com>
On 2008-10-26, budden <········@mtu-net.ru> wrote:
> In "modern" OO languages such as C++ or Java, each class in fact
> introduces its own namespace.
But these are not symbol namespaces but rather referential namespaces.
All symbols in C++ are in fact in one global namespace.
Given foo::x and bar::x, you are actually talking about three names: foo, bar
and x. The two x's are actually the same name.
So for instance if B is base class, D is derived, then D::x hides B::x.
There are more quirks in the design. Suppose that B::x is a virtual function
and D::x is also a function, and has the same type signature. D::x then
overrides B::x.
If a D object is accessed through a reference R to B, then R.x actually refers
to D::x. However, R.B::x refers to B::x.
> When you use a slot/method of a class in
> a definition of other method, you are into that namespace, so you
> don't need to fully qualify slots/members of that class.
Really? See above. If you're in the scope of class B, and call a function x,
you might actually be going to D::x, even though nothing is known about any D
in that scope. You have to use scope resolution to reach B::x.
Virtual functions can sneak up on you. Suppose a base class designer decides to
flip some regular function into being virtual. Oops; all functions in derived
classes which have the same name and a compatible signature are now overrides
of that function.
C++ has a pitifully stupid design with regard to how things are named, scoped
and referenced.
> It is
> reasonable as class might encapsulate many or most of the data
> required for method definition. This leads to shorter, more easily
> reading code. In Perl, class is distinctly bound to namespace. Pascal
> has a with construct which joins namespaces from several records.
It's not surprising you're a fan of Pascal's WITH.
Basically, you like brainadamaged things and you want Lisp to be that way.
Let's look at WITH:
(* in a procedure *)
VAR x : INTEGER;
WITH some_record ; BEGIN
y := func(x);
END
Above, func(x) refers to the local variable x, and y refers to some_record.y.
But suppose someone now maintains the program, and adds a field called x to
some_record. Oops! The stupid WITH statement now makes x refer to the x in the
record! The meaning of the assignment statement silently changes, and the
software breaks.
Think about how idiotic that is: a change done in some remote location of the
program, perhaps in another file, changes a meaning of a local variable
reference. Oops, I mean, what other file; Pascal originally didn't have
modules.
Modula-3 has a sanely designed WITH construct, which is similar to Lisp's
SYMBOL-MACROLET. It's something like:
WITH y = some_record.y, x = some_record.x[i] ; DO
...
END
See, you explicitly write every symbol that is introduced into the scope. There
are no hidden clashes.
Ada doesn't inherit Pascal's WITH statement either. Ada has a WITH statement
which does something else: it's used for bringing in packages.
Oberon has a WITH keyword, but the semantics is completely different something
like Lisp's TYPECASE.
So if we look at some of the predominant descendants of Pascal, we find that
the designers have not only repented the WITH mistake, but they sealed its fate
by reusing the word for other uses!
See, by redefining WITH, the language definitions of Ada, Modula 3 and Oberon
prevent implementors from providing a Pascal WITH as a backward-compatibility
extension for doing quick-and-dirty ports of questionable Pascal source.
Ada's WITH has the properties you like: you can use WITH to import packages
with clashing symbols. The clashes are identified as ambiguous at the point
where the symbols are used. This is perfectly fine in a language with a
well-defined compile time, in which all of the symbolic drama is played out to
its completion. If an Ada program builds with no ambiguous symbol references,
then there is no further worry.
> Human reader is clever enough to catch a "context".
That's great if you are writing programs to be executed by humans,
rather than machines.
> But if I try to combine this approach to CL standard "conflict free"
> package system state, this becomes practically unusable due to symbol
> clashes. I think lisp loses there in a competition to modern
> languages.
The question is, do we want to win in a race for the bottom?
P� Mon, 27 Oct 2008 22:36:31 +0100, skrev Kaz Kylheku <········@gmail.com>:
>
> All symbols in C++ are in fact in one global namespace.
>
Nop. All names are strings in the BSS segment. But each file can have it's
own. If you define a function to be static it is local to that file. Also
C++ offers a namespace construct which allows you to explicitly create
namespaces. (whic allows multiple files to share a namespace)
--------------
John Thingstad
Hi group.
I see I was wrong in how I suggested to implement "liberate
namespace merging" concept. Really, idea of uninterning a symbol upon
using conflict is completely idiotic :) Let's fix it. What needs to be
changed is in-package.
Consider
(in-packages package &rest more-packages)
for file-level and
#with-packages((package &rest more-packages) &body body)
What does it mean?
All package namespaces are merged. You may use all external symbols
without package prefix unless it participates in a conflict. If there
are package clashes, they are reported not at in-package execution
time, but at read time. All new unqualified symbols are interned into
first package. If you refer to clashing symbol as package::symbol, no
conflict is reported. Optionally, clashes may be reported as a
warnings at the time (use-packages ) is processed.
Why this is better then modifying use-package? It is an extension of
cl, not a modification.
> It's not surprising you're a fan of Pascal's WITH.
No, I'm not. But if WITH were fixed, it might be much more useful.
Consider
unit p1;
var sym,sym1:integer;
type p2=record
sym,sym2:integer;
end;
function foo;
var use_p2:p2;
var sym:integer;
begin
with use_p2 do
begin
sym1=sym2; { no ambiguity }
unit.sym; { refers to global var }
function.sym; { refers to local var }
use_p2.sym; { refers to use_p2 }
sym; { error: clashed }
end;
end;
They might fix it by adding a compiler switch which would allow either
strict namespace merging semantics (no ambiguities allowed) or
compatibility mode (as pascal does).
If it were so, I'd used with anywhere.
If you consider all the situation that can occur in programming
practice, you'll see that all is Ok there:
1. Starting learning new and yet unknown package. Just
write
(defpackage :test-package (:use))
(in-packages :test-package :my-favorite-libraries :new-package-to-
learn)
- all new symbols are interned to test-package.
- if no symbol clashes, all is ok; Use all symbols from my-favorite-
libraries and new-package-to learn without package prefix).
- if symbol clash appear, compiler reports a error exactly in the
place where it occured. You can just qualify your symbol and recompile
until no error occurs. Do not care this until this happens: compiler
want let you to err.
2. Adding new symbol to either package in a complex system
- no conflicts at export time (consider CL: your package is used
everywhere. To maintain correctness of use-package declration, cl
gives you a error when exporting a symbol with #'export creates a
symbol clash in some of the dependend packages. Things are worse when
your packages is used by someone else. He pulls an update from CVS and
occasionally gets a package error in a code he never even seen)
- all previously compiled code remains valid
- upon next recompilation all the places where symbol clash is
created, are reported. Recommended way of conflict resolution is to
qualify previously unqalified symbols. As project grows, more and more
symbols get prefixed with package names. It is reasonable.
3. Changing package context on the fly. Just see point 2.
4. What I've missed?
That is all for an essence of the question discussed. What goes to
lyrics/phylosophy,
> My advice:
>* don't fight the language
>* understand that Lisp is different (interactive, dynamic, introspective,
reflective, ...) and thus difficult to compare to static
language designed for batch use (C++, Java, ...)
I'm not fighting the language, I only finding a way to code
efficiently. Time=money. Efficiency=more free time. I'm neither
idealising nor debasing lisp. I'm totaly neutral. Lisp has many
wonderful and unique features, but I'm not going to disregard its
flaws.
I'm using lisp occasionally for nine years, so I think I at least
glanced at every CLHS entry. So thanks, no need to advice me to use
#'describe, #'documentation or with-slots.
What goes to dynamic nature, I not agree. Compilation in lisp has well
defined semantics and it is strict enough, so lisp _can_ act as a
compiled language, especially with the help of evel-when.
> I don't think human communication is a particular good
comparison. Common Lisp is not an 'artificial intelligence'
in itself.
Consider full software lifecycle. If it is not ideally documented,
developer would read code. Compare a time and cost of the following
parts of the large project life cycle:
1 human writes code
2 human reads code
3 computer reads code
4 computer writes code
5 human writes macros for internal DSLs
6 human writes code analysers for internal DSLs
I think in most sufficiently complex projects, item 2 will take most
of the time and cost (especially if code is self-documenting so no
documentation is created). So really efficient programming language
should be designed with human perception pecularities taken into
account. All consideration of style and other analogies to human
coversations are valid and relevant. If lisp failes to conform human
even simplest (and easy to conform) conventions of human conversation
style, it is a reason to change lisp.
In article
<····································@m74g2000hsh.googlegroups.com>,
budden <········@mtu-net.ru> wrote:
...
> Consider full software lifecycle. If it is not ideally documented,
> developer would read code. Compare a time and cost of the following
> parts of the large project life cycle:
> 1 human writes code
> 2 human reads code
> 3 computer reads code
> 4 computer writes code
> 5 human writes macros for internal DSLs
> 6 human writes code analysers for internal DSLs
>
> I think in most sufficiently complex projects, item 2 will take most
> of the time and cost (especially if code is self-documenting so no
> documentation is created). So really efficient programming language
> should be designed with human perception pecularities taken into
> account. All consideration of style and other analogies to human
> coversations are valid and relevant.
I think reading and maintaining source code is sufficiently
different from other human activities (hunting, eating, having sex,
...) and needs highly trained people. Maintaining source
code is a recent activity in human evolution (50 years
of Lisp compared to 100000+ years of humans) , so one
would be very careful to see what capabilities humans
have acquired during evolution and what they have learned
during their education and what is actually helpful for this
particular task. By default the usually link to SICP
applies.
> If lisp failes to conform human
> even simplest (and easy to conform) conventions of human conversation
> style, it is a reason to change lisp.
Right, reading code is extremely important. Software maintenance
is the most costly thing in the whole life cycle of
software.
This favors having the context (the namespace) of the symbols visible
in the source and having a system that can be asked
about the various source artifacts (classes, functions,
declarations, documentation, ...). It enables humans to much
more easily get back into the context during maintenance.
It provides the extra information that is helpful. Abbreviating
symbols or not using namespace prefixes is actually decreasing
maintainability.
What you propose helps in quickly writing less maintainable
code. I guess that's fine for people who are paid
to get some result quickly and/or get paid for maintenance.
I favor using package prefixes in my sources.
For example to list the user objects of a web server in a CLIM window:
(define-a-http-ui-command (com-list-users info-command-table :menu t)
((realm 'http:realm))
(when realm
(clim:with-application-frame (frame)
(let ((*standard-output* (clim:frame-standard-output frame)))
(terpri)
(loop for user in (http:sorted-users realm)
do (clim:present user))
(terpri)))))
I keep using the names for the CLIM and the HTTP package
to make clear where those symbols are coming from.
It gives me slightly more information than this version:
(define-a-http-ui-command (com-list-users info-command-table :menu t)
((realm 'realm))
(when realm
(with-application-frame (frame)
(let ((*standard-output* (frame-standard-output frame)))
(terpri)
(loop for user in (sorted-users realm)
do (present user))
(terpri)))))
And it saves me the effort of thinking about symbol clashes,
preparing a new packages using several packages
with possibly conflicting symbols and so on.
So it saves time during development (less clashes), debugging
(less clashes) and maintenance (improved readability).
Looks like a win to me.
--
http://lispm.dyndns.org/
Ok, Rainer,
> This favors having the context (the namespace) of the symbols visible in the source and having a system that can be asked
about the various source artifacts (classes, functions, declarations,
documentation, ...).
I think it is more a matter of style. I earned most of my money up
to the date by supporting rather large SQL code. SQL namespace merging
policy is wise. I never had a problems with namespace clashes. So I'm
sure my proposed policy is fairly scalable.
What goes to lisp, my work is more like experiments and small
projects. You may or may not prefer prefixes to non-clashing symbols,
but I tired of getting problems with new packages. I just want to play
around with it and maybe I'll throw it away tomorrow. Say, I'm trying
package :foo. I remember very well that it is "foo" and I'm definitely
reluctant of writing `foo:' it everywhere. So for the first time I do
just "in-package :foo". But if several days pass, and package is Ok, I
want use my library too. And there symbol clashes interfere my work.
Lisp forces me to deal with symbol clashes when there is no real
conflict yet. It forces me to deside, which symbol is better:
"foo::common-word" or "my-lib::common-word". What if there are many
such symbols? All this it is not right. Solution I proposed solves
it.
But is usable not only in the short term, not in small projects. It
is safe. You'll never be able to enter ambigious symbols by occasion.
My SQL experience shows it is Ok.
If I'll learn Emacs or other developer's GUI to parse #with-
packages, my "find-source" feature will still be functional. This way,
it is no difference if I use prefixes or not. When returning to old
code, I can easily see what does the symbol means with that feature.
When I look for it two or three times, I'll remember it. So, no more
reading prefixes would be needed. Source would be shorter and I find
that convinient.
So, my solution is very good for the beginners and very acceptable
for maintainers.
I think now it is time to close the topic. If I'll stay on lisp, I
think I'll implement this feature for myself, make it available for
the public, and will actively use it.
Good time of day Group...
I tried to implement what I wanted. Faced to difficulties that seem
to be impossible to solve:
1. No use of the feature without editor change. Not all editors are
available with sources.
2. Some low-level changes are required which go beyond flexibility
suggested by CL. E.g., I need to redefine intern and/or find-symbol.
But if they're inlined somewhere, it will fail.
Rainer, you were right when you adviced me not to fight the
language: language is stronger than me and I can't win and change it
to what I want. It is rather strange for a language whose main
advantage is its flexibility and extensibility...
So, maybe CL will be kept in my practice as a platform, but not as
an "end-user" language. Maybe I'll try to develop my own language with
lisp flaws fixed.
From: Kenny
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <4909d919$0$5640$607ed4bc@cv.net>
budden wrote:
> Good time of day Group...
> I tried to implement what I wanted. Faced to difficulties that seem
> to be impossible to solve:
> 1. No use of the feature without editor change. Not all editors are
> available with sources.
> 2. Some low-level changes are required which go beyond flexibility
> suggested by CL. E.g., I need to redefine intern and/or find-symbol.
> But if they're inlined somewhere, it will fail.
> Rainer, you were right when you adviced me not to fight the
> language: language is stronger than me and I can't win and change it
> to what I want. It is rather strange for a language whose main
> advantage is its flexibility and extensibility...
> So, maybe CL will be kept in my practice as a platform, but not as
> an "end-user" language. Maybe I'll try to develop my own language with
> lisp flaws fixed.
>
Thank god. I thought he would never leave.
Let's see. There are two packages both exporting the same symbol with
different functionality behind it and I want to use both packages
without sorting that out and it is cool because I am not going to use
that symbol and gosh I hope I do not call a function in either package
that /does/. I mean, yeah, I am deliberately mixing overlapping and
conflicting packages and there is now a semantic clash but I want to be
able to work that way without worrying about it until the lander is four
hundred feet over the surface of Mars. And CL will not let me? What
happened to trusting the programmer? I see an inconsistency in that
policy. In the garbage it goes. I bet it hangs out with terrorists and
cannot see Alaska from its house.
The problem is with you, not Lisp. You found an arguable deviation from
a /policy/ of trusting the programmer and you are paralyzed and will
have to create your own language?
I do not think so, I think you are simply insane. Welcome to the group!
:)
kt
In article
<····································@f77g2000hsf.googlegroups.com>,
budden <········@mtu-net.ru> wrote:
> Good time of day Group...
> I tried to implement what I wanted. Faced to difficulties that seem
> to be impossible to solve:
> 1. No use of the feature without editor change. Not all editors are
> available with sources.
> 2. Some low-level changes are required which go beyond flexibility
> suggested by CL. E.g., I need to redefine intern and/or find-symbol.
> But if they're inlined somewhere, it will fail.
> Rainer, you were right when you adviced me not to fight the
> language: language is stronger than me and I can't win and change it
> to what I want. It is rather strange for a language whose main
> advantage is its flexibility and extensibility...
Common Lisp comes with a lot of flexibility built in.
The implementations may provide even more flexibility.
But Common Lisp allows also a less flexible implementation
(compiler-only, lots of inlining, ...).
Some facilities in Common Lisp have a meta-level built-in.
The implementations also may provide meta-levels for other
things (like streams).
The package system does not have this flexibility. Packages and
symbols are not classes that can be subclassed. There are
no generic functions that can be extended. There are no
hooks for the developer. Condition classes are missing.
One might change individual implementations, but the
standard is not very flexible when it comes to classes.
On the positive side:
You can change the reader. You can also use the introspective
functionality of the package system to write code that
manipulates packages. Writing code that USES a package in
another package and deals with the conflicts is useful.
Programmatically generating package statements (exports,
defpackage, ...) can be useful.
I've seen some larger libraries struggle with packages.
Each has a slightly different way. There is also little
written about 'best practices' of organizing complex
software in Common Lisp packages.
It might be useful to take a certain implementation
and use implementation internal functionality to experiment
with changes to the package system.
A 'popular' extension are hierarchical packages. There should
be some code for that available. Maybe that can give some
inspiration...
> So, maybe CL will be kept in my practice as a platform, but not as
> an "end-user" language. Maybe I'll try to develop my own language with
> lisp flaws fixed.
--
http://lispm.dyndns.org/
From: Kaz Kylheku
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <20081030124706.842@gmail.com>
On 2008-10-30, budden <········@mtu-net.ru> wrote:
> Good time of day Group...
> I tried to implement what I wanted. Faced to difficulties that seem
> to be impossible to solve:
> 1. No use of the feature without editor change. Not all editors are
> available with sources.
> 2. Some low-level changes are required which go beyond flexibility
> suggested by CL. E.g., I need to redefine intern and/or find-symbol.
> But if they're inlined somewhere, it will fail.
> Rainer, you were right when you adviced me not to fight the
> language: language is stronger than me and I can't win and change it
> to what I want. It is rather strange for a language whose main
> advantage is its flexibility and extensibility...
> So, maybe CL will be kept in my practice as a platform, but not as
> an "end-user" language. Maybe I'll try to develop my own language with
> lisp flaws fixed.
I side with Kenny's observation that you are a nutjob.
Earlier in the thread, you made two claims. One is that you value your time,
which is great:
``I'm not fighting the language, I only finding a way to code
efficiently. Time=money. Efficiency=more free time. ''
But earlier, you identified it as a waste of your precious time and money to be
resolve some package use conflicts. But suddenly it's okay for you to waste
your time and money to write a whole new language to work around this perceived
problem. You're kidding, right?
The second claim you made is that most time in a large and complex project is
spent reading code:
``1 human writes code
2 human reads code
...
I think in most sufficiently complex projects, item 2 will take most
of the time and cost ...''
But the activity of preparing a conflict-free package composition is writing
code, not reading.
You're internally inconsistent with yourself, again. You regard code reading as
being the primary expense, rather than writing, yet you want to increase the
difficulty of reading for a small saving in writing.
If you don't eliminate symbol clashes at the point where packages are composed,
programmers will have to use explicit qualification elsewhere, which is ugly
and less readable.
From: Kenny
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <490a4ee1$0$5668$607ed4bc@cv.net>
Kaz Kylheku wrote:
> On 2008-10-30, budden <········@mtu-net.ru> wrote:
>
>>Good time of day Group...
...
> The second claim you made is that most time in a large and complex project is
> spent reading code:
>
Imissed this bit:
> ``1 human writes code
> 2 human reads code
> ...
>
> I think in most sufficiently complex projects, item 2 will take most
> of the time and cost ...''
Sounds like someone who does a bad job on item #1 [or like most good
Lispers has no intention of ever doing any item #1 and just want to yak
all day].
Well-written code does what its well-chosen API names say it does and so
all but the API effectively disappears, never to be read again. This is
a prerequisite for success for even insufficiently complex projects.
hth,kzo
Kenny, god is not on your side :))) If you are such a clever and
adequate fighter for language safety, what do you think about CL
allowing to intern a harmful symbol to any package at any time by just
writing e.g. 'cl:destracturing-bind? What do Marsian terrorists think
about that? I know there are package locks in sbcl, but it is not a
standard.
> In other words, C++ does not have symbol namespaces like Lisp (namespace for
resolving a reference of an identifier to a symbol).
Kaz, I see you know lisp very well, but I'd recommended to spend some
time reading C++ and SQL standards. You are certainly anaware of
"select" statement behavior (as it was clear from your earlier posts).
What goes to C++, there are "namespace" and "using namespace"
constructs.
I took a look at lexicons.pdf and lexicons.lisp
Not acceptable for me at all:
1. It redefines defun, so it would conflict with any lisp extension
which redefines defun too. E.g. with ap5 which I actively use. And,
say, with "screamer" which I never used, but which seem to be
extremely elegant.
2. No sence to make new concept which is analogous to existing one if
one can be fixed. Changing in-package to in-packages would fix this
too, and it would be compatible to lisp culture. It can be made say,
in sbcl/emacs as both are open-source projects. Using lexicons would
not free us from using packages when we want to load other's people
libraries.
3. Lisp is primarily a metaprogramming tool for me. So I use symbols
as a data, which is declared not to be intended by lexicons.
4. I didn't find a way to refer to other lexicons from the current
lexicon. It is a must for real namespace system.
5. Variable capture in macros resolved by using uninterned symbols,
not by using symbols from other packages. The method is conviniently
decorated as misc variants of "with-gensyms" macro. With that macro,
only a minimal testing is required. Compiler is smart enough to show
potential captures, when macro is compiled in an empty lexical
environment. So no need for other means for that problem.
From: Kenny
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <490ba532$0$5658$607ed4bc@cv.net>
budden wrote:
> Kenny, god is not on your side :))) If you are such a clever and
> adequate fighter for language safety,...
No, you missed that I slammed on the breaks when I realized I was
arguing for language safety and cleverly turned it into a personal
attack on your sanity. I have been studying McCain/Palin, one of whom
may not carry their home state in what will be an astonishing result
Tuesday: racist America electing a black president by almost a ten point
margin reflecting not a sudden leap in the sophistication of the
American voter rather what just might be the worst presidency (and
congress-ency and press-ency) in US history.
Kaz nailed it. This bothers you because it slows down your coding so you
are making a new language? You work for Haliburton, right? Dick Cheney
got you a nice contract, overruns no prob?
Forget about packages, doing something about those damn parentheses will
you?!!
peace,k
From: Kaz Kylheku
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <20081030095839.825@gmail.com>
On 2008-10-28, John Thingstad <·······@online.no> wrote:
> P� Mon, 27 Oct 2008 22:36:31 +0100, skrev Kaz Kylheku <········@gmail.com>:
>
>>
>> All symbols in C++ are in fact in one global namespace.
>>
>
> Nop. All names are strings in the BSS segment. But each file can have it's
> own. If you define a function to be static it is local to that file. Also
> C++ offers a namespace construct which allows you to explicitly create
> namespaces. (whic allows multiple files to share a namespace)
That is not the view from which I'm looking at this. In the actual C++ language
itself, foo::x and bar::x are not different symbols. They are scope resolution
syntax in which the same name x refers to different entities that are defined
in different named scopes.
Consider:
foo f; // class foo has a member x
bar b; // so does class bar
// look, foo::x and bar::x used in the same expression:
f.x(b.x);
Here, x is resolved not with scope resolution, but with member selection.
This resembles:
(funcall (slot-value f 'x) (slot-value b 'x))
All that stuff about BSS segments has nothing to do with C++. The ISO C++
standard doesn't discuss linkers and BSS. It's merely an implementation
strategy which C++ uses over that kind of linker model.
When C++ compilers generate code for this kind of linkage, they combine
multiple names (and other information such as function argument type
signatures) into a character string, which becomes a symbol at that level.
In other words, C++ does not have symbol namespaces like Lisp (namespace for
resolving a reference of an identifier to a symbol). C++ has symbol reference
namespaces: spaces for resolving a symbol to an entity such as a type,
variable, class, namespace, aggregate member, goto label, etc.
Remember that even C is said to have multiple namespaces.
For instance goto labels are in a different namespace from struct members:
struct foo {
int foo;
};
struct foo foo() {
struct foo foo;
goto foo;
foo:
foo.foo = 42;
return foo;
}
On Thu, 30 Oct 2008 17:20:23 +0000 (UTC), Kaz Kylheku
<········@gmail.com> wrote:
>On 2008-10-28, John Thingstad <·······@online.no> wrote:
>> P� Mon, 27 Oct 2008 22:36:31 +0100, skrev Kaz Kylheku <········@gmail.com>:
>>
>>>
>>> All symbols in C++ are in fact in one global namespace.
>>>
>>
>> Nop. All names are strings in the BSS segment. But each file can have it's
>> own. If you define a function to be static it is local to that file. Also
>> C++ offers a namespace construct which allows you to explicitly create
>> namespaces. (whic allows multiple files to share a namespace)
>
>That is not the view from which I'm looking at this. In the actual C++ language
>itself, foo::x and bar::x are not different symbols. They are scope resolution
>syntax in which the same name x refers to different entities that are defined
>in different named scopes.
>
>Consider:
>
> foo f; // class foo has a member x
> bar b; // so does class bar
>
> // look, foo::x and bar::x used in the same expression:
> f.x(b.x);
>
>Here, x is resolved not with scope resolution, but with member selection.
>This resembles:
>
> (funcall (slot-value f 'x) (slot-value b 'x))
>
>All that stuff about BSS segments has nothing to do with C++. The ISO C++
>standard doesn't discuss linkers and BSS. It's merely an implementation
>strategy which C++ uses over that kind of linker model.
>
>When C++ compilers generate code for this kind of linkage, they combine
>multiple names (and other information such as function argument type
>signatures) into a character string, which becomes a symbol at that level.
Partly. Only the base of a data structure is referenced externally
and the string version of the name is used only for linking. Debug
information in an executable is separate and duplicates the link
information where necessary.
Remember that C++ can statically resolve the structural offset of
object members. If there is an external object "foo" which has a
member "x", only "foo" may be referenced in the link segment -
references to "foo.x" in the code will become a static offset to be
added to the resolved base address. I say "may" be referenced because
the compiler might in fact translate an external object reference
directly into an offset from the base of a specific DATA segment - so
there may be no individual entry for the object in the link segment.
I've not seen a C++ compiler that do this, but I have seen compilers
for other languages do it and there's no technical reason a C++
compiler couldn't - it simply requires uniquely identifying data
segments.
With static linking, external names may not even be referenced by the
compiled code. Although it is typical to place an identifiable marker
in the code that refers to the link segment entry for the external
name, the marker is usually just a redundant check - the link entry
normally contains a patch list of code locations to update once the
object's base address is resolved. There are C/C++ compilers that
mark external references with a null or illegal address.
When dynamic linking with dlopen or GetLibrary, etc., the object's
name is needed at runtime and so it does become a DATA segment string.
However, the program's internal name for the pointer to which the
external object's address is assigned is again a statically
linked/resolved object.
>In other words, C++ does not have symbol namespaces like Lisp (namespace for
>resolving a reference of an identifier to a symbol). C++ has symbol reference
>namespaces: spaces for resolving a symbol to an entity such as a type,
>variable, class, namespace, aggregate member, goto label, etc.
Probably the most concise, correct explanation I've seen.
George
> >In other words, C++ does not have symbol namespaces like Lisp (namespace for
> >resolving a reference of an identifier to a symbol). C++ has symbol reference
> >namespaces: spaces for resolving a symbol to an entity such as a type,
> >variable, class, namespace, aggregate member, goto label, etc.
>
> Probably the most concise, correct explanation I've seen.
>
> George
Well, if you think that it is enough to bury what I say, you are
wrong. What I say is:
In C++, when we use two namespaces with potentially conflicting
symbols, conflict is not reported until we're trying to reference a
conflicting symbol without a qualifier.
It is:
i) safe. No misuse of any symbol is possible. It is either unique or
it raises an error
ii) convinient. You do not have to prefix symbols with namespace names
if they are unique.
iii) flexible. If you are scared that somehow you'll write foo::x
instead of bar::x, you are free NOT to use namespace.
What lisp does?
It reports a clashes when you are using namespaces.
So you have three choices:
i) use only one of the conlicting packages and prefix all symbols from
other packages
ii) use neither package and prefix all symbols.
iii) use selected symbols. This is bad when your have many packages
with many clashes and many dependencies.
It does not matter which mechanism would finally resolve text (symbol
name in a source file) to some entity in an executable image. It is a
conflict resolution style that matters. Everyone is trying to avoid
discussing this very simple and evident flaw in CL design.
BTW, I have to admit that I'm not completely right. I note no one gave
that example which partly breaks my point. It is a C. In a C, you are
unable to have two symbols with identical names in one namespace. That
is,
#include "p1.h"
#include "p2.h"
would fail if both p1 and p2 export sym with the same name but with
different signature.
My opponents might argue that great projects like mySQL, linux kernel,
etc were written in C and they obviously didn't suffer from that
strictness in merging namespaces. This is the only exception I know.
If we take a look at all other examples, they're much more liberal:
- you can use several binaries with the same names on $PATH variable,
this is never reported
- you can have field name clashes in sql, they are reported only when
you use ambigious symbol
- you can have conflicting names in C++ namespaces, they are reported
only when you get a conflict
- you can have conflicting names in a Pascal (Delphi is rather
scalable for enterprise applications).
- don't know about Java, but I glanced a forums and found it seem to
be liberal too.
Finally, I'd like to say thanks to all who answered to my post.
Special thanks to Rainer Joswig, who was not only informative and
attentive, but friendly too. Rainer, what you said about a Lisp
Machine is very important and interesting. You didn't try to find a
problems in my head, gave me some clues that supported my viewpoint
and suggested some ways to achieve my goal. In particulare, you
suggested such a powerful tool as using code generation for fighting
packages. I didn't think of it before. I think it might solve a
problem completely. But in this case some standard means for that are
required. I think they should be adopted widely before they'll become
really useful. Consider asdf which is (one of) de facto standard(s).
If such an extension would be developed or adopted (maybe conduit/
hierachical packages), the package problem would be much less
annoying.
On Fri, 31 Oct 2008 15:14:34 -0700 (PDT), budden <········@mtu-net.ru>
wrote:
>> >In other words, C++ does not have symbol namespaces like Lisp (namespace for
>> >resolving a reference of an identifier to a symbol). �C++ has symbol reference
>> >namespaces: spaces for resolving a symbol to an entity such as a type,
>> >variable, class, namespace, aggregate member, goto label, etc.
>>
>> Probably the most concise, correct explanation I've seen.
>>
>> George
>
>Well, if you think that it is enough to bury what I say, you are
>wrong. What I say is:
I didn't say a thing about what you said. I don't even know what you
said previously. I was commenting on Kaz's post, not yours.
>In C++, when we use two namespaces with potentially conflicting
>symbols, conflict is not reported until we're trying to reference a
>conflicting symbol without a qualifier.
>It is:
>i) safe. No misuse of any symbol is possible. It is either unique or
>it raises an error
>ii) convinient. You do not have to prefix symbols with namespace names
>if they are unique.
>iii) flexible. If you are scared that somehow you'll write foo::x
>instead of bar::x, you are free NOT to use namespace.
>
>What lisp does?
>It reports a clashes when you are using namespaces.
>So you have three choices:
>i) use only one of the conlicting packages and prefix all symbols from
>other packages
>ii) use neither package and prefix all symbols.
>iii) use selected symbols. This is bad when your have many packages
>with many clashes and many dependencies.
>
>It does not matter which mechanism would finally resolve text (symbol
>name in a source file) to some entity in an executable image. It is a
>conflict resolution style that matters. Everyone is trying to avoid
>discussing this very simple and evident flaw in CL design.
I don't particularly like CL's symbol conflict mechanism either. So
what? I don't particularly like the way C++ resolves the types of
object parameters, or the syntax of templates, or the fact that I
can't use keyword parameters. In spite of that - and a lot more
annoyances - I program in C++ for a living.
Lisp is not C++. Get over it.
>BTW, I have to admit that I'm not completely right. I note no one gave
>that example which partly breaks my point. It is a C. In a C, you are
>unable to have two symbols with identical names in one namespace. That
>is,
>
>#include "p1.h"
>#include "p2.h"
>
>would fail if both p1 and p2 export sym with the same name but with
>different signature.
That also happens in C++. And it does not break with anything you
said above - the error occurs because of type redeclaration, not
because of identifier conflict. If you don't understand that, you
shouldn't be lecturing anyone here on C++ (or C).
What you don't seem to understand is that C++ doesn't have symbols ...
it has identifiers. If you don't understand the difference then you
shouldn't be having this discussion.
George
From: Kenny
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <490bfdfb$0$5625$607ed4bc@cv.net>
budden wrote:
> Consider asdf which is (one of) de facto standard(s).
And crap. Moral there somewhere.
kzo
ps. Omigod! Dojo!!! The grownups make a Web2 library!!! k
Kenny, you are not too polite. I'm thinking about ignoring you...
Maybe I'm not too polite either. Sorry for that. But how do elections
in USA relate to packages and parens? What goes to matter of the
question, you might want to read other topic I started. In last post,
I claim that importing symbol one-by-one is not safe at all and prove
this with an example.
> What you don't seem to understand is that C++ doesn't have symbols ...
Ironically, we have some symbol clash in the terminology. Maybe this
is a reason
why it is hard to understand what I say (especially when you didn't
read that). If it is interesting, you might start reading the topic
from the start. I was talking as a namespace in an abstract sence, as
a collection of unique names, where every name is unambigiously
mapping to some entity. There is also a merge operation of a
namespaces. This operation is very common in any natural and
artificial languages. This does not relates to linker.
Examples of abstract namespaces and their merge operations:
package in a lisp (names are symbols)
class in a C++ (names are member names)
namespace in a C++ (names are any functions, classes, constants, types
declared there)
header file in a C/C++ (just the same)
units in a pascal (just the same)
table in an sql (names are field names)
record in a pascal (names are fields)
directory in a file system (names are file names)
"we are talking about..." (names are attributes of the object or a
topic)
lexical scopes
According merge operations:
for lisp package: use-package
C++ class: inheritance
C++ namespace: using namespace
header files: #include, semantics differs from that of C++ "namespace"
merging, as you noted.
in merged namespace.
units: use
sql table: join
record: with
directory: two operations with different sences:
i) setting PATH variable
ii) copying all files to other dir
"we are talking about x and y"
lexical scopes: shadowing by inner bindings
It is very natural that merge operation should maintain unambiguity.
There are three policies of doing so:
- reporting clash when namespaces are merged. So do C headers, lisp
packages
- let namespaces merge, but report clash when clashing symbol is
referenced. Disallow
direct referencing of clashing symbols. So do C++ "namespace"
construct, SQL joins. Kaz reported Ada's with to do so to. Copying
files does so to.
- let namespaces merge, don't report clash, use priority rules to
resolve it. So does
pascalish "uses", searching files by a PATH. So do lexical scopes.
First policy is the most safe one, though it sometimes too
restricting. In the case of the lisp, it fails to provide safety due
to ability to intern any symbol at any time with read. Third policy is
the least safe, but it is actively used everywhere, and in lisp, too.
Comparing all those, it is easy to see that lisp has a poor design in
this respect. It lacks a flexibility. It should be possible to allow
second policy, for packages, not only the first one. Practice proves
that the scond policy is safe and scalable enough. To add this is my
suggestion.
You are talking about the fact, that while C++ "using namespace" may
introduce clashing names for different objects, header files inclusion
in fact ensures that "clashing" names describe the same object. Well,
maybe this example is not completely fits my notion of namespace
merging. Or, more preciesely, it describes fourth merging policy:
clashing names must describe just the same object. And if they fail to
do so, violation is reported at merge time.
But this is only partly relevant to the merge policies themselves.
Rather complex case... Here #include looks like lispy re-importing the
same symbol by inheritance from several packages. In the case,
strictly speaking, we have a name clash, but it is resolved
automatically as the names relates to the same symbol.
What goes to C++ vs Lisp, I, too, don't like C++ at all (it is
horribly ugly almost in all its features). But there are many C++
position and only a very little lisp ones (especially here in Russia).
For this discussion, I took C++ as a good example of a language which
implements namespaces in at least three different ways (lexical
scoping is the forth).
To kenny: I have to admit that in fact my English is too weak to
understand what you write. I spent some time trying to decode that for
some time yesterday, but I was in a rush due to that interesting
discussion. If I misunderstood you and what I though was a curse was
only a light irony, I apologise to you.
From: Kenny
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <490d7c28$0$5636$607ed4bc@cv.net>
budden wrote:
> To kenny: I have to admit that in fact my English is too weak to
> understand what you write. I spent some time trying to decode that for
> some time yesterday, but I was in a rush due to that interesting
> discussion. If I misunderstood you and what I though was a curse was
> only a light irony, I apologise to you.
Relax! One of the best things about calling me bad names is that you can
never go wrong. Ask Costanza.
Not sure to what you refer, but if it was my terse comment on ASDF, no
that was not directed at you. My point was that ASDF is both a de facto
standard and a steaming turd (can't wait till you find that one on the
Web) so just imagine what would happen if it went from being an
unfortunate ubiquity to a candidate for enshrinement in the CL standard
(vast bloodletting).
The larger point being we should be programming applications, not trying
to keep pace with the exponentially growing Scheme standard.
Now if I can please get back to the desperate god-forsaken mess that is
Ajax.... that is no no-sequitor, btw. I am trying to help my client
build their software. I am crashing into idiocy at every turn, from
non-existent communities as great as c.l.l to just awful documentation
to amateurish programming held up as best in class right down to the
abysmalness of any language other than Lisp, tho of course Javascript is
pretty damn close I must say, more of a Lisp pretending to be C than a C
pretending to be Lisp. Am I over on some Ajax forum whining about HTML
not having the idea of a namespace?
Chya. I have work to do. I swat these things away like flies. Some of
them I have to chisel thru like granite. I hate those. I end up working
on them in my sleep. Then I drop my c.l.l for a little relaxation to see
who is the weekly clueless noob wanting to fix Lisp so I can exercise
the hounds. Then it's a game of Freecell and back to work.
Moral? Don't change, you are doing fine.
So help me group, what's our roster for the upcoming re-opening of the
standard? Ron Garret can be captain, he has actually programmed in Lisp.
But then who else? I remember Ilias and now we have Budden. Who were the
dozen in-between?
kxo
Hi Kenny, group!
Ok, I (mostly) understood you now. Yes, these were your words about
asdf that I misinterpreted. Btw I agree that asdf is far from ideal.
Having sbcl recompiled when I recompiled my system with :force t was a
great surprise! Make seem to be much better... I took asdf just as an
example.
I'm not an expert in AJAX (and in Web at all) and took only a very
little part in Symbolicweb. It seem that AJAX technology is just not a
mature one now. So (if were not a Google) the best way for a business
is just to avoid it. For us, programmers, it is more profitable as
knowledge is expensive.
> tho of course Javascript is pretty damn close I must say.
I agree.
> Then it's a game of Freecell and back to work
I guess having some sports instead would be much better.
> upcoming re-opening of the standard
Are you serios?
From: Kenny
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <490f1686$0$5626$607ed4bc@cv.net>
budden wrote:
> I'm not an expert in AJAX (and in Web at all) and took only a very
> little part in Symbolicweb. It seem that AJAX technology is just not a
> mature one now. So (if were not a Google) the best way for a business
> is just to avoid it.
Pioneers do not wait for the rest areas on the interstate highway to
have sushi bars.
>>Then it's a game of Freecell and back to work
>
> I guess having some sports instead would be much better.
You mean the tennis I play twice a week followed of course by the
obligatory beers and nachos and then being comatose for six hours from
the exhaustion? Too big a dent in the schedule.
>>upcoming re-opening of the standard
>
> Are you serios?
No, CL is finished. You may begin programming.
kxo
> Pioneers do not wait for the rest areas on the interstate highway to
> have sushi bars.
It is your Choice.
> You mean the tennis I play twice a week followed of course by the
> obligatory beers and nachos and then being comatose for six hours from
> the exhaustion? Too big a dent in the schedule.
No. This is other. "Proizvodstvennaya gymnastyka". Instead of playing
a stupid computer game, just stand up for that minute and make several
simple moves to relax neck, eyes, arms, brain, ass :) Maybe dance...
Btw it is offtopic... I don't think I should learn you how you should
live...
> No, CL is finished. You may begin programming.
I'll think of it.
>>No, CL is finished. You may begin programming.
>
> I'll think of it.
Perfect. The Lisp community in haiku form:
CL is finished.
You may begin programming.
I will think of it.
Kenny <·········@gmail.com> wrote:
+---------------
| >>No, CL is finished. You may begin programming.
| >
| > I'll think of it.
|
| Perfect. The Lisp community in haiku form:
|
| CL is finished.
| You may begin programming.
| I will think of it.
+---------------
Don't think too long, guys.
Great programming tasks await!
Code, bubulas, code!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Raffael Cavallaro
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <geqk23$o0b$1@aioe.org>
On 2008-11-03 22:16:02 -0500, Kenny <·········@gmail.com> said:
> Perfect. The Lisp community in haiku form:
>
> CL is finished.
> You may begin programming.
> I will think of it.
lisp:
rumors of lisp's death
for years now, have been greatly
exaggerated
kenny:
sour grapes caused by web
two point zero shininess
proclaim "lisp is dead"
From: Thomas A. Russ
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <ymiskqec71k.fsf@blackcat.isi.edu>
budden <········@mtu-net.ru> writes:
> In "modern" OO languages such as C++ or Java, each class in fact
> introduces its own namespace. When you use a slot/method of a class in
> a definition of other method, you are into that namespace, so you
> don't need to fully qualify slots/members of that class. It is
> reasonable as class might encapsulate many or most of the data
> required for method definition.
You are falling into the trap of thinking of methods in CLOS as
belonging to classes. THEY DON'T BELONG TO CLASSES. Methods belong to
generic functions, and so there isn't any class to provide a context.
This is a very different object model than what you would find in Java
or C++. It has, IMHO, many advantages over that model. One of the
great benefits is greater extensibility, since you can easily add
methods to classes that you don't own or even have the source code for.
Try doing that in some other language! (And no, subclassing doesn't
count, because it doesn't affect the original class.)
> This leads to shorter, more easily
> reading code. In Perl, class is distinctly bound to namespace. Pascal
> has a with construct which joins namespaces from several records. SQL
> implies namespace merging in its "select" statement. I think, this
> approach is good. Surely my esthetic taste appeals me to get rid of
> that ugly code like that:
>
> (let ((foo (make-foo))
> (print (foo-a foo) (foo-b foo)))
Um, right here you also seem to be confusing structs and classes.
Putting aside the historic development, there are certain fundamental
differences between structs and classes that drive this difference.
There is another fundamental problem with your suggestions, which is
that they seem to trade a perceived increase in simplicity for very
simple cases (where you don't really need much help), but at the expense
of creating many problems when you try to do anything larger or more
complicated. Common Lisp is designed to solve problems in writing large
systems, not be the most concise for certain toy examples.
Now to return to your example. Since from the development of the
syntax, FOO is a struct, you have to remember that the accessors for
structs are standard functions, not generic functions. [elide discussion
of reasons for that.] So that means they don't do any dispatch on their
arguments.
So what happens when you have
(defstruct foo a b)
(defstruct bar b a)
(let ((foo (make-foo))
(bar (make-bar)))
(print (a foo) (a bar)))
Oops! Suddenly we have the problem that the single function A can't be
distinguished, since it isn't generic. It is a standard function.
Now, if you were to use classes, you could have accessors that would
distinguish between the cases. But you do have to make the conscious
design decision to use classes and not structs. But the point of having
a language with a lot of tools is to allow you to choose the most
appropriate one for the situation. That is what the profession of
software engineering is about.
Frankly, I find that most of your suggestions for changing the language
are not well thought out in terms of their consequences. It seems that
everytime someone puts up a more complicated scenario, your changes fail
in often very cryptic ways. For now it would probably be good for you
to assume that the language designers had good reasons for doing things
the way they did. Once you have more experience with using the language
to do larger projects, you would be in a position to evaluate the
trade-offs that were made.
So, for now my advice to you would be to chill out and not try to make
lisp into some other existing language. It is different. Almost all
the time, those differences are there for very sound technical reasons.
You should take this as an opportunity to expand your way of thinking
about programming and how programming languages work. But you can only
achieve that expansion of your thinking if you will go with the flow of
the language, rather than trying to fight it and change it right away.
It would be, for example, quite silly for me to start to learn Russian
and then immediately seek to reduce the number of grammatical cases from
the six(?) that exist in the language, since that would be simpler. But
anyone fluent in Russian would surely find my suggestions useless, since
I wouldn't have the necessary background in the language.
You should go through Seibel's examples and Norvig's case studies on
Common Lisp before you try to change things. That will at least mean
you have some significant exposure to what the language can do. And
then try to imagine more complicated arrangements of code with many
programmers working on them.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Kaz Kylheku
Subject: Re: use-package & name conflict: why they are not deferred?
Date:
Message-ID: <20081030130825.388@gmail.com>
On 2008-10-30, Thomas A. Russ <···@sevak.isi.edu> wrote:
> budden <········@mtu-net.ru> writes:
>
>> In "modern" OO languages such as C++ or Java, each class in fact
>> introduces its own namespace. When you use a slot/method of a class in
>> a definition of other method, you are into that namespace, so you
>> don't need to fully qualify slots/members of that class. It is
>> reasonable as class might encapsulate many or most of the data
>> required for method definition.
>
> You are falling into the trap of thinking of methods in CLOS as
> belonging to classes. THEY DON'T BELONG TO CLASSES. Methods belong to
> generic functions, and so there isn't any class to provide a context.
Budden appears to be not quite straight on the difference between referential
namespaces (contexts in which a symbol is considered to refer to something) and
symbol namespaces (contexts in which a symbol name resolves to a symbol).
It amuses me to the point of pain to realize that the thing he may be
looking for is ...
Ron Garret's Lexicons!
:)
Hi
> You are falling into the trap of thinking of methods in CLOS as
belonging to classes. THEY DON'T BELONG TO CLASSES
I know that. As I wrote before, I'm not a novice in lisp. I also know
the difference between (defstruct (... :conc-name nil) ... )
and defclass in respect to equally-named slots.
OOP design (which I don't like) tends to encapsulate semantically
related slots to a class.
Some (not all, but many) methods would concentrate around one class's
slots. So it is sometimes (very often) practicable
to make a namespace for class slots and to refer to that namespace in
methods related to that class. This was all I meant.
Kaz, thanks for the keyword. I'll take a look at it.
On Oct 25, 9:51 am, budden <········@mtu-net.ru> wrote:
> Hallo, group!
> I replied to the topic, but my message didn't appear. Don't know if
> it is a bug or moderation?
>
> > I'm not sure one can compare that.
>
> Each sql table defines a namespace where every its field presents as a
> symbol.
> Joining two tables is equavalent to (locally) using both namespaces at
> one time.
>
> > Not well-defined means you don't know where the error should occur. Are you
>
> sure what ``well-defined'' means?
> Sorry for my English. Maybe "poorly designed" is more correct.
>
> > Hmm, I would like to get the error as early as possible.
>
> (defpackage :p1 (:exports :sym :sym1))
> (defpackage :p2 (:exports :sym :sym2))
> (use-package :p1)
> (use-package :p2)
> (print 'sym1)
> ; end of file
>
> Does this program contain an error? Not in CL standard sence, in
> common sence.
>
> E.g. consider
>
> you: We'll be talking about walrus and oysters
> me: Package error: symbol 'eye' clashed
>
> vs
>
> you: We'll be talking about walrus and oysters
> me: ok
> you: first lets talk about a tusks
> me: (have read tusk as walrus:tusk) ok
> you: then about their eyes
> me: (read error: symbol 'eye' clashes)
>
error: symbol EYES is not defined in package OYSTER.
Hallo Rainer, Kaz, group,
> I try to avoid using packages with USE-PACKAGE
It is a matter of taste, but if you don't use-package, symbol clashes
don't matter for you anyway.
> Why should it occur here, when the conflict is already known at the time
the packages are used, with 100% certainty?
Is it a conflict if I have no intention to use "sym"? Not in sence of
CL, in common sence?
If we're going to intern "SYM" at run-time, we'd like have a
_warning_, not an error, from package system while doing (use-
package).
"sym from p1 inner join p2" means "from p1 or from p2" in Firebird and
MS SQL. Don't think it is a bug.