Function syntax
I would be curious to know if there are difference (in terms of performance / elegance ) between those 2 ways of expressing functions E.g *(fn [ x] (- x sort last))* versus *#(last (sort %))* Both are supposedly equivalent, but would you recommend one preferred syntax , or this just a matter of personal style ? Thanks -- Eric Le Goff http://fr.linkedin.com/in/elegoff @elegoff https://twitter.com/elegoff -- 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/d/optout.
Re: Function syntax
2015-08-13 10:08 GMT+02:00 Eric Le Goff eleg...@gmail.com: I would be curious to know if there are difference (in terms of performance / elegance ) between those 2 ways of expressing functions E.g *(fn [ x] (- x sort last))* versus *#(last (sort %))* Both are supposedly equivalent, but would you recommend one preferred syntax , or this just a matter of personal style ? #() is for very short functions, mostly just one-liners, where the (fn []) would add significant noise. The line is blurry and a matter of taste; upper limit is when you need a nested fn, since #(#()) is not possible. Performance is equivalent, since #() desugars into (fn [..]). 2015-08-13 10:14 GMT+02:00 Erik Assum e...@assum.net: (comp last sort) That's not the same function as #(last (sort %)) The equivalent would be (comp last sort vec) cheers -- 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/d/optout.
Re: Decomplecting Clojure
I enjoyed the post. It's easy for those of us who've been in the community for a while to take such things for granted and not properly explain them to new folks. One suggestion - perhaps concurrency and immutability each deserve their own section? That wouldd give you a chance to dig deeper into immutability and perhaps cover structural sharing, which is the answer to many Clojure newcomers' puzzlement as to how immutability can be memory efficient. The current immutability/concurrency paragraph reads to me like concurrency is the main point of immutability, where in my experience it's just one useful consequence. On 13 August 2015 at 08:44, Sebastian Bensusan sbe...@gmail.com wrote: That was an error! The question has been corrected to Does it have a few dependencies? If the answer is 'No!' Thanks! If you your teammates do read it, please report any feedback. Documents like this one are sometimes appraised by converts and rejected by newcomers which is not the point :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acris...@gmail.com wrote: Hi Sebastian, Thanks for sharing! I'm enjoying read this document, and I plan to share it with a few teammates. I do have a question about one section however: Near the end, under Principles and Community you list three questions, and then state that if the answer to any of the questions is No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: Hi everybody! I've written a short post on my interpretation of Clojure. It is meant for people that are curious about the language and want to understand what the language is about. http://bensu.github.io/decomplecting_clojure/ Any feedback is welcome. Thanks to the folks at Slack that read the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: Function syntax
(comp last sort) Erik. -- i farta Den 13. aug. 2015 kl. 10.08 skrev Eric Le Goff eleg...@gmail.com: I would be curious to know if there are difference (in terms of performance / elegance ) between those 2 ways of expressing functions E.g (fn [ x] (- x sort last)) versus #(last (sort %)) Both are supposedly equivalent, but would you recommend one preferred syntax , or this just a matter of personal style ? Thanks -- Eric Le Goff http://fr.linkedin.com/in/elegoff @elegoff -- 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/d/optout. -- 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/d/optout.
Re: Decomplecting Clojure
That was an error! The question has been corrected to Does it have a few dependencies? If the answer is 'No!' Thanks! If you your teammates do read it, please report any feedback. Documents like this one are sometimes appraised by converts and rejected by newcomers which is not the point :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acris...@gmail.com wrote: Hi Sebastian, Thanks for sharing! I'm enjoying read this document, and I plan to share it with a few teammates. I do have a question about one section however: Near the end, under Principles and Community you list three questions, and then state that if the answer to any of the questions is No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: Hi everybody! I've written a short post on my interpretation of Clojure. It is meant for people that are curious about the language and want to understand what the language is about. http://bensu.github.io/decomplecting_clojure/ Any feedback is welcome. Thanks to the folks at Slack that read the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
Re: Function syntax
Hi, That's not the same function as #(last (sort %)) The equivalent would be (comp last sort vec) Could you please explain why is the `vec` needed? From what I understand, we are expected to treat the variadic args argument as a seq, nothing more. On Thursday, 13 August 2015 14:02:38 UTC+5:30, Herwig Hochleitner wrote: 2015-08-13 10:08 GMT+02:00 Eric Le Goff ele...@gmail.com javascript:: I would be curious to know if there are difference (in terms of performance / elegance ) between those 2 ways of expressing functions E.g *(fn [ x] (- x sort last))* versus *#(last (sort %))* Both are supposedly equivalent, but would you recommend one preferred syntax , or this just a matter of personal style ? #() is for very short functions, mostly just one-liners, where the (fn []) would add significant noise. The line is blurry and a matter of taste; upper limit is when you need a nested fn, since #(#()) is not possible. Performance is equivalent, since #() desugars into (fn [..]). 2015-08-13 10:14 GMT+02:00 Erik Assum er...@assum.net javascript:: (comp last sort) That's not the same function as #(last (sort %)) The equivalent would be (comp last sort vec) cheers -- 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/d/optout.
Re: Function syntax
Hi, I originally interpreted Erik's reply to mean - Instead of `#(last (sort %))` do `#((comp last sort) %)`. This works without any issue. Herwig's suggestion was about replacing the entire anonymous function with `(comp last sort vec)`. The example you gave `((comp last sort) 3 2 1)`, even if we make it `((comp last sort vec) 3 2 1)`, it will throw an error about `vec` being called with too many parameters. For it to work with variable args, as Herwig said in his reply to me, we need a function that can return a sequence from a varargs. `vector` or `list would work, not `vec`. It should be `((comp last sort list) 3 2 1)`. Please correct me if I am understanding this wrong. On Thursday, 13 August 2015 16:13:24 UTC+5:30, Tassilo Horn wrote: Amith George strid...@gmail.com javascript: writes: That's not the same function as #(last (sort %)) The equivalent would be (comp last sort vec) Could you please explain why is the `vec` needed? From what I understand, we are expected to treat the variadic args argument as a seq, nothing more. With ((comp last sort) 3 2 1), sort will be called as (apply sort (list 3 2 1)) which essentially is (sort 3 2 1). Hovever, sort is no varargs function but wants a collection. Bye, Tassilo -- 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/d/optout.
Re: Function syntax
Amith George strider...@gmail.com writes: That's not the same function as #(last (sort %)) The equivalent would be (comp last sort vec) Could you please explain why is the `vec` needed? From what I understand, we are expected to treat the variadic args argument as a seq, nothing more. With ((comp last sort) 3 2 1), sort will be called as (apply sort (list 3 2 1)) which essentially is (sort 3 2 1). Hovever, sort is no varargs function but wants a collection. Bye, Tassilo -- 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/d/optout.
Re: Function syntax
Maybe you meant to use `vector` instead of `vec`? `vec` doesn't accept variable args. Hence my original question. On Thursday, 13 August 2015 16:24:43 UTC+5:30, Herwig Hochleitner wrote: 2015-08-13 11:13 GMT+02:00 Amith George strid...@gmail.com javascript: : Could you please explain why is the `vec` needed? From what I understand, we are expected to treat the variadic args argument as a seq, nothing more. What Tassilo said. Also, it's not nessecary to use `vec`, but you need a function that creates a seqable from varargs, like vec, list, ... . That's what the rest argument syntax does for you: create a collection object from a variable number of arguments. -- 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/d/optout.
Re: Function syntax
2015-08-13 11:13 GMT+02:00 Amith George strider...@gmail.com: Could you please explain why is the `vec` needed? From what I understand, we are expected to treat the variadic args argument as a seq, nothing more. What Tassilo said. Also, it's not nessecary to use `vec`, but you need a function that creates a seqable from varargs, like vec, list, ... . That's what the rest argument syntax does for you: create a collection object from a variable number of arguments. -- 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/d/optout.
Re: Function syntax
Yep, I meant the thing, `vector` is doing. Thanks! 2015-08-13 13:36 GMT+02:00 Amith George strider...@gmail.com: Maybe you meant to use `vector` instead of `vec`? `vec` doesn't accept variable args. Hence my original question. On Thursday, 13 August 2015 16:24:43 UTC+5:30, Herwig Hochleitner wrote: 2015-08-13 11:13 GMT+02:00 Amith George strid...@gmail.com: Could you please explain why is the `vec` needed? From what I understand, we are expected to treat the variadic args argument as a seq, nothing more. What Tassilo said. Also, it's not nessecary to use `vec`, but you need a function that creates a seqable from varargs, like vec, list, ... . That's what the rest argument syntax does for you: create a collection object from a variable number of arguments. -- 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/d/optout. -- 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/d/optout.
Re: [ANN] Clojure 1.8.0-alpha3
Not to my knowledge but could be I suppose. -- 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/d/optout.
Re: Hashing With Consistent Results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Atamert, sorry for replying late. On 11.08.2015 10:29, Atamert Ölçgen wrote: Hi Christian, hasch looks nice, I might end up just using it. I will be hashing smaller collections (maps where keys are keywords and values are atomic data like integers). Ok, then io will probably hurt you much more than some overhead for hashing, I guess. Collisions BTW are not such a big deal for my use case. I will have a limited number of fragments (buckets, index pages, etc.) anyway. 65536 of them perhaps. The more I think about the problem the more I realize I am implementing some sort of hash map. I guess a durable one. In this case it might be interesting to think about extending the persistent datastructures of Clojure in a way to keep them on disk. I am currently experimenting a bit with that on hash-maps of a commit graph, although I need it to work in ClojureScript as well and cannot just reimplement core protocols because of async io. That way changing metadata of my datatype can have constant size. Feel free to post any feedback on your progress/findings :). Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVzITYAAoJEKel+aujRZMkZX4H/j5kpqolsS61y2IH+68Bq55/ sdiME1eXdJ4VgYQH+IF4WDTYtPGZgV7U3XnM7Bqc5SygkGxOvDc5p4piTeSfpJIh HE8GkBP8RkQNU5rqKu0M6xeSJGQdnAp/1VzQdJux9KAC2+0RG+SLKKft95zka9iz PHDy+n/m8qTrMSUjpk2tVxuglyjkGaQeBm9bfRN07Cn/96e9XcafzsekMwZiI8HU 70n5ACbBWFXz5zxe0xfoUdA48OJSXrnoQTCmA95zOLnZ9thHgs066jjXCjNtomzD NRhx7J9hi4lU54VmRcYJb4mVw5JLXQCWnARh8//o6P2SbmYFJkDIsCLtPJ9xJu4= =H4lz -END PGP SIGNATURE- -- 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/d/optout.
Re: Hashing With Consistent Results
Could you use something like Redis? Use hashes as keys, fake immutability by 'popping' kv pairs and inserting new ones keyed to the (presumably different) hash of the updated map. On Thursday, August 13, 2015 at 7:52:06 AM UTC-4, Christian Weilbach wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Atamert, sorry for replying late. On 11.08.2015 10:29, Atamert Ölçgen wrote: Hi Christian, hasch looks nice, I might end up just using it. I will be hashing smaller collections (maps where keys are keywords and values are atomic data like integers). Ok, then io will probably hurt you much more than some overhead for hashing, I guess. Collisions BTW are not such a big deal for my use case. I will have a limited number of fragments (buckets, index pages, etc.) anyway. 65536 of them perhaps. The more I think about the problem the more I realize I am implementing some sort of hash map. I guess a durable one. In this case it might be interesting to think about extending the persistent datastructures of Clojure in a way to keep them on disk. I am currently experimenting a bit with that on hash-maps of a commit graph, although I need it to work in ClojureScript as well and cannot just reimplement core protocols because of async io. That way changing metadata of my datatype can have constant size. Feel free to post any feedback on your progress/findings :). Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVzITYAAoJEKel+aujRZMkZX4H/j5kpqolsS61y2IH+68Bq55/ sdiME1eXdJ4VgYQH+IF4WDTYtPGZgV7U3XnM7Bqc5SygkGxOvDc5p4piTeSfpJIh HE8GkBP8RkQNU5rqKu0M6xeSJGQdnAp/1VzQdJux9KAC2+0RG+SLKKft95zka9iz PHDy+n/m8qTrMSUjpk2tVxuglyjkGaQeBm9bfRN07Cn/96e9XcafzsekMwZiI8HU 70n5ACbBWFXz5zxe0xfoUdA48OJSXrnoQTCmA95zOLnZ9thHgs066jjXCjNtomzD NRhx7J9hi4lU54VmRcYJb4mVw5JLXQCWnARh8//o6P2SbmYFJkDIsCLtPJ9xJu4= =H4lz -END PGP SIGNATURE- -- 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/d/optout.
Re: Function syntax
It is a matter of personal style. Note that there is a max function. On Thursday, August 13, 2015 at 1:53:23 PM UTC+2, Herwig Hochleitner wrote: Yep, I meant the thing, `vector` is doing. Thanks! 2015-08-13 13:36 GMT+02:00 Amith George strid...@gmail.com javascript: : Maybe you meant to use `vector` instead of `vec`? `vec` doesn't accept variable args. Hence my original question. On Thursday, 13 August 2015 16:24:43 UTC+5:30, Herwig Hochleitner wrote: 2015-08-13 11:13 GMT+02:00 Amith George strid...@gmail.com: Could you please explain why is the `vec` needed? From what I understand, we are expected to treat the variadic args argument as a seq, nothing more. What Tassilo said. Also, it's not nessecary to use `vec`, but you need a function that creates a seqable from varargs, like vec, list, ... . That's what the rest argument syntax does for you: create a collection object from a variable number of arguments. -- 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 javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
apply, mapply, recur, looking for insights
These inconsistencies are bugging me, I just wondered if I was missing some
standard language thing about argument passing or destructuring, so I'm
looking for comments.
At issue (for me), keyword arguments and maps that bundle them.
user (defn foo [a b {:keys [c d]}]
[a b c d])
#'user/foo
user (defn bar [a b {:keys [c d] :as options}]
(println (apply foo a b options)))
#'user/bar
user (bar 1 2)
[1 2 nil nil]
nil
;; Okay so far
user (bar 1 2 :c 3)
IllegalArgumentException No value supplied for key: [:c 3]
clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
;; I'm wishing the above was smarter, but okay, so I use 'mapply', which
seems to me it ought to be in clojure.core but isn't.
user (defn mapply
[f args]
(apply f (apply concat (butlast args) (last args
#'user/mapply
user (defn bar2 [a b {:keys [c d] :as options}]
(println (mapply foo a b options)))
#'user/bar2
user (bar2 1 2 :c 3)
[1 2 3 nil]
nil
;; Okay, that works nicely
So maybe this is all fine, though if there's some standard way of doing
this using things shipped with clojure please let me know.
However then 'recur' bucks the trend, which adds to confusion.
user (defn baz [a b {:keys [c d] :as options}]
(if ( a 0)
(recur (- a 1) b options)
[a b c d]))
#'user/baz
user (baz 2 3 :c 4)
[0 3 4 nil]
So recur does this arguably very useful thing, but apply does not (and
probably with good reason, otherwise how would we pass maps as regular
arguments...)
I guess what I'm seeking is the canonical clojure approach to dealing with
keyword arguments and maps in call sites, and I find
the apply/recur difference confusing, and the lack of 'mapply' an oversight.
Thoughts? Comments? Please educate on what I'm missing, thanks.
--
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/d/optout.
Re: Decomplecting Clojure
Hi Chris, I agree that concurrency is one useful consequence. I tried to explain all the benefits of immutability in previous drafts and failed miserably. It's something that comes after enlightenment. That's why I ended up explaining immutability only through very practical terms. On how is it efficient?, I decided to edit it out for two reasons: first, not everybody asks that, since there are many (specially younger programmers) that naively trust tools. Secondly, I figured that if they do ask the question, it might lead them into research, which is the whole point! Thanks for the feedback, Sebastian On Thu, Aug 13, 2015 at 10:35 AM, Chris Ford christophertf...@gmail.com wrote: I enjoyed the post. It's easy for those of us who've been in the community for a while to take such things for granted and not properly explain them to new folks. One suggestion - perhaps concurrency and immutability each deserve their own section? That wouldd give you a chance to dig deeper into immutability and perhaps cover structural sharing, which is the answer to many Clojure newcomers' puzzlement as to how immutability can be memory efficient. The current immutability/concurrency paragraph reads to me like concurrency is the main point of immutability, where in my experience it's just one useful consequence. On 13 August 2015 at 08:44, Sebastian Bensusan sbe...@gmail.com wrote: That was an error! The question has been corrected to Does it have a few dependencies? If the answer is 'No!' Thanks! If you your teammates do read it, please report any feedback. Documents like this one are sometimes appraised by converts and rejected by newcomers which is not the point :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acris...@gmail.com wrote: Hi Sebastian, Thanks for sharing! I'm enjoying read this document, and I plan to share it with a few teammates. I do have a question about one section however: Near the end, under Principles and Community you list three questions, and then state that if the answer to any of the questions is No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: Hi everybody! I've written a short post on my interpretation of Clojure. It is meant for people that are curious about the language and want to understand what the language is about. http://bensu.github.io/decomplecting_clojure/ Any feedback is welcome. Thanks to the folks at Slack that read the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout. -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit
Re: apply, mapply, recur, looking for insights
Dave Tenny dave.te...@gmail.com writes:
Hi Dave,
At issue (for me), keyword arguments and maps that bundle them.
user (defn foo [a b {:keys [c d]}]
[a b c d])
#'user/foo
user (defn bar [a b {:keys [c d] :as options}]
(println (apply foo a b options)))
#'user/bar
user (bar 1 2)
[1 2 nil nil]
nil
;; Okay so far
user (bar 1 2 :c 3)
IllegalArgumentException No value supplied for key: [:c 3]
clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
Yes, because `apply` wants to have a sequable thing as its last
argument. A map is a sequable thing: `(seq my-map)` returns `([key1
val1] [key2 val2] ...)`, i.e., a sequence of tuples of the map's keys
and values. However, your `foo` function doesn't want tuples but just
keys and values. Basically, what you are doing is essentially
(foo a b [:c cval] [:d dval])
where it should be
(foo a b :c cval :d dval)
So maybe this is all fine, though if there's some standard way of
doing this using things shipped with clojure please let me know.
Well, emulating keyword args with varargs and map destructuring can
sometimes be nice in order to have a nice convenient API but it doesn't
really compose well. I'd suggest to define `foo` with arguments
[a b {:keys [c d]}
i.e., no varargs. Then `bar` can just call `(foo a b options)`. Or
maybe drop varargs altogether and define `bar` as
(defn bar
([a b] (bar a b {}))
([a b {:keys [c d] :as options}] ...))
However then 'recur' bucks the trend, which adds to confusion.
user (defn baz [a b {:keys [c d] :as options}]
(if ( a 0)
(recur (- a 1) b options)
[a b c d]))
#'user/baz
user (baz 2 3 :c 4)
[0 3 4 nil]
Indeed. Here I had expected as exception No value supplied for key:
{:c 4} because the first recur call should be equivalent to `(baz 1 3
{:c 4})`, and
user (baz 1 3 {:c 4})
; IllegalArgumentException No value supplied for key: {:c 4}
; clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
So now I'm also confused. :-)
Bye,
Tassilo
--
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/d/optout.
Re: Decomplecting Clojure
Wait. If a module has dependencies, that's usually a *good* thing --- it hopefully does one thing well, and doesn't reinvent the wheel. Also, the article online still reads, Does it have many dependencies? By the way, I enjoyed the article. Thanks! I liked the short pithy sentences you wrote throughout: The JVM makes Clojure *practical*. A functional style makes Clojure *elegant*. Lisp makes Clojure *powerful*. Data as Data makes Clojure *simple*. Immutability makes Clojure programs *easy to reason about*. Oooh, looking at that list, I wonder if one about laziness is missing... -- John On Thursday, August 13, 2015 at 3:45:23 AM UTC-4, Sebastian Bensusan wrote: That was an error! The question has been corrected to Does it have a few dependencies? If the answer is 'No!' Thanks! If you your teammates do read it, please report any feedback. Documents like this one are sometimes appraised by converts and rejected by newcomers which is not the point :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acri...@gmail.com javascript: wrote: Hi Sebastian, Thanks for sharing! I'm enjoying read this document, and I plan to share it with a few teammates. I do have a question about one section however: Near the end, under Principles and Community you list three questions, and then state that if the answer to any of the questions is No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? -- 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/d/optout.
Re: Decomplecting Clojure
Default laziness can cause problems, but I'm not sure that they're bad problems, necessarily. I think 'opt-out' laziness (and the headaches it can cause) push people--especially people coming from non-FP backgrounds--to really zero in on writing pure, focused functions. On the other hand, from a 'marketing' perspective, I'd talk more about transducers than laziness--they're more exotic, at least. On Thursday, August 13, 2015 at 2:27:21 PM UTC-4, Alan Thompson wrote: I must agree with Lee that, IMHO, default laziness can cause unexpected problems. I would argue that it violates the Principle of Least Surprise. A better way would be to make laziness optional and explicit, perhaps by adding a z suffix to the lazy version of each function (e.g. map - mapz, for - forz, etc). Then lazy behavior would be available whenever it was desired, but the code would explicitly indicate when laziness was being employed. Alan On Thu, Aug 13, 2015 at 11:01 AM, Lee Spector lspe...@hampshire.edu javascript: wrote: Thanks Sebastian for the thoughtful and helpful document! I like it and have shared it with my group. On Aug 13, 2015, at 1:51 PM, Sebastian Bensusan sbe...@gmail.com javascript: wrote: I never thought of laziness! It's a good point. Retroactively I might add it to the Functional Style section :) You did a nice job of presenting both pros and cons for the other features of Clojure, and I expect there would be something similar for your entry on laziness but FWIW from my perspective the cons here are more significant than for any other feature (and I know that opinions will vary on this!). I know that no language is perfect for everyone or every purpose, but at least from my perspective pervasive laziness is one of Clojure's very few true mistakes (sort of like my father-in-law says that eggplant is one of god's very few true mistakes). Laziness is often glorious and elegant, and the way that it's everywhere by default in Clojure is quite cool. But in a not-purely-functional environment it can cause weird problems at unexpected times and in unexpected places. There are several ways to get into trouble -- there was a nice blog post on some of them years ago, maybe by Chas Emerick? -- but I think most of my own come from the not-purely-functional nature of synchronization, awaiting the completion of tasks dispatched to agents. Symptoms that I get include the saturation of only one core when I expect to be saturating all of them, and sometimes out-of-memory errors. I think the former are due to delayed lazy computations taking place at unexpected times, and that the latter come from GC not collecting things that it would know it could collect if the deferred computations were completed in a non-lazy way. It has been hard to replicate or track down the sources of these problems, but they do always go away when I un-lazify everything -- coercing sequences to vectors, calling doall, changing every call to map to mapv, etc. Because these problems are so hard to diagnose and think about, I've taken to pre-emptively avoiding laziness whenever possible, unless I really want it (which is relatively rare, for me). This can be a bit awkward, and it's one of the very few things that I feel like I have to apologize for when I introduce Clojure to students. -Lee -- 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 javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
Re: Decomplecting Clojure
Hi John, Thanks for the heads up, I clearly didn't push the changes. When it comes to dependencies, I find that from the user's perspective, they are not desirable: 1. They might conflict with other modules (i.e., lein deps :tree can be a little hell of its own). 2. They increase the size of your artifacts (very relevant in browsers). Now, I do agree that they are a good heuristic of good code: a module that uses dependencies wisely and doesn't reinvent the wheel is better than one that does. So, there are two conflicting forces, and we are left with compromise: we should use modules that use dependencies in a balanced way. That is why I broke the questions into few dependencies and does one thing well to tackle the issues separately. I never thought of laziness! It's a good point. Retroactively I might add it to the Functional Style section :) Thanks for the feedback, Sebastian On Thu, Aug 13, 2015 at 5:09 PM, John Gabriele jmg3...@gmail.com wrote: Wait. If a module has dependencies, that's usually a *good* thing --- it hopefully does one thing well, and doesn't reinvent the wheel. Also, the article online still reads, Does it have many dependencies? By the way, I enjoyed the article. Thanks! I liked the short pithy sentences you wrote throughout: The JVM makes Clojure *practical*. A functional style makes Clojure *elegant*. Lisp makes Clojure *powerful*. Data as Data makes Clojure *simple*. Immutability makes Clojure programs *easy to reason about*. Oooh, looking at that list, I wonder if one about laziness is missing... -- John On Thursday, August 13, 2015 at 3:45:23 AM UTC-4, Sebastian Bensusan wrote: That was an error! The question has been corrected to Does it have a few dependencies? If the answer is 'No!' Thanks! If you your teammates do read it, please report any feedback. Documents like this one are sometimes appraised by converts and rejected by newcomers which is not the point :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acri...@gmail.com wrote: Hi Sebastian, Thanks for sharing! I'm enjoying read this document, and I plan to share it with a few teammates. I do have a question about one section however: Near the end, under Principles and Community you list three questions, and then state that if the answer to any of the questions is No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
[ANN] Clojure/conj CFP closes Aug 21st!
We've been seeing a lot of out of office replies on mailings for the Conj CFP, so we've pushed back the deadline one week to Aug 21st. We'd love to have submissions about Clojure, ClojureScript, libraries, tool, experience reports, etc! https://cognitect.wufoo.com/forms/clojureconj-2015-call-for-presentations/ Clojure/conj will be held in Philadelphia Nov 16-18. Tickets will be on sale soon. http://clojure-conj.org We are currently working on workshop offerings for the weekend before that. We will have a Clojure intro course and probably some other offerings. If you have a *desired* workshop topic (or an idea to teach one), please contact eve...@cognitect.com. Alex -- 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/d/optout.
Re: Decomplecting Clojure
I must agree with Lee that, IMHO, default laziness can cause unexpected problems. I would argue that it violates the Principle of Least Surprise. A better way would be to make laziness optional and explicit, perhaps by adding a z suffix to the lazy version of each function (e.g. map - mapz, for - forz, etc). Then lazy behavior would be available whenever it was desired, but the code would explicitly indicate when laziness was being employed. Alan On Thu, Aug 13, 2015 at 11:01 AM, Lee Spector lspec...@hampshire.edu wrote: Thanks Sebastian for the thoughtful and helpful document! I like it and have shared it with my group. On Aug 13, 2015, at 1:51 PM, Sebastian Bensusan sbe...@gmail.com wrote: I never thought of laziness! It's a good point. Retroactively I might add it to the Functional Style section :) You did a nice job of presenting both pros and cons for the other features of Clojure, and I expect there would be something similar for your entry on laziness but FWIW from my perspective the cons here are more significant than for any other feature (and I know that opinions will vary on this!). I know that no language is perfect for everyone or every purpose, but at least from my perspective pervasive laziness is one of Clojure's very few true mistakes (sort of like my father-in-law says that eggplant is one of god's very few true mistakes). Laziness is often glorious and elegant, and the way that it's everywhere by default in Clojure is quite cool. But in a not-purely-functional environment it can cause weird problems at unexpected times and in unexpected places. There are several ways to get into trouble -- there was a nice blog post on some of them years ago, maybe by Chas Emerick? -- but I think most of my own come from the not-purely-functional nature of synchronization, awaiting the completion of tasks dispatched to agents. Symptoms that I get include the saturation of only one core when I expect to be saturating all of them, and sometimes out-of-memory errors. I think the former are due to delayed lazy computations taking place at unexpected times, and that the latter come from GC not collecting things that it would know it could collect if the deferred computations were completed in a non-lazy way. It has been hard to replicate or track down the sources of these problems, but they do always go away when I un-lazify everything -- coercing sequences to vectors, calling doall, changing every call to map to mapv, etc. Because these problems are so hard to diagnose and think about, I've taken to pre-emptively avoiding laziness whenever possible, unless I really want it (which is relatively rare, for me). This can be a bit awkward, and it's one of the very few things that I feel like I have to apologize for when I introduce Clojure to students. -Lee -- 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/d/optout. -- 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/d/optout.
Re: Decomplecting Clojure
Thanks Sebastian for the thoughtful and helpful document! I like it and have shared it with my group. On Aug 13, 2015, at 1:51 PM, Sebastian Bensusan sbe...@gmail.com wrote: I never thought of laziness! It's a good point. Retroactively I might add it to the Functional Style section :) You did a nice job of presenting both pros and cons for the other features of Clojure, and I expect there would be something similar for your entry on laziness but FWIW from my perspective the cons here are more significant than for any other feature (and I know that opinions will vary on this!). I know that no language is perfect for everyone or every purpose, but at least from my perspective pervasive laziness is one of Clojure's very few true mistakes (sort of like my father-in-law says that eggplant is one of god's very few true mistakes). Laziness is often glorious and elegant, and the way that it's everywhere by default in Clojure is quite cool. But in a not-purely-functional environment it can cause weird problems at unexpected times and in unexpected places. There are several ways to get into trouble -- there was a nice blog post on some of them years ago, maybe by Chas Emerick? -- but I think most of my own come from the not-purely-functional nature of synchronization, awaiting the completion of tasks dispatched to agents. Symptoms that I get include the saturation of only one core when I expect to be saturating all of them, and sometimes out-of-memory errors. I think the former are due to delayed lazy computations taking place at unexpected times, and that the latter come from GC not collecting things that it would know it could collect if the deferred computations were completed in a non-lazy way. It has been hard to replicate or track down the sources of these problems, but they do always go away when I un-lazify everything -- coercing sequences to vectors, calling doall, changing every call to map to mapv, etc. Because these problems are so hard to diagnose and think about, I've taken to pre-emptively avoiding laziness whenever possible, unless I really want it (which is relatively rare, for me). This can be a bit awkward, and it's one of the very few things that I feel like I have to apologize for when I introduce Clojure to students. -Lee -- 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/d/optout.
[ANN] stateful-check 0.3.1 - test stateful systems with test.check
Hey everyone! I've just released a new version of my library for testing stateful systems with test.check! [org.clojars.czan/stateful-check 0.3.1] https://github.com/czan/stateful-check https://clojars.org/org.clojars.czan/stateful-check Changes in this version: + :real/setup and :real/cleanup actually work again! There was a bug in the previous release that broke them, but they're fixed now. + :model/generate-command is now optional, with a default value which randomly selects a command from all the provided command specifications. + :model/args now coerces things to generators, so [gen/nat] will be treated as (gen/tuple gen/nat), for instance. + the output of the results of commands is now correct, even when the objects themselves are mutated later in the test. + added :tries to specification-correct? to aid in testing non-deterministic tests. + shrinking is now more aggressive and will shrink more effectively in some cases. See the changelog for more details. I hope somebody finds this useful! -- 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/d/optout.
