james anderson <··············@setf.de> writes:
> are there documents somewhere which recount the experience and
> deliberations which led to the common lisp package system?
Not in brief, nor in a single document, but a large number of
documents do contain information about this. Why do you ask?
Some particular thing you're wondering about? May just be easier
to ask.
one may have observed notes from me related to xml.
in that domain there are these things called "namespaces" which,
depending on whom you ask, combine aspects of packages, modules, and
environments. "names" (the identifiers for markup tags and for the
attributes which can appear in tags) are "in" "namespaces". if one tries
to get more precise than that, opinions diverge. it's not easy.
i've at least glanced at the other lisp implementations for xml modules.
one thing common to all is that, where they support namespaces, they
model names as singletons - in some cases symbols, which are collected
into named sets - in some cases packages.
this runs contrary to implementations in other languages. it also, as
matters would have it, runs contrary the semantics which one might be
tempted to infer from many of the base xml standards. when these are
read in isolation, they imply, for example, that - as restated for lisp,
the form for a function definition should accept an explicit argument
for the package name in addition to that for the function name. this
even though no one ever states a use which would demand this degree of
articulation. that is, no one has ever made a case for (setf
(function-package ...) ...).
i am at a loss to explain why that community insists on this approach. i
wonder whether it is rooted in it origin in text processing. one
unfortunate consequence is that later standards must contend with these
articulate names even though they are unnecessary.
i was just wondering how these developemnts stand in relation to
experiences with and the evolution of lisp. for example:
why do packages have global extent?
why are symbols in packages?
why are the bindings static?
why are packages first class objects?
where did the symbol syntax come from?
why do symbols encapsulate a symbol name and a package?
why shouldn't one be able to say (setf (function-package ...) ...)?
questions like that.
at the moment it's just idle curiosity. i recall seeing transcripts
which i surmised were leading up to the formulation of common lisp, but
by that point, there was nothing left as to whether, why and how.
Kent M Pitman wrote:
>
> james anderson <··············@setf.de> writes:
>
> > are there documents somewhere which recount the experience and
> > deliberations which led to the common lisp package system?
>
> Not in brief, nor in a single document, but a large number of
> documents do contain information about this. Why do you ask?
> Some particular thing you're wondering about? May just be easier
> to ask.
james anderson <··············@setf.de> writes:
> why do packages have global extent?
well, there have been several hierarchical package systems but they died.
i can't say why. but this is really a consistency issue with an overall
design paradigm of what I call "initial" vs "global". some systems give
you an initial environment, and that's got certain lexicality/locality
coolness but makes talking about "far off" things painful because you have
to root around to find them. some systems give you "global" stuff because
the system designers value being able to dead-reckon important functionality.
the same issues come up in absolute vs relative pathnames. being able to
say "/etc/passwd" or "/usr/local/bin/foo" is very useful.
> why are symbols in packages?
because systems were originally organized around an "i own the world"
metaphor and then later merged. symbol clashes occurred, and package
partitioning kept symbols from clobbering each other, both semantically
for functions and data-wise for things like properties, symbolic data
indicators, etc.
> why are the bindings static?
i don't know what this means. do you mean, why is the binding from a symbol
to a namespace static? because symbol equality is important in more than
just programs. and because reflective programming allows programs to inspect
the relationship between programs and data. and because of speed.
> why are packages first class objects?
why not?
> where did the symbol syntax come from?
the syntax of "foo"? it came from reality.
the package marker syntax? because : won the war over which lesser-used
connective would be ceded for this purpose. arbitrary.
> why do symbols encapsulate a symbol name and a package?
if i understand you, the answer is: because if they had only a name,
you'd have to write the whole name. the package part becomes an
omittable shorthand.
> why shouldn't one be able to say (setf (function-package ...) ...)?
because functions are things that live in symbols. function-package is
a meaningless concept.
(defun foo (x) x)
(setf (symbol-function 'bar) (symbol-function 'foo))
(setf (function-package #'bar) ...) would set what??
At this point both FOO and BAR have the same function definition.
The symbol points to the function, not vice versa.
The symbol also points to a package, but that's just convention;
in fact, the symbol may live in multiple packages.
The fact that you asked this question suggests that you have some very
deep-rooted misunderstandings about the whole architecture of symbols and
other data in the Lisp system, and probably at some level accounts for
all your other questions as well. I don't mean to put you down. Everyone
goes through this. But you're not going to get the real answers you seek
until you properly understand the way the Lisp data world is connected.
> questions like that.
>
> at the moment it's just idle curiosity. i recall seeing transcripts
> which i surmised were leading up to the formulation of common lisp, but
> by that point, there was nothing left as to whether, why and how.
A lot of it was iterative design. I have draft after draft of the design
in which the semantics change wildly as CLTL "cooled". At one point,
symbols were hiearchically arranged, for example. There was a PACKAGE package
and package names were found in that. PACKAGE:FOO:X was the same as FOO:X.
You could say FOO:BAR:BAZ:X. But that went away mysteriously, with no other
explanation than a cryptic note saying "does anyone want this?" or some such
that was probably answered by "no". We were not very experienced with packages
when we decided a lot of this. The design isn't probably optimal, but is
mostly usable. So it has survived.
the questions were informal and, partly, rhetorical. thanks for trying
them on for size anyway. i did not expect them to make much sense from
the perspective of symbolic processing, but there's this other domain,
which has an awful lot to do with names, where a lot of folks have come
to what would appear to be a distinctly different conclusion on similar
issues. i'm just wondering if there are any lessons which could be
distilled from the path lisp has taken to get where it is.
> > why do packages have global extent?
> > why are the bindings static?
the "quadry", when expressed more accurately, would be "why do package
names have indefinite scope and packages themselves indefinite extent."
the answer to the former was "evolution".
the semantics of hierarchial names is not clear to me. when fully
qualified they're like the present-day symbols, but they also imply the
possibility of some additional form of package name scoping.
did anyone ever try to build systems with names like package:x:y:z?
as chance would have it, explanations of xml validation mechanisms are
resorting to similar naming forms...
> > why are symbols in packages?
>
> because systems were originally organized around an "i own the world"
> metaphor and then later merged. ...
why are symbols _interned_ in packages? (humor me.) other than speed.
symbol equality could well have been defined based on the identity of
name and package slots.
were there any counter examples? why one wouldn't want to.
did anyone ever do an analysis of lisp code to determine that interning
overhead was more than compensated for by more efficient comparisons?
across different application domains?
> > why are packages first class objects?
>
> why not?
well, it entails interning?
>
> > why do symbols encapsulate a symbol name and a package?
>
> if i understand you, the answer is: because if they had only a name,
> you'd have to write the whole name. the package part becomes an
> omittable shorthand.
i meant this in distinction to requiring/permitting both parts of a name
to be expressed independently.
> > why shouldn't one be able to say (setf (function-package ...) ...)?
>
> because functions are things that live in symbols. function-package is
> a meaningless concept.
>
> (defun foo (x) x)
> (setf (symbol-function 'bar) (symbol-function 'foo))
> (setf (function-package #'bar) ...) would set what??
> At this point both FOO and BAR have the same function definition.
> The symbol points to the function, not vice versa.
> The symbol also points to a package, but that's just convention;
> in fact, the symbol may live in multiple packages.
>
> The fact that you asked this question suggests that you have some very
> deep-rooted misunderstandings about the whole architecture of symbols and
> other data in the Lisp system, and probably at some level accounts for
> all your other questions as well. I don't mean to put you down. Everyone
> goes through this. But you're not going to get the real answers you seek
> until you properly understand the way the Lisp data world is connected.
hey, no problem. the analogy was a bit over the edge. which doesn't mean
it was inaccurate.
yes, no one in their right mind would think of writing the following,
let alone using it.
? (defgeneric (setf function-package) (package function)
(:method ((name string) (function t))
(setf (function-package function)
(or (find-package name)
(error "no package: ~s.")))
name)
(:method ((package t) (function symbol))
(setf (function-package (symbol-function function))
package)
package)
(:method ((package package) (function function)
&aux (name (function-name function)))
(unless name
(error "can't rename an anonymous function: ~s." function))
(fmakunbound name)
(setf name (intern (string name) package))
(setf (symbol-function name) function)
package))
#<STANDARD-GENERIC-FUNCTION (SETF FUNCTION-PACKAGE) #x72AA666>
? (defun x (x) x)
X
? (x 1)
1
? (setf (function-package 'x) "xml")
"xml"
? (x 1)
> Error in process Listener 3: Undefined function X called with arguments (1) .
> While executing: "Unknown"
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry applying X to (1).
See the Restarts� menu item for further choices.
1 > (|xml|::x 1)
1
1 >
on the other hand, could one guarantee that no one contemplates things
like this:
? (defgeneric (setf class-package) (package class)
(:method ((name string) (class t))
(setf (class-package class)
(or (find-package name)
(error "no package: ~s.")))
name)
(:method ((package t) (class symbol))
(setf (class-package (find-class class))
package)
package)
(:method ((package package) (class class)
&aux (name (class-name class)))
(unless name
(error "can't rename an anonymous class: ~s." class))
(setf (find-class name) nil)
(setf name (intern (string name) package))
(setf (find-class name) class)
(setf (class-name class) name)
package))
#<STANDARD-GENERIC-FUNCTION (SETF CLASS-PACKAGE) #x72E6D26>
? (defclass z () ())
#<STANDARD-CLASS Z>
? (setf (class-package 'z) "xml")
"xml"
? (make-instance '|xml|::z)
#<|xml|::Z #x72F016E>
...
james anderson <··············@setf.de> writes:
> the questions were informal and, partly, rhetorical. thanks for trying
> them on for size anyway. i did not expect them to make much sense from
> the perspective of symbolic processing, but there's this other domain,
> which has an awful lot to do with names, where a lot of folks have come
> to what would appear to be a distinctly different conclusion on similar
> issues. i'm just wondering if there are any lessons which could be
> distilled from the path lisp has taken to get where it is.
if i get some time, i'll try to answer this in a more detailed way. i
answered superficially, but you shouldn't think i thought it was a
superficial question. better answers take longer.
> why are symbols _interned_ in packages? (humor me.) other than speed.
> symbol equality could well have been defined based on the identity of
> name and package slots.
no, they could not. this is an option some languages might have, but not
lisp. lisp is above all else fundamentally about object identity. an object
either is something or it is not something. it doesn't vary. we can certainly
make tings like you describe, but those things are not objects. it is the
very essence of first-class-ness that it uses (effectively) pointer compares.
(i say effectively because there are some cheats with numbers and characters
for various reasons that have to do with trading compilability of efficient
machine instructions for a slightly more elaborate model. but if you think
of eql as meaning pointer compare, and you utterly ignore eq, you'd never
know it wasn't pointers always.)
> were there any counter examples? why one wouldn't want to.
it isn't first class. it works completely against the style of the language.
- - - -
i'll try to answer some of your other questions later.
Kent M Pitman wrote:
>
> james anderson <··············@setf.de> writes:
>
> > the questions were informal and, partly, rhetorical. ...
>
> if i get some time, i'll try to answer this in a more detailed way. i
> answered superficially, but you shouldn't think i thought it was a
> superficial question. better answers take longer.
>
> > why are symbols _interned_ in packages? (humor me.) other than speed.
> > symbol equality could well have been defined based on the identity of
> > name and package slots.
>
> no, they could not. this is an option some languages might have, but not
> lisp. lisp is above all else fundamentally about object identity. an object
> either is something or it is not something. it doesn't vary. we can certainly
> make tings like you describe, but those things are not objects. it is the
> very essence of first-class-ness that it uses (effectively) pointer compares.
is this a rhetorical "first-class", or is this notion of lisp
"first-class-ness" distinct from bind/pass/return?
> (i say effectively because there are some cheats with numbers and characters
> for various reasons that have to do with trading compilability of efficient
> machine instructions for a slightly more elaborate model. but if you think
> of eql as meaning pointer compare, and you utterly ignore eq, you'd never
> know it wasn't pointers always.)
>
> - - - -
> i'll try to answer some of your other questions later.
please ...
james anderson <··············@setf.de> writes:
> Kent M Pitman wrote:
> >
> > james anderson <··············@setf.de> writes:
> >
> > > the questions were informal and, partly, rhetorical. ...
> >
> > if i get some time, i'll try to answer this in a more detailed way. i
> > answered superficially, but you shouldn't think i thought it was a
> > superficial question. better answers take longer.
> >
> > > why are symbols _interned_ in packages? (humor me.) other than speed.
> > > symbol equality could well have been defined based on the identity of
> > > name and package slots.
> >
> > no, they could not. this is an option some languages might have, but not
> > lisp. lisp is above all else fundamentally about object identity. an object
> > either is something or it is not something. it doesn't vary. we can certainly
> > make tings like you describe, but those things are not objects. it is the
> > very essence of first-class-ness that it uses (effectively) pointer compares.
>
> is this a rhetorical "first-class", or is this notion of lisp
> "first-class-ness" distinct from bind/pass/return?
First class means it has definite identity and an indefinite scope and extent.
It means you can do with it anything you can do with any other object.
I have not even the foggiest idea of what you mean by bind/pass/return which
are remarks about evaluation. Object identity and nature has nothing
whatsoever to do with evaluation and would exist even if the entire system
was a hard-wired program to which you had no access to programming capability,
if all you had was an API for passing things in and out.
This relates to your earlier model of function-package. In Lisp, objects
have type. In most other languages, locations have type. In Lisp, objects are
sacred. You can make typed locations in Lisp, but that just means you can make
containers that will not hold some kinds of objects--that doesn't mean you
have done something to objects. Variables are just places to put pointers
to objects, but objects are inviolate things, each of which by its type, has
an API that determines how it may be used and by its identity achieves
its place in the world, its role in certain operations, its reputation, etc.
second-class objects are objects that don't really have some property of
REAL objects. An object that is second-class is something like a go tag.
In principle, there is a namespace that hold these things. But you can't
get those objects and manipulate, inspect them. You can't be sure someone
isn't substituting one for another behind your back. Scheme continuations,
by comparison, are first-class objects that are like go tags. Just so you can
see the contrast.
Lisp allows you to sometimes make second-class object like dynamic-extent
objects if you want these, but that's not the default. And really, you're
promising not to do anything that would really detect whether they were
dynamic-extent or not, so you can't REALLY tell whether you got a first-
or second-class one.
Kent M Pitman wrote:
>
> >
> > is this a rhetorical "first-class", or is this notion of lisp
> > "first-class-ness" distinct from bind/pass/return?
>
> First class means it has definite identity and an indefinite scope and extent.
> It means you can do with it anything you can do with any other object.
>
> I have not even the foggiest idea of what you mean by bind/pass/return which
> are remarks about evaluation.
i was looking for a shorthand expression of the scheme notion of "first
class object"
> Object identity and nature has nothing
> whatsoever to do with evaluation and would exist even if the entire system
> was a hard-wired program to which you had no access to programming capability,
> if all you had was an API for passing things in and out.
>
> This relates to your earlier model of function-package. In Lisp, objects
> have type. In most other languages, locations have type. In Lisp, objects are
> sacred. You can make typed locations in Lisp, but that just means you can make
> containers that will not hold some kinds of objects--that doesn't mean you
> have done something to objects. Variables are just places to put pointers
> to objects, but objects are inviolate things, each of which by its type, has
> an API that determines how it may be used and by its identity achieves
> its place in the world, its role in certain operations, its reputation, etc.
>
> second-class objects are objects that don't really have some property of
> REAL objects. An object that is second-class is something like a go tag.
> In principle, there is a namespace that hold these things. But you can't
> get those objects and manipulate, inspect them.
> [1] You can't be sure someone
> isn't substituting one for another behind your back. Scheme continuations,
> by comparison, are first-class objects that are like go tags. Just so you can
> see the contrast.
>
> Lisp allows you to sometimes make second-class object like dynamic-extent
> objects if you want these, but that's not the default.
> [2] And really, you're
> promising not to do anything that would really detect whether they were
> dynamic-extent or not, so you can't REALLY tell whether you got a first-
> or second-class one.
so, is it fair to repraise the issues [1,2] which govern the legitimacy
of symbols as a model for xml names as that of referential transparency?
that is, whether two names with the same expression are the same thing
independent of the respective expressions' contexts?
james anderson <··············@setf.de> writes:
> so, is it fair to repraise the issues [1,2] which govern the legitimacy
> of symbols as a model for xml names as that of referential transparency?
> that is, whether two names with the same expression are the same thing
> independent of the respective expressions' contexts?
i'm going to have trouble getting you a detailed answer soon, so again
i'll answer very briefly and hope it keeps you on track.
i've looked at xml namespaces a fair amount but have not actually dealt
with situations where they are actually used in a manner other than of
my own devising. my understanding of the semantics is from the
text of the document and has not been tested against someone else's
understanding.
it is my present and untested working assumption that the following important
difference between xml and lisp exists. if someone knows and can cite
documentation proving that i'm wrong, i won't be surprised, and i will
quite appreciate the citation, becuase i'd love to find im' wrong on this:
as nearly as i can tell, xml says
foo is a symbol
a:foo is a symbol, but is not foo.
b:foo is a symbol, but is not foo.
foo might MEAN the same (semantically) as a:foo or b:foo
in Lisp
foo is a symbol
a:foo is a symbol, and might be the aforementioned symbol foo or b:foo
b:foo is a symbol, and might be the aforementioned symbol foo or a:foo
As nearly as I can tell, if you implement a function similar to lisp READ
for xml, that is, something that parses XML but applies no semantics to it,
you would read:
<a:foo>
<foo>
...
<foo>
</a:foo>
as referring to different symbol A:FOO and FOO *even if* this XMl was
to be processed in the "defaultly A" namespace. So READ would return
#s(xml :tag #S(marker :name "foo" :namespace "a")
:attributes ()
:contents ( #s(xml :tag #S(marker :name "foo" :namespace nil)
:attributes ()
:contents (...)) ))
and in particular it would *not* return
#s(xml :tag #1=#S(marker :name "foo" :namespace "a")
:attributes ()
:contents ( #s(xml :tag #1#
:attributes ()
:contents (...)) ))
In Lisp, the semantics is applied to the data. In Lisp, if you
READ
(a:foo (foo))
in the A package, you get back
(FOO (FOO)), that is, (A:FOO (A:FOO)).
and if you read it in the B package (where B has no shared symbols with
A), you get:
(FOO (B:FOO)), that is, (A:FOO (B:FOO))
In Lisp there is no notion of "I read a symbol that has no package".
XML seems to have that notion. Package is attached at read time.
In Lisp, there is no notion of "I have one package now but a different one
later." A package has a symbol in Lisp, not vice versa. Symbols are
immutable, and while you could arrange subtitution semantics like:
(SUBST 'A:FOO 'FOO '(A:FOO (FOO)))
yielding a new and unrelated expression
(A:FOO (A:FOO))
you can't just say
(WOO-WOO-MAGIC-INCANTATION-HERE-PRETEND-FOO-IS-NOT-FOO
'(A:FOO (FOO)))
and have this mean anything except if you create out-of-band storage in
WOO-WOO-MAGIC-INCANTATION-HERE-PRETEND-FOO-IS-NOT-FOO, and if everything
that wants to "pretend" FOO and A:FOO are the same.
You might, for example, do
(defvar *the-unpackaged-package*
(make-package "THE-UNPACKAGED-PACKAGE" :use '()))
(defun make-unpackaged-symbol (string)
(intern string *the-unpackaged-package*))
(defun unpackaged-p (symbol)
(eq (symbol-package symbol) *the-unpackaged-package* ))
(defun my-symbol-package (symbol)
(if (unpackaged-p symbol)
*dominant-package*
(symbol-package symbol)))
(defun compare-symbols (symbol1 symbol2)
(or (eq symbol1 symbol2)
(and (eq (my-symbol-package symbol1)
(my-symbol-package symbol2))
(eq (symbol-name symbol1) (symbol-name symbol2)))))
And you could make a binding form for *dominant-package*, etc.
But even here, you'd get screwed by the (or (eq symbol1 symbol2) ...)
because that's not just an optimization but an active semantic
impediment. It's ALSO possible in XML, as nearly as I can tell, to do:
<bleah>
<a:foo xmlns="x"> ...</a:foo>
<a:foo xmlns="y">...</a:foo></bleah>
so that even if you have symbols Lisp would say ARE packaged, the
"meaning" of the package can change. Again, that can't happen in Lisp.
The reason is that in Lisp, if I do
(get x 'foo)
I am asking to find the FOO property on X. That's not a semantic FOO,
that's a literal data FOO. Just like as if I wrote
(get x 3)
There is only one 3. Y ou don't get a different 3 than I get.
Lisp programmers long ago put lots of programs together with data markers
being the place things are stored. When they loaded their programs together,
there were lots of
(SETF (GET 'HOME 'WINDOW) 'LATTICE-GRID)
in one file for Fred's application possibly conflicting with
(SETF (GET 'HOME 'WINDOW) MACINTOSH:*DESKTOP*)
in another. That is, people didn't agree not just on prrogram but on data.
So we segmented things and said "Symbols have meaning and we must be able
to both separate them AND reliably notate which one we're referring to in
a hybrid environment, out of context". You can't debug a data layout if
you have to have a program run and compile and attach a semantics because
there may not be any program that has that layout.
Lisp takes the point that DATA exists and that programs are the contrivance
of man that serves data. XML seems to take the opposite approach, that
programs exist and that DATA is the contrivance of programs ... but to what
end? Something must be outside the programs. I claim there's data out there
and that it is primitive to programs. If it is, it must be inspectable
and it must have identity INDEPENDENT of programs. It can't rely on programs
in order to give it a meaning. (It probably does, in the sense that
all of the universe is probably a creation of our minds, but that gets into
heavy philosophy I don't want to get into. The simplest model of the world
that mechanically expresses the notion that you and i can talk to one another
is not "everything i receive is data from my sensory inputs and it's
questionable whether you exist" but rather "i trust my data sources, which
say that you exist and i exist and we exist in the concept of things that
can be seen, touched, and, importantly, described ... In that model, data
is primitive. So even symbols that don't have semantics have semantics--they
have the semantics of "being the s ymbol that had no semantics". You can't
REALLY delay that. You can create an elaborate fiction to pretend you
did. But that isn't the primitive way of the world.
Lisp and XML are only superficially similar. They disagree at a VERY deep
level. You might learn something about the world by comparing their
differenes, but because they diverge so early in the tree of fundamental
assumptions, i'm not sure you'll learn much of use ...
unless my reading of xml is confused, which i hope it is.
I somehow doubt this clarified anything, but it's the best "short answer"
I could come up with at this hour of the night.
Kent M Pitman wrote:
>
> ...
>
> as nearly as i can tell, xml says
>
> foo is a symbol
> a:foo is a symbol, but is not foo.
> b:foo is a symbol, but is not foo.
well, the problem, the root of this discussion, is that xml has no
explicit notion of a symbol. the expressions "foo", "a:foo", and "b:foo"
are qualified names, mean something only in the presence of bindings for
the respective prefixes. if one looks, for example at the infoset [1],
both an element and an attribute are described in terms of a 'local
name', a 'namespace name', and a prefix. whereby the prefix is
deprecated in the presence namespaces and is understood to have been
supplanted with the namespace bound to the prefix in the context in
which the respective form appeared. the local name and the namespace
name constitute a universal name, which is immutable.
[1] http://www.w3.org/TR/xml-infoset#infoitem.element,
http://www.w3.org/TR/xml-infoset#infoitem.attribute
>
> foo might MEAN the same (semantically) as a:foo or b:foo
>
> in Lisp
>
> foo is a symbol
> a:foo is a symbol, and might be the aforementioned symbol foo or b:foo
> b:foo is a symbol, and might be the aforementioned symbol foo or a:foo
the distinction between "meaning the same thing (semantically)" and "be
the aformentioned" confuses me. please see below.
>
> As nearly as I can tell, if you implement a function similar to lisp READ
> for xml, that is, something that parses XML but applies no semantics to it,
> you would read:
>
> <a:foo>
> <foo>
> ...
> <foo>
> </a:foo>
>
> as referring to different symbol A:FOO and FOO *even if* this XMl was
> to be processed in the "defaultly A" namespace. So READ would return
> #s(xml :tag #S(marker :name "foo" :namespace "a")
> :attributes ()
> :contents ( #s(xml :tag #S(marker :name "foo" :namespace nil)
> :attributes ()
> :contents (...)) ))
>
> and in particular it would *not* return
>
> #s(xml :tag #1=#S(marker :name "foo" :namespace "a")
> :attributes ()
> :contents ( #s(xml :tag #1#
> :attributes ()
> :contents (...)) ))
that is the question.
if every operation one is permitted to perform on objects of type xml
returns the same value and has the same side-effects for all #S(marker
:name n_0 :namespace ns_0) and
#S(marker :name n_1 :namespace ns_1) where n_0 == n_1 and ns_0 == ns_1
and the same applies to objects of type marker themselves - as is the
crux of those higher-level xml specs which describe their semantics in
terms of an abstract model, then what is the difference?
>
> In Lisp, the semantics is applied to the data. In Lisp, if you
> READ
>
> (a:foo (foo))
>
> in the A package, you get back
>
> (FOO (FOO)), that is, (A:FOO (A:FOO)).
>
> and if you read it in the B package (where B has no shared symbols with
> A), you get:
>
> (FOO (B:FOO)), that is, (A:FOO (B:FOO))
>
> In Lisp there is no notion of "I read a symbol that has no package".
> XML seems to have that notion. [The package] is attached at read time.
XML specifications for serialization are expressed as if such a notion
were to exist.
the specifications for validation and other operations, on the other
hand, specify semantics which introduce designated values to play the
role of this "namespace of names which are not in any namespace." by
which means the collection is eventually determined at the time of
evaluation. as it always ends up being the same collection, i can't
recognize an effect or purpose for delaying the determination.
> In Lisp, there is no notion of "I have one package now but a different one
> later." A package has a symbol in Lisp, not vice versa. Symbols are
> immutable, and while you could arrange subtitution semantics like:
>
> (SUBST 'A:FOO 'FOO '(A:FOO (FOO)))
>
> yielding a new and unrelated expression
>
> (A:FOO (A:FOO))
>
> you can't just say
>
> (WOO-WOO-MAGIC-INCANTATION-HERE-PRETEND-FOO-IS-NOT-FOO
> '(A:FOO (FOO)))
there is while reading, via *package*, to a limited extent. i suggest
that the same applies to xml. i have not discerned a broader notion of
"one package now but a different one later" in xml either. the
mechanisms for binding prefixes to namespaces differ from those used to
associate package names with packages (cf my earlier questions about
scope and extent), but, once parsed, the association between namespace
and local part is treated in every spec i have seen as if it is
immutable.
> ...
> It's ALSO possible in XML, as nearly as I can tell, to do:
>
> <bleah>
> <a:foo xmlns="x"> ...</a:foo>
> <a:foo xmlns="y">...</a:foo></bleah>
>
> so that even if you have symbols Lisp would say ARE packaged, the
> "meaning" of the package can change.
the "'meaning' of the package does not change. the meaning of the
prefix, that is the namespace's nickname, changes. the mechanism used to
bind prefixes to namespaces is different than that which binds package
names to packages.
the above is sugar for
<bleah>
<{x}foo > ... </{x}foo>
<{y}foo > ... </{y}foo></bleah>
which does not exhibit the objectionable behaviour. the prefix bindings
for namespaces are lexically scoped. this pertains to the bindings, not
to the namespaces themselves. the infoset goes a step further and
specifies that the bindings have indefinite extent but deprecates their
use. it is argued that one needs them for editors. it's a minor point
and i've not yet seen anywhere where it would make a difference.
> Again, that can't happen in Lisp.
agreed. 'cause package names in common lisp constitute a binding with
indefinite scope, and they are used as if they were constants. ? how
much of the "'meaning' of packages" changes when this is not true?
>
> ...
>
> Lisp takes the point that DATA exists and that programs are the contrivance
> of man that serves data. ... In that model, data
> is primitive. So even symbols that don't have semantics have semantics--they
> have the semantics of "being the s ymbol that had no semantics". You can't
> REALLY delay that.
i agree. which is why i argue it is appropriate to model xml's universal
names with symbols. not the qualified names, the universal names.
> Lisp and XML are only superficially similar. They disagree at a VERY deep
> level.
i am not yet convinced.
> You might learn something about the world by comparing their
> differenes, but because they diverge so early in the tree of fundamental
> assumptions, ...t
james anderson <··············@setf.de> writes:
> > in Lisp
> >
> > foo is a symbol
> > a:foo is a symbol, and might be the aforementioned symbol foo or b:foo
> > b:foo is a symbol, and might be the aforementioned symbol foo or a:foo
>
> the distinction between "meaning the same thing (semantically)" and "be
> the aformentioned" confuses me. please see below.
The difference is that if I do:
(defun foo (x) (+ x 1))
(foo 3) => 4
(setf (symbol-function 'bar) (symbol-function 'foo))
(bar 3) => 4
The symbols "FOO" and "BAR" now "mean the same thing" in the sense of having
the same definition. But they are NOT the same thing.
To keep from going crazy, one MUST be able to converse about the fact
that one is an expression containing FOO and one is an expression
contianing BAR.
We make a conscious choice in Lisp to confuse certain expressions. For
example, we say that
(setq x '|FOO|)
and
(setq x '\F\O\O)
are equivalent expressions. They both set a variable X to a symbol FOO.
Lost forever after is the ability to tell what notation we used on type-in.
Likewise,
(setq x 'foo)
and
(setq x 'FOO)
are the same in the normal readtable, because the readtable is
case-translating.
Likewise '(+ 3 4) is the same as '(+ 3 4). We do not deal in
text expressions, we deal in lists.
The READ phase is responsible for "canonicalizing" input from text into a
set of items onto which we attach semantics. We allow READ to do a small
amount of defined pre-processing, but once it has done that, we produce
the expressions that are "the meat of the matter", they are symbolic
representations of what is typed.
One of these canonicalization operations is that, at read read-time,
we choose to make CAR mean CL:CAR. We could have made these separate symbols
and made other operators to compare them than pointer compare. What would
be lost? (1) speed and (2) perspicuity of all programs. My guess is people
would just always write either CAR or always CL:CAR, just to get back the
speed of the pointer compare. I cite Scheme as a community that made this
decision. However, while I think there is a definite elegance about the
Scheme approach to symbols, it also comes with a large price. Lisp programs
used to be easier to develop and inspect because of their use of the property
symbol's list, which was a quickly-available structure hanging directly off
the symbol, not something one had to spend time looking up in hash tables.
Scheme eliminated the ability to use the symbol property list because the
namespace is too small. This lost something even new programmers care about
sometimes, but it also broke all program compatibility with the past. There
are some very big programs that use properties in subtle ways, and the cost
of retrofitting them to a new semantics would be tricky.
We explicitly and intentionally and thoughtfully and purposely designed into
the CL syntax the idea that we wanted to say (car x) meaning (cl:car x) and
that we didn't want afterward to know which one we had said. We knew we
were losing the ability to say "You need to say (cl:car x) rather than (car x)."
in error messages. But we felt we were gaining the ability to have a REAL
shorthand. You do not have a shorthand when whoever you are talking to can
complain about your use of the shorthand. Package prefixing is intentionally
part of the text pre-processing phase accomodated by READ, just like 'foo
vs (quote foo) is.
> >
> > As nearly as I can tell, if you implement a function similar to lisp READ
> > for xml, that is, something that parses XML but applies no semantics to it,
> > you would read:
> >
> > <a:foo>
> > <foo>
> > ...
> > <foo>
> > </a:foo>
> >
> > as referring to different symbol A:FOO and FOO *even if* this XMl was
> > to be processed in the "defaultly A" namespace. So READ would return
> > #s(xml :tag #S(marker :name "foo" :namespace "a")
> > :attributes ()
> > :contents ( #s(xml :tag #S(marker :name "foo" :namespace nil)
> > :attributes ()
> > :contents (...)) ))
> >
> > and in particular it would *not* return
> >
> > #s(xml :tag #1=#S(marker :name "foo" :namespace "a")
> > :attributes ()
> > :contents ( #s(xml :tag #1#
> > :attributes ()
> > :contents (...)) ))
>
> that is the question.
>
> if every operation one is permitted to perform on objects of type xml
> returns the same value and has the same side-effects for all #S(marker
> :name n_0 :namespace ns_0) and
> #S(marker :name n_1 :namespace ns_1) where n_0 == n_1 and ns_0 == ns_1
> and the same applies to objects of type marker themselves - as is the
> crux of those higher-level xml specs which describe their semantics in
> terms of an abstract model, then what is the difference?
Philosophers have debated this question forever.
The term "the morning star" refers to the planet Venus. For a long time,
people knew of the morning star.
The term "the evening star" also refers to the planet Venus. For a long
time, people knew of the evening star.
But lots of people didn't know the morning star was the evening star.
One wants to be able to tell someone that fact. How does one do that?
It cannot be done in a language that does unconditional substitution
of equals for equals. The statement
"the morning star is the evening star"
is most assuredly not equivalent to the trivial claim
"the morning star is the morning star"
nor to the additional fact you might still not know which is
"the morning star is the evening star"
Fortunately, English is able to carry this through IS, which is magic.
But if it were not, it would require quoting and a representation of other
things. Philosophy papers on this are dreary for lack of good notation and
the need to constantly explain the long notation. But it can be done.
Now look at Lisp. Maybe we have a MORNING package with STAR in it and an
EVENING package with STAR in it. Maybe those are shared and maybe they
are not. You're going to sometimes run into the confusion above, and other
times not. Maybe in XML you will hit the problem in different ways or maybe
not.
However, I regard these philosophical paradigms in the same way as
mathemeticians do "reducing a problem to the traveling salesman problem".
I have cached "the morning star/evening star" problem as something that
will be there for a long time. It isn't good or bad. It just is. As soon
as you see something that is like it, you MUST stop caring to solve it
or you will spin your wheels forever uselessly.
The fact is that ANY representation, or at least any good one, is going to
allow some inevitable confusions and some discussion about them. The issue
is not "will this happen" but when. "surprises of identity" are part of
life. The question is "when do I want to bear them and when not".
And I certainly don't want to be addressing them in every function or macro
I write. So I pick a notation that makes the common things convenient and
makes me do extra work to back off into a meta-representation that an address
the odd cases. When I write the setf macro, I don't want to do:
(cond ((member op '(car fred:car bill:car sally:car ...))
`(set-car ,cons ,value))
...)
The reason is that it's slow. I just want one symbol CAR to test against
and I want it to take one machine instruction to do the test, and then I
want to be done. But I don't want to impose a cost on the user at input
time saying "you must write your code just so". So that he writes
car or CAR or Car or |CAR| or FRED:CAR (where FRED inherits from CL) or
CL:CAR or CL:\C\A\R is utterly up to him. I can still, by virtue of Lisp's
chosen semantics, do a single-instruction compare to make sure I'm dispatching
on the right item. And that's the design trade-off Lisp intentionally made.
Likewise, I don't want to do this:
(cond ((meaning-equal (meaning-of 'car user-env)
(meaning-of op user-env))
...))
I don't want to do this for efficiency reasons. And I don't want to do it
because it's cumbersome. I really just want to do:
(cond ((eq op 'car) ...))
THAT is the Lisp tradition that predated packages and that's the one I
want preserved. Now, in Scheme, you can sometimes get away with "punning"
(what they always say CL people do with two namespaces and tell us how
gross it is, not realizing they do it themselves but in different ways):
(cond ((eq op car) ...))
where you have arranged for your module system to put the "meaning of" CAR
in the car variable, so really CAR here is being used as secretely meaning
"meaning of car" but the syntax is not admitting that. And you have to have
done a dereferencing phase on op, turning it into "meaning of op" for this
to work. But that's just painful because it means that for every such
situation you come into where you want to make the case dispatch pretty, you
have to contort all the rest of your module environment in order to prepare
for this one little island of pretty.
I'm not really knocking scheme here. They made a design decision to make
any package-name association in symbols be added "after the fact" and
they've lived with it. And we've made our decision and we've lived with it.
I think both communities are happy, which is more a statement about how
different people like different things than a statement about how one made
the right choice over another. It's right that there be two languages here
because we just don't have the same goals or sensibilities and it would be
brutal all trying to live under one roof.
If you asked all your questions to scheme people, you'd maybe get answers you
liked better. But it wouldn't make the cl community wrong.
Only one little detail about the Scheme model that wouldn't help you.
In Scheme, cl:foo is a six-letter symbol. One artifact of their choice
not to package is that doing (symbol-package 'cl:foo) is a string operation
(or, at minimum, consults a cache of pre-computed answers to string
operations). That is, CL:FOO is not stored as
#S(scheme-symbol :package "CL" :name "FOO")
nor is FOO
#S(scheme-symbol :package #f :name "FOO")
but rather,
#S(scheme-symbol :name "CL:FOO")
or
#S(scheme-symbol :name "FOO")
> >
> > In Lisp, the semantics is applied to the data. In Lisp, if you
> > READ
> >
> > (a:foo (foo))
> >
> > in the A package, you get back
> >
> > (FOO (FOO)), that is, (A:FOO (A:FOO)).
> >
> > and if you read it in the B package (where B has no shared symbols with
> > A), you get:
> >
> > (FOO (B:FOO)), that is, (A:FOO (B:FOO))
> >
> > In Lisp there is no notion of "I read a symbol that has no package".
> > XML seems to have that notion. [The package] is attached at read time.
>
> XML specifications for serialization are expressed as if such a notion
> were to exist.
> the specifications for validation and other operations, on the other
> hand, specify semantics which introduce designated values to play the
> role of this "namespace of names which are not in any namespace." by
> which means the collection is eventually determined at the time of
> evaluation. as it always ends up being the same collection, i can't
> recognize an effect or purpose for delaying the determination.
Regardless of where you draw the line on ANY semantic translation,
it's always useful to be able to delay that. Even in Lisp, I'd love
to be able to find out whether someone typed FOO or foo on input once
in a while. I might defend the practice of canonicalization, but I
could never form a serious statement like "i can't recognize an effect
or purpose of delaying the determination of that the user meant FOO."
> > In Lisp, there is no notion of "I have one package now but a different one
> > later." A package has a symbol in Lisp, not vice versa. Symbols are
> > immutable, and while you could arrange subtitution semantics like:
> >
> > (SUBST 'A:FOO 'FOO '(A:FOO (FOO)))
> >
> > yielding a new and unrelated expression
> >
> > (A:FOO (A:FOO))
> >
> > you can't just say
> >
> > (WOO-WOO-MAGIC-INCANTATION-HERE-PRETEND-FOO-IS-NOT-FOO
> > '(A:FOO (FOO)))
>
> there is while reading, via *package*, to a limited extent. i suggest
> that the same applies to xml. i have not discerned a broader notion of
> "one package now but a different one later" in xml either. the
> mechanisms for binding prefixes to namespaces differ from those used to
> associate package names with packages (cf my earlier questions about
> scope and extent), but, once parsed, the association between namespace
> and local part is treated in every spec i have seen as if it is
> immutable.
except that you've made it slow. you have something which immutably
of one identity, but can't easily be pointer-compared. (or else you've
reinvented symbol packages but don't expose them to the user in spite
of using a notation remarkably like them.)
> > ...
> > It's ALSO possible in XML, as nearly as I can tell, to do:
> >
> > <bleah>
> > <a:foo xmlns="x"> ...</a:foo>
> > <a:foo xmlns="y">...</a:foo></bleah>
> >
> > so that even if you have symbols Lisp would say ARE packaged, the
> > "meaning" of the package can change.
>
> the "'meaning' of the package does not change. the meaning of the
> prefix, that is the namespace's nickname, changes. the mechanism used to
> bind prefixes to namespaces is different than that which binds package
> names to packages.
obviously.
> the above is sugar for
>
> <bleah>
> <{x}foo > ... </{x}foo>
> <{y}foo > ... </{y}foo></bleah>
>
> which does not exhibit the objectionable behaviour. the prefix bindings
> for namespaces are lexically scoped. this pertains to the bindings, not
> to the namespaces themselves. the infoset goes a step further and
> specifies that the bindings have indefinite extent but deprecates their
> use. it is argued that one needs them for editors. it's a minor point
> and i've not yet seen anywhere where it would make a difference.
I don't know what indefinite extent would mean. Would it extend to the
adding of untagged expressions later? What "evaluation" is here baffles
me. Meaning and evaluation seem intertwined in a way they should not be.
> > Again, that can't happen in Lisp.
>
> agreed. 'cause package names in common lisp constitute a binding with
> indefinite scope, and they are used as if they were constants. ? how
> much of the "'meaning' of packages" changes when this is not true?
NO. because symbol's identities are inviolate. Packages in CL are normally
consulted ONLY at readtime (and for printing later, to provide for
re-readability). All operations on symbols ignore package (which incidentally
is something recognized as an object after that, too, not by name; you can
rename a package after the symbols are loaded and things will, if you've
writen stuff right, still work--I used to do this with Macsyma. I'd load
the system, rename the package, then load it again (usually a newer version),
so I could test the two against each other.) and ignore name. Those are
artifacts of typein. It is usually bad style to make do operations on a
symbol's name when the symbol is being used like it is in these examples
here. THere are symbolic processing examples which by their nature in the
real world require the use of the symbol and its name, but they are much
rarer.
> > Lisp takes the point that DATA exists and that programs are the contrivance
> > of man that serves data. ... In that model, data
> > is primitive. So even symbols that don't have semantics have semantics--they
> > have the semantics of "being the s ymbol that had no semantics". You can't
> > REALLY delay that.
>
> i agree. which is why i argue it is appropriate to model xml's universal
> names with symbols. not the qualified names, the universal names.
I don't think that's a good idea since the same symbol can have two different
meanings in different applications. I didn't get your indefinite extent
remark above, but if <a:foo> ... </a:foo> can mean two different things at
different times, then symbols are a bad representation. And if it CANNOT
mean different things at different times, then XML has hog-tied itself in a
way that will bring it down because an XML editor or Lisp image or whatever
will have to be restarted before a second file with <a:foo>...</a:foo> can
be loaded and played with, and the two will never be able to interact.
At that point, youmight as well just say they all have to be dns names
so they can never conflict.
> > Lisp and XML are only superficially similar. They disagree at a VERY deep
> > level.
>
> i am not yet convinced.
That's too bad.
> > You might learn something about the world by comparing their
> > differenes, but because they diverge so early in the tree of fundamental
> > assumptions, ...t
* james anderson wrote:
> is this a rhetorical "first-class", or is this notion of lisp
> "first-class-ness" distinct from bind/pass/return?
I think part of the notion of first-classness is that you can ask if
two objects are the same object by comparing their `addresses in
memory': only if they are the same address are they the same object.
In particular what you do *not* need to do some kind of thing like
(obviously this could not be written in CL for a lot of reasons and
it's only part of what the solution would be):
(defmethod eq ((o1 t) (o2 t))
(= (address o1) (address o2)))
(defmethod eq ((o1 symbol) (o2 symbol))
(and (string= (symbol-name o1)
(symbol-name o2))
(string= (symbol-package o1)
(symbol-package o2))))
...
If symbols were like that they would not be first-class.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* james anderson wrote:
>
>> is this a rhetorical "first-class", or is this notion of lisp
>> "first-class-ness" distinct from bind/pass/return?
>
>I think part of the notion of first-classness is that you can ask if
>two objects are the same object by comparing their `addresses in
>memory': only if they are the same address are they the same object.
>In particular what you do *not* need to do some kind of thing like
>(obviously this could not be written in CL for a lot of reasons and
>it's only part of what the solution would be):
>
> (defmethod eq ((o1 t) (o2 t))
> (= (address o1) (address o2)))
>
> (defmethod eq ((o1 symbol) (o2 symbol))
> (and (string= (symbol-name o1)
> (symbol-name o2))
> (string= (symbol-package o1)
> (symbol-package o2))))
>
> ...
>
>If symbols were like that they would not be first-class.
Furthermore, first-classness is based on an identity that doesn't change
over time. You can change the SYMBOL-PACKAGE of a symbol, but that doesn't
change what symbol it is.
The OP asked for some history of packages. Kent has gone into great deal
of detail about the philosophy of the package system that has evolved, but
here is an extremely brief (and probably incomplete) history of how they
came to be.
In Maclisp there were objects called "obarrays"; they were basically just
hash tables that mapped strings to symbols (Maclisp didn't have a
generally-accessible hash table mechanism like CL does). They were used
for many of the same things that packages are used for, but they were
pretty limited. There was no package prefix notation, so the reader always
used the current obarray. There was no inheritance among obarrays. I
think functions like INTERN took an optional obarray argument, much as CL's
versions of these functions take an optional package. Obarrays didn't have
names, they were passed around as first-class objects, and you made one the
current obarray by setting a global variable. They were an obscure feature
and pretty inconvenient to use, so they weren't used very much; the Lisp
compiler used them to ensure that symbols used by the program being
compiled didn't conflict with the symbols used in the compiler itself (and
then it had to play some games to bring the two worlds together when
processing (eval-when (compile) ...)).
Lisp Machine Lisp replaced the obarray stuff with named packages. It was
like the CL package system in many ways. The biggest difference was in the
inheritance system. Rather than allowing arbitrary inheritance (CL's
USE-PACKAGE function), LM Lisp's package system was hierarchical. There
was a tree of packages and subpackages; when searching for a symbol, it
would start in the current package and then search its superpackage, and so
on (similar to the way OO systems search for methods in the class
hierarchy). Package names were also interpreted relative to this
hierarchy, so you could have MACSYMA:INTEGRALS:RIEMANN and
MATHEMATICA:INTEGRALS:RIEMANN. There was no internal/external symbol
distinction, though.
Common Lisp took the LM Lisp package system and replaced the inheritance
hierarchy with a directed acyclic graph. The notion of external symbols
was introduced to support this -- when one package "uses" another, it only
inherits its exported symbols. And since packages were no longer organized
hierarchically, the hierarchy of package names was also dropped. Ideally
this should argue for a central registry of package names, to prevent
conflicts, but it apparently hasn't become a big problem.
Note that throughout its history, one thing has remained constant:
attributes and semantics are associated with symbols, not their names.
Symbols are first-class objects, obarrays and packages are merely ways of
looking them up. One thing that distinguishes Lisp from many other
languages is the existence of symbols as a real data type. In most
conventional languages, symbols are only used as identifiers in programs,
which only exist at compile time, so a module system that supports
different namespaces for different uses (variables vs. functions) makes
sense. Because symbols exist at run time in Lisp and the attributes hang
off the symbol itself, it would be difficult to support different
namespaces based on how the symbol is being used.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
* Barry Margolin wrote:
> Furthermore, first-classness is based on an identity that doesn't change
> over time. You can change the SYMBOL-PACKAGE of a symbol, but that doesn't
> change what symbol it is.
Yes, and in fact in some cases you can even change what kind of thing
it is - CHANGE-CLASS does this. This has always struck me as pushing
the limit of what I'm comfortable with first-class meaning, but I'm
not sure quite why.
--tim
* Barry Margolin wrote:
> In Maclisp there were objects called "obarrays"; they were basically just
> hash tables that mapped strings to symbols (Maclisp didn't have a
> generally-accessible hash table mechanism like CL does). They were used
> for many of the same things that packages are used for, but they were
> pretty limited. There was no package prefix notation, so the reader always
> used the current obarray. There was no inheritance among obarrays. I
> think functions like INTERN took an optional obarray argument, much as CL's
> versions of these functions take an optional package. Obarrays didn't have
> names, they were passed around as first-class objects, and you made one the
> current obarray by setting a global variable. They were an obscure feature
> and pretty inconvenient to use, so they weren't used very much; the Lisp
> compiler used them to ensure that symbols used by the program being
> compiled didn't conflict with the symbols used in the compiler itself (and
> then it had to play some games to bring the two worlds together when
> processing (eval-when (compile) ...)).
I think that emacs lisp is quite close to this - there is a thing
called an obarray (which is implementationally a vector, but obviously
being used as a hashtable secretly), and a global variable, obarray,
which is the obarray that is used by default. intern takes an
optional obarray argument so you can use them a bit like packages. I
suppose you could assign to obarray but I suspect the results would be
rapidly catastophic...
--tim
From: Sunil Mishra
Subject: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <3B44121A.5080807@notmyemail.com>
james anderson wrote:
> one may have observed notes from me related to xml.
>
> in that domain there are these things called "namespaces" which,
> depending on whom you ask, combine aspects of packages, modules, and
> environments. "names" (the identifiers for markup tags and for the
> attributes which can appear in tags) are "in" "namespaces". if one tries
> to get more precise than that, opinions diverge. it's not easy.
>
> i've at least glanced at the other lisp implementations for xml modules.
> one thing common to all is that, where they support namespaces, they
> model names as singletons - in some cases symbols, which are collected
> into named sets - in some cases packages.
>
> this runs contrary to implementations in other languages. it also, as
> matters would have it, runs contrary the semantics which one might be
> tempted to infer from many of the base xml standards. when these are
> read in isolation, they imply, for example, that - as restated for lisp,
> the form for a function definition should accept an explicit argument
> for the package name in addition to that for the function name. this
> even though no one ever states a use which would demand this degree of
> articulation. that is, no one has ever made a case for (setf
> (function-package ...) ...).
>
This section of your message is simutaneously intriguing, illuminating
and confusing. I have personally never understood the need for lisp
programmers to equate lisp symbols with anything but lisp symbols. In
particular, I think representing XML names as lisp symbols is a short
term convenience and a long term mistake.
As the two standards currently stand, the semantics of lisp symbols and
those of xml names are fairly close. Both of them are used for naming
things. But consider what can constitute an XML name and a lisp symbol.
XML names allow for unicode characters. Lisp symbols have, as far as I
know, not yet clarified their positions on these. On the other hand,
lisp symbols can start with characters that would be illegal in XML names.
For reasons I find entirely inexplicable, many programmers have decided
the similarities between lisp symbols and XML names is sufficient to
represent the latter using the former. Worse yet, some have decided to
extend this correspondence, to have lisp packages be equivalent to XML
namespaces. IMHO, there is great danger here. XML names may in the
future diverge in their semantics from lisp symbols. All the code that
has been written for processing XML data will suddenly find itself in a
difficult situation. The likelihood of such a divergence is much greater
for XML namespaces than for the names themselves, which makes the use of
packages for handling namespaces that much more dangerous a prospect.
Now, I ask you, why are you comparing XML names and lisp symbols? XML
conceptually has relatively little to do with lisp. The two are not only
different languages, they are intended for different purposes. The
former is intended as a data representation and exchange language, while
the latter is intended as a programming language. Then does it make
sense for programmers to believe their names to be aligned in their
semantics?
I'm genuinely curious to hear your reaction and that of others.
Regards,
Sunil
From: james anderson
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <3B44287D.3B805A1C@setf.de>
Sunil Mishra wrote:
>
> james anderson wrote:
>
> > ...
>
> This [elided] section of [my] message is simutaneously intriguing, illuminating
> and confusing. I have personally never understood the need for lisp
> programmers to equate lisp symbols with anything but lisp symbols. In
> particular, I think representing XML names as lisp symbols is a short
> term convenience and a long term mistake.
well, that is exactly what i'm trying to figure out.
>
> As the two standards currently stand, the semantics of lisp symbols and
> those of xml names are fairly close.
the question is, where do they diverge?
> Both of them are used for naming
> things. But consider what can constitute an XML name and a lisp symbol.
> XML names allow for unicode characters. Lisp symbols have, as far as I
> know, not yet clarified their positions on these.
hmm... i had read the lisp spec to say that a symbol may have any
character in its name. whereby, where the implementation supports
unicode characters, they would be legal constituents of symbol names.
> On the other hand,
> lisp symbols can start with characters that would be illegal in XML names.
which would make symbols a superset.
>
> For reasons I find entirely inexplicable, many programmers have decided
> the similarities between lisp symbols and XML names is sufficient to
> represent the latter using the former. Worse yet, some have decided to
> extend this correspondence, to have lisp packages be equivalent to XML
> namespaces. IMHO, there is great danger here.
i hope i have not left the impression that i am not concerned about this.
> XML names may in the
> future diverge in their semantics from lisp symbols. All the code that
> has been written for processing XML data will suddenly find itself in a
> difficult situation. The likelihood of such a divergence is much greater
> for XML namespaces than for the names themselves, which makes the use of
> packages for handling namespaces that much more dangerous a prospect.
that's why i'm posing the question. please note that i have posed the
same question "over there". often. ever since the spec on names was
endorsed two and a half years ago. this is the first response.
the question is, why is it dangerous? please elaborate. i have noted in
the foregoing messages the distinctions which i have been able to
discern from the multi-megabytes of specs issuing from the w3c. the
first is, that the name and the namespace - or as re-expressed in terms
of the to be deprecated implementation, the symbol name and the package,
are articulate properties of named objects and not themselves
encapsulated in one object. the second is, that there is no notion of
interning. i have, however, observed in those specs neither any
stipulation nor a description of any use case for which these aspects of
the abstract structure make a difference.
there is a third distinction, that namespaces conflate aspects of
packages, modules, and environments. i use that "conflate", rather than
"combine", since their exact nature depends on whom one asks. which i
take as more a sign of confusion than of intent. i suggest that, where
one distinguishes these aspects of namespaces, and models with symbols
and packages strictly those properties which are stipulated in the
namespaces recommendation, there is no danger of nonconformance.
>
> Now, I ask you, why are you comparing XML names and lisp symbols?
i have done it both ways. i've waited several years since the namespace
recommendation was endorsed to see how they would be used and observe that
first, the noted properties do not, so far as i can tell, figure in the
specified semantics. while i haven't gone to the extent of rewriting the
(rare) abstract semantics present in the respective w3c specs, reading
them to replace articulated names with with an abstract domain which
could be modeled directly with symbols has not revealed any cases where
the meaning would be changed.
second, because - to the extent that i comprehend both those specs and
the notion of referential transparency - xml names are referentially
transparent. that is the identity of a name depends exclusively on the
identity of the "name of its namespace" and on the identity of its
"local part". which is at least a close match to the notion of symbol identity.
> XML
> conceptually has relatively little to do with lisp. The two are not only
> different languages, they are intended for different purposes. The
> former is intended as a data representation and exchange language, while
> the latter is intended as a programming language. Then does it make
> sense for programmers to believe their names to be aligned in their
> semantics?
while not identical, certainly expressible.
the question is, how to use lisp objects to model xml documents? perhaps
_direct_ expression of processes which concern xml documents should not
be attempted in lisp. ok, so, what are the abstractions on top of lisp
which are necessary to express the domains inherent to xml.
wrt names, i've yet to discern a need to implement an abstraction other
than symbols. questions such as the following arise:
where one is parsing from and/or serializing to native objects, what is
the relation between the serialized name and the name of the class of
the object. how is this relation to be declared, modelled and managed. a
mechanism which relies on symbols is one possibility.
how does one associate functions/methods with documents and document
components? symbols are convenient terms to use to identify those
functions/methods. a mapping between symbols used to model elements'
generic identifiers and function identifiers is convenient. identity is,
of various mappings, the most convenient.
>
> I'm genuinely curious to hear your reaction and that of others.
>
please. i am as well.
...
From: Sunil Mishra
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <3B449E0D.4080304@notmyemail.com>
I had misread your post (late) last night, and had drawn the wrong
conclusions on your intent. My apologies.
james anderson wrote:
>
>>As the two standards currently stand, the semantics of lisp symbols and
>>those of xml names are fairly close.
>>
>
> the question is, where do they diverge?
Looking at this practically, lisp symbols and XML names as they are
currently defined can work interchangeably *in the absense of namespace
declarations*. I'll bring up namespaces again later.
Any XML name can be simply interened into, say, the CL-USER package as a
lisp symbol, and then document manipulation can proceed as the symbol is
in fact a full representation of the name.
>
> hmm... i had read the lisp spec to say that a symbol may have any
> character in its name. whereby, where the implementation supports
> unicode characters, they would be legal constituents of symbol names.
OK, my bad. Should have read a little more carefully :-)
>>For reasons I find entirely inexplicable, many programmers have decided
>>the similarities between lisp symbols and XML names is sufficient to
>>represent the latter using the former. Worse yet, some have decided to
>>extend this correspondence, to have lisp packages be equivalent to XML
>>namespaces. IMHO, there is great danger here.
>>
>
> i hope i have not left the impression that i am not concerned about this.
>
>
>> XML names may in the
>>future diverge in their semantics from lisp symbols. All the code that
>>has been written for processing XML data will suddenly find itself in a
>>difficult situation. The likelihood of such a divergence is much greater
>>for XML namespaces than for the names themselves, which makes the use of
>>packages for handling namespaces that much more dangerous a prospect.
>>
>
> that's why i'm posing the question. please note that i have posed the
> same question "over there". often. ever since the spec on names was
> endorsed two and a half years ago. this is the first response.
>
> the question is, why is it dangerous? please elaborate.
This would be counter to good engineering practice, IMHO. I consider it
dangerous in that sense. Consider a potential scenario where some
organization has been handling XML documents for a few years, collecting
a large database of them, and storing them as lisp structures. If the
standards are revised for either CL or XML in this state such that the
semantics of symbols and XML names diverge to make their equivalence
impractical, then the risk is that updating the lisp code to conform to
the new standards will create a legacy system situation that will take a
bit of work to overcome. I cannot judge how probable or improbable this
scenario is. But it is immediately avoidable, and not trying to do so is
an error on par with defining IP addresses to be 32 bit to save space.
But obviously your concerns are much deeper, and more interesting.
> i have noted in
> the foregoing messages the distinctions which i have been able to
> discern from the multi-megabytes of specs issuing from the w3c. the
> first is, that the name and the namespace - or as re-expressed in terms
> of the to be deprecated implementation, the symbol name and the package,
> are articulate properties of named objects and not themselves
> encapsulated in one object.
Are you saying that the underlying object in XML (which is not defined
in its form or content) can change its name? If not, then a very similar
meaning can be applied to lisp symbols as well. A lisp symbol does not
implicitly belong to a package. Witness uninterned symbols. The act of
interning a symbol does however make it accessible to the reader, giving
it a more permanent status. In XML the option to have an "uninterned"
name does not appear to exist. That is an important distinction, but
IMHO one that has more to do with namespaces than with the names
themselves. (Implicit here is the position that the namespace and the
name of the symbol can be separated and discussed meaningfully
independent of one another. I'm not sure if this is accurate, but I have
settled on that interpretation through experience with lisp. Perhaps it
is this interpretation that you are saying is incorrect?)
> the second is, that there is no notion of
> interning. i have, however, observed in those specs neither any
> stipulation nor a description of any use case for which these aspects of
> the abstract structure make a difference.
I am not surprised at the non-specificity of the specs on this matter.
XML is a new standard, and there are probably only a handful of people
out there doing things that are interesting from a semantics point of
view. It will probably get clarified when the XML user community does
run into any semantic difficulties.
I believe that all XML documentation should be read with an eye on SGML.
Your reading might for instance be interpreted in the context of DTD's
and document validation. While there is no explicit notion of interning,
the DTD does specify the structure of a document, implicitly imposing a
limit on the number of symbols for that kind of document. The limit on
the creation of names thus has a different source. While in lisp we
intern to create symbols, in the world of valid XML documents we write
DTD's to create them.
>
> there is a third distinction, that namespaces conflate aspects of
> packages, modules, and environments. i use that "conflate", rather than
> "combine", since their exact nature depends on whom one asks. which i
> take as more a sign of confusion than of intent. i suggest that, where
> one distinguishes these aspects of namespaces, and models with symbols
> and packages strictly those properties which are stipulated in the
> namespaces recommendation, there is no danger of nonconformance.
Namespaces and packages are sufficiently different that I would keep
them well apart. A package is an object in lisp that is used for
managing program code and data. It has a name, which can change, but
that is the primary means of accessing and talking about it. A namespace
is defined by a URI. The name of the namespace is irrelevant. Within a
single document two namespace qualifiers can refer to a single URI!
Doing so does not however change the "name" of the namespace, simply the
way in which we refer to it.
A package says nothing about symbol usage. While a namespace may have a
great deal to say. As I understand it, the URI must refer to a DTD or
XML schema definition that describes the document structure when names
of the given namespace are used. At least if one wants the documents
written using that namespace to be validatable.
Third, there are a number of means described by which packages may
exchange data among each other. With namespaces, no such exchange
mechanism is defined, as far as I know. A name in one namespace cannot
ever be equivalent to tha same name in a second namespace. With lisp
packages, one can export and import symbols, use packages in others, and
so on.
The needs that namespaces and packages satisfy are also substantially
different. Packages are for controlling collisions in code and data we
write in our lisp software. It is a means for partitioning different
programs, to allow them to coexist. This is where I get really fuzzy on
details. I am not clear on where the rules for mixing multiple
namespaces arise. I believe they come from a DTD or schema definition,
but I haven't looked into this aspect sufficiently. I have never had the
need to validate XML documents :-)
>>Now, I ask you, why are you comparing XML names and lisp symbols?
>>
>
> i have done it both ways. i've waited several years since the namespace
> recommendation was endorsed to see how they would be used and observe that
>
> first, the noted properties do not, so far as i can tell, figure in the
> specified semantics. while i haven't gone to the extent of rewriting the
> (rare) abstract semantics present in the respective w3c specs, reading
> them to replace articulated names with with an abstract domain which
> could be modeled directly with symbols has not revealed any cases where
> the meaning would be changed.
>
> second, because - to the extent that i comprehend both those specs and
> the notion of referential transparency - xml names are referentially
> transparent. that is the identity of a name depends exclusively on the
> identity of the "name of its namespace" and on the identity of its
> "local part". which is at least a close match to the notion of symbol identity.
>
>
>> XML
>>conceptually has relatively little to do with lisp. The two are not only
>>different languages, they are intended for different purposes. The
>>former is intended as a data representation and exchange language, while
>>the latter is intended as a programming language. Then does it make
>>sense for programmers to believe their names to be aligned in their
>>semantics?
>>
>
> while not identical, certainly expressible.
>
> the question is, how to use lisp objects to model xml documents? perhaps
> _direct_ expression of processes which concern xml documents should not
> be attempted in lisp. ok, so, what are the abstractions on top of lisp
> which are necessary to express the domains inherent to xml.
>
> wrt names, i've yet to discern a need to implement an abstraction other
> than symbols. questions such as the following arise:
>
> where one is parsing from and/or serializing to native objects, what is
> the relation between the serialized name and the name of the class of
> the object. how is this relation to be declared, modelled and managed. a
> mechanism which relies on symbols is one possibility.
[rest snipped]
My intuition runs counter to this. When one introduces namespaces, then
the semantics of XML names diverge more substantially from lisp symbols,
in ways that I have already listed above.
You might be conflating multiple problems here, I am not sure. The XML
document standard does not directly talk about serialization or any
such. It is an abstract representation mechanism, like s-expressions are
a printed representation of cons cells and other data structures. The
act of reading an XML document should produce an internal lisp
representation of the XML document, nothing more, nothing less. If the
document specifies a serialization, then it is correct to attempt a
transformation of the XML document into some other kind of lisp data
structure. I really don't see what the serialized name of the lisp
object has to do with XML names. Perhaps I'm again misreading your intent?
Sunil
From: Kent M Pitman
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <sfwsngbfdz9.fsf@world.std.com>
Sunil Mishra <·······@notmyemail.com> writes:
> Namespaces and packages are sufficiently different that I would keep
> them well apart. A package is an object in lisp that is used for
> managing program code and data. It has a name, which can change, but
> that is the primary means of accessing and talking about it. A namespace
> is defined by a URI.
(or in Scheme by a module system). But the essential point here bears
repeating--symbol namespaces and semantic modules are orthogonal concepts.
Neither precludes the other. Trying to force them to be the same is going
to buy only headache and risk leaving no one happy. Neither injures the
other.
> The name of the namespace is irrelevant. Within a
> single document two namespace qualifiers can refer to a single URI!
> Doing so does not however change the "name" of the namespace, simply the
> way in which we refer to it.
> A package says nothing about symbol usage. While a namespace may have a
> great deal to say. As I understand it, the URI must refer to a DTD or
> XML schema definition that describes the document structure when names
> of the given namespace are used. At least if one wants the documents
> written using that namespace to be validatable.
And, actually, this is a VERY weak meaning of "meaning".
I've had infinite headaches trying over and over to program any workable
meanig of XML namespaces that can co-reside with the myriad
HTML-psuedo-transitional-version-n-dot-m-with-meta-wingdings
namespaces that are almost identical but vary in subtle ways. The sharing
is nowhere captured, and the pain of figuring out that <html>...</html> in all
of these or the <p>...</p> in most of them means almost or maybe exaxctly
the same thing is EXCRUCIATING.
Mostly I just make an HTMLP predicate on namespaces and say
(if (and (htmlp (namespace tag))
(equal (name tag) "P"))
...)
and I *hate* that. But anything else that might be more semantically accurate
is impossibly complex to write without tons of meta-data that the standards
don't even bother to try to capture, since none acknowledges any of the
others.
> > wrt names, i've yet to discern a need to implement an abstraction other
> > than symbols. questions such as the following arise:
> >
> > where one is parsing from and/or serializing to native objects, what is
> > the relation between the serialized name and the name of the class of
> > the object. how is this relation to be declared, modelled and managed. a
> > mechanism which relies on symbols is one possibility.
this notion of "knowledge as a transient" is counter to the whole way lisp
has evolved. many lisp programs declare "facts" they will never use just
in case another program tries to link up. you speak in terms of information
compiling away, not building up. if this theory of yours were used to
create the world-wide-web, we'd have missed the notion of the URL because it
would have sufficed for everyone to just use the variable "my-page", there
being no others. additivity comes sometimes from the persistence of
information in usable form after a program is compiled and run. it is
from this experience and tradition that lisp is evolved.
> My intuition runs counter to this. When one introduces namespaces, then
> the semantics of XML names diverge more substantially from lisp symbols,
> in ways that I have already listed above.
>
> You might be conflating multiple problems here, I am not sure. The XML
> document standard does not directly talk about serialization or any
> such.
Nor to the interaction of serialized documents which try to attach
comparative meta-knowledge among data that were separately created and
processed. he speaks as if it were a private decision made in isolation, not
a decision made as part of a community of people sharing knowledge.
> It is an abstract representation mechanism, like s-expressions are
> a printed representation of cons cells and other data structures.
(and they are also a mechanism for sharing)
> The
> act of reading an XML document should produce an internal lisp
> representation of the XML document, nothing more, nothing less. If the
> document specifies a serialization, then it is correct to attempt a
> transformation of the XML document into some other kind of lisp data
> structure. I really don't see what the serialized name of the lisp
> object has to do with XML names. Perhaps I'm again misreading your intent?
I always assume when someone says "serialized" that they are implicitly
saying "it's none of your business how this is represented", and implicitly
as well "there is no need for this to be suitable for any other use than
to invert my storage paradigm". I don't think of a serialized mechanism
as an exchange format because I know of no language-independent repository
of how to interpret serialized forms. I can tell you the syntax of lisp
independent of its language semantics, and a program can do intersting
symbol processingon lisp without knowing what IF or SETQ or FLET means.
Not so of Java serialization that I can tell. I'd love to be corrected.
From: Sunil Mishra
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <3B456170.7000101@notmyemail.com>
Kent M Pitman wrote:
>>A package says nothing about symbol usage. While a namespace may have a
>>great deal to say. As I understand it, the URI must refer to a DTD or
>>XML schema definition that describes the document structure when names
>>of the given namespace are used. At least if one wants the documents
>>written using that namespace to be validatable.
>>
>
> And, actually, this is a VERY weak meaning of "meaning".
>
> I've had infinite headaches trying over and over to program any workable
> meanig of XML namespaces that can co-reside with the myriad
> HTML-psuedo-transitional-version-n-dot-m-with-meta-wingdings
> namespaces that are almost identical but vary in subtle ways. The sharing
> is nowhere captured, and the pain of figuring out that <html>...</html> in all
> of these or the <p>...</p> in most of them means almost or maybe exaxctly
> the same thing is EXCRUCIATING.
>
> Mostly I just make an HTMLP predicate on namespaces and say
> (if (and (htmlp (namespace tag))
> (equal (name tag) "P"))
> ...)
> and I *hate* that. But anything else that might be more semantically accurate
> is impossibly complex to write without tons of meta-data that the standards
> don't even bother to try to capture, since none acknowledges any of the
> others.
I think of this as the minimal definition of meaning that can be
attached and still get something working. The only charitable way I can
look upon these standards is that they are following strongly in the
"worse is better" vein. Things are invented as they are needed. I have a
feeling we might be paying for these standards rather heavily in short
order.
>>The
>>act of reading an XML document should produce an internal lisp
>>representation of the XML document, nothing more, nothing less. If the
>>document specifies a serialization, then it is correct to attempt a
>>transformation of the XML document into some other kind of lisp data
>>structure. I really don't see what the serialized name of the lisp
>>object has to do with XML names. Perhaps I'm again misreading your intent?
>>
>
> I always assume when someone says "serialized" that they are implicitly
> saying "it's none of your business how this is represented", and implicitly
> as well "there is no need for this to be suitable for any other use than
> to invert my storage paradigm". I don't think of a serialized mechanism
> as an exchange format because I know of no language-independent repository
> of how to interpret serialized forms. I can tell you the syntax of lisp
> independent of its language semantics, and a program can do intersting
> symbol processingon lisp without knowing what IF or SETQ or FLET means.
> Not so of Java serialization that I can tell. I'd love to be corrected.
>
I haven't explored java serialization sufficiently to be able to debate
the matter. But I am confused when you talk about serialization and
language independence. What do you mean by a language independent
repository for interpreting serialization forms? There are serialization
formats out there that attempt cross language serialization. SOAP, CORBA
and RPC come to mind. (I cannot vouch for their quality though. I don't
have enough experience in that regard.) At least in the case of SOAP one
can distinguish processing the XML structure of the document from the
processing required to turn it into data. That appears to have some of
the properties that lisp s-expressions have. Perhaps I'm missing the point?
Sunil
From: Kent M Pitman
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <sfwhewqaxnx.fsf@world.std.com>
Sunil Mishra <·······@notmyemail.com> writes:
> Kent M Pitman wrote:
>
> >>A package says nothing about symbol usage. While a namespace may have a
> >>great deal to say. As I understand it, the URI must refer to a DTD or
> >>XML schema definition that describes the document structure when names
> >>of the given namespace are used. At least if one wants the documents
> >>written using that namespace to be validatable.
> >>
> >
> > And, actually, this is a VERY weak meaning of "meaning".
> >
> > I've had infinite headaches trying over and over to program any workable
> > meanig of XML namespaces that can co-reside with the myriad
> > HTML-psuedo-transitional-version-n-dot-m-with-meta-wingdings
> > namespaces that are almost identical but vary in subtle ways. [...]
>
>
> I think of this as the minimal definition of meaning that can be
> attached and still get something working. The only charitable way I can
> look upon these standards is that they are following strongly in the
> "worse is better" vein. Things are invented as they are needed. I have a
> feeling we might be paying for these standards rather heavily in short
> order.
Maybe not so slow. The pain this induces to work with it might mean that
even things we think of as "simple uses" are a long way off. The hard
ones are presumably even farther off. ;-)
> >>The
> >>act of reading an XML document should produce an internal lisp
> >>representation of the XML document, nothing more, nothing less. If the
> >>document specifies a serialization, then it is correct to attempt a
> >>transformation of the XML document into some other kind of lisp data
> >>structure. I really don't see what the serialized name of the lisp
> >>object has to do with XML names. Perhaps I'm again misreading your intent?
> >>
> >
> > I always assume when someone says "serialized" that they are implicitly
> > saying "it's none of your business how this is represented", and implicitly
> > as well "there is no need for this to be suitable for any other use than
> > to invert my storage paradigm". I don't think of a serialized mechanism
> > as an exchange format because I know of no language-independent repository
> > of how to interpret serialized forms. I can tell you the syntax of lisp
> > independent of its language semantics, and a program can do intersting
> > symbol processingon lisp without knowing what IF or SETQ or FLET means.
> > Not so of Java serialization that I can tell. I'd love to be corrected.
> >
>
> I haven't explored java serialization sufficiently to be able to debate
> the matter. But I am confused when you talk about serialization and
> language independence. What do you mean by a language independent
> repository for interpreting serialization forms? There are serialization
> formats out there that attempt cross language serialization. SOAP, CORBA
> and RPC come to mind. (I cannot vouch for their quality though. I don't
> have enough experience in that regard.) At least in the case of SOAP one
> can distinguish processing the XML structure of the document from the
> processing required to turn it into data. That appears to have some of
> the properties that lisp s-expressions have. Perhaps I'm missing the point?
Well, I probably wasn't that clear, but I was thinking Java serialization
when I said it. Even so...
I haven't looked at SOAP except to understand that it's an enveloping
protocol. I didn't know it had a marshalling protocol. I'll look further.
This is the only one of the three that I imagine even might.
As to CORBA, it's funny but I never thought of that as cross-language because
it still requires CORBA (a programming system) on either end; I hadn't thought
of extracting the marshalling part separately and using it absent CORBA, but
offhand I'd have assumed the data is somehow tied up in its communication
protocol, and not easily gettable from "outside", by which again I had meant
more than "people in a clique" but rather "anyone in any situation who merely
has "stored data" and "a spec on how the data is stored". Does CORBA offer
that?
Ditto RPC, for that matter.
XML's job in life is to be an externalization format. To pack it into
something else seems to be what misses the point.
From: Kent M Pitman
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <sfw8zi2auut.fsf@world.std.com>
Kent M Pitman <······@world.std.com> writes:
> Sunil Mishra <·······@notmyemail.com> writes:
>
> > I have a
> > feeling we might be paying for these standards rather heavily in short
> > order.
>
> Maybe not so slow.
Er, I meant "Maybe not such short order".
> The pain this induces to work with it might mean that
> even things we think of as "simple uses" are a long way off. The hard
> ones are presumably even farther off. ;-)
From: Per Bothner
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <m2zoaf8bj4.fsf@kelso.bothner.com>
Kent M Pitman <······@world.std.com> writes:
> I don't think that's a good idea since the same symbol can have two different
> meanings in different applications. I didn't get your indefinite extent
> remark above, but if <a:foo> ... </a:foo> can mean two different things at
> different times, then symbols are a bad representation.
Does not follow. <a:foo> ... </a:foo> can mean different things at
different times which means that we need to use symbols whose
meanings does not change.
Consider an XSLT (XML style/tranformation language) "program",
which may contain things like:
<xsl:template name="x">...</xsl:template>
The "xsl:" is just a conventonal abbreviation. The actual "true"
name of the namespace is "http://www.w3.org/1999/XSL/Transform".
So you represent xsl:template as a symbol "template" in the
package whose name is "http://www.w3.org/1999/XSL/Transform".
This of course is tedious, so you can define "xsl" as a nickname
for "http://www.w3.org/1999/XSL/Transform". But the latter is the
true unchanging name. The "xsl" alias is defined is the "lexical"
scope while parsing an xml file. I.e. while parsing an xml file
you need to maintain a stack of current aliases. You could use
package nicknames for this.
--
--Per Bothner
···@bothner.com http://www.bothner.com/per/
From: Kent M Pitman
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <sfwg0c7yro0.fsf@world.std.com>
Per Bothner <···@bothner.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > I don't think that's a good idea since the same symbol can have two different
> > meanings in different applications. I didn't get your indefinite extent
> > remark above, but if <a:foo> ... </a:foo> can mean two different things at
> > different times, then symbols are a bad representation.
>
> Does not follow. <a:foo> ... </a:foo> can mean different things at
> different times which means that we need to use symbols whose
> meanings does not change.
>
> Consider an XSLT (XML style/tranformation language) "program",
> which may contain things like:
>
> <xsl:template name="x">...</xsl:template>
>
> The "xsl:" is just a conventonal abbreviation. The actual "true"
> name of the namespace is "http://www.w3.org/1999/XSL/Transform".
> So you represent xsl:template as a symbol "template" in the
> package whose name is "http://www.w3.org/1999/XSL/Transform".
I didn't overlook this as an option.
I've tried this as well, and had troubles with it.
I'll try to see if I can dig into why this doesn't work.
One of the reasons might be that you end up with some objects for
which you dno't know the package, and so you can't resolve this.
You still need to be able to create objects which will be what Lisp
think is "identity-distinct" from those things, but which XML will
not treat as distinct because XML thinks you can lazily assign this
later. Such would cause two extant first-class objects in Lisp to
merge / become unified. That's not a valid operation. And as such,
the appropriate representation is not the one you suggest.
Further, the sharing issues I mentioned before make this a very
tedious way to recover HTML equivalence. You almost need yet a third
level of indirection to a feigned "meaning-object" which can make some
pseudo-attempt at sharing meaning even when urls don't.
It also begs the question of whether namespace urls will always contain
the same data. If editing of any of their contents ever occurs,
an identity disaster will happen.
> This of course is tedious, so you can define "xsl" as a nickname
> for "http://www.w3.org/1999/XSL/Transform". But the latter is the
> true unchanging name. The "xsl" alias is defined is the "lexical"
> scope while parsing an xml file. I.e. while parsing an xml file
> you need to maintain a stack of current aliases. You could use
> package nicknames for this.
This part is simple bookkeeping and is not at all the problem.
You can also maintain a registry from URL to integer index and just
use #S(xml-tag :namespace-index 17 :name "fred") as the representation
which can be compared pretty quickly. But this still won't help you
when you come up against
(setq tag1 #S(xml-tag :namespace-index 17 :name "fred"))
(setq tag2 #S(xml-tag :namespace-index nil :name "fred")
(tag-equal tag1 tag2)
which is sometimes true and sometimes not, and which certainly cannot
depend on lisp object identity to sort it out.
Further, if you really "intern" these, you lose "intentional" information
about what alias was used in the presence of several possible equivalent
aliases when nesting occurs and there may be a preferred alias, so
re-printing the information can lose information.
From: Per Bothner
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <m2n16ddip6.fsf@kelso.bothner.com>
Kent M Pitman <······@world.std.com> writes:
> It also begs the question of whether namespace urls will always contain
> the same data. If editing of any of their contents ever occurs,
> an identity disaster will happen.
Ah. This may be the source of some of the confusion. Namespace URIs
do not "contain" data. They are merely globally-unique names. There
is no requirement that they actually be valid URLs that refer to real
data. The meaning of a namespace is just its URI, not any data that
the name might refer to.
The following definitions from the namespace specification
(http://www.w3.org/TR/1999/REC-xml-names-19990114/) may help:
[Definition:] URI references which identify namespaces are
considered identical when they are exactly the same
character-for-character. Note that URI references which are not
identical in this sense may in fact be functionally
equivalent. Examples include URI references which differ only in
case, or which are in external entities which have different
effective base URIs.
[Definition:] The attribute's value, a URI reference, is the
namespace name identifying the namespace. The namespace name, to
serve its intended purpose, should have the characteristics of
uniqueness and persistence. It is not a goal that it be directly
usable for retrieval of a schema (if any exists). An example of a
syntax that is designed with these goals in mind is that for
Uniform Resource Names [RFC2141]. However, it should be noted that
ordinary URLs can be managed in such a way as to achieve these
same goals.
> One of the reasons might be that you end up with some objects for
> which you dno't know the package, and so you can't resolve this.
> You still need to be able to create objects which will be what Lisp
> think is "identity-distinct" from those things, but which XML will
> not treat as distinct because XML thinks you can lazily assign this
> later. Such would cause two extant first-class objects in Lisp to
> merge / become unified. That's not a valid operation. And as such,
> the appropriate representation is not the one you suggest.
In XML, the namespace URI and the "local part" (the part after the
colon) are immutable and non-context-dependent aspects of a qualified
name, and identity is defined in terms of those aspects. However, the
"prefix" (the part before the colon) *is* context-dependent, and it
is *not* part of the semantics of a quantified name or its "identity";
it is merely part of the read/print syntax, for convenience.
Thus mapping an XML qualified *and namespace-resolved* name maps
quite well to a CL symbol, as long as you use the namespace URI as
the package name. That gives you "identity-distinct" representations
that matches the XML semantics - though perhaps not the XML surface
syntax! There is no need to merge/unify objects, and there is never a
need to change the home package of a symbol (for XML's sake).
> Further, if you really "intern" these, you lose "intentional" information
> about what alias was used in the presence of several possible equivalent
> aliases when nesting occurs and there may be a preferred alias, so
> re-printing the information can lose information.
Part of the "XML dataset" include "namespace nodes". Each XML document
must contain definitions for all of its namespoaces. An internal
representation (such as a Document Object Module or DOM) needs to
maintain the "namespace nodes" and use those to print-out namespace-correct
XML. Yes, you can lose information if there are multiple namespace
prefixes in scope that map to the same namespace URI. An application
does of course have the option of storing the local prefix (as written
in the XML source) as well as the namespace URI; the standard DOM API
(as revised for namespaces) does this. So for Lisp, you might have
a "element" class, whose fields are "qualified-name" (a symbol interned
in the package named by a namespace URI), a "tag-name" (a string or
symbol giving the name as written in the XML source), plus fields for
children, attributes - and namespace nodes (used to name the mapping
from local prefix to namespace URI).
--
--Per Bothner
···@bothner.com http://www.bothner.com/per/
From: james anderson
Subject: Re: XML names and lisp symbols (was Re: package system history)
Date:
Message-ID: <3B4A1230.E6B2A2E7@setf.de>
Kent M Pitman wrote:
>
> Per Bothner <···@bothner.com> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > ...
> >
> > The "xsl:" is just a conventonal abbreviation. The actual "true"
> > name of the namespace is "http://www.w3.org/1999/XSL/Transform".
> > So you represent xsl:template as a symbol "template" in the
> > package whose name is "http://www.w3.org/1999/XSL/Transform".
>
> I didn't overlook this as an option.
> I've tried this as well, and had troubles with it.
> I'll try to see if I can dig into why this doesn't work.
>
> One of the reasons might be that you end up with some objects for
> which you [don't] know the package, and so you can't resolve this.
when does this happen?
> You still need to be able to create objects which will be what Lisp
> think is "identity-distinct" from those things, but which XML will
> not treat as distinct because XML thinks you can lazily assign this
> later.
when does this happen?
> Such would cause two extant first-class objects in Lisp to
> merge / become unified. That's not a valid operation. And as such,
> the appropriate representation is not the one you suggest.
>
> Further, the sharing issues I mentioned before make this a very
> tedious way to recover HTML equivalence. You almost need yet a third
> level of indirection to a feigned "meaning-object" which can make some
> pseudo-attempt at sharing meaning even when urls don't.
>
> It also begs the question of whether namespace urls will always contain
> the same data. If editing of any of their contents ever occurs,
> an identity disaster will happen.
i suspect this passage is a reference to the schema which one is
permitted to associate with an url. if i understand the term "HTML
equivalence", it has to do with the same thing.
if we are referring to the same thing, one case where the problem does
arise is that of multiple document definitions for which analogous - but
not identical - types are associated with names from the same namespace.
XHTML1.0 is such a case. an early proposal suggested that a distinct
namespace be used for each formulation of the document definitions.[1]
that ultimately lost out and a single namespace is specified instead.[2]
[1] http://www.xml.com/pub/a/1999/11/p3p/xhtmlindex.html?wwwrrr_19991103.txt
[2] http://www.w3.org/TR/2000/REC-xhtml1-20000126
there are two isssues. first, to the extent that the interpretation is
local to the respective document, the situation is no different that
local type declarations on lexical bindings within blocks. the "meaning"
associated with a given symbol may change based on context. where, on
the other hand, a global "meaning" is required - case keys in static
functions, global class names, ..., then the namespace name is -
contrary to rec-names, not sufficient to identify the universal name. a
second property is required. in this specific case, it is the public
identifier on the DTD, which indicates which document definition - and
thus for purposes of type assigment and defaults, which meaning is to be
associated with the names.
>
> > This of course is tedious, so you can define "xsl" as a nickname
> > for "http://www.w3.org/1999/XSL/Transform". But the latter is the
> > true unchanging name. The "xsl" alias is defined is the "lexical"
> > scope while parsing an xml file. I.e. while parsing an xml file
> > you need to maintain a stack of current aliases. You could use
> > package nicknames for this.
>
package nicknames are not appropriate for this, since the possibility of
homographic qualified names runs counter to the indefinite scope
effective for package nicknames.
> This part is simple bookkeeping and is not at all the problem.
> You can also maintain a registry from URL to integer index and just
> use #S(xml-tag :namespace-index 17 :name "fred") as the representation
> which can be compared pretty quickly. But this still won't help you
> when you come up against
> (setq tag1 #S(xml-tag :namespace-index 17 :name "fred"))
> (setq tag2 #S(xml-tag :namespace-index nil :name "fred")
> (tag-equal tag1 tag2)
> which is sometimes true and sometimes not,
what are the circumstances which distinguish "sometimes true and
sometimes not"? can they be inferred from the text of the original
document? do they arise as a consequence of operations on a document model?
> and which certainly cannot
> depend on lisp object identity to sort it out.
>
> Further, if you really "intern" these, you lose "intentional" information
> about what alias was used in the presence of several possible equivalent
> aliases when nesting occurs and there may be a preferred alias, so
> re-printing the information can lose information.
it just means that, if it important to reproduce the original text, you
need to drag the alias along as baggage. that's what the infomodel does.
for the cases where the original prefix would suffice, a canonical
namespace prefix will serve as well, so there's not really a benefit to
preserving the binding. for the cases where the canonical prefix doesn't
suffice - where prefixes would produce a non-conformant document, one
needs to generate a new prefix anyway, which leads to the same
conclusion wrt the original prefix.
...