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.
However, the bigger problem comes when we start discussing parallel
operations on these datasets. Here it makes no sense to define an order for
(pmap inc #{1 2 3}) when there is no defined order in the input collection
to begin with. This is the entire reason behind clojure's reducers, they
allow the input and output data structures to drive how processing is
handled.
http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
And as the article states, reducers "use(s) regular data structures, not
'parallel collections' or other OO malarkey"
Timothy Baldridge
On Sat, Feb 8, 2014 at 10:10 AM, Gary Verhaegen <gary.verhae...@gmail.com>wrote:
> 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 clojure.core/map, and it is defined as taking a seq as
> argument. seq is an abstraction, for which there are many functions in the
> Clojure standard library. Whenever you are calling any one of them, you
> leave the realm of concrete collection and enter the realm of seqs.
>
> Functions that operate on seqs are listed on the following page:
> http://clojure.org/sequences.
>
> Now, these functions only accept seqs as arguments. You are right that one
> possible choice would have been to throw an expection every time you pass
> in something else than a seq, which would force you to write something
> along the lines of:
>
> (map #(mod % 3) (seq #{3 6}))
>
> The language designer has decided that all of the sequence functions in
> the standard library would, instead of throwing an exception when the
> argument is not a seq, first try to convert it to a seq (by calling the seq
> function as illustrated above).
>
> This is a design choice which could have been different. This choice in
> particular is based on the famous Perlis quote "It is better to have 100
> functions operate on one data structure than 10 functions on 10 data
> structures." So the standard library focuses on providing a lot of very
> useful functions on the sequence abstraction; what all of these functions
> have in common is that they can be described in terms of considering the
> elements of the seq one at a time.
>
> Arguably, most collections should be able to provide access to all of
> their elements one at a time. Any collection that can do that can
> participate in the seq abstraction. Practically, this means that if you
> define your own data structure (to build on the running example in this
> thread, some kind of tree), you only have to implement one function - seq -
> on your collection to enable the use of all the seq functions from the
> standard library (and many other functions from other libraries that also
> build on the seq abstraction). However, since all of these functions know
> nothing about your data structure except that they can ask for the next
> element, they have no way to keep the structure of your collection.
>
> As a general rule, in Clojure, each collection type has a small number of
> functions that are defined for that collection (and are thus
> type-preserving when it makes sense), but all basic collections support the
> seq abstraction and most of the work is done through the sequence functions.
>
> Each collection type defines how to turn itself into a seq; non-ordered
> collections in the Clojure base language (sets and maps) make no promise
> about the order of their elements when turned into a seq (if you really
> want to know, you can look at the implementation, but you cannot count on
> it not changing in the future).
>
>
>
> On 8 February 2014 17:40, 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 describes what order
>> seq chooses when converting a set to it. (I honestly tried to find it but
>> could not.)
>>
>>
>>
>> >The order or items in the resulting sequence is dependent on the
>> collection type. As the conversion to the sequence is a referentially
>> transparent function, you will always get the same order for the same
>> collection.
>>
>> So for particularly huge sets, I understand Clojure will not attempt to
>> sort them (read be inefficient) before producing the sequence, is it
>> correct?
>>
>>
>>
>>
>> --
>> 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
>> ---
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
> --
> 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
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
"One of the main causes of the fall of the Roman Empire was that-lacking
zero-they had no way to indicate successful termination of their C
programs."
(Robert Firth)
--
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
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
