Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
On Wednesday, July 3, 2013 2:06:34 AM UTC+2, Ben wrote: On Tue, Jul 2, 2013 at 4:33 PM, Dragan Djuric drag...@gmail.comjavascript: wrote: And in this case you have to explicitly specify which monad you want to use, every time you call bind. I understand that in some case it might be a preferred way, but in my opinion for most cases that I care about I prefer it the other way. No, you don't. You don't have to specify the monad you want to use until you actually want to use it: Unless you need to use two or more different monads in that function, in which case I don't see now would you do that at all. And, you have to structure the code a bit awkwardly for clojure, and have to say specifically, I want such and such monad type, and run it with a runner. I'm not saying that that is not good option. Clojure has its features and some compromise has to be made. I just prefer the sort of compromises I made for Fluokitten to the sorts of compromises made by other libraries. ; nREPL 0.1.7 user #Namespace monads.core monads.core (defn mc [x] (= (return x) (fn [a] (= (return (inc a)) (fn [b] (return (+ x (* 2 b #'monads.core/mc monads.core (def m* (mc 5)) #'monads.core/m* monads.core (require '[monads.identity :as i] '[monads.maybe :as m]) nil monads.core (run-monad i/m m*) 17 monads.core (run-monad m/m m*) #Just 17 monads.core m* is already defined in a completely agnostic way before it's run. I thought i had already demonstrated that in my previous email when I defined mc as (= (return 3) (f inc)), prior to interpreting it in the context of any particular monad. Regarding monadic laws, which one exactly demands that you cannot change the monad (not counting the fact that haskell's implementation does it that way)? Here are the laws, in Haskell: return a = k = k a m = return= m m = (\x - k x = h) = (m = k) = h It seems to me the laws are still satisfied if you keep changing monads in each bind (if compiler is not restricting it, as is the case with Haskell but not with Clojure). I suppose that may be right: you're supposed to verify that the laws obtain for a putative monad; they don't come for free just by calling something a monad. Allowing = to have the type m a - (a - n b) - n b just means that you can't verify that yours obeys the laws. If you get to choose the type of return, even the second one is up for grabs! It does seem somewhat odd to me to advertise the package as being familiar to Haskellers and to employ category-theoretic concepts and then to be so blasé about the definition of a monad. (I wonder if you can get away with this changing of type at all if you define bind in terms of fmap and join). Here is how the laws are specified (and tested) in Fluokitten (writing from the top of my head so please excuse me if I mess up something): (def return (pure [])) ;;This def is to make it more familiar for those who already read this tread, it is not actually in fluokitten tests. (def k (comp return foo bar baz)) ;; note the agnostic return. There are ways in Clojure to change what is it bound for, but I won't go into that here, It does not seem that important to me now. The point is, fluokitten supports it... (= (return a) k) = (k a) (= [1 2 3] return) = m (= [1 2 3] (fn [x] (bind (k x) h))) = (= m k h) So, if monad stays the same, everything is nice and tidy and close enough to Clojure and Haskell. Now, what would happen if monad changes after the bind? The first law does not constrain it The second does not too, since it says what happens when you bind with (pure m) not (pure n) The third, associativity, will also be satisfied Haskell compiler would complain wildly, but there is no Haskell compiler in my REPL :) Can I prove it? NO, I didn't try. As you say, most of the time you will work in the same monad. Since Clojure is dynamic, the programmer is expected to take an extra care and test that everything works as expected. But, it seems to me that, even if the monad change, (in most cases?) it will still work... On Wednesday, July 3, 2013 1:19:10 AM UTC+2, Ben wrote: IMO you *always* want the monad to stay the same---the laws describing monadic computations don't account for swapping the things out midstream, at any rate. And it pays to be able to define monadic computations without having to explicitly pass around a token to serve as the current monad. FWIW, you *can* directly translate that function into clojure: monads.core (defn f [g] (comp return g g)) #'monads.core/f monads.core (require '[monads.state :as st]) nil monads.core (st/run-state (= get-state (f inc)) 5) #Pair [7 5] monads.core (require '[monads.list :as l]) nil monads.core (require '[monads.maybe :as m]) nil monads.core (def mc (= (return 3) (f inc)))
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
The specific bind implementations always get the instance of the Monad protocol the bind was called with (since it is a part of an implementation of the Monad protocol), so you use that instance as a first argument to pure. Of course, if you call bind with a function that does not make sense in a context, you'll get a runtime exception, like in the rest of Clojure. Clojure is not strongly typed, so it puts some expectations on the programmer. I am not trying to fix Clojure. Thank you for some very thoughtful comments. If you are interested, we can try to write a bit more detailed comparisons of the approaches in both libraries. On Wednesday, July 3, 2013 2:21:29 AM UTC+2, Ben wrote: On Tue, Jul 2, 2013 at 5:06 PM, Ben Wolfson wol...@gmail.comjavascript: wrote: On Tue, Jul 2, 2013 at 4:33 PM, Dragan Djuric drag...@gmail.comjavascript: wrote: Regarding monadic laws, which one exactly demands that you cannot change the monad (not counting the fact that haskell's implementation does it that way)? Here are the laws, in Haskell: return a = k = k a m = return= m m = (\x - k x = h) = (m = k) = h It seems to me the laws are still satisfied if you keep changing monads in each bind (if compiler is not restricting it, as is the case with Haskell but not with Clojure). I suppose that may be right: you're supposed to verify that the laws obtain for a putative monad; they don't come for free just by calling something a monad. Allowing = to have the type m a - (a - n b) - n b just means that you can't verify that yours obeys the laws. If you get to choose the type of return, even the second one is up for grabs! It does seem somewhat odd to me to advertise the package as being familiar to Haskellers and to employ category-theoretic concepts and then to be so blasé about the definition of a monad. (I wonder if you can get away with this changing of type at all if you define bind in terms of fmap and join). How are you even supposed to implement bind, in fact? (Never mind reasoning about what's going on in your program if you can't be certain that the code won't switch out the monad you think you're working in, when it does matter to you that you're in a specific one.) Generally for some specific monad you need to do something specific with the return of f. For instance, your seq-bind is implemented in terms of mapcat---meaning that the f that's the second argument of mapcat had better return a seqable. This doesn't work: (mapcat (comp atom inc) '(1 2 3)). -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] clojure-sql 0.1.0: relational algebra in clojure
Hey guys! I've been working on a small library to make writing SQL queries a little bit easier. It's along the same lines as ClojureQL, but takes a different approach and compiles into quite different SQL in the end. At the moment it's quite immature, but it should be able to support any queries which can be expressed in relational algebra. There will be some SQL queries which can't be expressed in clojure-sql, but hopefully there won't be too many of those. A greater limitation is that at the moment the SQL generation is specific to the PostgresSQL database (although any contributions for other databases are welcome!). Dependency vector: [clojure-sql 0.1.0] Repository: https://bitbucket.org/czan/clojure-sql Clojars link: https://clojars.org/clojure-sql Let me know what you think! Carlo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
How to implement a distributed and concurrent system in Clojure?
Hi, I read recently on the internet that Clojure concurrency tools make it easy to implement a highly concurrent system but on a single machine. But how to implement a highly concurrent system that runs on a multiple machines? Erlang, Elixir and Scala have the Actors model. Please correct me if I'm wrong. Thanks for help and time. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure generates unnecessary and slow type-checks
After following Jason's suggestion to use BigInteger and .multiply instead of BigInt and * I too am getting speed on par with Java (108-109 miroseconds on my RPI). Therefore, I consider this issue closed :) @Stuart thanks for running the benchmark yourself...maybe I could have save you some time if I had posted my new results late last night...I was about to conclude that 'nothing beats a for-loop' but it seems that loop/recur is equally fast. Jim On 03/07/13 01:33, Stuart Sierra wrote: Hi Jim, I cannot reproduce your results. I see Clojure and Java with similar performance when they are both using java.lang.BigInteger. Clojure's arbitrary-precision integer defaults to clojure.lang.BigInt, which in my test is about 12% slower than java.lang.BigInteger. See https://gist.github.com/stuartsierra/5914513 for my code and results. I did not use Criterium or Leiningen to run the benchmark. -S On Tue, Jul 2, 2013 at 2:05 PM, Jim - FooBar(); jimpil1...@gmail.com mailto:jimpil1...@gmail.com wrote: I'm really sorry for coming back to this but even after everything we learned I'm still not able to get performance equal to java in a simple factorial benchmark. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Build fails with any IBM JDK above 6.0.x
Hello Andy, Thanks for getting back to me. The problem is that I specifically need to build Clojure 1.1 which doesn't seem to have the io.clj in neither clojure nor clojure-contrib. Disabling the JIT compiler (-Xnojit to JVM Arguments), I was able to build both successfully with IBM JDK 1.6.+. However, My problem is that even after I was able to build successfully, I am still getting the same exception I used to get from building the Clojure library on my application so it was a temporary victory at best. Please let me know your thoughts on that. Is there a way to build with IBM JDK 1.6+ without disabling the Just In Time compiler? Is there another fix specific to Clojure 1.1? Your help is most appreciated. Sherif M Ali On Monday, July 1, 2013 5:59:45 PM UTC+2, Andy Fingerhut wrote: Sherif: The last time I tried a few months ago, Clojure 1.5.1 plus the patch clj-967-disable-failing-io-copy-tests-on-ibm-jdk-16-patch1.txt built and passed all tests with IBM JDK 1.6. http://dev.clojure.org/jira/browse/CLJ-967 The main change in that patch is to disable a couple of unit tests for clojure.java.io/copy that work on other JDKs but fail with IBM JDK 1.6, related to how it handles UTF-16 encoding a bit differently. Let me know if that works for you. Andy On Sun, Jun 30, 2013 at 10:22 AM, Sherif Ali alys...@gmail.comjavascript: wrote: Hello all, I am having a problem building any Clojure version (1.1, 1.2, 1.3, 1.5) with any IBM JDK over 6.0.x. My main interest is for version 1.1 but I will take anything above as well. Is there a fix, certain setup, configuration, pre-built version, etc. that can get me running on IBM JDK 626 or above. Kindly take into consideration that if this is not possible then Clojure can't run on WebSphere Application Server 8.0 or above. Just to put your mind to ease, I was able to build all these version with SUN JDK normally. Your help is greatly appreciated. Thanks in advance. Sherif M Ali -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal 0.1.9 has been released
Brenton has been working hard at preparing a full tutorial of pedestal-app. We're expecting to release that in just under a month or so. Great news! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal 0.1.9 has been released
It's so close I can almost taste it. Most Relevance Pedestallions are going to be doing what I think is a final review on Friday. I really think you folks are going to enjoy it. -- Ryan Neufeld On Jul 3, 2013, at 6:47 AM, Leon Talbot leontal...@gmail.com wrote: Brenton has been working hard at preparing a full tutorial of pedestal-app. We're expecting to release that in just under a month or so. Great news! -- -- 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/gHAxWvNleGg/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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal 0.1.9 has been released
Looking forward to an elaborate docs/video tuts on pedestal. Cheers On Wed, Jul 3, 2013 at 4:38 PM, Ryan Neufeld r...@thinkrelevance.comwrote: It's so close I can almost taste it. Most Relevance Pedestallions are going to be doing what I think is a final review on Friday. I really think you folks are going to enjoy it. -- Ryan Neufeld On Jul 3, 2013, at 6:47 AM, Leon Talbot leontal...@gmail.com wrote: Brenton has been working hard at preparing a full tutorial of pedestal-app. We're expecting to release that in just under a month or so. Great news! -- -- 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/gHAxWvNleGg/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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Regards, Mayank. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal 0.1.9 has been released
Docs first, videos in a bit. I don't want this to be like that Christmas where you thought you were going to get *all* the presents and you were all disappointed but had to put on a brave face to seem like you still appreciated it. -- Ryan Neufeld On Jul 3, 2013, at 7:20 AM, Mayank Jain firesof...@gmail.com wrote: Looking forward to an elaborate docs/video tuts on pedestal. Cheers On Wed, Jul 3, 2013 at 4:38 PM, Ryan Neufeld r...@thinkrelevance.com wrote: It's so close I can almost taste it. Most Relevance Pedestallions are going to be doing what I think is a final review on Friday. I really think you folks are going to enjoy it. -- Ryan Neufeld On Jul 3, 2013, at 6:47 AM, Leon Talbot leontal...@gmail.com wrote: Brenton has been working hard at preparing a full tutorial of pedestal-app. We're expecting to release that in just under a month or so. Great news! -- -- 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/gHAxWvNleGg/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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Regards, Mayank. -- -- 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/gHAxWvNleGg/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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
This looks fantastic. I probably won't be able to resist to type check it with core.typed at some point. And enough documentation to satisfy Michael Klishin? I'm impressed :) Thanks, Ambrose On Wed, Jul 3, 2013 at 2:07 AM, Dragan Djuric draga...@gmail.com wrote: I am pleased to announce a first public release of new (and different) monads and friends library for Clojure. Extensive *documentation* is at http://fluokitten.uncomplicate.org Fluokitten is a Clojure library that implements category theory concepts, such as functors, applicative functors, monads, monoids etc. in idiomatic Clojure. Main project goals are: - Fit well into idiomatic Clojure - Clojure programmers should be able to use and understand Fluokitten like any regular Clojure library. - Fit well into Haskell monadic types conventions - programmers should be able to reuse existing widespread monadic programming know-how and easily translate it to Clojure code. - Be reasonably easy to learn - the code from the existing books, articles and tutorials for learning monadic programming, which is usually written in Haskell should be easily translatable to Clojure with Fluokitten. - Offer good performance. Please give us your feedback, and we would also love if anyone is willing to help, regardless of previous experience, so please *get involved*. There are lots of things to be improved: - If you are a native English speaker, i would really appreciate if you can help with correcting the English on the Fluokitten site and in the documentation. - Contribute your example code (your own or the ports from Haskell tutorials) to be added to Fluokitten tests. - Contribute articles and tutorials. - Do code review of the Fluokitten code and suggest improvements. - If you find bugs, report them via Fluokitten issue tracker. - If you have any additional suggestion, contact us here: http://fluokitten.uncomplicate.org/articles/community.html -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal 0.1.9 has been released
Sure :) On Wed, Jul 3, 2013 at 4:55 PM, Ryan Neufeld r...@thinkrelevance.comwrote: Docs first, videos in a bit. I don't want this to be like that Christmas where you thought you were going to get *all* the presents and you were all disappointed but had to put on a brave face to seem like you still appreciated it. -- Ryan Neufeld On Jul 3, 2013, at 7:20 AM, Mayank Jain firesof...@gmail.com wrote: Looking forward to an elaborate docs/video tuts on pedestal. Cheers On Wed, Jul 3, 2013 at 4:38 PM, Ryan Neufeld r...@thinkrelevance.comwrote: It's so close I can almost taste it. Most Relevance Pedestallions are going to be doing what I think is a final review on Friday. I really think you folks are going to enjoy it. -- Ryan Neufeld On Jul 3, 2013, at 6:47 AM, Leon Talbot leontal...@gmail.com wrote: Brenton has been working hard at preparing a full tutorial of pedestal-app. We're expecting to release that in just under a month or so. Great news! -- -- 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/gHAxWvNleGg/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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Regards, Mayank. -- -- 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/gHAxWvNleGg/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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Regards, Mayank. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
I probably won't be able to resist to type check it with core.typed at some point. If you contribute that, or help me baking in (some) non-invasive type checking into Fluokitten, that would be FANTASTIC! I have that in vague long-term plans, but I haven't had time to look at core.typed (I only skimmed through the homepage when it was released). And enough documentation to satisfy Michael Klishin? I'm impressed :) Thanks :) Actually, one of the main project goals is to make monads (et al) approachable for beginners, and for that, docs and tutorials are the main thing. So, this library really does not make much sense without lots of documentation. I hope to even improve it on that point. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
On Wed, Jul 3, 2013 at 7:50 PM, Dragan Djuric draga...@gmail.com wrote: I probably won't be able to resist to type check it with core.typed at some point. If you contribute that, or help me baking in (some) non-invasive type checking into Fluokitten, that would be FANTASTIC! I have that in vague long-term plans, but I haven't had time to look at core.typed (I only skimmed through the homepage when it was released). I'm very glad you're interested! Skimming your code, you use conj a lot (via into). I'm actually working on an accurate and extensible type for conj type right now. The code looks very pure and accommodating for type checking. And enough documentation to satisfy Michael Klishin? I'm impressed :) Thanks :) Actually, one of the main project goals is to make monads (et al) approachable for beginners, and for that, docs and tutorials are the main thing. So, this library really does not make much sense without lots of documentation. I hope to even improve it on that point. Thought: Whether type signatures help for beginners here is debatable. It probably makes some parts clearer, and some parts incomprehensible. Anyway, I'll be in touch, congratulations again :) Ambrose -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
2013/7/3 Dragan Djuric draga...@gmail.com one of the main project goals is to make monads (et al) approachable for beginners, and for that, docs and tutorials are the main thing. So, this library really does not make much sense without lots of documentation. I hope to even improve it on that point. Dragan, That's a worthy goal. I tried to find the doc site source on github but couldn't. Is it open source? I think making it open source under a liberal license with a straightforward contribution policy is a good idea. Others will be able to help (as you know, everybody and their grandma in the FP community has an opinion on monads et al.) Thanks! -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
Michael, The site source is in the gh-pages branch in the main source repository on github: https://github.com/uncomplicate/fluokitten/tree/gh-pages On Wednesday, July 3, 2013 2:19:07 PM UTC+2, Michael Klishin wrote: 2013/7/3 Dragan Djuric drag...@gmail.com javascript: one of the main project goals is to make monads (et al) approachable for beginners, and for that, docs and tutorials are the main thing. So, this library really does not make much sense without lots of documentation. I hope to even improve it on that point. Dragan, That's a worthy goal. I tried to find the doc site source on github but couldn't. Is it open source? I think making it open source under a liberal license with a straightforward contribution policy is a good idea. Others will be able to help (as you know, everybody and their grandma in the FP community has an opinion on monads et al.) Thanks! -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
2013/7/3 Dragan Djuric draga...@gmail.com The site source is in the gh-pages branch in the main source repository on github: https://github.com/uncomplicate/fluokitten/tree/gh-pages It's worth mentioning somewhere. ClojureWerkz projects link to doc source at the top of every guide, adding a README link is fine, too. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to implement a distributed and concurrent system in Clojure?
I'd like to hear others opinions on this too. I don't believe Clojure has anything built in at this point. My plan of action (not yet implemented) is to use gearman(possibly java, but it seems that it is no longer updated) and zeroconf for clusters (just for automatic master determination). I know there is support for Hadoop in Clojure as well, which does not fit my needs but may fit your needs. A quick google search will get you started. Immutant has support for clustering too, but I believe it requires leiningen to start, where I need to compile everything into a single jar. Immutant under the hood is using JBoss' message queue, so that may be an option to explore as well. I'm curious what others are doing. Best., --Joseph On Wednesday, July 3, 2013 4:26:53 AM UTC-5, Hussein B. wrote: Hi, I read recently on the internet that Clojure concurrency tools make it easy to implement a highly concurrent system but on a single machine. But how to implement a highly concurrent system that runs on a multiple machines? Erlang, Elixir and Scala have the Actors model. Please correct me if I'm wrong. Thanks for help and time. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
On Wed, Jul 3, 2013 at 12:32 AM, Dragan Djuric draga...@gmail.com wrote: On Wednesday, July 3, 2013 2:06:34 AM UTC+2, Ben wrote: On Tue, Jul 2, 2013 at 4:33 PM, Dragan Djuric drag...@gmail.com wrote: And in this case you have to explicitly specify which monad you want to use, every time you call bind. I understand that in some case it might be a preferred way, but in my opinion for most cases that I care about I prefer it the other way. No, you don't. You don't have to specify the monad you want to use until you actually want to use it: Unless you need to use two or more different monads in that function, in which case I don't see now would you do that at all. And, you have to structure the code a bit awkwardly for clojure, and have to say specifically, I want such and such monad type, and run it with a runner. I'm not saying that that is not good option. Clojure has its features and some compromise has to be made. I just prefer the sort of compromises I made for Fluokitten to the sorts of compromises made by other libraries. Well, my *very first* message demonstrated how to do that in a generic way. (defn tst-reader [f] (mdo env - ask v - (lift (f env)) (return (println here I am)) (return v))) You use more than one monad here in the same way you do it in Haskell: using a monad transformer, lifting from one to the other. Here you can do it without specifying *either* layer of the stack (as long as the first supports ask). You *never* have to say I want such and such monad type while you're writing the function, until you actually run it, and the same computation can be run with multiple different types (again, my first message demonstrated this, embedding arbitrary different effects including early exit and mutable state into that function without modifying it at all). As far as I can tell, with Fluokitten you *always* do. I suppose that may be right: you're supposed to verify that the laws obtain for a putative monad; they don't come for free just by calling something a monad. Allowing = to have the type m a - (a - n b) - n b just means that you can't verify that yours obeys the laws. If you get to choose the type of return, even the second one is up for grabs! It does seem somewhat odd to me to advertise the package as being familiar to Haskellers and to employ category-theoretic concepts and then to be so blasé about the definition of a monad. (I wonder if you can get away with this changing of type at all if you define bind in terms of fmap and join). Here is how the laws are specified (and tested) in Fluokitten (writing from the top of my head so please excuse me if I mess up something): (def return (pure [])) ;;This def is to make it more familiar for those who already read this tread, it is not actually in fluokitten tests. (def k (comp return foo bar baz)) ;; note the agnostic return. There are ways in Clojure to change what is it bound for, but I won't go into that here, It does not seem that important to me now. The point is, fluokitten supports it... That is not an agnostic return: it works only for vectors. You could change what it's bound for with, I suppose, with-redefs? (= (return a) k) = (k a) (= [1 2 3] return) = m (= [1 2 3] (fn [x] (bind (k x) h))) = (= m k h) So, if monad stays the same, everything is nice and tidy and close enough to Clojure and Haskell. Now, what would happen if monad changes after the bind? The first law does not constrain it The second does not too, since it says what happens when you bind with (pure m) not (pure n) The third, associativity, will also be satisfied Really? Let's find out! uncomplicate.fluokitten.core (def return (pure [])) #'uncomplicate.fluokitten.core/return uncomplicate.fluokitten.core (def k (comp return inc (partial * 2))) uncomplicate.fluokitten.core (= (= [1 2 3] k) (fn [x] (atom (inc x IllegalArgumentException Don't know how to create ISeq from: clojure.lang.Atom clojure.lang.RT.seqFrom (RT.java:505) uncomplicate.fluokitten.core (= [1 2 3] (fn [x] (= (k x) (fn [y] (atom (inc y)) IllegalArgumentException Don't know how to create ISeq from: clojure.lang.Atom clojure.lang.RT.seqFrom (RT.java:505) I guess you're right: they are the same. However, I think this, regarding the second law, is telling: The second does not too, since it says what happens when you bind with (pure m) not (pure n) *all* the laws only say what happen when you stay within the same monad, because the types the laws give to = and return *require* that. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
On Wed, Jul 3, 2013 at 7:07 AM, Ben Wolfson wolf...@gmail.com wrote: However, I think this, regarding the second law, is telling: The second does not too, since it says what happens when you bind with (pure m) not (pure n) *all* the laws only say what happen when you stay within the same monad, because the types the laws give to = and return *require* that. Addendum, if you're going to say that the various monad laws don't apply because the types differ, then you are, whether you like it or not, not talking about monads; monads are what the laws describe. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to implement a distributed and concurrent system in Clojure?
clj-zookeeper + avout. We run our solution on clusters of small nodes, we needed a lightweight solution. We implemented cluster queues and use avout locking. Our configuration is also stored in zookeeper as clojure expressions. We isolated this in a coordinator module so nothing spills out in the rest of the code. We could swap this for another alternative with minimal headaches but so far it scales pretty well. For inter cluster exchanges we are using zeromq but we do not need the same tight intra cluster integration. Luc P. I'd like to hear others opinions on this too. I don't believe Clojure has anything built in at this point. My plan of action (not yet implemented) is to use gearman(possibly java, but it seems that it is no longer updated) and zeroconf for clusters (just for automatic master determination). I know there is support for Hadoop in Clojure as well, which does not fit my needs but may fit your needs. A quick google search will get you started. Immutant has support for clustering too, but I believe it requires leiningen to start, where I need to compile everything into a single jar. Immutant under the hood is using JBoss' message queue, so that may be an option to explore as well. I'm curious what others are doing. Best., --Joseph On Wednesday, July 3, 2013 4:26:53 AM UTC-5, Hussein B. wrote: Hi, I read recently on the internet that Clojure concurrency tools make it easy to implement a highly concurrent system but on a single machine. But how to implement a highly concurrent system that runs on a multiple machines? Erlang, Elixir and Scala have the Actors model. Please correct me if I'm wrong. Thanks for help and time. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
Monads as a Haskell construct is what the previously mentioned laws describe. Monads in category theory are defined in a category X as a triple (T, n, m) where T is a functor and m and n certan natural transformations such that certan diagrams commute. In that sense, I am not sure that even Haskell's implementation is perfectly clean. There's a lot of nitpicking to be done, but, that's not the point, and we are digressing a bit. The point is that in Fluokitten, you are expected to work within the certain monad as you agree, and since there is no type checking on the value that a function returns, it is the responsibility of the developer to make sure that it makes sense as in Clojure generally. It is fairly easy to do by passing a parameter to f that pure can use, if f implementation needs to be agnostic to the actual monad that it will be called from. There are other approaches, so the programmer can make a choice that is the best fit for the problem at hand. Even in the example that you gave from your library, what stops the programmer to shoot himself in the foot by doing basically the same thing that we are talking about here: (defn f [g] (comp atom g g)) (require '[monads.maybe :as m]) (def mc (= (return 3) (f inc))) (run-monad m/m mc) What is the result if f is broken (in the context of the monad m/m in this case)? I didn't try it, so I may be wrong, but I doubt that the Clojure compiler complains about that one. On Wednesday, July 3, 2013 4:11:31 PM UTC+2, Ben wrote: On Wed, Jul 3, 2013 at 7:07 AM, Ben Wolfson wol...@gmail.comjavascript: wrote: However, I think this, regarding the second law, is telling: The second does not too, since it says what happens when you bind with (pure m) not (pure n) *all* the laws only say what happen when you stay within the same monad, because the types the laws give to = and return *require* that. Addendum, if you're going to say that the various monad laws don't apply because the types differ, then you are, whether you like it or not, not talking about monads; monads are what the laws describe. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] lein-spell: Spell check your clojure docstrings and library docs
That's really nice. It would be good to have an option to *not* pick up parameter names; I often refer to these in doc strings, and they are not always spelling mistakes. Phil Gabriel Horner gabriel.hor...@gmail.com writes: Introducing lein-spell, https://github.com/cldwalker/lein-spell - a library to quickly and easily spell check your clojure libraries. Usage - lein-spell prints misspelled words, one per line to STDOUT. By default your library's docstrings and markdown/txt docs are searched: $ lein-spell associtaed bugfix communitcated ... You can also check individual files: $ lein-spell doc/my-tutorial.org Until lein-spell's dictionary is good enough, there will be false positives. Add those to your local whitelist in .lein-spell. In the example above, bugfix would be a false positive. Once you're ready to edit your typos, you can see their locations with: $ lein spell -n ./README.md:25:associtaed src/my/lib.clj:44:communitcated This format is compatible with vim's grep so you can easily navigate your typos $ vim -c 'set grepprg=lein\ spell\ -n' -c 'botright copen' -c 'silent! grep' Install - Install aspell: # For mac osx $ brew install aspell # For ubuntu/debian $ apt-get install aspell Add to your project's :plugins key: [lein-spell 0.1.0] For more info, see the readme, https://github.com/cldwalker/lein-spell#readme Feedback welcome, Gabriel -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
I've never really used monads or monoids, but one thing that does confuse me is how come there are so may libraries for supporting them. I've been reading the documentation of morph (https://github.com/blancas/morph) recently, which is the first one I've understood. A quick look at fluokitten suggests that the doc is good also! What I've not yet understood is what the difference is between all of these libraries? Phil Dragan Djuric draga...@gmail.com writes: I am pleased to announce a first public release of new (and different) monads and friends library for Clojure. Extensive *documentation* is at http://fluokitten.uncomplicate.org Fluokitten is a Clojure library that implements category theory concepts, such as functors, applicative functors, monads, monoids etc. in idiomatic Clojure. Main project goals are: - Fit well into idiomatic Clojure - Clojure programmers should be able to use and understand Fluokitten like any regular Clojure library. - Fit well into Haskell monadic types conventions - programmers should be able to reuse existing widespread monadic programming know-how and easily translate it to Clojure code. - Be reasonably easy to learn - the code from the existing books, articles and tutorials for learning monadic programming, which is usually written in Haskell should be easily translatable to Clojure with Fluokitten. - Offer good performance. Please give us your feedback, and we would also love if anyone is willing to help, regardless of previous experience, so please *get involved*. There are lots of things to be improved: - If you are a native English speaker, i would really appreciate if you can help with correcting the English on the Fluokitten site and in the documentation. - Contribute your example code (your own or the ports from Haskell tutorials) to be added to Fluokitten tests. - Contribute articles and tutorials. - Do code review of the Fluokitten code and suggest improvements. - If you find bugs, report them via Fluokitten issue tracker. - If you have any additional suggestion, contact us here: http://fluokitten.uncomplicate.org/articles/community.html -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
If Clojure has all of the Haskell's type features, I guess there would be only one Clojure monad library, more or less a direct port of Haskell's. As Clojure is different, there are different ways to approach monads from neither of which can be the same as Haskell's, each having its pros and cons, so there are many libraries. Additional motivation in my case is that the other libraries (except morph, which is also a newcomer) were poorly documented or not documented at all, and that even simple examples from Haskell literature were not simple at all in those libraries, and in many cases, not even supported (many of them don't even define functors and monoids, let alone applicative functors). What I've not yet understood is what the difference is between all of these libraries? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal 0.1.9 has been released
I'm sure I will :) In the meantime, I'll dive in the Application Overview section to wrap my head around all the moving parts. Loving it so far! Nice job. Il giorno mercoledì 3 luglio 2013 13:08:11 UTC+2, Ryan Neufeld ha scritto: It's so close I can almost taste it. Most Relevance Pedestallions are going to be doing what I think is a final review on Friday. I really think you folks are going to enjoy it. -- Ryan Neufeld On Jul 3, 2013, at 6:47 AM, Leon Talbot leont...@gmail.com javascript: wrote: Brenton has been working hard at preparing a full tutorial of pedestal-app. We're expecting to release that in just under a month or so. Great news! -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/gHAxWvNleGg/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
Hi, Am Mittwoch, 3. Juli 2013 16:49:43 UTC+2 schrieb Dragan Djuric: Monads as a Haskell construct is what the previously mentioned laws describe. Monads in category theory are defined in a category X as a triple (T, n, m) where T is a functor and m and n certan natural transformations such that certan diagrams commute. In that sense, I am not sure that even Haskell's implementation is perfectly clean. in category theory, monads are functors with additional constraints. Haskell's implementation is clean to the extend that Hask, i.e Haskell types and morphisms between them, form a category (there are some issues with laziness). The connection to the categorical definition is most easily seen if you define monads using join instead of = (bind). You basically need a functor, i.e. a type constructor with a proper fmap (check the laws here as well), and two natural transformations mu, eta. As it turns out, polymorphic functions are natural transformations in Haskell's category, i.e. they always obey the required laws, no need to check them. Let's call your functor type t, then mu and eta have the following types: mu :: a - t a -- Haskell's return eta :: t (t a) - t a -- Haskell's join The required laws now state that: eta (eta mm) = eta (fmap eta mm) eta (mu m) = eta (fmap mu m)= identity which just says that if you have something of type t (t (t a)) it does not matter whether you flatten it from the inside or outside first and if you have something of type t a, you can put it into another t from the outside or inside and flatten it to get back the identity. Now, conceptually changing the monad does not make much sense. Remember that a monad is a functor with additional structure, so we are always working in the same functor! The laws just express that we have a special functor which obeys additional properties, besides the functorial ones. Also generalizing the types of (=) to support different monads is forbidden by the laws. Try to define myBind :: (Monad m, Monad n) = m a - (a - n b) - n b-- like (=), but changes the monad and now look at the second law: x = return = x or written with explicit types: ((x :: m a) = (return :: a - m a)) :: m a = x :: m a ((x :: m a) `myBind` (return :: a - n a)) :: n a but this cannot equal (x :: m a), since it does not even have the same type! Best, Nils -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] lein-spell: Spell check your clojure docstrings and library docs
Yep. I hadn't got around to that but it's definitely possible with :arglists I've added a ticket to track it if anyone gets to it before I do - https://github.com/cldwalker/lein-spell/issues/4 On Wed, Jul 3, 2013 at 10:51 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: That's really nice. It would be good to have an option to *not* pick up parameter names; I often refer to these in doc strings, and they are not always spelling mistakes. Phil Gabriel Horner gabriel.hor...@gmail.com writes: Introducing lein-spell, https://github.com/cldwalker/lein-spell - a library to quickly and easily spell check your clojure libraries. Usage - lein-spell prints misspelled words, one per line to STDOUT. By default your library's docstrings and markdown/txt docs are searched: $ lein-spell associtaed bugfix communitcated ... You can also check individual files: $ lein-spell doc/my-tutorial.org Until lein-spell's dictionary is good enough, there will be false positives. Add those to your local whitelist in .lein-spell. In the example above, bugfix would be a false positive. Once you're ready to edit your typos, you can see their locations with: $ lein spell -n ./README.md:25:associtaed src/my/lib.clj:44:communitcated This format is compatible with vim's grep so you can easily navigate your typos $ vim -c 'set grepprg=lein\ spell\ -n' -c 'botright copen' -c 'silent! grep' Install - Install aspell: # For mac osx $ brew install aspell # For ubuntu/debian $ apt-get install aspell Add to your project's :plugins key: [lein-spell 0.1.0] For more info, see the readme, https://github.com/cldwalker/lein-spell#readme Feedback welcome, Gabriel -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- 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/hC98dzsWgS0/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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
Yes, I agree completely, when we stay inside Haskell. However, Clojure is dynamic. Here are two objects that are equal despite having different types: Consider this case: (= [1] (list 1)) ;= true (isa? (type [1]) (list 1)) ;= false In fact, equality in Java (and Clojure) depends on the implementation of equals and hashCode, so, as in the previous example, it is possible that two things are equal while having different type. I know, these are special cases, but a library that wants to be idiomatic has to support even those special cases that are common in a language. So, a bind that operates on a vector might return a list - different types, different monad, but still equal! I am not sure what would be the best solution, I'm just giving a counterexample that illustrates why these things in Clojure are not that straightforward as in Haskell. On Wednesday, July 3, 2013 6:20:08 PM UTC+2, Nils Bertschinger wrote: Hi, Am Mittwoch, 3. Juli 2013 16:49:43 UTC+2 schrieb Dragan Djuric: Monads as a Haskell construct is what the previously mentioned laws describe. Monads in category theory are defined in a category X as a triple (T, n, m) where T is a functor and m and n certan natural transformations such that certan diagrams commute. In that sense, I am not sure that even Haskell's implementation is perfectly clean. in category theory, monads are functors with additional constraints. Haskell's implementation is clean to the extend that Hask, i.e Haskell types and morphisms between them, form a category (there are some issues with laziness). The connection to the categorical definition is most easily seen if you define monads using join instead of = (bind). You basically need a functor, i.e. a type constructor with a proper fmap (check the laws here as well), and two natural transformations mu, eta. As it turns out, polymorphic functions are natural transformations in Haskell's category, i.e. they always obey the required laws, no need to check them. Let's call your functor type t, then mu and eta have the following types: mu :: a - t a -- Haskell's return eta :: t (t a) - t a -- Haskell's join The required laws now state that: eta (eta mm) = eta (fmap eta mm) eta (mu m) = eta (fmap mu m)= identity which just says that if you have something of type t (t (t a)) it does not matter whether you flatten it from the inside or outside first and if you have something of type t a, you can put it into another t from the outside or inside and flatten it to get back the identity. Now, conceptually changing the monad does not make much sense. Remember that a monad is a functor with additional structure, so we are always working in the same functor! The laws just express that we have a special functor which obeys additional properties, besides the functorial ones. Also generalizing the types of (=) to support different monads is forbidden by the laws. Try to define myBind :: (Monad m, Monad n) = m a - (a - n b) - n b-- like (=), but changes the monad and now look at the second law: x = return = x or written with explicit types: ((x :: m a) = (return :: a - m a)) :: m a = x :: m a ((x :: m a) `myBind` (return :: a - n a)) :: n a but this cannot equal (x :: m a), since it does not even have the same type! Best, Nils -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
On Wed, Jul 3, 2013 at 10:31 AM, Dragan Djuric draga...@gmail.com wrote: Yes, I agree completely, when we stay inside Haskell. However, Clojure is dynamic. Here are two objects that are equal despite having different types: If you're going to talk about category theory concepts, then that's the constraint you have to operate under. monad is constituted by the laws, the laws involve operations with a certain type, and that's just it. It's not a matter of being in Haskell or not, it's a matter of accurately implementing the concepts you claim to be implementing. I would actually maintain that a call to bind whose first argument is a vector but which returns a list (because it's implemented with mapcat, say) is not changing the monad, because you're actually operating in the list monad (what algo.monads calls the sequence monad, I think) and while the implementation might choose different ways of mapping the function depending on the type of the first argument to bind, that's an implementation detail. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
If you're going to talk about category theory concepts, then that's the constraint you have to operate under. monad is constituted by the laws, the laws involve operations with a certain type, and that's just it. It's not a matter of being in Haskell or not, it's a matter of accurately implementing the concepts you claim to be implementing. I do not want to be a nitpick, but category theory does not define monads (and functors and everything else) through types, but through categories. Categories themselves are not defined through types, but through - objects - arrows - source and target assignments between arrows and objects - assignment id from objects to arrows - partial composition of arrows - restricting axioms of associativity and identity So, not only that types are not necessary for talking about monads, even functions are not necessary, let alone the laws that are defined strictly through types and/or functions (which I suppose is a special case). But, as I said, neither it is terribly important for now, neither I am prepared (or willing) to go that deep into CT, which, not being a matematician, I do not have a desire to dedicate my life to, so I would stay away from this digression from now on :) I agree that Haskell's way is the most advanced and formally right impementation available today, but I do not agree with your and that's just it. I gave an example (and there are more) where in Clojure it's not just it, and regarding the list monad, I do not agree with you. The vector, list, lazy-seq etc, contexts are not the same, although they are similar, and in a lot of cases in Clojure programming it is very important to be certain whether you are using a vector, a list or a lazy seq. Treating everything as a list monad is enough in some cases, and not enough in others, which are common. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
On Wed, Jul 3, 2013 at 7:49 AM, Dragan Djuric draga...@gmail.com wrote: Monads as a Haskell construct is what the previously mentioned laws describe. Monads in category theory are defined in a category X as a triple (T, n, m) where T is a functor and m and n certan natural transformations such that certan diagrams commute. In that sense, I am not sure that even Haskell's implementation is perfectly clean. There's a lot of nitpicking to be done, but, that's not the point, and we are digressing a bit. The point is that in Fluokitten, you are expected to work within the certain monad as you agree, and since there is no type checking on the value that a function returns, it is the responsibility of the developer to make sure that it makes sense as in Clojure generally. It is fairly easy to do by passing a parameter to f that pure can use, if f implementation needs to be agnostic to the actual monad that it will be called from. There are other approaches, so the programmer can make a choice that is the best fit for the problem at hand. Even in the example that you gave from your library, what stops the programmer to shoot himself in the foot by doing basically the same thing that we are talking about here: (defn f [g] (comp atom g g)) (require '[monads.maybe :as m]) (def mc (= (return 3) (f inc))) (run-monad m/m mc) What is the result if f is broken (in the context of the monad m/m in this case)? I didn't try it, so I may be wrong, but I doubt that the Clojure compiler complains about that one. Of course the compiler doesn't complain, how could it? I'm not asking you to have the clojure compiler complain. I'm attempting to point out that your library makes it impossible to write generic functions involving monads. That is, for fluokitten, you *have* to write f as something like (comp atom g g) or (comp vector g g) or (comp just g g) or whatever. You don't have the option of writing (comp return g g) and having that work right when the function is run in *multiple* monads. Which is a major expressivity drawback, in my mind. This is basically the same thing as comes up with Armando Blancas' morph library, which is, like yours, based on protocols. The expressivity point is the key, not the nonexistent haskell-in-clojure typechecker. That's why I asked the question I asked in my first email: whether it's possible to write this function (which I've desugared): (defn tst-reader [f] (= ask (fn [env] (= (lift (f env)) (fn [_] (= (return (println here I am)) (fn [_] (return v which can operate in an instance of the reader monad transformer parametrized by an *arbitrary* inner monad---so that you don't know in advance what the return or = should be (and you don't know in advance what the lift should be, since more than one interpretation of the reader monad is possible---all that's required here is that the monad support an ask operation). I suppose you could thread specimen special return, bind, ask, and lift functions through (and if you used fancy macrology to do that, you'd have the core.monads approach), but that's really quite cumbersome. IMO, the ability to write code like that is a large part of what makes monadic abstraction powerful and interesting. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Pedestal introduction question
I know there's a pedestal-users mailing list, and I sent my question to it, but
for whatever reason it hasn't shown up there (perhaps it's still in the
moderation queue?). Hopefully someone here might be able to help.
On this page: http://pedestal.io/documentation/application-introduction/
There is the following code (at the very bottom of the page):
(def templates (html-templates/hello-world-templates))
(defn count-model [old-state message]
(condp = (msg/type message)
msg/init (:value message)
:inc (inc old-state)))
(defn render-page [renderer [_ path] input-queue]
(let [parent (push/get-parent-id renderer path)
html (templates/add-template renderer path (:hello-world-page
templates))]
(dom/append! (dom/by-id parent) (html {:message }
I don't understand how a map, in this case `templates', is also being used as a
namespace: `(templates/add-template renderer ... )'.
What's going on?
Many thanks,
Greg
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
core.match error?
This is with 0.2.0-rc2. This expression evaluates as expected: user (m/match [:r :d] [:s :d] nil [:r :t] nil [:r :d] :x [:s :t] nil) :x But this one throws an exception: user (m/match [:r :d] [:r :t] nil [:s :d] nil [:r :d] :x [:s :t] nil) IllegalArgumentException No matching clause: :r :d user/eval1087 (NO_SOURCE_FILE:1) They're the same except the order of the first two match expressions has been flipped. Surely this should match on the third row? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.match error?
Thanks for the report, that's definitely a bug and I know the cause: http://dev.clojure.org/jira/browse/MATCH-80 David On Wed, Jul 3, 2013 at 9:07 PM, Ben Wolfson wolf...@gmail.com wrote: This is with 0.2.0-rc2. This expression evaluates as expected: user (m/match [:r :d] [:s :d] nil [:r :t] nil [:r :d] :x [:s :t] nil) :x But this one throws an exception: user (m/match [:r :d] [:r :t] nil [:s :d] nil [:r :d] :x [:s :t] nil) IllegalArgumentException No matching clause: :r :d user/eval1087 (NO_SOURCE_FILE:1) They're the same except the order of the first two match expressions has been flipped. Surely this should match on the third row? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding implicit indexing to Clojure lists and arrays?
(defn indexed Returns a lazy sequence of [index, item] pairs, where items come from 's' and indexes count up from zero. (indexed '(a b c d)) = ([0 a] [1 b] [2 c] [3 d]) [s] (map vector (iterate inc 0) s)) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.match error?
0.2.0-rc3 going out with a fix. On Wed, Jul 3, 2013 at 9:14 PM, David Nolen dnolen.li...@gmail.com wrote: Thanks for the report, that's definitely a bug and I know the cause: http://dev.clojure.org/jira/browse/MATCH-80 David On Wed, Jul 3, 2013 at 9:07 PM, Ben Wolfson wolf...@gmail.com wrote: This is with 0.2.0-rc2. This expression evaluates as expected: user (m/match [:r :d] [:s :d] nil [:r :t] nil [:r :d] :x [:s :t] nil) :x But this one throws an exception: user (m/match [:r :d] [:r :t] nil [:s :d] nil [:r :d] :x [:s :t] nil) IllegalArgumentException No matching clause: :r :d user/eval1087 (NO_SOURCE_FILE:1) They're the same except the order of the first two match expressions has been flipped. Surely this should match on the third row? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.match error?
Thanks! On Wed, Jul 3, 2013 at 6:44 PM, David Nolen dnolen.li...@gmail.com wrote: 0.2.0-rc3 going out with a fix. On Wed, Jul 3, 2013 at 9:14 PM, David Nolen dnolen.li...@gmail.comwrote: Thanks for the report, that's definitely a bug and I know the cause: http://dev.clojure.org/jira/browse/MATCH-80 David On Wed, Jul 3, 2013 at 9:07 PM, Ben Wolfson wolf...@gmail.com wrote: This is with 0.2.0-rc2. This expression evaluates as expected: user (m/match [:r :d] [:s :d] nil [:r :t] nil [:r :d] :x [:s :t] nil) :x But this one throws an exception: user (m/match [:r :d] [:r :t] nil [:s :d] nil [:r :d] :x [:s :t] nil) IllegalArgumentException No matching clause: :r :d user/eval1087 (NO_SOURCE_FILE:1) They're the same except the order of the first two match expressions has been flipped. Surely this should match on the third row? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
