Re: [ANN] com.walmartlabs/cond-let 1.0.0
I'm glad my little library has gotten some attention on better-cond, which even I'm switching over to. On Thu, Oct 4, 2018 at 10:39 PM Mark Engelberg wrote: > Documentation for latest features in the 2.0.1 branch: > https://github.com/Engelberg/better-cond/tree/v2.0.1 > > An example: > > (cond >(odd? a) 1 >:let [a (quot a 2)] >:when-let [x (fn-which-may-return-nil a), > y (fn-which-may-return-nil (* 2 a))] >:when (seq x) >:do (println x) >(odd? (+ x y)) 2 >:else 3) > > The :do performs a side-effecting statement if it gets that far in the > cond. :do is my favorite bonus addition for cond beyond :let. I find I > use it a lot to quickly insert some debugging print commands without > needing to change the shape of my code, so it can be trivially removed > later. > > When :do did not exist, but :let did exist in my cond macro, I found > myself frequently writing things like: > :let [_ (println x)] > in order to insert a side-effecting statement into the cond sequence. > :do is a cleaner solution. > > :when only continues with the cond if the value is truthy, otherwise it > bails out of the cond with nil. > :when-some (not yet merged in) will do much the same thing, but continuing > if non-nil, rather than truthy. > > :when, :when-some, and :when-let don't add a whole lot of richness. For > example, that :when line in the example could just have easily been written > as: > (not (seq x)) nil > > But using these can potentially add clarity of intention, so even though I > could make do without them, I go ahead and use them when relevant. > > In better-cond's cond macro, that final :else is optional. You may prefer > the new cond-let library if you want to continue enforcing the use of :else > on the last clause. > > To reiterate, :let is by far the most valuable addition, and I find :do to > be the second-most valuable addition. Other additions are fairly minor > syntactic sugar. > > On Thu, Oct 4, 2018 at 1:36 PM Alan Thompson wrote: > >> How would the :when and :do forms work? >> Alan >> >> On Wed, Oct 3, 2018 at 7:22 PM Mark Engelberg >> wrote: >> >>> This looks like a case of "convergent evolution". >>> >>> Having the ability to do a :let in the middle of a cond feels like one >>> of those things that *should* be in the core language, so if it's not >>> in there, a bunch of people are naturally going to arrive at the same >>> solution and make it happen in their own utility libraries. A bunch of us >>> Clojure programmers from the early 1.0 days had been privately passing >>> around and using a "cond that supports :let bindings" macro for years. The >>> first time I saw the macro was in a blog post by Christophe Grand. I really >>> hoped it would make it into Clojure proper -- other functional languages >>> like Racket and F# support ways to bind local variables with "clearer, more >>> linear code, that doesn't make a march for the right margin", as Howard >>> Lewis Ship put it. But after several years had passed without any >>> indication that CLJ-200 was ever going to be addressed, I eventually made >>> the improved cond macro into a clojars library. >>> >>> walmartlabs' cond-let addresses the most important thing (let), which is >>> the critical piece of functionality that feels like the most natural, >>> needed addition to the language. better-cond's :let syntax is identical. >>> But as us old-school Clojurians passed around the "better cond" macro over >>> the years, it grew in functionality. So in better-cond, I included the >>> other little improvements that had accumulated over time, which I had found >>> useful. So better-cond also supports :when, :when-let, and :do (and will >>> soon have :when-some). :let is the only piece that I felt really belonged >>> in the core language's cond, and if CLJ-200 had made it into the core >>> language, I would have been content to just use Clojure's own cond. But >>> once I realized I was going to need a library to achieve the much-needed >>> :let inside of cond, I figured I might as well use that library to include >>> the other convenient cond additions as well. So better-cond is a superset >>> of cond-let's functionality, with support for :let plus a few bonuses. >>> >>> Use whichever one strikes your fancy. cond-let is perfect if all you >>> care about is adding :let to your cond. If you want to experiment with >>> some of the other features beyond :let, you could use better-cond and see >>> what you think. >>> >>> Either way, I strongly encourage you to use one of these two libraries >>> so you can start using :let inside your cond. I agree fully with Howard >>> Lewis Ship that it results in clearer code. Try either library which >>> supports this -- it will change your life! >>> >>> >>> On Wed, Oct 3, 2018 at 5:05 PM Matching Socks >>> wrote: >>> Is this a refinement of Mark Engelberg's "better-cond", or an alternative approach? I have not used better-cond myself, but it
Re: [ANN] com.walmartlabs/cond-let 1.0.0
Documentation for latest features in the 2.0.1 branch: https://github.com/Engelberg/better-cond/tree/v2.0.1 An example: (cond (odd? a) 1 :let [a (quot a 2)] :when-let [x (fn-which-may-return-nil a), y (fn-which-may-return-nil (* 2 a))] :when (seq x) :do (println x) (odd? (+ x y)) 2 :else 3) The :do performs a side-effecting statement if it gets that far in the cond. :do is my favorite bonus addition for cond beyond :let. I find I use it a lot to quickly insert some debugging print commands without needing to change the shape of my code, so it can be trivially removed later. When :do did not exist, but :let did exist in my cond macro, I found myself frequently writing things like: :let [_ (println x)] in order to insert a side-effecting statement into the cond sequence. :do is a cleaner solution. :when only continues with the cond if the value is truthy, otherwise it bails out of the cond with nil. :when-some (not yet merged in) will do much the same thing, but continuing if non-nil, rather than truthy. :when, :when-some, and :when-let don't add a whole lot of richness. For example, that :when line in the example could just have easily been written as: (not (seq x)) nil But using these can potentially add clarity of intention, so even though I could make do without them, I go ahead and use them when relevant. In better-cond's cond macro, that final :else is optional. You may prefer the new cond-let library if you want to continue enforcing the use of :else on the last clause. To reiterate, :let is by far the most valuable addition, and I find :do to be the second-most valuable addition. Other additions are fairly minor syntactic sugar. On Thu, Oct 4, 2018 at 1:36 PM Alan Thompson wrote: > How would the :when and :do forms work? > Alan > > On Wed, Oct 3, 2018 at 7:22 PM Mark Engelberg > wrote: > >> This looks like a case of "convergent evolution". >> >> Having the ability to do a :let in the middle of a cond feels like one of >> those things that *should* be in the core language, so if it's not in >> there, a bunch of people are naturally going to arrive at the same solution >> and make it happen in their own utility libraries. A bunch of us Clojure >> programmers from the early 1.0 days had been privately passing around and >> using a "cond that supports :let bindings" macro for years. The first time >> I saw the macro was in a blog post by Christophe Grand. I really hoped it >> would make it into Clojure proper -- other functional languages like Racket >> and F# support ways to bind local variables with "clearer, more linear >> code, that doesn't make a march for the right margin", as Howard Lewis Ship >> put it. But after several years had passed without any indication that >> CLJ-200 was ever going to be addressed, I eventually made the improved cond >> macro into a clojars library. >> >> walmartlabs' cond-let addresses the most important thing (let), which is >> the critical piece of functionality that feels like the most natural, >> needed addition to the language. better-cond's :let syntax is identical. >> But as us old-school Clojurians passed around the "better cond" macro over >> the years, it grew in functionality. So in better-cond, I included the >> other little improvements that had accumulated over time, which I had found >> useful. So better-cond also supports :when, :when-let, and :do (and will >> soon have :when-some). :let is the only piece that I felt really belonged >> in the core language's cond, and if CLJ-200 had made it into the core >> language, I would have been content to just use Clojure's own cond. But >> once I realized I was going to need a library to achieve the much-needed >> :let inside of cond, I figured I might as well use that library to include >> the other convenient cond additions as well. So better-cond is a superset >> of cond-let's functionality, with support for :let plus a few bonuses. >> >> Use whichever one strikes your fancy. cond-let is perfect if all you >> care about is adding :let to your cond. If you want to experiment with >> some of the other features beyond :let, you could use better-cond and see >> what you think. >> >> Either way, I strongly encourage you to use one of these two libraries so >> you can start using :let inside your cond. I agree fully with Howard Lewis >> Ship that it results in clearer code. Try either library which supports >> this -- it will change your life! >> >> >> On Wed, Oct 3, 2018 at 5:05 PM Matching Socks >> wrote: >> >>> Is this a refinement of Mark Engelberg's "better-cond", or an >>> alternative approach? >>> >>> I have not used better-cond myself, but it starts here: >>> https://dev.clojure.org/jira/browse/CLJ-200. >>> >>> -- >>> 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
Re: [ANN] com.walmartlabs/cond-let 1.0.0
How would the :when and :do forms work? Alan On Wed, Oct 3, 2018 at 7:22 PM Mark Engelberg wrote: > This looks like a case of "convergent evolution". > > Having the ability to do a :let in the middle of a cond feels like one of > those things that *should* be in the core language, so if it's not in > there, a bunch of people are naturally going to arrive at the same solution > and make it happen in their own utility libraries. A bunch of us Clojure > programmers from the early 1.0 days had been privately passing around and > using a "cond that supports :let bindings" macro for years. The first time > I saw the macro was in a blog post by Christophe Grand. I really hoped it > would make it into Clojure proper -- other functional languages like Racket > and F# support ways to bind local variables with "clearer, more linear > code, that doesn't make a march for the right margin", as Howard Lewis Ship > put it. But after several years had passed without any indication that > CLJ-200 was ever going to be addressed, I eventually made the improved cond > macro into a clojars library. > > walmartlabs' cond-let addresses the most important thing (let), which is > the critical piece of functionality that feels like the most natural, > needed addition to the language. better-cond's :let syntax is identical. > But as us old-school Clojurians passed around the "better cond" macro over > the years, it grew in functionality. So in better-cond, I included the > other little improvements that had accumulated over time, which I had found > useful. So better-cond also supports :when, :when-let, and :do (and will > soon have :when-some). :let is the only piece that I felt really belonged > in the core language's cond, and if CLJ-200 had made it into the core > language, I would have been content to just use Clojure's own cond. But > once I realized I was going to need a library to achieve the much-needed > :let inside of cond, I figured I might as well use that library to include > the other convenient cond additions as well. So better-cond is a superset > of cond-let's functionality, with support for :let plus a few bonuses. > > Use whichever one strikes your fancy. cond-let is perfect if all you care > about is adding :let to your cond. If you want to experiment with some of > the other features beyond :let, you could use better-cond and see what you > think. > > Either way, I strongly encourage you to use one of these two libraries so > you can start using :let inside your cond. I agree fully with Howard Lewis > Ship that it results in clearer code. Try either library which supports > this -- it will change your life! > > > On Wed, Oct 3, 2018 at 5:05 PM Matching Socks > wrote: > >> Is this a refinement of Mark Engelberg's "better-cond", or an alternative >> approach? >> >> I have not used better-cond myself, but it starts here: >> https://dev.clojure.org/jira/browse/CLJ-200. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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
Re: [ANN] com.walmartlabs/cond-let 1.0.0
Yes, I wouldn't have bothered if I had known about better-cond, so there you go. I think I first wrote this code at Aviso at least five years ago. On Wed, Oct 3, 2018 at 7:22 PM Mark Engelberg wrote: > This looks like a case of "convergent evolution". > > Having the ability to do a :let in the middle of a cond feels like one of > those things that *should* be in the core language, so if it's not in > there, a bunch of people are naturally going to arrive at the same solution > and make it happen in their own utility libraries. A bunch of us Clojure > programmers from the early 1.0 days had been privately passing around and > using a "cond that supports :let bindings" macro for years. The first time > I saw the macro was in a blog post by Christophe Grand. I really hoped it > would make it into Clojure proper -- other functional languages like Racket > and F# support ways to bind local variables with "clearer, more linear > code, that doesn't make a march for the right margin", as Howard Lewis Ship > put it. But after several years had passed without any indication that > CLJ-200 was ever going to be addressed, I eventually made the improved cond > macro into a clojars library. > > walmartlabs' cond-let addresses the most important thing (let), which is > the critical piece of functionality that feels like the most natural, > needed addition to the language. better-cond's :let syntax is identical. > But as us old-school Clojurians passed around the "better cond" macro over > the years, it grew in functionality. So in better-cond, I included the > other little improvements that had accumulated over time, which I had found > useful. So better-cond also supports :when, :when-let, and :do (and will > soon have :when-some). :let is the only piece that I felt really belonged > in the core language's cond, and if CLJ-200 had made it into the core > language, I would have been content to just use Clojure's own cond. But > once I realized I was going to need a library to achieve the much-needed > :let inside of cond, I figured I might as well use that library to include > the other convenient cond additions as well. So better-cond is a superset > of cond-let's functionality, with support for :let plus a few bonuses. > > Use whichever one strikes your fancy. cond-let is perfect if all you care > about is adding :let to your cond. If you want to experiment with some of > the other features beyond :let, you could use better-cond and see what you > think. > > Either way, I strongly encourage you to use one of these two libraries so > you can start using :let inside your cond. I agree fully with Howard Lewis > Ship that it results in clearer code. Try either library which supports > this -- it will change your life! > > > On Wed, Oct 3, 2018 at 5:05 PM Matching Socks > wrote: > >> Is this a refinement of Mark Engelberg's "better-cond", or an alternative >> approach? >> >> I have not used better-cond myself, but it starts here: >> https://dev.clojure.org/jira/browse/CLJ-200. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Howard M. Lewis Ship Senior Mobile Developer at Walmart Labs (971) 678-5210 http://howardlewisship.com @hlship -- 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
Re: [ANN] com.walmartlabs/cond-let 1.0.0
The short-circuiting is a 'feature' of letting the type control the sequencing of operations. In practice you mix multiple interacting monads depending on what your requirements are, for example I regularly work with Deferred Options and Deferred Results. In clojure, you could try to add a 'if-let' style nil-punning thing to a cond-let implementation but at that point I imagine it more appropriate to take a step back instead :-). I'm not convinced yet that it's worth thinking about it like this in a dynamically typed language, but brought it up because there's a named concept that addresses the need people feel to extend cond/lets. On Thu, Oct 4, 2018 at 12:57 PM lei Shulang wrote: > But a Maybe/Nothing will short-circuit the whole flow where cond-let > won't? > > > On Thursday, 4 October 2018 08:38:05 UTC-7, Moe Aboulkheir wrote: > >> See https://funcool.github.io/cats/latest/#mlet for something closer to >> home, in the monadic vein. >> >> >> On Thu, Oct 4, 2018 at 4:10 PM Gary Trakhman wrote: >> > These are all just sugar over monadic bind, right? >>> >>> Here's one way to do it in the ocaml alternate universe: >>> >>> https://github.com/janestreet/ppx_let#syntactic-forms-and-actual-rewriting >>> >>> But it can be made to work for async or options or whatever, too. >>> >>> We can put the async helpers in the same bucket: >>> https://github.com/ztellman/manifold/blob/master/docs/deferred.md#let-flow >>> >>> The general idea is turning function application into something that >>> looks less nested. >>> >>> On Wed, Oct 3, 2018 at 10:22 PM Mark Engelberg >>> wrote: >>> >> This looks like a case of "convergent evolution". Having the ability to do a :let in the middle of a cond feels like one of those things that *should* be in the core language, so if it's not in there, a bunch of people are naturally going to arrive at the same solution and make it happen in their own utility libraries. A bunch of us Clojure programmers from the early 1.0 days had been privately passing around and using a "cond that supports :let bindings" macro for years. The first time I saw the macro was in a blog post by Christophe Grand. I really hoped it would make it into Clojure proper -- other functional languages like Racket and F# support ways to bind local variables with "clearer, more linear code, that doesn't make a march for the right margin", as Howard Lewis Ship put it. But after several years had passed without any indication that CLJ-200 was ever going to be addressed, I eventually made the improved cond macro into a clojars library. walmartlabs' cond-let addresses the most important thing (let), which is the critical piece of functionality that feels like the most natural, needed addition to the language. better-cond's :let syntax is identical. But as us old-school Clojurians passed around the "better cond" macro over the years, it grew in functionality. So in better-cond, I included the other little improvements that had accumulated over time, which I had found useful. So better-cond also supports :when, :when-let, and :do (and will soon have :when-some). :let is the only piece that I felt really belonged in the core language's cond, and if CLJ-200 had made it into the core language, I would have been content to just use Clojure's own cond. But once I realized I was going to need a library to achieve the much-needed :let inside of cond, I figured I might as well use that library to include the other convenient cond additions as well. So better-cond is a superset of cond-let's functionality, with support for :let plus a few bonuses. Use whichever one strikes your fancy. cond-let is perfect if all you care about is adding :let to your cond. If you want to experiment with some of the other features beyond :let, you could use better-cond and see what you think. Either way, I strongly encourage you to use one of these two libraries so you can start using :let inside your cond. I agree fully with Howard Lewis Ship that it results in clearer code. Try either library which supports this -- it will change your life! On Wed, Oct 3, 2018 at 5:05 PM Matching Socks wrote: >>> Is this a refinement of Mark Engelberg's "better-cond", or an > alternative approach? > > I have not used better-cond myself, but it starts here: > https://dev.clojure.org/jira/browse/CLJ-200. > > -- > 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 > 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 > For more
Re: [ANN] com.walmartlabs/cond-let 1.0.0
But a Maybe/Nothing will short-circuit the whole flow where cond-let won't? On Thursday, 4 October 2018 08:38:05 UTC-7, Moe Aboulkheir wrote: > > See https://funcool.github.io/cats/latest/#mlet for something closer to > home, in the monadic vein. > > > On Thu, Oct 4, 2018 at 4:10 PM Gary Trakhman > wrote: > >> These are all just sugar over monadic bind, right? >> >> Here's one way to do it in the ocaml alternate universe: >> https://github.com/janestreet/ppx_let#syntactic-forms-and-actual-rewriting >> >> But it can be made to work for async or options or whatever, too. >> >> We can put the async helpers in the same bucket: >> https://github.com/ztellman/manifold/blob/master/docs/deferred.md#let-flow >> >> The general idea is turning function application into something that >> looks less nested. >> >> On Wed, Oct 3, 2018 at 10:22 PM Mark Engelberg > > wrote: >> >>> This looks like a case of "convergent evolution". >>> >>> Having the ability to do a :let in the middle of a cond feels like one >>> of those things that *should* be in the core language, so if it's not >>> in there, a bunch of people are naturally going to arrive at the same >>> solution and make it happen in their own utility libraries. A bunch of us >>> Clojure programmers from the early 1.0 days had been privately passing >>> around and using a "cond that supports :let bindings" macro for years. The >>> first time I saw the macro was in a blog post by Christophe Grand. I really >>> hoped it would make it into Clojure proper -- other functional languages >>> like Racket and F# support ways to bind local variables with "clearer, more >>> linear code, that doesn't make a march for the right margin", as Howard >>> Lewis Ship put it. But after several years had passed without any >>> indication that CLJ-200 was ever going to be addressed, I eventually made >>> the improved cond macro into a clojars library. >>> >>> walmartlabs' cond-let addresses the most important thing (let), which is >>> the critical piece of functionality that feels like the most natural, >>> needed addition to the language. better-cond's :let syntax is identical. >>> But as us old-school Clojurians passed around the "better cond" macro over >>> the years, it grew in functionality. So in better-cond, I included the >>> other little improvements that had accumulated over time, which I had found >>> useful. So better-cond also supports :when, :when-let, and :do (and will >>> soon have :when-some). :let is the only piece that I felt really belonged >>> in the core language's cond, and if CLJ-200 had made it into the core >>> language, I would have been content to just use Clojure's own cond. But >>> once I realized I was going to need a library to achieve the much-needed >>> :let inside of cond, I figured I might as well use that library to include >>> the other convenient cond additions as well. So better-cond is a superset >>> of cond-let's functionality, with support for :let plus a few bonuses. >>> >>> Use whichever one strikes your fancy. cond-let is perfect if all you >>> care about is adding :let to your cond. If you want to experiment with >>> some of the other features beyond :let, you could use better-cond and see >>> what you think. >>> >>> Either way, I strongly encourage you to use one of these two libraries >>> so you can start using :let inside your cond. I agree fully with Howard >>> Lewis Ship that it results in clearer code. Try either library which >>> supports this -- it will change your life! >>> >>> >>> On Wed, Oct 3, 2018 at 5:05 PM Matching Socks >> > wrote: >>> Is this a refinement of Mark Engelberg's "better-cond", or an alternative approach? I have not used better-cond myself, but it starts here: https://dev.clojure.org/jira/browse/CLJ-200. -- 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 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 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 . For more options, visit https://groups.google.com/d/optout. >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@googlegroups.com >>> For more
Re: [ANN] com.walmartlabs/cond-let 1.0.0
See https://funcool.github.io/cats/latest/#mlet for something closer to home, in the monadic vein. On Thu, Oct 4, 2018 at 4:10 PM Gary Trakhman wrote: > These are all just sugar over monadic bind, right? > > Here's one way to do it in the ocaml alternate universe: > https://github.com/janestreet/ppx_let#syntactic-forms-and-actual-rewriting > > But it can be made to work for async or options or whatever, too. > > We can put the async helpers in the same bucket: > https://github.com/ztellman/manifold/blob/master/docs/deferred.md#let-flow > > The general idea is turning function application into something that looks > less nested. > > On Wed, Oct 3, 2018 at 10:22 PM Mark Engelberg > wrote: > >> This looks like a case of "convergent evolution". >> >> Having the ability to do a :let in the middle of a cond feels like one of >> those things that *should* be in the core language, so if it's not in >> there, a bunch of people are naturally going to arrive at the same solution >> and make it happen in their own utility libraries. A bunch of us Clojure >> programmers from the early 1.0 days had been privately passing around and >> using a "cond that supports :let bindings" macro for years. The first time >> I saw the macro was in a blog post by Christophe Grand. I really hoped it >> would make it into Clojure proper -- other functional languages like Racket >> and F# support ways to bind local variables with "clearer, more linear >> code, that doesn't make a march for the right margin", as Howard Lewis Ship >> put it. But after several years had passed without any indication that >> CLJ-200 was ever going to be addressed, I eventually made the improved cond >> macro into a clojars library. >> >> walmartlabs' cond-let addresses the most important thing (let), which is >> the critical piece of functionality that feels like the most natural, >> needed addition to the language. better-cond's :let syntax is identical. >> But as us old-school Clojurians passed around the "better cond" macro over >> the years, it grew in functionality. So in better-cond, I included the >> other little improvements that had accumulated over time, which I had found >> useful. So better-cond also supports :when, :when-let, and :do (and will >> soon have :when-some). :let is the only piece that I felt really belonged >> in the core language's cond, and if CLJ-200 had made it into the core >> language, I would have been content to just use Clojure's own cond. But >> once I realized I was going to need a library to achieve the much-needed >> :let inside of cond, I figured I might as well use that library to include >> the other convenient cond additions as well. So better-cond is a superset >> of cond-let's functionality, with support for :let plus a few bonuses. >> >> Use whichever one strikes your fancy. cond-let is perfect if all you >> care about is adding :let to your cond. If you want to experiment with >> some of the other features beyond :let, you could use better-cond and see >> what you think. >> >> Either way, I strongly encourage you to use one of these two libraries so >> you can start using :let inside your cond. I agree fully with Howard Lewis >> Ship that it results in clearer code. Try either library which supports >> this -- it will change your life! >> >> >> On Wed, Oct 3, 2018 at 5:05 PM Matching Socks >> wrote: >> >>> Is this a refinement of Mark Engelberg's "better-cond", or an >>> alternative approach? >>> >>> I have not used better-cond myself, but it starts here: >>> https://dev.clojure.org/jira/browse/CLJ-200. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to
Re: [ANN] com.walmartlabs/cond-let 1.0.0
These are all just sugar over monadic bind, right? Here's one way to do it in the ocaml alternate universe: https://github.com/janestreet/ppx_let#syntactic-forms-and-actual-rewriting But it can be made to work for async or options or whatever, too. We can put the async helpers in the same bucket: https://github.com/ztellman/manifold/blob/master/docs/deferred.md#let-flow The general idea is turning function application into something that looks less nested. On Wed, Oct 3, 2018 at 10:22 PM Mark Engelberg wrote: > This looks like a case of "convergent evolution". > > Having the ability to do a :let in the middle of a cond feels like one of > those things that *should* be in the core language, so if it's not in > there, a bunch of people are naturally going to arrive at the same solution > and make it happen in their own utility libraries. A bunch of us Clojure > programmers from the early 1.0 days had been privately passing around and > using a "cond that supports :let bindings" macro for years. The first time > I saw the macro was in a blog post by Christophe Grand. I really hoped it > would make it into Clojure proper -- other functional languages like Racket > and F# support ways to bind local variables with "clearer, more linear > code, that doesn't make a march for the right margin", as Howard Lewis Ship > put it. But after several years had passed without any indication that > CLJ-200 was ever going to be addressed, I eventually made the improved cond > macro into a clojars library. > > walmartlabs' cond-let addresses the most important thing (let), which is > the critical piece of functionality that feels like the most natural, > needed addition to the language. better-cond's :let syntax is identical. > But as us old-school Clojurians passed around the "better cond" macro over > the years, it grew in functionality. So in better-cond, I included the > other little improvements that had accumulated over time, which I had found > useful. So better-cond also supports :when, :when-let, and :do (and will > soon have :when-some). :let is the only piece that I felt really belonged > in the core language's cond, and if CLJ-200 had made it into the core > language, I would have been content to just use Clojure's own cond. But > once I realized I was going to need a library to achieve the much-needed > :let inside of cond, I figured I might as well use that library to include > the other convenient cond additions as well. So better-cond is a superset > of cond-let's functionality, with support for :let plus a few bonuses. > > Use whichever one strikes your fancy. cond-let is perfect if all you care > about is adding :let to your cond. If you want to experiment with some of > the other features beyond :let, you could use better-cond and see what you > think. > > Either way, I strongly encourage you to use one of these two libraries so > you can start using :let inside your cond. I agree fully with Howard Lewis > Ship that it results in clearer code. Try either library which supports > this -- it will change your life! > > > On Wed, Oct 3, 2018 at 5:05 PM Matching Socks > wrote: > >> Is this a refinement of Mark Engelberg's "better-cond", or an alternative >> approach? >> >> I have not used better-cond myself, but it starts here: >> https://dev.clojure.org/jira/browse/CLJ-200. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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
Re: [ANN] com.walmartlabs/cond-let 1.0.0
This looks like a case of "convergent evolution". Having the ability to do a :let in the middle of a cond feels like one of those things that *should* be in the core language, so if it's not in there, a bunch of people are naturally going to arrive at the same solution and make it happen in their own utility libraries. A bunch of us Clojure programmers from the early 1.0 days had been privately passing around and using a "cond that supports :let bindings" macro for years. The first time I saw the macro was in a blog post by Christophe Grand. I really hoped it would make it into Clojure proper -- other functional languages like Racket and F# support ways to bind local variables with "clearer, more linear code, that doesn't make a march for the right margin", as Howard Lewis Ship put it. But after several years had passed without any indication that CLJ-200 was ever going to be addressed, I eventually made the improved cond macro into a clojars library. walmartlabs' cond-let addresses the most important thing (let), which is the critical piece of functionality that feels like the most natural, needed addition to the language. better-cond's :let syntax is identical. But as us old-school Clojurians passed around the "better cond" macro over the years, it grew in functionality. So in better-cond, I included the other little improvements that had accumulated over time, which I had found useful. So better-cond also supports :when, :when-let, and :do (and will soon have :when-some). :let is the only piece that I felt really belonged in the core language's cond, and if CLJ-200 had made it into the core language, I would have been content to just use Clojure's own cond. But once I realized I was going to need a library to achieve the much-needed :let inside of cond, I figured I might as well use that library to include the other convenient cond additions as well. So better-cond is a superset of cond-let's functionality, with support for :let plus a few bonuses. Use whichever one strikes your fancy. cond-let is perfect if all you care about is adding :let to your cond. If you want to experiment with some of the other features beyond :let, you could use better-cond and see what you think. Either way, I strongly encourage you to use one of these two libraries so you can start using :let inside your cond. I agree fully with Howard Lewis Ship that it results in clearer code. Try either library which supports this -- it will change your life! On Wed, Oct 3, 2018 at 5:05 PM Matching Socks wrote: > Is this a refinement of Mark Engelberg's "better-cond", or an alternative > approach? > > I have not used better-cond myself, but it starts here: > https://dev.clojure.org/jira/browse/CLJ-200. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] com.walmartlabs/cond-let 1.0.0
Is this a refinement of Mark Engelberg's "better-cond", or an alternative approach? I have not used better-cond myself, but it starts here: https://dev.clojure.org/jira/browse/CLJ-200. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
