I created a slightly modified version of clojure.set and have released it
as funjible.set
More info here, if you are curious:
https://github.com/jafingerhut/funjible
Andy
On Mon, Sep 30, 2013 at 8:00 PM, splondike <splond...@gmail.com> wrote:
> If it's a case of prioritization, that makes sense. I was going to suggest
> raising a bug, and then triaging it as low priority, but I notice that
> there is already a declined JIRA
> issue<http://dev.clojure.org/jira/browse/CLJ-810>.
> I apologize for not checking there before adding this thread.
>
> I'm very new to Clojure which is why I wasn't sure whether this kind of
> runtime defensive programming was the norm, and you seem to suggest that
> it's not. A static checker/lint would of course be preferable if it could
> catch these kinds of programmer errors.
>
> I notice that there's a very successful crowdsource fund going toward
> core.typed <http://www.indiegogo.com/projects/typed-clojure>, perhaps
> this static checker will be a reality this time next year.
>
> On Monday, September 30, 2013 5:55:01 PM UTC-4, stuart....@gmail.comwrote:
>
>> Hi splondike,
>>
>> I disagree with your arguments about what is sensible -- *any* behavior
>> is sensible when you violate the contract of an API.
>>
>> Of course everybody could get behind the "throwing the error" plan if the
>> cost of throwing that error was zero: zero assessment cost, zero
>> development cost, zero runtime cost, and zero maintenance cost. But those
>> costs are not zero, so as a screener I have to ask myself "should I spend
>> my next half hour looking at this issue, which impacts only broken
>> programs, or one of the (currently 20) screenable tickets, many of which
>> impact *correct* programs?
>>
>> That said, perhaps core.typed can help us here. I believe core.typed can
>> allow us to check programs and detect these kinds of errors, without
>> runtime impact (and without any change to Clojure at all.) I am doing some
>> experiments with exactly this case, and will follow up on a separate thread.
>>
>> Regards,
>> Stu
>>
>>
>> On Mon, Sep 30, 2013 at 2:20 PM, splondike <splo...@gmail.com> wrote:
>>
>>> Thanks for the comment. The current behaviour is sensible for the code
>>> branch where the second argument is the same length or shorter than the
>>> first (see my first post). It is the other branch that does not do what you
>>> would expect. My real issue though is how the behaviour changes
>>> dramatically once we hit this branch (for non set args).
>>>
>>> The original author of the
>>> patch<https://github.com/clojure/clojure/commit/60e805dc7bd42b7b26fc8c8925bf71079729e0e6>which
>>> produced this behaviour noted
>>> this shortcoming himself <http://dev.clojure.org/jira/browse/CLJ-67>,
>>> and only refrained from implementing the check due to being unsure about
>>> the performance penalty.
>>>
>>> I think that people who are currently relying on this function working
>>> for non set arguments are playing a risky game (which, like me, they're
>>> probably not aware of) due to this sudden change in behaviour. I would
>>> argue that existing users would be better served by having an error thrown
>>> rather than having unexpected data generated which is hard to track down.
>>>
>>> On Sunday, September 29, 2013 7:05:17 PM UTC-4, stuart....@gmail.comwrote:
>>>>
>>>> I think the bar for such an enhancement is fairly high, and the value
>>>> delivered fairly low. It isn't so much the impact of assessing this single
>>>> change, as the impact of managing the universe of such changes.
>>>>
>>>> Regards,
>>>> Stu
>>>>
>>> --
>>> --
>>> 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/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.
>
--
--
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.
