Proposal/request: Give clojure.core/conj a unary implementation
It would be nice if clojure.core/conj had a unary implementation
([coll] coll)
The motivating use case is when one is conjoining sequences of
items to a collection all at once:
(apply conj coll seqable)
such as (apply conj #{1 2 3} [2 4 6 8 10]).
Currently (1.4.0), this will raise an arity exception
if the seqable object is empty:
(apply conj #{1 2 3} [])
necessitating an awkward empty? check when,
for instance, the sequence is computed or passed in.
It seems to me that making unary conj the identity is both
a natural interpretation and essentially cost free, while
making this use case much more convenient.
Moreover, it is consistent with clojure.core/disj for sets
which does act like this
(apply disj #{1 2 3} []) -> #{1 2 3}
and has an identity unary implementation.
Comments?
--
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
Re: Proposal/request: Give clojure.core/conj a unary implementation
There is never a reason to write (apply conj ...). Instead, use `into`,
which does the same thing but faster and with fewer characters.
On Saturday, November 3, 2012 3:27:24 PM UTC-7, CGAT wrote:
>
> It would be nice if clojure.core/conj had a unary implementation
>
>([coll] coll)
>
> The motivating use case is when one is conjoining sequences of
> items to a collection all at once:
>
>(apply conj coll seqable)
>
> such as (apply conj #{1 2 3} [2 4 6 8 10]).
> Currently (1.4.0), this will raise an arity exception
> if the seqable object is empty:
>
>(apply conj #{1 2 3} [])
>
> necessitating an awkward empty? check when,
> for instance, the sequence is computed or passed in.
>
> It seems to me that making unary conj the identity is both
> a natural interpretation and essentially cost free, while
> making this use case much more convenient.
> Moreover, it is consistent with clojure.core/disj for sets
> which does act like this
>
> (apply disj #{1 2 3} []) -> #{1 2 3}
>
> and has an identity unary implementation.
>
> Comments?
>
>
>
--
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
Re: Proposal/request: Give clojure.core/conj a unary implementation
There might be a reason to write (apply f coll seqable) in a situation
in which f might be conj, though.
On Sat, Nov 3, 2012 at 4:25 PM, Alan Malloy wrote:
> There is never a reason to write (apply conj ...). Instead, use `into`,
> which does the same thing but faster and with fewer characters.
>
>
> On Saturday, November 3, 2012 3:27:24 PM UTC-7, CGAT wrote:
>>
>> It would be nice if clojure.core/conj had a unary implementation
>>
>>([coll] coll)
>>
>> The motivating use case is when one is conjoining sequences of
>> items to a collection all at once:
>>
>>(apply conj coll seqable)
>>
>> such as (apply conj #{1 2 3} [2 4 6 8 10]).
>> Currently (1.4.0), this will raise an arity exception
>> if the seqable object is empty:
>>
>>(apply conj #{1 2 3} [])
>>
>> necessitating an awkward empty? check when,
>> for instance, the sequence is computed or passed in.
>>
>> It seems to me that making unary conj the identity is both
>> a natural interpretation and essentially cost free, while
>> making this use case much more convenient.
>> Moreover, it is consistent with clojure.core/disj for sets
>> which does act like this
>>
>> (apply disj #{1 2 3} []) -> #{1 2 3}
>>
>> and has an identity unary implementation.
>>
>> Comments?
>>
>>
> --
> 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
--
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
Re: Proposal/request: Give clojure.core/conj a unary implementation
That's a good point Alan, and I should have mentioned into.
But this came up for me in a situation relevant to Ben's' point.
I was adding or removing a computed sequence of elements of a set based on
some other
input and was using either conj or disj depending on that input, with apply.
It worked on the disj's but failed on the conj's, of course.
I could in this case have made the check at the time of change and used
into or disj
as appropriate, but in general, one might be passed just the functions as
Ben suggests.
Even if there is a better way to handle this problem in this case, I don't
see it as an argument
against the unary conj. The unary conj is conceptually natural, is
consistent with disj, does not
mask bugs, appears to really have no practical downside, and seems to have
at least one useful application.
Why not include it?
On Saturday, November 3, 2012 7:43:22 PM UTC-4, Ben wrote:
>
> There might be a reason to write (apply f coll seqable) in a situation
> in which f might be conj, though.
>
> On Sat, Nov 3, 2012 at 4:25 PM, Alan Malloy >
> wrote:
> > There is never a reason to write (apply conj ...). Instead, use `into`,
> > which does the same thing but faster and with fewer characters.
> >
> >
> > On Saturday, November 3, 2012 3:27:24 PM UTC-7, CGAT wrote:
> >>
> >> It would be nice if clojure.core/conj had a unary implementation
> >>
> >>([coll] coll)
> >>
> >> The motivating use case is when one is conjoining sequences of
> >> items to a collection all at once:
> >>
> >>(apply conj coll seqable)
> >>
> >> such as (apply conj #{1 2 3} [2 4 6 8 10]).
> >> Currently (1.4.0), this will raise an arity exception
> >> if the seqable object is empty:
> >>
> >>(apply conj #{1 2 3} [])
> >>
> >> necessitating an awkward empty? check when,
> >> for instance, the sequence is computed or passed in.
> >>
> >> It seems to me that making unary conj the identity is both
> >> a natural interpretation and essentially cost free, while
> >> making this use case much more convenient.
> >> Moreover, it is consistent with clojure.core/disj for sets
> >> which does act like this
> >>
> >> (apply disj #{1 2 3} []) -> #{1 2 3}
> >>
> >> and has an identity unary implementation.
> >>
> >> Comments?
> >>
> >>
> > --
> > 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
>
>
>
> --
> 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
Re: Proposal/request: Give clojure.core/conj a unary implementation
> > It would be nice if clojure.core/conj had a unary implementation > >([coll] coll) > I support this. Reasons: 1. It makes sense, adding nothing to something should give back the something. 2. It's consistent with disj as mentioned. 3. Supporting edge cases like this can make some algorithms much more succinct. (as in CGAT's code - no need to check for extra cases) Compare: (conj nil 3) => (3) Jonathan -- 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
Re: Proposal/request: Give clojure.core/conj a unary implementation
On Sunday, November 4, 2012 12:43:22 AM UTC+1, Ben wrote: > There might be a reason to write (apply f coll seqable) in a situation > in which f might be conj, though. > One may use (reduce f coll seqable) instead, if that makes sense semantically in that context. -- 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
Re: Proposal/request: Give clojure.core/conj a unary implementation
I created CLJ-1103 and attached a patch that makes this change, as well as related changes to conj! assoc assoc! and dissoc! (dissoc, disj and disj! already handled these cases). http://dev.clojure.org/jira/browse/CLJ-1103 Andy On Nov 4, 2012, at 5:52 AM, Jonathan Fischer Friberg wrote: > It would be nice if clojure.core/conj had a unary implementation > >([coll] coll) > > I support this. Reasons: > > 1. It makes sense, adding nothing to something should give back the something. > 2. It's consistent with disj as mentioned. > 3. Supporting edge cases like this can make some algorithms much more > succinct. >(as in CGAT's code - no need to check for extra cases) >Compare: (conj nil 3) => (3) > > Jonathan > > -- > 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 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
Re: Proposal/request: Give clojure.core/conj a unary implementation
+1
2012年11月4日日曜日 7時27分24秒 UTC+9 CGAT:
>
> It would be nice if clojure.core/conj had a unary implementation
>
>([coll] coll)
>
> The motivating use case is when one is conjoining sequences of
> items to a collection all at once:
>
>(apply conj coll seqable)
>
> such as (apply conj #{1 2 3} [2 4 6 8 10]).
> Currently (1.4.0), this will raise an arity exception
> if the seqable object is empty:
>
>(apply conj #{1 2 3} [])
>
> necessitating an awkward empty? check when,
> for instance, the sequence is computed or passed in.
>
> It seems to me that making unary conj the identity is both
> a natural interpretation and essentially cost free, while
> making this use case much more convenient.
> Moreover, it is consistent with clojure.core/disj for sets
> which does act like this
>
> (apply disj #{1 2 3} []) -> #{1 2 3}
>
> and has an identity unary implementation.
>
> Comments?
>
>
>
--
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
