On Sat, Jan 19, 2013 at 1:26 PM, Stephen Compall
<stephen.comp...@gmail.com> 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 the
guarantees one requires.
> 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
--
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
