> How about introducing a second part to the api? (store) creates a
> wrapper for the persistent address, and refp then takes one of those
> wrappers and the name?
I like that. I would go one step further and say refp should have a
default data store that is used unless you specify anything else via
'store' or additional arguments to refp. This would go partway
towards making "persistence like garbage collection".
The reason I suggested persisting entire nampespaces was that
sometimes (often) the need to persist data is outside of any usage of
refs (or atoms, or agents). Maybe such a high-level facility could be
built on top of refp.
Another thing I'd like to see (as I mentioned) is an extension of map
syntax for the kinds of (e.g. SQLish or XMLish) data structures you
get out of persistent stores. One of the brilliant things about
Clojure is its unification of multiple sequence types. It was
something that was crying out to be done. I think that, similarly,
there could be a more unified and standard way of dealing with maps,
maps-of-maps, maps containing lists, etc.
There is already a nice shorthand syntax for maps: to get a key's
value out of a map, you pass it the key:
({:a 1 :b 2} :a) -> 1
How about extending this system to selection among sets of maps (i.e.
relational data), by passing a key-value pair:
(#{{:a 1 :b 2}
{:a 3 :c 4}} {:a 3}) ->
{:a 3 :c 4}
Which could then be further processed by just passing a key or set of
keys to "project":
(... :a) -> 3
Now consider nested maps with lists, which might come from XML or some
other kind of hierarchical data (note this is not what you would get
from read-xml; I'm trying to imagine a "native" structure that doesn't
refer to external concepts such as attributes, content, etc.):
{:catalog [{{:node :book :isbn 100}
{:author :Shakespeare :genre :play}}
{{:node :book :isbn 101}
{:author :Shakespeare :genre :sonnet}}
{{:node :book :isbn 102}
{:author :Knuth :genre :textbook}}]}
You might pass this a sequence of terms "above" a given node to
identify it:
(data [:book :author :Shakespeare :sonnet])
Which yields the entire hierarchy above any identified nodes:
-> {:catalog [{{:node :book :isbn 100}
{:author :Shakespeare :genre :sonnet}}]}
This can then be further processed by "projecting" the node level you
want to look at:
(... [:catalog :node :book]) -> {{:node :book :isbn 100}
{:author :Shakespeare :genre :sonnet}}
(... [:catalog {:node :book} :author]) -> :Shakespeare
You could be as imprecise as you like in doing these "queries"----all
the way from sets of unordered terms (using set notation) to specific
key-value pairs (e.g. in the last example). The idea is to make the
best of your (sometimes partial) knowledge.
. This is a \very rough idea, and it completely ignores some edge
cases, but the basic point is that I am trying to query "relational"
data and hierarchical data in the same way. A further way of
"unifying" external data sources is to converge on a standard way of
dealing with relational or hierarchical data, and meanwhile allowing
the same methods of querying to be used on different representations.
For instance, maps themselves can be represented as maps, as a list of
alternating key-value pairs, a vector of two-place vectors, or a list
of keys and a list of values. We should be able to query all these
things in the same way, and there should be utility functions to
convert between them (I always end up writing my own).
In the case of relational data, different programs pick different
representations. There is Clojure's native way, which is sets of
maps. Incanter has a two item-map with :column-names and :rows.
ClojureQL does something else again. When I have relational-like data
in my own programs, I tend to pick one column as the "key", and map it
to subsidiary data, e.g.:
{:screw {:price 0.1 :supplier :Acme}
:bolt {:price 0.2 :supplier :Nuts}}
It should be possible to query any reasonable representation in the
same way, and writers of libraries meanwhile should try to converge on
a single way of representing these things (why not Clojure's?).
--
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
Note that posts from new members are moderated - please be patient with your
first post.
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
