On Dec 12, 4:34 am, "evins.mi...@gmail.com" <evins.mi...@gmail.com>
wrote:
> On Dec 11, 9:08 pm, Chouser <chou...@gmail.com> wrote:
>
>
>
> > On Thu, Dec 11, 2008 at 7:49 PM, Robert Koberg <r...@koberg.com> wrote:
>
> > > Hi,
>
> > > Would it be desirable to further define keywords such that it allows a
> > > special kind of namespacing.
>
> > > * This could allow for more efficient (for the user) and targeted
> > > navigation over large, nested collections.
> > > * It would allow for mixing related data that might need to be treated
> > > in different ways.
> > > * It could provide the building blocks for a collection transformation
> > > language
>
> > > For example:
>
> > > :keyword or :nil:keyword - defines a keyword in a null namespace
> > > -- keeps backward compatibility
> > > -- equivalent to the XML element <foo/> (no namepsace defined)
>
> > > ::keyword - defines a namespaced keyword in a default namespace
> > > -- equivalent to the XML element <foo xmlns="http://some/namespace"/>
>
> > > :myns:keyword - defines a namespaced keyword in a named namespace
> > > -- equivalent to the XML element <foo xmlns:myns="http://some/namespace
> > > "/>
>
> > > Perhaps a requirement for this type of thing would be that the
> > > namespaces need to be declared on the root element of the (nested)
> > > collection.
>
> > Keywords can already be namespace-qualified:
>
> > user=> (namespace :foo)
> > nil
> > user=> (namespace :my-ns/foo)
> > "my-ns"
> > user=> (namespace ::foo)
> > "user"
>
> > The idea of using this feature to specify XML namespaces has been
> > discussed. Rich even adjusted the reader rules to allow fully-qualified
> > URLs as namespaces:
>
> > user=> (namespace :http://n01se.net/chouser/tag)
> > "http://n01se.net/chouser";
>
> > This should allow something to parse XML and produce a tree of Clojure
> > collections representing it with full namespace qualifications, though to my
> > knowledge this hasn't been done yet.
>
> It would be a convenience for some of my work if it were legal to do
> (derive :foo :bar) using unqualified keywords. I don't know enough yet
> about Clojure to know what that might break. In Common Lisp, the text
> ":FOO" is guaranteed always to be turned into a reference to the exact
> same keyword object, a symbol in the KEYWORD package whose name is
> "FOO"; I don't know what the rules are in Clojure about keywords
> without namespaces. Perhaps they're like uninterned symbols; I don't
> know.
>
> I'm building a type system for classifying lots of hunks of data and
> selecting appropriate operations for them, and derive is nice for
> that, but it's a minor inconvenience to have to namespace-qualify all
> those typenames. It's nice that I *can* qualify them by namespace; it
> isn't always nice that I *have* to.
>
> That said, it doesn't prevent me from getting anything done, it's just
> a sort of pebble in my shoe sometimes.
Keywords have interned identity semantics, that is, :foo anywhere is
the identical object, and :my-ns/foo is a different object.
The problem with your (derive :foo :bar) is that it is incompatible
with my (derive :bar :foo). Since such derives constitute a global
hierarchy, that is prohibited.
There are a few things that can mitigate somewhat:
1) ::foo will give you a keyword qualified with the current namespace:
user=> ::foo
:user/foo
2) namespace qualifiers in keywords can be namespace aliases - :alias/
foo
3) a recent patch lets you define relationships between names without
qualifiers in private hierarchies
(derive my-hierarchy :foo :bar)
I'm thinking about a multimethod enhancement that will let you specify
the hierarchy to be used.
4) You can use symbols instead of keywords and get require/use
capability.
Rich
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
