Re: [Q] Guarantees of sorted-map-by calling the comparator?
If you are looking for a guarantee in the documentation that this will never happen in the current version of Clojure, and it is promised never to change in that way in future Clojure versions, then I don't see anything in the documentation that would give that guarantee. If you are looking for a guarantee that the Clojure 1.6.0 implementation of sorted-set-by will never call a comparator function with the same key as long as no one ever tries to add a key a second time, that seems possible to do by inspecting the code and carefully thinking about it. I would be surprised if the existing implementation ever compares the same key to itself. One could also create their own sorted set implementation that has the first equal key in wins behavior and does not throw an exception if one tries to add a second equal key, but leaves the sorted-map unchanged, but it sounds like you want the exception if that is ever tried. Andy On Wed, Apr 22, 2015 at 2:39 AM, Henrik Heine h3nr1k.h3...@googlemail.com wrote: Hi, I'd like to build a sorted map that uses a user-supplied comparator using sorted-map-by. And I'd like to make sure, that one will never add a key already contained in the map. This is what I came up with: (defn compare-not-equal [x y] (let [r (compare x y)] (if-not (= 0 r) r (throw (RuntimeException. (str Key collision: x)) (into (sorted-map-by compare-not-equal) [[:foo 1] [:bar 2] [:bar 3]]) Adding [:bar 3] will fail, which is what I wanted. This implementation depends on sorted-set-by *NEVER* calling the comparator with [x x] for what ever reason it may do that. So my question is: is there a guarantee that sorted-map-by will never do that? Is there a better way to do what I'm trying to do? - Henrik -- 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: Explicitly document return values in some core.async functions?
core.async is still technically alpha, so everything is potentially subject to change. Rich H. wrote[1] most of those core.async functions, and he tends to treat the docstring as the only contract for future releases. If you want to be safe, make a unit test in your app that specifically tests any undocumented properties of public functions, so you can see if and when they change. [1]: https://github.com/clojure/core.async/blame/d8047c0b0ec13788c1092f579f03733ee635c493/src/main/clojure/clojure/core/async.clj#L455 –S On Wednesday, April 22, 2015 at 11:26:11 AM UTC+1, Stanislav Yurin wrote: Hello, There are functions like 'pipe' and 'tap' that are returning back receiving channel parameter, but this behavior is not explicitly documented. Should we rely on this feature or this may be changed in future? Thanks. Stanislav. -- 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: Too many words written on referential transparency in Clojure and Haskell
Andy Fingerhut andy.finger...@gmail.com writes: Dave, you say seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. I think I would instead say: seq *is* a pure function, even though it violates the property of x equals y implies f(x) equals f(y). There is nothing impure about the definition of seq on sets. I would say that it is the way equals is defined on hash sets, intentionally ignoring internal implementation details that are visible to seq, that leads to the violation of that property. I have updated my article with a Conclusion section since yesterday. I have copied it below for those that have already read the article and want to see only the new stuff: In hindsight after writing this, it now seems clear to me that if one wants to maintain the property x is equal to y implies f(x) is equal to f(y) for all functions f, then it is pretty important to be clear on what equal means. As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. another example is that in clojure '(2) is equal to [2] - and this is a good thing, but (conj '(2) 3) is not equal to (conj [2] 3). so I agree that the property x = y = f(x) = f(y) is not reasonable for normal equality. It could be for pure functions and identical? Example 3 highlights this point: one can create implementations of data structures using only pure functions, and a 'reasonable' definition of equality, where the property can be violated. The root of this issue is: sometimes reasonable definitions of equality regard two values as equal, intentionally ignoring internal implementation details of the data structure, but those differences ignored by equal can be made observable by other functions you implement on the data structure (like `seq` / `toList`). Andy On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann daves...@gmail.com wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq of a set is not itself a set and therefore is not subject to the same referential transparency rules as a set. Dave On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote: Thanks for sharing this. I found the write-up to be very informative and to have good background sources. I certainly never thought about this sneaky behavior concerning `seq` and hash sets before now. I'll have to look out for that one! On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut
Re: Too many words written on referential transparency in Clojure and Haskell
This is exactly one of the reasons a bunch of folk ( aka, purests maybe )
don't like that map/filter etc. in Clojure convert the input collection
into seqs, unlike Haskell or others where the those monad laws keep you in
check that map/filter return the *same* container - so mapping a set
would yield another set - also with no guaranteed order, and also with
uniqueness applied - so technically a map over a set may yield a collection
of an equal or smaller size, but never greater.
This seems to fuel a lot of debate when entered into - so I guess I'm
asking for trouble in replies here :)
Mark
I suppose Clojure 1.7 transducers can address this thought in a way.
e.g. (into #{} (map some-fn) some-set)
Doesn't expose any intermediate seq state of the collection.
--
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: Too many words written on referential transparency in Clojure and Haskell
Dave, you say seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. I think I would instead say: seq *is* a pure function, even though it violates the property of x equals y implies f(x) equals f(y). There is nothing impure about the definition of seq on sets. I would say that it is the way equals is defined on hash sets, intentionally ignoring internal implementation details that are visible to seq, that leads to the violation of that property. I have updated my article with a Conclusion section since yesterday. I have copied it below for those that have already read the article and want to see only the new stuff: In hindsight after writing this, it now seems clear to me that if one wants to maintain the property x is equal to y implies f(x) is equal to f(y) for all functions f, then it is pretty important to be clear on what equal means. As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. Example 3 highlights this point: one can create implementations of data structures using only pure functions, and a 'reasonable' definition of equality, where the property can be violated. The root of this issue is: sometimes reasonable definitions of equality regard two values as equal, intentionally ignoring internal implementation details of the data structure, but those differences ignored by equal can be made observable by other functions you implement on the data structure (like `seq` / `toList`). Andy On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann daves...@gmail.com wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq of a set is not itself a set and therefore is not subject to the same referential transparency rules as a set. Dave On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote: Thanks for sharing this. I found the write-up to be very informative and to have good background sources. I certainly never thought about this sneaky behavior concerning `seq` and hash sets before now. I'll have to look out for that one! On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote: I had come across the issue of Clojure hash sets that contain the same set of elements returning their elements in different orders from each other, depending upon which order they were added to the set (only if they have equal values for (hash x)). This and other questions on referential transparency on the Clojure group got me
Re: Too many words written on referential transparency in Clojure and Haskell
This. x = y = f(x) = f(y) obviously doesn't hold for arbitrary functions and arbitrary notions of equality (e.g. all sets that contain the same elements are equal, but the structures used to implement 'equal' sets need not be equal themselves). So if you then introduce a function that derives its result from the internal structure of the set - such as seq does - then you obviously break that property for your notion of 'set equality'. This doesn't mean the function isn't pure. It means your assumptions are wrong. If you want to guarantee a specific ordering then you have to use containers and/or algorithms that do actually guarantee a specific ordering. On Wednesday, April 22, 2015 at 9:53:47 AM UTC-4, Andy Fingerhut wrote: Dave, you say seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. I think I would instead say: seq *is* a pure function, even though it violates the property of x equals y implies f(x) equals f(y). There is nothing impure about the definition of seq on sets. I would say that it is the way equals is defined on hash sets, intentionally ignoring internal implementation details that are visible to seq, that leads to the violation of that property. I have updated my article with a Conclusion section since yesterday. I have copied it below for those that have already read the article and want to see only the new stuff: In hindsight after writing this, it now seems clear to me that if one wants to maintain the property x is equal to y implies f(x) is equalThis. to f(y) for all functions f, then it is pretty important to be clear on what equal means. As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. Example 3 highlights this point: one can create implementations of data structures using only pure functions, and a 'reasonable' definition of equality, where the property can be violated. The root of this issue is: sometimes reasonable definitions of equality regard two values as equal, intentionally ignoring internal implementation details of the data structure, but those differences ignored by equal can be made observable by other functions you implement on the data structure (like `seq` / `toList`). Andy On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann dave...@gmail.com javascript: wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq of a set is not
Re: Explicitly document return values in some core.async functions?
Thanks, this is perfectly reasonable! On Wednesday, April 22, 2015 at 4:35:17 PM UTC+3, Stuart Sierra wrote: core.async is still technically alpha, so everything is potentially subject to change. Rich H. wrote[1] most of those core.async functions, and he tends to treat the docstring as the only contract for future releases. If you want to be safe, make a unit test in your app that specifically tests any undocumented properties of public functions, so you can see if and when they change. [1]: https://github.com/clojure/core.async/blame/d8047c0b0ec13788c1092f579f03733ee635c493/src/main/clojure/clojure/core/async.clj#L455 –S On Wednesday, April 22, 2015 at 11:26:11 AM UTC+1, Stanislav Yurin wrote: Hello, There are functions like 'pipe' and 'tap' that are returning back receiving channel parameter, but this behavior is not explicitly documented. Should we rely on this feature or this may be changed in future? Thanks. Stanislav. -- 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: Too many words written on referential transparency in Clojure and Haskell
yes - ok - I agree with that. I don't see this as a problem with the definition of equality. D On Thursday, 23 April 2015 00:40:20 UTC+10, Hannes Steffenhagen wrote: This. x = y = f(x) = f(y) obviously doesn't hold for arbitrary functions and arbitrary notions of equality (e.g. all sets that contain the same elements are equal, but the structures used to implement 'equal' sets need not be equal themselves). So if you then introduce a function that derives its result from the internal structure of the set - such as seq does - then you obviously break that property for your notion of 'set equality'. This doesn't mean the function isn't pure. It means your assumptions are wrong. If you want to guarantee a specific ordering then you have to use containers and/or algorithms that do actually guarantee a specific ordering. On Wednesday, April 22, 2015 at 9:53:47 AM UTC-4, Andy Fingerhut wrote: Dave, you say seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. I think I would instead say: seq *is* a pure function, even though it violates the property of x equals y implies f(x) equals f(y). There is nothing impure about the definition of seq on sets. I would say that it is the way equals is defined on hash sets, intentionally ignoring internal implementation details that are visible to seq, that leads to the violation of that property. I have updated my article with a Conclusion section since yesterday. I have copied it below for those that have already read the article and want to see only the new stuff: In hindsight after writing this, it now seems clear to me that if one wants to maintain the property x is equal to y implies f(x) is equalThis. to f(y) for all functions f, then it is pretty important to be clear on what equal means. As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. Example 3 highlights this point: one can create implementations of data structures using only pure functions, and a 'reasonable' definition of equality, where the property can be violated. The root of this issue is: sometimes reasonable definitions of equality regard two values as equal, intentionally ignoring internal implementation details of the data structure, but those differences ignored by equal can be made observable by other functions you implement on the data structure (like `seq` / `toList`). Andy On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann dave...@gmail.com wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless
Re: Too many words written on referential transparency in Clojure and Haskell
Speaking of definitions of equality: Writing a university project jvm to llvm 'compiler', I found myself designing a type in Haskell whose Ord and Eq instances 'naturally' got defined in such a way that less than AND equal to made sense. I doubt anyone's sanity except mine survived the project. Joel On Wed, Apr 22, 2015 at 6:25 PM, Maik Schünemann maikschuenem...@gmail.com wrote: Andy Fingerhut andy.finger...@gmail.com writes: Dave, you say seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. I think I would instead say: seq *is* a pure function, even though it violates the property of x equals y implies f(x) equals f(y). There is nothing impure about the definition of seq on sets. I would say that it is the way equals is defined on hash sets, intentionally ignoring internal implementation details that are visible to seq, that leads to the violation of that property. I have updated my article with a Conclusion section since yesterday. I have copied it below for those that have already read the article and want to see only the new stuff: In hindsight after writing this, it now seems clear to me that if one wants to maintain the property x is equal to y implies f(x) is equal to f(y) for all functions f, then it is pretty important to be clear on what equal means. As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. another example is that in clojure '(2) is equal to [2] - and this is a good thing, but (conj '(2) 3) is not equal to (conj [2] 3). so I agree that the property x = y = f(x) = f(y) is not reasonable for normal equality. It could be for pure functions and identical? Example 3 highlights this point: one can create implementations of data structures using only pure functions, and a 'reasonable' definition of equality, where the property can be violated. The root of this issue is: sometimes reasonable definitions of equality regard two values as equal, intentionally ignoring internal implementation details of the data structure, but those differences ignored by equal can be made observable by other functions you implement on the data structure (like `seq` / `toList`). Andy On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann daves...@gmail.com wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq
Re: Too many words written on referential transparency in Clojure and Haskell
On Wed, Apr 22, 2015 at 9:25 AM, Maik Schünemann maikschuenem...@gmail.com wrote: Andy Fingerhut andy.finger...@gmail.com writes: As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. another example is that in clojure '(2) is equal to [2] - and this is a good thing, but (conj '(2) 3) is not equal to (conj [2] 3). That is Example 1 in the article [1], and the example I have seen brought up most often in this group over several years that violates the x=y implies f(x)=f(y) property. As stated there , it is a design choice to make clojure.core/= true between lists, vectors, lazy sequences, etc. (Alex Miller tells me the superset including all of these is seqables). I think it is a reasonable design choice. so I agree that the property x = y = f(x) = f(y) is not reasonable for normal equality. It could be for pure functions and identical? My own opinion: the property x=y implies f(x)=f(y) is a useful one, but there are cases where it is reasonable to write define = and write functions f that violate the property. For purposes like memoizing functions, it is pretty important to know whether the function you want to memoize violates it or not, and if so, in what precise way (because the way it violates it might be acceptable for your purposes). The property (identical? x y) implies (identical? (f x) (f y)) is not true for *many* Clojure functions, and identical? is not the way to go if what you care about are immutable values, not identities. Here is merely one of many examples: user= (def x (inc' Long/MAX_VALUE)) #'user/x user= (identical? x x) true user= (identical? (inc x) (inc x)) false Andy -- 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: Clojure web server capacity
Hey, I'm curious what you are trying to measure in regards to Clojure. As far as I know there is not a single Web Server actually written in Clojure, they are all written in Java and we just use them. The Compojure benchmark you linked uses the default Jetty Adapter for Ring (like Rack in Ruby land). http-kit is written in Java as well with only tiny bits of Clojure. So to answer your question: If I wanted to write something that satisfies your requirements (and only those) I would probably take something like undertow and just use that. See https://github.com/thheller/undertow-test https://github.com/thheller/undertow-test/blob/master/src/undertow_test/core.clj There are some tweaked settings in there which I used from the Java version of the techempower benchmark, I'm doubt they are ideal for your benchmark but I cannot run a test like you describe on my machine to find better parameters. OSX just runs out of sockets after a couple seconds. You'll need leiningen [1] to produce the uberjar. lein uberjar java -cp target/undertow-test-0.1.0-SNAPSHOT-standalone.jar clojure.main -m undertow-test.core localhost 5500 That launches a JVM with the example server bound to localhost:5500. I have not used undertow before myself and don't know about recommended GC parameters. The Clojure bits do very little and you are basically just testing undertow at this point so I'd imagine the performance to be identical to a similar pure Java version. I doubt that this is what you have in mind when trying to produce a Clojure benchmark but since all we Clojure-Folk do is built upon Java servers anyways and I wouldn't want to make it look bad by using things we don't really need (ring, compojure, etc ...). I don't use ring or compojure myself so I can't say how much overhead they would introduce. I'm happy to help if you have any Clojure related questions for your benchmark. If all you really want to test is the web server performance it probably doesn't make much sense to include Clojure since there are no Clojure web servers (AFAIK). HTH, /thomas [1] http://leiningen.org/ On Wednesday, April 22, 2015 at 3:05:29 PM UTC+2, Jesper Louis Andersen wrote: Hi, I'm trying to build up a different kind of web server framework benchmark, where measurement is not on peak performance, but on capacity and latency. That is, the numbers we keep stable are: * 10k connections * 30k req/s * 2053 bytes of static content served by a GET request on a simple route * Near perfect 1 gigabit connection between two machines * The test runs for 20 minutes. This is in contrast to many such measurements. The recent round 10 TechEmpower benchmark will for instance let connections vary, try to push as many req/s through and report the maximal number for a Hello World! message. So for one system, they will report the number for 1024 connections, whereas another system will have 4096 connections, whichever has the highest peak performance. This is a big no-no in my book. Furthermore, I'm questioning the correctness of their latency measurements because they report average latency and std. deviation without establishing that their distributions are normal. And they don't report the median latency so we can see they aren't. The thing I'm interested in is latency of the 30k req/s, run over a 20 minute period. That is, employing Gil Tene's HDRHistogram, we can accurately measure latencies for each request and make a distribution function plot of those latencies. I'm sitting with approximately 15 frameworks, spread out over multitiple languages. The numbers are vastly different from typical benchmarks and they are interesting to report. For Clojure, I started out with a simple adaptation of the Compojure benchmark from the TechEmpower-land. But it exhibits lots of queueing when trying to process requests simply due to maximizing the CPU cores of the System-under-test. My JVM-fu is quite weak, which is a big problem in these tests. I more or less need a setup, which has some kind of well-tunedness in advance, because I have little hope in achieving it myself on my own. It's somewhat like 10 years ago I last tuned GC on a JVM and I bet things change. Currently Clojure is in the ballpark of Python and Ruby in speed, which is so slow I'm going to argue that there is something wrong with my test implementation: http://imgur.com/wCFnFnd (X-axis are percentiles, note it's compression toward the 0th percentile. I'm interested in the upper percentiles) The graphs of Python, Ruby and Clojure/Compojure here are clear indicators that queueing/stalling is going on even at the very low percentiles. The solutions Go and Java/Undertow are in the graph for comparison with a couple of frameworks which does not exhibit queueing[0]. The highest scoring benchmark in the techempower rounds is a combination of Clojure and Resin (whatever resin is, I've not really
Re: Clojure web server capacity
On 23 April 2015 at 00:34, Paul deGrandis paul.degran...@gmail.com wrote: Also note that Compojure (and Ring) applications are artificially limiting, because they cannot utilize the containers' full capabilities (Ring apps can't go async at the container level, they can't use NIO responses, etc). Ring adapters do make use of blocking I/O, but the Ring core library can also be used with async applications. - James -- 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: Clojure web server capacity
Also note that Compojure (and Ring) applications are artificially limiting, because they cannot utilize the containers' full capabilities (Ring apps can't go async at the container level, they can't use NIO responses, etc). For these use-cases, you'll have to program directly to container itself, use Pedestal (limiting to the Servlet-only case), or use Aleph (rides on top of Netty). I'd also encourage you to reconsider your benchmark - ask yourself, What does this really tell me? Is the benchmark an accurate representation of the kinds of HTTP services you build? Are the payloads (parsing and generation) representative of common data you deal with in the systems you build? Is the network, topology, and traffic generation realistic (or at least analogous) to production systems? Can the results of the benchmark directly inform architectural considerations of real systems? Food for thought! Good luck! Cheers, Paul -- 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: Clojure web server capacity
You should check your sources. http-kit is not written in Clojure and does not use netty. On Wednesday, April 22, 2015 at 11:40:21 PM UTC+2, François Rey wrote: On 22/04/15 20:22, Thomas Heller wrote: As far as I know there is not a single Web Server actually written in Clojure, they are all written in Java and we just use them. http-kit http://www.http-kit.org/ would be one, although it's using netty http://netty.io/ which is a java io library. -- 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: Clojure web server capacity
On 22/04/15 20:22, Thomas Heller wrote: As far as I know there is not a single Web Server actually written in Clojure, they are all written in Java and we just use them. http-kit would be one, although it's using netty which is a java io library. -- 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: Clojure web server capacity
On 23/04/15 00:49, Thomas Heller wrote: You should check your sources. http-kit is not written in Clojure and does not use netty. You're right, I looked at it too quickly: the src directory is mostly java and the project.clj has a dev only dependency to netty. I always thought it was written in Clojure when I first heard about it, but in fact it's java for consumption in clojure. -- 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: ClojureScript 0.0-3211
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript Leiningen dependency information: [org.clojure/clojurescript 0.0-3211] This release is a bugfix release addressing some regressions as well as introducing some further REPL refinements. As usual feedback welcome! ## 0.0-3211 ### Changes * CLJS-1205: Conditional reading in REPLs * CLJS-1204: cljs.build.api/watch can now take compilation inputs * CLJS-1203: standard way to pass multiple directories to build ### Fixes * CLJS-1216: incorrect max fixed arity for fns both multi-arity and variadic * cljs.analyzer/parse-ns did not bind *cljs-file* * CLJS-1201: compare broken for IIndexed collections * CLJS-1202: cljs.repl/load-file is not additive * CLJS-1199: array-map should skip dropped elements of IndexedSeq * CLJS-1197: load-file does not reload associated macro namespace -- 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.
Clojure web server capacity
Hi,
I'm trying to build up a different kind of web server framework benchmark,
where measurement is not on peak performance, but on capacity and latency.
That is, the numbers we keep stable are:
* 10k connections
* 30k req/s
* 2053 bytes of static content served by a GET request on a simple route
* Near perfect 1 gigabit connection between two machines
* The test runs for 20 minutes.
This is in contrast to many such measurements. The recent round 10
TechEmpower benchmark will for instance let connections vary, try to push
as many req/s through and report the maximal number for a Hello World!
message. So for one system, they will report the number for 1024
connections, whereas another system will have 4096 connections, whichever
has the highest peak performance. This is a big no-no in my book.
Furthermore, I'm questioning the correctness of their latency measurements
because they report average latency and std. deviation without establishing
that their distributions are normal. And they don't report the median
latency so we can see they aren't.
The thing I'm interested in is latency of the 30k req/s, run over a 20
minute period. That is, employing Gil Tene's HDRHistogram, we can
accurately measure latencies for each request and make a distribution
function plot of those latencies. I'm sitting with approximately 15
frameworks, spread out over multitiple languages. The numbers are vastly
different from typical benchmarks and they are interesting to report.
For Clojure, I started out with a simple adaptation of the Compojure
benchmark from the TechEmpower-land. But it exhibits lots of queueing when
trying to process requests simply due to maximizing the CPU cores of the
System-under-test. My JVM-fu is quite weak, which is a big problem in these
tests. I more or less need a setup, which has some kind of well-tunedness
in advance, because I have little hope in achieving it myself on my own.
It's somewhat like 10 years ago I last tuned GC on a JVM and I bet things
change. Currently Clojure is in the ballpark of Python and Ruby in speed,
which is so slow I'm going to argue that there is something wrong with my
test implementation:
http://imgur.com/wCFnFnd
(X-axis are percentiles, note it's compression toward the 0th percentile.
I'm interested in the upper percentiles)
The graphs of Python, Ruby and Clojure/Compojure here are clear indicators
that queueing/stalling is going on even at the very low percentiles. The
solutions Go and Java/Undertow are in the graph for comparison with a
couple of frameworks which does not exhibit queueing[0].
The highest scoring benchmark in the techempower rounds is a combination of
Clojure and Resin (whatever resin is, I've not really dug too much into
it), but I'm told that http-kit may be a more viable route. Also, I might
be needing some underlying web server I guess, and what are good
suggestions there?.
So my question is this: If you were to write a webserver where curl
http://localhost:8080/ would return the first 2053 bytes of Alice in
Wonderland[1], what would you do? In particular if the above data is
known: capacity is 10k connections, rates are 30k req/s. Goal is
low-latency operation. As I said, the current numbers are just too far off,
but in contrast to Ruby/Python, I think Clojure might just be my bad
implementation of what is going on. That is, if you went tabula rasa on my
frankenstein monster, what would you do?
[0] What is not present on this graph is the bi-modal behavior of Go and
Undertow once GC kicks in, however.
[1] This is a grave mistake! It should have been Jabberwocky!
The techempower code is
here:
https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Clojure/compojure
and my field-surgery is below for hello.clj:
(ns hello.handler
(:import com.mchange.v2.c3p0.ComboPooledDataSource)
(:use compojure.core
ring.middleware.json
ring.util.response)
(:require [compojure.handler :as handler]
[compojure.route :as route]))
(def plaintext
Test 6: Plaintext
{:status 200
:headers {Content-Type text/plain; charset=utf-8}
:body CHAPTER I. Down the Rabbit-Hole Alice was beginning to get very
tired of sitting by her sister on the bank, and of having nothing to do:
once or twice she had peeped into the book her sister was reading, but it
had no pictures or conversations in it, and what is the use of a book,
thought Alice without pictures or conversations? So she was considering
in her own mind (as well as she could, for the hot day made her feel very
sleepy and stupid), whether the pleasure of making a daisy-chain would be
worth the trouble of getting up and picking the daisies, when suddenly a
White Rabbit with pink eyes ran close by her. There was nothing so very
remarkable in that; nor did Alice think it so very much out of the way to
hear the Rabbit say to itself, Oh dear! Oh dear! I shall be late! (when
she thought it over
Mastodon C is hiring a UI designer and developer
Hi all, We’re looking for a User Interface designer and developer to help us work on an upcoming project. Knowledge or interest in ClojureScript is a plus :) More details here: http://blog.mastodonc.com/2015/04/22/want-to-build-ui-in-clojurescript/ Cheers, Anna -- 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: Too many words written on referential transparency in Clojure and Haskell
x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com javascript: wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq of a set is not itself a set and therefore is not subject to the same referential transparency rules as a set. Dave On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote: Thanks for sharing this. I found the write-up to be very informative and to have good background sources. I certainly never thought about this sneaky behavior concerning `seq` and hash sets before now. I'll have to look out for that one! On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote: I had come across the issue of Clojure hash sets that contain the same set of elements returning their elements in different orders from each other, depending upon which order they were added to the set (only if they have equal values for (hash x)). This and other questions on referential transparency on the Clojure group got me thinking on my commutes about it some more, and I dug into it way more than I expected to, and wrote up an article on it. If you think such a topic would interest you, you can read more about it here: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md Guaranteed at least 99% epiphany free Andy -- 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
Explicitly document return values in some core.async functions?
Hello, There are functions like 'pipe' and 'tap' that are returning back receiving channel parameter, but this behavior is not explicitly documented. Should we rely on this feature or this may be changed in future? Thanks. Stanislav. -- 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.
[Q] Guarantees of sorted-map-by calling the comparator?
Hi, I'd like to build a sorted map that uses a user-supplied comparator using sorted-map-by. And I'd like to make sure, that one will never add a key already contained in the map. This is what I came up with: (defn compare-not-equal [x y] (let [r (compare x y)] (if-not (= 0 r) r (throw (RuntimeException. (str Key collision: x)) (into (sorted-map-by compare-not-equal) [[:foo 1] [:bar 2] [:bar 3]]) Adding [:bar 3] will fail, which is what I wanted. This implementation depends on sorted-set-by *NEVER* calling the comparator with [x x] for what ever reason it may do that. So my question is: is there a guarantee that sorted-map-by will never do that? Is there a better way to do what I'm trying to do? - Henrik -- 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: Too many words written on referential transparency in Clojure and Haskell
one thought - (set (seq a-set)) is pure even is (seq a-set) is not - because (set a-seq) throws away the (random) order information that was added. Dave On Wednesday, 22 April 2015 19:03:23 UTC+10, Mark Derricutt wrote: On 22 Apr 2015, at 20:22, Dave Sann wrote: for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. This is exactly one of the reasons a bunch of folk ( aka, purests maybe ) don't like that map/filter etc. in Clojure convert the input collection into seqs, unlike Haskell or others where the those monad laws keep you in check that map/filter return the *same* container - so mapping a set would yield another set - also with no guaranteed order, and also with uniqueness applied - so technically a map over a set may yield a collection of an equal or smaller size, but never greater. This seems to fuel a lot of debate when entered into - so I guess I'm asking for trouble in replies here :) Mark -- Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt -- 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: Too many words written on referential transparency in Clojure and Haskell
On 22 Apr 2015, at 20:22, Dave Sann wrote: for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. This is exactly one of the reasons a bunch of folk ( aka, purests maybe ) don't like that map/filter etc. in Clojure convert the input collection into seqs, unlike Haskell or others where the those monad laws keep you in check that map/filter return the _same_ container - so mapping a `set` would yield another `set` - also with no guaranteed order, and also with uniqueness applied - so technically a map over a set may yield a collection of an equal or smaller size, but never greater. This seems to fuel a lot of debate when entered into - so I guess I'm asking for trouble in replies here :) Mark -- Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt -- 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. signature.asc Description: OpenPGP digital signature
Re: Too many words written on referential transparency in Clojure and Haskell
On 22 April 2015 at 10:22, Dave Sann daves...@gmail.com wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you implicitly add new information - as (seq set) does - then they cannot be. Strachey's paper might be interesting reading on this: http://www.itu.dk/courses/BPRD/E2009/fundamental-1967.pdf /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- 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: [Q] Any Clojure code browsing and cross referencer?
That looks promising! 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: Generating .clj files with content
Thanks everyone for your help. The route that I choose to go is a mix of selmer for the predefined mostly static things and quoting with pprints code-dispatch. Very useful, didn't know that :-) Best Regards, Sven Am Donnerstag, 9. April 2015 21:45:41 UTC+2 schrieb Devin Walters (devn): To Leon's point above, that looks like: 12345678910111213 (require '[clojure.pprint :as pp]) (pp/with-pprint-dispatch pp/code-dispatch (pp/pprint (read-string (defn foo [xs] (apply str (reverse (str (apply + (for [y (filter (fn [x] (= x 1)) xs)] (inc y)) = nil (defn foo [xs] (apply str (reverse (str (apply + (for [y (filter (fn [x] (= x 1)) xs)] (inc y))) On Thu, Apr 9, 2015 at 2:34 PM, Leon Grapenthin grapent...@gmail.com javascript: wrote: You can use https://clojure.github.io/clojure/clojure.pprint-api.html#clojure.pprint/with-pprint-dispatch with https://clojure.github.io/clojure/clojure.pprint-api.html#clojure.pprint/code-dispatch to achieve that. On Wednesday, April 8, 2015 at 8:14:02 PM UTC+2, Sven Richter wrote: Hi, @Tassilo Thank you. Your example works nicely the way I imagined it. However, I want to generate human readable code and I want line breaks and nice formatting and things. I will also try a templating language. lein-template uses moustache or something. I will see how that works out. Thanks everyone for your suggestions, Sven Am Mittwoch, 8. April 2015 19:25:23 UTC+2 schrieb James Reeves: On 8 April 2015 at 14:20, Sven Richter sve...@googlemail.com wrote: I want to create clojure source files with some code and a namespace and everything else what is useful for some source code. What I am looking for is a templating language for clojure code, is there something like this already? What would be the most idiomatic way to do that besides just writing strings into a file? What's the purpose? If it's just to generate some Clojure code that will never be read by a human, then you can use Clojure's backtick syntax with the pr-str function. If it's to generate human-readable code, then you're probably best using a text templating language. You may also want to look at Leiningen templates or lein-generate. - James -- 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.
