That's precisely the design followed by Magpie, described here: http://journal.stuffwithstuff.com/2013/04/17/well-done/
Parts 1 & 2 of that series are worth reading too. On Sat, Aug 17, 2013 at 8:48 PM, Mikera <mike.r.anderson...@gmail.com>wrote: > My overall sense is that the convenience of using if-let directly in a few > use cases doesn't justify making channels fall short of being able to send > arbitrary values (nil specifically, and clearly boolean false can cause > some problems too). > > I think it would be a much better design to have a sentinel value and a > couple of specialised functions or macros that can detect / interact with > it appropriately. With a sentinel value the key part of your if-recv code > could just be something like: > > `(let [~name (<! ~port)] > (if (end-of-stream? ~name) > ~else > ~then)))) > > > I can see that wrappers for nil values could also work, but that seems to > be a more complex solution (and also potentially with more overhead) than a > sentinel value.... > > > On Saturday, 17 August 2013 07:50:06 UTC+8, Brandon Bloom wrote: > >> I ran into the other half of this problem: If you expect nils to signify >> closed channels, then you can't leverage the logically false nature of nil >> without excluding explicit boolean false values. Given the pleasant syntax >> of if-let / <! pairs, I reworked my early experiments to use if-recv >> which is defined as follows: >> >> (defmacro if-recv >> "Reads from port, binding to name. Evaluates the then block if the >> read was successful. Evaluates the else block if the port was closed." >> ([[name port :as binding] then] >> `(if-recv ~binding ~then nil)) >> ([[name port] then else] >> `(let [~name (<! ~port)] >> (if (nil? ~name) >> ~else >> ~then)))) >> >> >> I've considered some alternative core.async designs, such as an >> additional "done" sentinel value, or a pair of quote/unquote operators (see >> "reduced"), but nothing seems as simple as just avoiding booleans and nils, >> as annoying as that is. I'd be curious to here what Rich & team >> considered and how they're thinking about it. However, my expectation is >> that the nil approach won't change, since it's pretty much good enough. >> >> On Thursday, August 15, 2013 10:44:48 PM UTC-4, Mikera wrote: >>> >>> Hi all, >>> >>> I'm experimenting with core.async. Most of it is exceptionally good, but >>> bit I'm finding it *very* inconvenient that nil can't be sent over >>> channels. In particular, you can't pipe arbitrary Clojure sequences through >>> channels (since sequences can contain nils). >>> >>> I see this as a pretty big design flaw given the ubiquity of sequences >>> in Clojure code - it appears to imply that you can't easily compose >>> channels with generic sequence-handling code without some pretty ugly >>> special-case handling. >>> >>> Am I missing something? Is this a real problem for others too? >>> >>> If it is a design flaw, can it be fixed before the API gets locked down? >>> >> -- > -- > 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/pF9FEP7b77U/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.
