Re: Associative extends Seqable?
On Sat, 2013-01-19 at 14:56 -0800, Ben Wolfson wrote:
> > Such sets couldn't support forward domain transformation, though,
> > because membership testing could then fail to terminate.
>
> Given the definition of seq you suggested above, membership testing
> for a transformed map will also be in danger of not terminating.
> That's the only reason it's not observably incorrect.
Domain transformation need not be implemented with enumeration, as in
the case of vacuous domains, as it is not permitted for the transform to
do something like exclude keys that were present in the old domain.
> But fine---again, it's not clear to me why this makes the sets deficient.
You can test for membership of infinite sets like the even integers very
quickly. Once an arbitrary injection is applied, though, it is more
troublesome.
> > The only way you can apply both transformations is if your
> > domain is vacuous: that is, constant functions like yours are
> > the only ones that permit domain transform in either direction.
>
> [given, I assume, the proviso that the transformed result must be
> capable of further forward transformation?]
Of course. :)
> >> But in the end my more fundamental question is: what makes it the case
> >> that associatives can transform their domains forward? AFAICT the
> >> answer is "the enumerability of associatives".
> >
> > My previous email argued that the former implied the latter, rather than
> > vice versa. Forward domain transformation via injection seems more
> > fundamental than enumerability, to me.
>
> But there's a case where forward domain transformation is possible
> without (correct) enumeration being possible (you don't, contrary to
> what you said, need to produce the entire search space), which ought
> to scotch that direction of implication.
That's fair. The slightly stronger claim of Associative, then, is
useful for its exclusion of constant functions.
> > Because that definition of associative, "associating elements of a
> > domain with elements of a codomain", is entirely characterized by the
> > codomain of the associative -> function isomorphism.
Apologies, I should have said "monomorphism"; indeed, there are no
isomorphisms given the definitions I'm using :]
> > Such functions support containsKey, entryAt, assoc, and both
> > valAts.
>
> And without, too. Except that actually they don't support any of them:
>
> user=> (.containsKey even? 2)
> java.lang.IllegalArgumentException: No matching method found:
> containsKey for class clojure.core$even_QMARK_ (NO_SOURCE_FILE:0)
> user=> (get even? 2)
> nil
Yes; Clojure can't discriminate this kind of function, so implementing
even that subset of Associative I mentioned couldn't be done safely. We
can write them, though, applying the needed constraints ourselves if you
wish safety.
;; A total function whose codomain represents both boundedness and the
;; values of some other function.
(def-alias Kma (TFn [[x :variance :contravariant]
[y :variance :covariant]]
(Fn [x -> (Option (Vector* y))])))
(ann associative->kma
(All [a b] (Fn [(IPersistentMap a b) -> (Kma a b)])))
(defn associative->kma
"This is *the* associative -> function monomorphism, because it is
isomorphic to all other associative -> function monomorphisms."
[m]
(fn [k] (if-let [[_ v] (find m k)]
[v])))
(ann entry-at
(All [a b] (Fn [(Kma a b) a -> (Option (Vector* a b))])))
(defn entry-at
"As with entryAt."
[kma k]
(if-let [[v] (kma k)]
[k v]))
(ann val-at
(All [a b] (Fn [(Kma a b) a -> (Option b)]
[(Kma a b) a b -> b])))
(defn val-at
"As with valAt."
([kma k] (first (kma k)))
([kma k o] (if-let [[v] (kma k)]
v
o)))
(ann assoc'
(All [a b] (Fn [(Kma a b) a b -> (Kma a b)])))
(defn assoc'
"Preserves the earlier law suggested for assoc."
[kma k v]
(fn [k'] (if (= k k') [v] (kma k'
(ann contains?'
(All [a b] (Fn [(Kma a b) a -> Boolean])))
(defn contains?'
[kma k]
(if (kma k) true false)) ;yeah I know
> I suspect the implementation of assoc gains by not being e.g. (fn [m k
> v] #(if (= % k) v (m %))), not to mention the implementation of the
> maps themselves.
Agreed. However, a general assoc could detect when you are using a
specialized representation of function, preserving compatibility with
something like Kma.
> In very few cases, I think, has anyone thought "should I use a function
> or a map? Well, I need forward domain transformation, so, a map."
I imagine it goes on indirectly, that is to say "well, I need [some
implication of forward domain transformation], so, a map."
> * though one could imagine a reader macro to do the relevant transformation.
Aye, what is {}, after all?
> I don't really care about the name. If there were an interface
> IDomainToCodomain, I wouldn't complain that Associative extends
> IPersistentCo
Re: Associative extends Seqable?
On Sat, Jan 19, 2013 at 1:26 PM, Stephen Compall
wrote:
> What do you return for count, though?
I don't currently implement count.
>> There are other ways to make trouble anyway: it's perfectly possible
>> to define infinite sets that support conjoining, disjoining, union,
>> intersection, difference, etc., whether in forms that also support
>> seq-ing, e.g. sets of multiples of a given integer, or not (or not
>> obviously to me), in terms of an arbitrary characteristic
>> function---these not necessarily being infinite, I suppose.
>
> Such sets couldn't support forward domain transformation, though,
> because membership testing could then fail to terminate.
Given the definition of seq you suggested above, membership testing
for a transformed map will also be in danger of not terminating.
That's the only reason it's not observably incorrect.
But fine---again, it's not clear to me why this makes the sets deficient.
> But you couldn't transform that result's domain with a newdomain ->
> newhotnessdomain; it would thus no longer be an associative under the
> qualification I'm positing.
[...]
>
> Yes; this is the case I described as follows:
>
> The only way you can apply both transformations is if your
> domain is vacuous: that is, constant functions like yours are
> the only ones that permit domain transform in either direction.
[given, I assume, the proviso that the transformed result must be
capable of further forward transformation?]
>> But in the end my more fundamental question is: what makes it the case
>> that associatives can transform their domains forward? AFAICT the
>> answer is "the enumerability of associatives".
>
> My previous email argued that the former implied the latter, rather than
> vice versa. Forward domain transformation via injection seems more
> fundamental than enumerability, to me.
But there's a case where forward domain transformation is possible
without (correct) enumeration being possible (you don't, contrary to
what you said, need to produce the entire search space), which ought
to scotch that direction of implication.
>> So, in fact, it has not helped me to look at the relation between
>> enumerability and forward domain transformability, because I no more
>> see why the latter is something that belongs with associating elements
>> of a domain with elements of a codomain than I do the former.
>
> Because that definition of associative, "associating elements of a
> domain with elements of a codomain", is entirely characterized by the
> codomain of the associative -> function isomorphism. Such functions
> support containsKey, entryAt, assoc, and both valAts.
And without, too. Except that actually they don't support any of them:
user=> (.containsKey even? 2)
java.lang.IllegalArgumentException: No matching method found:
containsKey for class clojure.core$even_QMARK_ (NO_SOURCE_FILE:0)
user=> (get even? 2)
nil
And, as Clojure now stands, such functions *can't* honestly support
those operations, because supporting them would require also
supporting seq and count. They can support valAt through ILookUp, but
there are no corresponding independent interfaces for containsKey,
entryAt (both of which you might expect to be in ILookUp), or assoc.
Or without.
In practice, there are lots of reasons to use these not-a-functions
other than extra operations and guarantees. I would not like to have
to write the map {2 :x -2 :y} as #(case % 2 :x -2 :y ::not-found)* and
I suspect the implementation of assoc gains by not being e.g. (fn [m k
v] #(if (= % k) v (m %))), not to mention the implementation of the
maps themselves. In very few cases, I think, has anyone thought
"should I use a function or a map? Well, I need forward domain
transformation, so, a map." In the particular case that eventually
prompted my discovery of the inheritance relation mentioned in the
subject of this thread, neither enumeration nor forward domain
transformation was relevant, just assoc and valAt.
* though one could imagine a reader macro to do the relevant transformation.
Now, I would like to use, alongside the full-fledged not-a-functions
that have the various extra operations and guarantees, some
basically-just-a-functions, with the same interface---since the only
operations I'll actually use can be supported by both. But the only
interface that provides get, assoc, and dissoc makes *further*
guarantees.
I don't really care about the name. If there were an interface
IDomainToCodomain, I wouldn't complain that Associative extends
IPersistentCollection and Seqable. (In fact, in that case, Associative
could consist entirely in extending IDomainToCodomain and
IPersistentCollection. (Optimally---from my perspective---there would
additionally be some interface for dissociable things apart from
everything IPersistentMap brings with it.) If that separation were
effected, then the decision whether to use a function or a
not-a-function could be made on the basis of the strength of t
Re: Associative extends Seqable?
On Sat, 2013-01-19 at 11:39 -0800, Ben Wolfson wrote: > You couldn't observe the breakage, but it would still the case that > for many elements of the domain no finite subsequence of the seq > contains those elements. Indeed, it would merely be observably correct, not actually correct. What do you return for count, though? > There are other ways to make trouble anyway: it's perfectly possible > to define infinite sets that support conjoining, disjoining, union, > intersection, difference, etc., whether in forms that also support > seq-ing, e.g. sets of multiples of a given integer, or not (or not > obviously to me), in terms of an arbitrary characteristic > function---these not necessarily being infinite, I suppose. Such sets couldn't support forward domain transformation, though, because membership testing could then fail to terminate. > I don't really understand this. Surely you can, in fact, transform the > domain of an associative the same way you transform the domain of a > function? You could support the associative interface via a function > from newdomain -> olddomain + the old associative. But you couldn't transform that result's domain with a newdomain -> newhotnessdomain; it would thus no longer be an associative under the qualification I'm positing. It would be no different from converting to a function, with a peculiarly shaped codomain that modeled domain membership testing, then transforming the domain in the usual way for functions. > (And if you can go function -> associative But you can't. > If the domain transformation function is injective and the associative > maps everything to the same value, then transforming the domain > forward is a no-op: there can't be something in the new domain that > wasn't in the old domain at all, since everything was in the old > domain. All we could do is shuffle elements in the domain around with > respect to what they're associated with. But they're all associated > with the same thing. You don't need to enumerate anything in this > case. Yes; this is the case I described as follows: The only way you can apply both transformations is if your domain is vacuous: that is, constant functions like yours are the only ones that permit domain transform in either direction. > If the domain transformation function is not injective, then I get > very nervous about transforming the domain at all. I would absolutely agree that only injective forward domain transformations are well-defined. > But in the end my more fundamental question is: what makes it the case > that associatives can transform their domains forward? AFAICT the > answer is "the enumerability of associatives". My previous email argued that the former implied the latter, rather than vice versa. Forward domain transformation via injection seems more fundamental than enumerability, to me. > So, in fact, it has not helped me to look at the relation between > enumerability and forward domain transformability, because I no more > see why the latter is something that belongs with associating elements > of a domain with elements of a codomain than I do the former. Because that definition of associative, "associating elements of a domain with elements of a codomain", is entirely characterized by the codomain of the associative -> function isomorphism. Such functions support containsKey, entryAt, assoc, and both valAts. Because such an isomorphism exists, the only reason to use this not-a-function is to exploit the extra operations and guarantees by law we get, and allowing domain transformation this way is a stronger claim than the ability to override particular mappings. -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- 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
Re: Associative extends Seqable?
On Fri, Jan 18, 2013 at 10:31 PM, Stephen Compall
wrote:
> First, I have a suggestion for your associative: make `seq' return (map
> vector (iterate inc' 0) (constantly the-const-value)). This would be a
> correct result, as far as it's possible to observe.
True, but it would break this proposed law:
"""
anAssociative.entryAt(k) returning entry E,
implies that (seq anAssociative) contains E.
"""
You couldn't observe the breakage, but it would still the case that
for many elements of the domain no finite subsequence of the seq
contains those elements.
[(x,y) | x <- [0..], y <- [0..]] correctly produces all the pairs of
the integers as far as it's possible to observe, but it's still less
correct than a diagonal procedure.
There are other ways to make trouble anyway: it's perfectly possible
to define infinite sets that support conjoining, disjoining, union,
intersection, difference, etc., whether in forms that also support
seq-ing, e.g. sets of multiples of a given integer, or not (or not
obviously to me), in terms of an arbitrary characteristic
function---these not necessarily being infinite, I suppose. But sets
are also counted (twice over, once by extending Counted and once by
extending IPersistentCollection).
> On Fri, 2013-01-18 at 16:16 -0800, Ben Wolfson wrote:
> It may seem less odd if, instead of "I can enumerate my contents", you
> take the implication as "I can transform my domain forwards".
>
> In ordinary functions, the domain can be transformed, but the
> transformer function can't go olddomain -> newdomain; it has to go
> newdomain -> olddomain. (This also applies to those functions that can,
> given a value, report whether that value is defined for the domain,
> because such functions simply have a total codomain of a particular
> shape.)
>
> Associatives are related to functions in that converting an associative
> to a function is an injection, and both have domains and codomains. But
> the way you transform the domain of an associative is backwards from how
> you must for functions: the transformer function goes olddomain ->
> newdomain.
I don't really understand this. Surely you can, in fact, transform the
domain of an associative the same way you transform the domain of a
function? You could support the associative interface via a function
from newdomain -> olddomain + the old associative. (And if you can go
function -> associative, couldn't you just transform the domain of the
associative forwards, then stick a function newdomain -> codomain in
front of it, thereby transforming the domain of the initial function?)
> Why does this imply enumeration? You can't use the transformer function
> on lookups; the lookup keys are in newdomain already. So you must have
> applied that transformer to a data representation of the domain first,
> so that you have a newdomain search space for the key you're looking up.
> You must be able to produce the entire search space during a domain
> transform, which implies an enumeration. Once you're enumerating the
> domain, you can just apply the associative to produce the codomain, and
> thus, "enumerate the contents."
I can see why enumeration implies the ability to transform the domain
forward (modulo a question, below), but not why, in every case, the
forward transformation of the domain implies enumeration.
If the domain transformation function is injective and the associative
maps everything to the same value, then transforming the domain
forward is a no-op: there can't be something in the new domain that
wasn't in the old domain at all, since everything was in the old
domain. All we could do is shuffle elements in the domain around with
respect to what they're associated with. But they're all associated
with the same thing. You don't need to enumerate anything in this
case.
If the domain transformation function is not injective, then I get
very nervous about transforming the domain at all.
Given the map {-2 :x 2 :y} and the domain transformation function #(*
% %), what should the result map be? {4 :x}? {4 :y}? Blowup
(tantamount to requiring an injective function in the first place)?
What actually happens in clojure-land is clearly a function of how you
actually implement the transformation:
user=> (defn map-keys [f m] (->> m (map (fn [[k v]] [(f k) v])) (into {})))
#'user/map-keys
user=> (map-keys #(* % %) {-2 :x 2 :y})
{4 :y}
user=> (defn map-keys* [f m] (let [ks (set (keys m))] (apply hash-map
(mapcat (juxt f m) ks
#'user/map-keys*
user=> (map-keys* #(* % %) {-2 :x 2 :y})
java.lang.IllegalArgumentException: Duplicate key: 4 (NO_SOURCE_FILE:0)
And of course the fact that we got {4 :y} and not {4 :x} in the first
case is a function of the (arbitrary!) ordering of the result of seq.
But in the end my more fundamental question is: what makes it the case
that associatives can transform their domains forward? AFAICT the
answer is "the enumerability of associatives". So, in fact, it has not
helped me to look at the relation betwee
Re: Associative extends Seqable?
First, I have a suggestion for your associative: make `seq' return (map vector (iterate inc' 0) (constantly the-const-value)). This would be a correct result, as far as it's possible to observe. On Fri, 2013-01-18 at 16:16 -0800, Ben Wolfson wrote: > Right: I basically want (constantly 'foo), but supporting the map > interface. Or, rather, a subset of the map interface as it's currently > defined: it seems odd to me that being able to answer the question "do > I contain x?" implies "I can enumerate my contents". It may seem less odd if, instead of "I can enumerate my contents", you take the implication as "I can transform my domain forwards". In ordinary functions, the domain can be transformed, but the transformer function can't go olddomain -> newdomain; it has to go newdomain -> olddomain. (This also applies to those functions that can, given a value, report whether that value is defined for the domain, because such functions simply have a total codomain of a particular shape.) Associatives are related to functions in that converting an associative to a function is an injection, and both have domains and codomains. But the way you transform the domain of an associative is backwards from how you must for functions: the transformer function goes olddomain -> newdomain. Why does this imply enumeration? You can't use the transformer function on lookups; the lookup keys are in newdomain already. So you must have applied that transformer to a data representation of the domain first, so that you have a newdomain search space for the key you're looking up. You must be able to produce the entire search space during a domain transform, which implies an enumeration. Once you're enumerating the domain, you can just apply the associative to produce the codomain, and thus, "enumerate the contents." The only way you can apply both transformations is if your domain is vacuous: that is, constant functions like yours are the only ones that permit domain transform in either direction. -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- 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
Re: Associative extends Seqable?
On Fri, Jan 18, 2013 at 3:37 PM, Stephen Compall
wrote:
> On Jan 18, 2013 2:36 PM, "Ben Wolfson" wrote:
>> >> I could just extend ILookup, which contains only valAt, but I'd also
>> >> like to be able to implement containsKey and entryAt, which AFAICT are
>> >> only found in Associative.
>
> Associative also contains
>
> Associative assoc(Object key, Object val);
>
> I would propose, as a law, that anAssociative.assoc(k, v).valAt(k) = v. Do
> you satisfy that? (An enumeration of Associative laws would be helpful
> here.)
No, I don't: assoc is a is a no-op (as is without). Both assoc and
without are, in fact, only there to prevent set/rename-keys and a few
other functions from blowing up (set/rename-keys is *also* a no-op
with those definitions of assoc and without---but given the definition
of valAt, rename-keys being a no-op is correct).
However, it would certainly be possible to support that behavior while
retaining the nonsensicality of calling seq on the structures:
(defn constmap [o & [override]]
(let [override (or override {})]
(reify
clojure.lang.Associative
(containsKey [this _] true)
(entryAt [this k] (if (.containsKey override k)
(.entryAt override k)
(clojure.lang.MapEntry. k o)))
(valAt [this k] (second (.entryAt this k)))
(assoc [this k v] (constmap o (.assoc override k v))
> Anyway, anyone is free to assume that, given an IPersistentMap (or what have
> you), all of the laws of its superclasses are also implied.
Yes, that is probably so.
> So I think
> inheriting Seqable is a positive statement of this law:
>
> anAssociative.entryAt(k) returning entry E,
> implies that (seq anAssociative) contains E.
>
> But I cannot be sure. Without this law, though, you are basically left with
> (pure) function.
Right: I basically want (constantly 'foo), but supporting the map
interface. Or, rather, a subset of the map interface as it's currently
defined: it seems odd to me that being able to answer the question "do
I contain x?" implies "I can enumerate my contents".
--
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]
--
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
Re: Associative extends Seqable?
On Jan 18, 2013 2:36 PM, "Ben Wolfson" wrote: > >> I could just extend ILookup, which contains only valAt, but I'd also > >> like to be able to implement containsKey and entryAt, which AFAICT are > >> only found in Associative. Associative also contains Associative assoc(Object key, Object val); I would propose, as a law, that anAssociative.assoc(k, v).valAt(k) = v. Do you satisfy that? (An enumeration of Associative laws would be helpful here.) Anyway, anyone is free to assume that, given an IPersistentMap (or what have you), all of the laws of its superclasses are also implied. So I think inheriting Seqable is a positive statement of this law: anAssociative.entryAt(k) returning entry E, implies that (seq anAssociative) contains E. But I cannot be sure. Without this law, though, you are basically left with (pure) function. -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- 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
Re: Associative extends Seqable?
On Fri, Jan 18, 2013 at 11:32 AM, Kevin Downey wrote: > use ILookup instead of Associative >> I could just extend ILookup, which contains only valAt, but I'd also >> like to be able to implement containsKey and entryAt, which AFAICT are >> only found in Associative. (If I'm wrong, please let me know---I know >> that count is found in e.g. both IPersistentCollection and Counted.) >> And in any case I'd like to be able to use IPersistentMap as well, for >> without. There are sensible definitions of all the functions >> specifically defined for IPersistentMap and Associative, but there are >> *not* sensible definitions for all of what they bring along. -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] -- 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
Re: Associative extends Seqable?
use ILookup instead of Associative On Fri, Jan 18, 2013 at 11:00 AM, Ben Wolfson wrote: > I've got a bit of code implementing Associative, in order to provide a > fake map that responds to all calls to valAt with the same object, no > matter what the key is. > > Since it therefore "contains" every possible key, it doesn't make much > sense to call keys or seq on it (and it doesn't make *much* sense to > call vals on it if you expect the result of vals to be equinumerous > with the key/value pairs in the map). Nor does it make much sense to > call count on it. > > However, since Associative extends IPersistentCollection extends > Seqable, the result is an instance of Seqable, and coll? returns true, > etc., even though, as I said, the promises those interfaces make don't > really make sense. > > I could just extend ILookup, which contains only valAt, but I'd also > like to be able to implement containsKey and entryAt, which AFAICT are > only found in Associative. (If I'm wrong, please let me know---I know > that count is found in e.g. both IPersistentCollection and Counted.) > And in any case I'd like to be able to use IPersistentMap as well, for > without. There are sensible definitions of all the functions > specifically defined for IPersistentMap and Associative, but there are > *not* sensible definitions for all of what they bring along. > > Is there a way to weasel out of this? Force coll? to return false, > make the runtime think these pseudo-maps aren't instances of Seqable? > Being enumerable or seqable is not a necessary property of something > that maps keys to values. > > -- > Ben Wolfson > "Human kind has used its intelligence to vary the flavour of drinks, > which may be sweet, aromatic, fermented or spirit-based. ... Family > and social life also offer numerous other occasions to consume drinks > for pleasure." [Larousse, "Drink" entry] > > -- > 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 > -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
Associative extends Seqable?
I've got a bit of code implementing Associative, in order to provide a fake map that responds to all calls to valAt with the same object, no matter what the key is. Since it therefore "contains" every possible key, it doesn't make much sense to call keys or seq on it (and it doesn't make *much* sense to call vals on it if you expect the result of vals to be equinumerous with the key/value pairs in the map). Nor does it make much sense to call count on it. However, since Associative extends IPersistentCollection extends Seqable, the result is an instance of Seqable, and coll? returns true, etc., even though, as I said, the promises those interfaces make don't really make sense. I could just extend ILookup, which contains only valAt, but I'd also like to be able to implement containsKey and entryAt, which AFAICT are only found in Associative. (If I'm wrong, please let me know---I know that count is found in e.g. both IPersistentCollection and Counted.) And in any case I'd like to be able to use IPersistentMap as well, for without. There are sensible definitions of all the functions specifically defined for IPersistentMap and Associative, but there are *not* sensible definitions for all of what they bring along. Is there a way to weasel out of this? Force coll? to return false, make the runtime think these pseudo-maps aren't instances of Seqable? Being enumerable or seqable is not a necessary property of something that maps keys to values. -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] -- 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
