+1

On Saturday, December 1, 2012 6:38:54 PM UTC+1, Andy Fingerhut wrote:
>
> I don't have suggestions for the best names for these new things, but one 
> good example in the doc string would go a long way to making it clearer 
> what they *do* and how they are intended to be used.  The doc strings are 
> written once, but read thousands of times, and are your most reliable line 
> of communication to Clojure developers.  Everyone can find them quickly. 
>
> Andy 
>
> On Dec 1, 2012, at 6:48 AM, Rich Hickey wrote: 
>
> > I'll argue that if 'e' in conde is enough to imply 'each' then '->' in 
> cond-> is enough to imply it keeps threading. 
> > 
> > I think many people have ideas about -> operators born of some of these 
> libraries that supply a wealth of 'things you can use in ->'.  Most of 
> their operators have '->' in their names, but don't fundamentally thread - 
> e.g. they are terminators or one shots like if-> (or ->if). 
> > 
> > A op-> operator, IMO, should take an open set of expressions and thread 
> the return values through them in some way. Otherwise it shouldn't be an 
> op->. 
> > 
> > When one reads -> as 'thread' vs 'for use in threading', things might 
> become clearer. 
> > 
> > 
> > On Dec 1, 2012, at 9:31 AM, Steve Miner wrote: 
> > 
> >> gate-> would work.  Like guard-> it doesn't have any connotations in 
> the Clojure world, but it's learnable.  I'll add one more: qual-> ... short 
> for "qualified threading macro".  Each clause is qualified by a test 
> condition. 
> >> 
> >> Of course, there's always conde-> to borrow from miniKanren and 
> core.logic.  The "e" stands for "every" because multiple clauses can 
> succeed as opposed to the short-circuiting cond. 
> >> 
> >> 
> >> On Nov 30, 2012, at 2:49 PM, Rich Hickey <richh...@gmail.com<javascript:>> 
> wrote: 
> >> 
> >>> 
> >>> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote: 
> >>> 
> >>>> I propose guard-> to avoid the cond-> confusion. 
> >>>> 
> >>> 
> >>> Yeah, that came up. Guards in other langs are short circuiting, just 
> like cond. 
> >>> 
> >>> Another in that camp was gate-> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com<javascript:> 
> >> Note that posts from new members are moderated - please be patient with 
> your first post. 
> >> To unsubscribe from this group, send email to 
> >> clojure+u...@googlegroups.com <javascript:> 
> >> For more options, visit this group at 
> >> http://groups.google.com/group/clojure?hl=en 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com<javascript:> 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com <javascript:> 
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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

Reply via email to