On Fri, Jan 18, 2013 at 10:31 PM, Stephen Compall
<stephen.comp...@gmail.com> 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 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.
--
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
