--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Why should it build a concrete result?
set-s are indeed a sticky point here since the result of a map would different depending in the convention.
I do perceive sets, lists, vector as atoms which are indivisible (well, this is not true but this is popular meaning) from semantics standpoint. Therefore map is just a function which processes them as whole, again from semantics point of view. Implementation and laziness should not matter really and we still should get the same result.
But what really bothers me is that laziness / not laziness affects the result of evaluation as in above example. That is against some fundamental rules of FP (gotta check how Haskell does it :-P).
Following your intuition, what would you expect from the following?> (map + [1 3 5] '(2 4 6))# => ?
But you're misunderstanding what map does: it converts its collection
arguments to _sequences_ and then it processes those sequences. Map
doesn't operate on sets, or vectors, or maps, only on sequences.
"Perfection is the enemy of the good."
Would you mind to point me to that piece where doc describes what order seq chooses when converting a set to it. (I honestly tried to find it but could not.)>Every persistent collection in Clojure supports conversion to the sequence of items. This is clearly documented in the official docs and there is no surprise here.
This might be too detailed a point, but I wanted to mention that while you will always get the same order for the same collection (same as determined by identical?, or Java ==, i.e. it is the same object in memory), you are *not* guaranteed to get the same order for collections of the same type that are equal to each other as determined by Clojure = or Java .equals. In particular, if two values have the same hash value, then if they are used as a set in a Clojure PersistentHashSet or a key in a PersistentHashKey, they are put into a linear list in a hash bucket for that hash value, and their order in that list can be different in different sets/maps, and the order that (seq ...) returns on those sets/maps will be different.I am not certain, but this might violate referential transparency (replacing a value that is equals for another value in an expression will always give you an equal result).
Two collections equivalent by their values may easily have a different order of their items.
--
user> (= s1 s2)trueuser> (= (seq s1) (seq s2))false
--
Agreed - there are always tradeoffs. Another common example is that pretty well any language that uses IEEE floating point is also breaking referential transparency in the interest of pragmatism:
user=> (= 0.3 (+ 0.1 0.2))
false
user=> (= (bigdec 0.3) (+ (bigdec 0.1) (bigdec 0.2)))
true
- Korny
The Contrib library algo.generic provides a function fmap which does
preserve the type of its input.
So, these are some of the available conceptual arguments. There is
also a rather convincing practical argument in the form of the
existing body of Clojure code, written using the existing Clojure core
library and its conventions and achieving, in many cases, amazing
levels of clarity and concision