The Contrib library algo.generic provides a function fmap which does
preserve the type of its input.
As for the idea that clojure.core/map should preserve type, it's worth
remembering that in order to map a function over a set and return a
set, we must do two things: (1) apply the function to
There are many types and flavors of equality, and only handful of symbols.
Symbol '=' in Clojure does not represent yours fundamental = comparison
operator. = in Clojure compares for the actual value ignoring concrete
types of collections and the internal representation of how the items are
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
-
On Sun, Feb 9, 2014 at 4:46 AM, Michał Marczyk michal.marc...@gmail.comwrote:
The Contrib library algo.generic provides a function fmap which does
preserve the type of its input.
Thanks for the pointer.
So, these are some of the available conceptual arguments. There is
also a rather
On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield s...@corfield.org wrote:
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.
Your assertion
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.
The order or items in the resulting sequence is dependent on the collection
type. As the conversion to the sequence is a
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.
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
On Sun, Feb 9, 2014 at 12:40 AM, Andy C andy.coolw...@gmail.com wrote:
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.
Would you mind to point me to that piece where doc
The definition of map in Clojure is that it is a function on seqs. It is
defined as operating on a seq, and returning a seq.
Whereas in Scala, you hold an object and have thus access to its class (so
you can call Set.map on a set and List.map on a map), in Clojure there is
only one function
First of all, you are right. Map with things like sets is a bit of iffy
concept. Now, most of the the time, I just don't care. If I was to
increment every value in a set I'll just do (set (map inc #{1 2 3})) and
not really care less about data structure theory. It works and I can get
work done.
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
The sequence abstraction is documented here:
http://clojure.org/sequences
Clearly map is documented as working on sequences.
A sequence is not a concrete type as explained by others on
this thread.
If you really need some specific behavior from a concrete type then
do not rely on sequences.
On Sat, Feb 8, 2014 at 6:39 PM, Timothy Baldridge tbaldri...@gmail.com wrote:
First of all, you are right. Map with things like sets is a bit of iffy
concept. Now, most of the the time, I just don't care. If I was to increment
every value in a set I'll just do (set (map inc #{1 2 3})) and not
First, thanks everybody for explanations of design decision behind map and
collections. I should in fact change subject to seq semantics ;-).
For me the bottom line is that while I do not care about order so much I
still can count on that seq function will produce consistent sequences. Or
wait a
By 'same' I've meant an identical :).
Two collections equivalent by their values may easily have a different
order of their items. This is because in unordered collections, their
internal order (as any other implementation detail) must not be taken into
account when comparing for value
On Sat, Feb 8, 2014 at 1:46 PM, Jozef Wagner jozef.wag...@gmail.com wrote:
Two collections equivalent by their values may easily have a different
order of their items.
It all boils down this:
is it possible to have two clojure.lang.PersistentHashSet with identical
values (in mathematical
On Feb 8, 2014, at 15:14 , Andy C andy.coolw...@gmail.com wrote:
It all boils down this:
is it possible to have two clojure.lang.PersistentHashSet with identical
values (in mathematical sense) but producing different seqs?
Are you serious? The entire point of the email you responded to was
Yes. Behold a Murmur3 hash collision:
user (def n1 -2023261231)
#'user/n1
user (def n2 9223372036854771971)
#'user/n2
user (== (hash n1) (hash n2))
true
user (def s1 (conj #{} n1 n2))
#'user/s1
user (def s2 (conj #{} n2 n1))
#'user/s2
user (= s1 s2)
But practically, I cannot think of any
I've forgot the most interesting part :)
user (= s1 s2)
true
user (= (seq s1) (seq s2))
false
JW
On Sat, Feb 8, 2014 at 11:32 PM, Jozef Wagner jozef.wag...@gmail.comwrote:
Yes. Behold a Murmur3 hash collision:
user (def n1 -2023261231)
#'user/n1
user (def n2 9223372036854771971)
Well it does not break referential transparency if both equalities (for
input values and for results) are of a same kind. You would have to compare
inputs by value and outputs by identity, if you want to percieve an
inconsistency.
JW
On Saturday, February 8, 2014 6:49:39 PM UTC+1, Andy
On Feb 8, 2014, at 7:59 AM, Andy C andy.coolw...@gmail.com wrote:
Your assertion that I am misunderstanding something is wrong.
Now that you've seen everyone else's responses, perhaps you understand my
assertion was correct? :)
Sean Corfield -- (904) 302-SEAN
An Architect's View --
user (= s1 s2)
true
user (= (seq s1) (seq s2))
false
Thx. If a=b then f(a) must = f(b). Something is broken here.
--
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
It is working as designed.
If you do not want this, consider using sorted sets / sorted maps, where (=
s1 s2) implies (= (seq s1) (seq s2)).
Or, perhaps another programming language would be more to your liking.
Andy
On Sat, Feb 8, 2014 at 4:10 PM, Andy C andy.coolw...@gmail.com wrote:
Hi Andy,
Andy C andy.coolw...@gmail.com wrote:
user (= s1 s2)
true
user (= (seq s1) (seq s2))
false
Thx. If a=b then f(a) must = f(b). Something is broken here.
If a seq is a sequential view of a thing, and a set is an unordered thing, then
it does not seem shocking to me that multiple
To add just one more thing to this: Referential transparency is clearly
valuable, but it's not the *only* valuable property a function or system might
have. There are always tradeoffs to be made. Clojure has made different
tradeoffs than you expected, or would yourself have made, but that doesn't
I can ensure all of you that it is very uncomfortable for a newcomer with a
goofy nick to just come in and say things are broke LOL . So at that point
I have two choices:
1) as suggested, find another programming language but that would mean that
I would have to erase my Clojure tattoo (very
Maybe another way to put it is that what is, uh, broken isn't 'map' or
'seq', but '=', which is willing to tell you that two things (sets) are the
same when they're not! We also have the non-broken predicate 'identical?',
however, that gets it right. It's nice to also have a set-equal
Maybe physical identity is too strong of a requirement for equality. So
another way to think about it is that it's 'hash-set', 'set', and '#{}'
that are--you know--broken, but that there's a fix, which is to always
use 'sorted-set'. (I'm assuming that calling 'seq' on any two sorted sets
Hi,
I have a short question, why map builds up a LazySeq instead of an input
collection as found below:
user= (type (map #(mod % 3) #{3 6}))
clojure.lang.LazySeq
user= (type (map #(mod % 3) '(3 6)))
clojure.lang.LazySeq
user= (type (map #(mod % 3) [3 6]))
clojure.lang.LazySeq
user= (type (map
Why should it build a concrete result?
Here's my reasons why it makes sense to be lazy here:
- It would use more memory otherwise. Since, if you are transforming a list
to a set there's got to a transformed copy of the original data structure
when it's materialized.
- It might take longer than
On Sat, Feb 8, 2014 at 3:05 AM, Andy C andy.coolw...@gmail.com wrote:
set-s are indeed a sticky point here since the result of a map would
different depending in the convention.
No the result would be the same. Only the order of the elements in the lazy
sequence would differ, but that's to
user= (map #(mod % 3) #{3 6})
(0 0)
user= (set (map #(mod % 3) #{3 6}))
#{0}
--
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
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
Andy C, I think that in the Clojure world, there is a widespread view that
lazy sequences should be the (or one of the) primary datatypes, that
iteration should usually produce lazy sequences, etc. They are something
like the default in Clojure. Clojure includes a systematically organized
I actually like the laziness by default but as you suggest, wish there is a
way to switch it on/off for blocks of the code (rather than compiler
option). Scala guys did some research and in most practical cases Lists are
very short hence they are not lazy and evaluated at once. Just an
interesting
On Feb 7, 2014, at 22:17 , Andy C andy.coolw...@gmail.com wrote:
Having map to produce a lazy seq implies that the input must be serializable
(or linear).
That's just what map is in Clojure: an operation on sequences. It works on
various concrete types because those can be viewed as
On Fri, Feb 7, 2014 at 9:41 PM, Andy C andy.coolw...@gmail.com wrote:
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
On Friday, February 7, 2014 10:17:15 PM UTC-6, Andy C wrote:
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).
Well, it's not really laziness
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.
Scala goes out of its way to retain input types as output types on
many of its collection
39 matches
Mail list logo
