Thanks for checking Steve.
Ambrose
On Sun, Jul 27, 2014 at 5:09 AM, Steve Miner wrote:
> I tried the latest patch from Ambrose for CLJ-1475. Looks good to me.
> Well done.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this
Awesome job, everyone! You guys rock!
Michael
On Saturday, July 26, 2014 3:09:56 PM UTC-6, miner wrote:
>
> I tried the latest patch from Ambrose for CLJ-1475. Looks good to me.
> Well done.
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To
I tried the latest patch from Ambrose for CLJ-1475. Looks good to me. Well
done.
--
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 b
I reuploaded the patch 3 times for various reasons, please refresh to get
the latest.
Thanks,
Ambrose
On Sun, Jul 27, 2014 at 12:44 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> I handled preconditions, and added a new patch.
>
> Thanks,
> Ambrose
>
>
> On Sat, Jul 26, 2
I handled preconditions, and added a new patch.
Thanks,
Ambrose
On Sat, Jul 26, 2014 at 11:52 PM, Michael O'Keefe <
michael.p.oke...@gmail.com> wrote:
> Nice work everyone on the patches -- I'm very impressed!
>
> There's been a couple of questions about how to interpret this. My thought
> is w
Nice work everyone on the patches -- I'm very impressed!
There's been a couple of questions about how to interpret this. My thought
is we should try and mimic an explicit recursion:
In other words:
(defn g
[xs acc]
{:pre [(or (nil? xs) (sequential? xs)) (number? acc)]
:post [(number? %)]
Doh! I forgot preconditions :D
Fixing..
Ambrose
On Sat, Jul 26, 2014 at 11:30 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> Hi Steve,
>
> I think I got it right, please have a look:
> http://dev.clojure.org/jira/browse/CLJ-1475
>
> Thanks,
> Ambrose
>
>
> On Sat, Jul 26,
Hi Steve,
I think I got it right, please have a look:
http://dev.clojure.org/jira/browse/CLJ-1475
Thanks,
Ambrose
On Sat, Jul 26, 2014 at 10:38 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> I'll give it a shot..
>
>
> On Sat, Jul 26, 2014 at 9:59 PM, Steve Miner wrote:
I'll give it a shot..
On Sat, Jul 26, 2014 at 9:59 PM, Steve Miner wrote:
> I'm giving up on this bug. My approach was adding too much complexity to
> handle an edge case. Hacking the fn macro is not as easy as it looks. :-)
>
> I recommend the loop work-around if you run into this problem.
I'm giving up on this bug. My approach was adding too much complexity to
handle an edge case. Hacking the fn macro is not as easy as it looks. :-)
I recommend the loop work-around if you run into this problem. Or refactor the
recursive code into a separate function and call it from another fu
The intuitive behaviour (to me) would be that :pre is applied to every
recur as stated and post is applied only to the eventually returned value
and this *_should_ *be considered a bug. My logic is as follows:
1. A (pure, for simplicity of this argument) function, in the absence of
erroneou
Yes :pre should apply to every recur, like usual without :post.
user=> ((fn [a] {:pre [(number? a)]} (recur 'a)) 1)
AssertionError Assert failed: (number? a) user/eval5376/fn--5377
(form-init687485383035947214.clj:1)
That probably means that if :post is present, the preconditions should be
moved
My first patch was buggy with destructured args so I had to withdraw it.
While working on a better patch, I came up against a related issue: Should the
:pre conditions apply to every recur "call". I'm saying no. The :pre
conditions should be checked just once on the initial function call and ne
I hear what you're saying. Given that recur is a special form, there exists
a closed set of exceptions to be worked around like this even
theoretically, so I could see the argument for having this patch accepted
and not opening pandora's box.
On Friday, July 25, 2014 11:36:36 AM UTC-4, Michael
Adrian, thanks for your input on whether this is a bug or not. Your
viewpoint may yet prove to be the "accepted" one but I still felt like the
original way I wrote the function should have meant:
. In that sense, it feels
like my original function g should have been semantically equivalent to
Ticket CLJ-1475 with my patch.
http://dev.clojure.org/jira/browse/CLJ-1475
--
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 patien
Now that Steve mentions it, I have fixed this kind of issue in my own defn
macros. IIRC adding an inner loop form did the trick.
Thanks,
Ambrose
On Fri, Jul 25, 2014 at 10:35 PM, wrote:
> I do not believe this should be considered a bug. Recur is a special form
> that rebinds the bindings at t
I do not believe this should be considered a bug. Recur is a special form
that rebinds the bindings at the point of recursion with new values. It
does not return a value. It does not get evaluated in the normal sense of
the word. You cannot type check a value on a valueless expression. Just
thi
Thanks Bob, Steve, and Andy. I was trying to get logged into JIRA to file
the bug report but I seem to be having a heck of a time -- I have a CA and
am signed up at dev.clojure.org but when I try to log into JIRA, it gives
me a nice "System Error" saying " user should not be null!". I've run out
I will call it a bug. It's definitely surprising to the user, and therefore
worthy of a ticket. On first glance, it seems that the fix isn't too hard. In
core.clj where the macro fn is redefined, we just need to wrap the section that
handles the post condition either with a loop* or a fn* so t
Sorry, I forgot the following disclaimer: I am in no way an official voice
for what will or will not be changed in Clojure in the future. I am merely
an interested observer of what has changed in Clojure in the past. I've
created and edited some tickets, written some Clojure patches, some of
whic
On Jul 25, 2014, at 12:27 AM, Michael O'Keefe
wrote:
> Andy, good advice and I agree. Thanks. I'll think on it then.
Would you want one of your users going though this kind of thought process: I
won't file a ticked because I don't think it can be fixed? It's a bug, file the
ticket. At the ve
Ambrose, thanks -- I was NOT aware of that. Sorry I misunderstood your
original.
Andy, good advice and I agree. Thanks. I'll think on it then.
Cheers,
Michael
On Thursday, July 24, 2014 10:20:57 PM UTC-6, Ambrose Bonnaire-Sergeant
wrote:
>
> On Fri, Jul 25, 2014 at 12:13 PM, Michael O'Keefe
I do not see any straightforward change to Clojure that would enable this
to work (someone else might, though). Given that adding a loop form inside
the function is a fairly straightforward workaround to the limitation, and
the difficulty of enhancing it to avoid the limitation, I would personally
On Fri, Jul 25, 2014 at 12:13 PM, Michael O'Keefe <
michael.p.oke...@gmail.com> wrote:
>
>
>- Ambrose, both (number? %) and number? are valid post-condition
>forms; the issue is that the post-condition check bumps the recur out of
>tail position
>
>
>
I'm aware of the context, I just wa
Thank you everyone, for the replies:
- The macro expansion was helpful
- Andy, thanks for pointing out where the lines are -- very helpful
- Ambrose, both (number? %) and number? are valid post-condition forms;
the issue is that the post-condition check bumps the recur out of tail
Hi Michael,
I believe your post condition should read {:post [(number? %)]}.
Thanks,
Ambrose
On Fri, Jul 25, 2014 at 6:56 AM, Michael O'Keefe wrote:
> Hello All,
>
> I encountered the following behavior in Clojure 1.6 and wanted to check if
> it should be considered a bug or not. I would say
I do not know whether it is considered a bug or not, but it is definitely
caused by the postcondition handling causing the recur to be knocked out of
tail position. Here is a reference to the code:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L4185-L4192
Andy
On Thu,
Indeed this is the case and no; I would not consider it a bug. Because you
have specified a post condition on the return value, the clojure.core/fn
macro is macroexpanding properly to support that post condition. By
recursively macroexpanding the form, you can see the what the form will
eventua
Hello All,
I encountered the following behavior in Clojure 1.6 and wanted to check if
it should be considered a bug or not. I would say yes but wanted to double
check on the list first.
Here's a minimal test case that elicited the error:
(defn f
[xs acc]
(if (nil? xs)
acc
(recur (
30 matches
Mail list logo
