Re: bug affecting clojure.core/bean?
Seems I got it totally wrong :-( I'll re-read the lazy page ... Sorry, -- Laurent 2009/2/18 David Nolen > If I've been following things correct: > rest _used_ to force the seq, it does no longer. > next forces the seq > > In my own mind i'm thinking next to mean (return the seq with the next > value computed), rest now means just give me the uncomputed remaining values > of the seq. > > On Wed, Feb 18, 2009 at 12:00 PM, Laurent PETIT > wrote: > >> >> >> 2009/2/18 Mark Volkmann >> >> >>> On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey >>> wrote: >>> > >>> > On Feb 18, 11:04 am, Chouser wrote: >>> >> On Wed, Feb 18, 2009 at 12:35 AM, Rob wrote: >>> >> >>> >> > I'm wondering if I found a bug. I have the latest source from svn >>> >> > (r1291). >>> >> >>> >> > user=> (bean 1) >>> >> > java.lang.IllegalArgumentException: Wrong number of args passed to: >>> >> > core$bean--5161$fn--5179$thisfn >>> >> >>> >> You sure did. The conversion to lazy-seq code appears to introduce a >>> >> paren typo and an incorrect nil pun. Patch attached. >>> >> >>> > >>> > Patch applied, svn 1293 - thanks! >>> > >>> >> Rich, I think it'd be pretty useful to have as you mentioned in IRC a >>> >> variant of & destructuring that provided an unforced lazy-seq. It >>> >> seems pretty common to want, in the body of a lazy-seq, a destructured >>> >> 'first' but an unforced 'rest'. This is already the third or fourth >>> >> time I've wanted to be able to do something like: >>> >> >>> >> (fn thisfn [plseq] >>> >> (lazy-seq >>> >> (when-let [[pkey &rest etc] plseq] >>> >> (cons (new clojure.lang.MapEntry pkey (v pkey)) >>> >> (thisfn etc) >>> >> >>> > >>> > Yes, sure. It just comes down to the name: >>> > >>> > &rest >>> > && >>> > >>> > others? >>> >>> Of those I prefer &rest because its meaning is more explicit. >> >> >> Maybe I miss the point totally, but didn't the recent change give the >> function 'next the meaning of not forcing the seq ? >> >> So &next instead of &rest ? ... and maybe either &rest or &next , and not >> just & anymore ? >> >> >>> >>> >>> -- >>> R. Mark Volkmann >>> Object Computing, Inc. >>> >>> >>> >> >> >> >> > > > > --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
If I've been following things correct: rest _used_ to force the seq, it does no longer. next forces the seq In my own mind i'm thinking next to mean (return the seq with the next value computed), rest now means just give me the uncomputed remaining values of the seq. On Wed, Feb 18, 2009 at 12:00 PM, Laurent PETIT wrote: > > > 2009/2/18 Mark Volkmann > > >> On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey >> wrote: >> > >> > On Feb 18, 11:04 am, Chouser wrote: >> >> On Wed, Feb 18, 2009 at 12:35 AM, Rob wrote: >> >> >> >> > I'm wondering if I found a bug. I have the latest source from svn >> >> > (r1291). >> >> >> >> > user=> (bean 1) >> >> > java.lang.IllegalArgumentException: Wrong number of args passed to: >> >> > core$bean--5161$fn--5179$thisfn >> >> >> >> You sure did. The conversion to lazy-seq code appears to introduce a >> >> paren typo and an incorrect nil pun. Patch attached. >> >> >> > >> > Patch applied, svn 1293 - thanks! >> > >> >> Rich, I think it'd be pretty useful to have as you mentioned in IRC a >> >> variant of & destructuring that provided an unforced lazy-seq. It >> >> seems pretty common to want, in the body of a lazy-seq, a destructured >> >> 'first' but an unforced 'rest'. This is already the third or fourth >> >> time I've wanted to be able to do something like: >> >> >> >> (fn thisfn [plseq] >> >> (lazy-seq >> >> (when-let [[pkey &rest etc] plseq] >> >> (cons (new clojure.lang.MapEntry pkey (v pkey)) >> >> (thisfn etc) >> >> >> > >> > Yes, sure. It just comes down to the name: >> > >> > &rest >> > && >> > >> > others? >> >> Of those I prefer &rest because its meaning is more explicit. > > > Maybe I miss the point totally, but didn't the recent change give the > function 'next the meaning of not forcing the seq ? > > So &next instead of &rest ? ... and maybe either &rest or &next , and not > just & anymore ? > > >> >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. >> >> >> > > > > > --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
2009/2/18 Mark Volkmann > > On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey > wrote: > > > > On Feb 18, 11:04 am, Chouser wrote: > >> On Wed, Feb 18, 2009 at 12:35 AM, Rob wrote: > >> > >> > I'm wondering if I found a bug. I have the latest source from svn > >> > (r1291). > >> > >> > user=> (bean 1) > >> > java.lang.IllegalArgumentException: Wrong number of args passed to: > >> > core$bean--5161$fn--5179$thisfn > >> > >> You sure did. The conversion to lazy-seq code appears to introduce a > >> paren typo and an incorrect nil pun. Patch attached. > >> > > > > Patch applied, svn 1293 - thanks! > > > >> Rich, I think it'd be pretty useful to have as you mentioned in IRC a > >> variant of & destructuring that provided an unforced lazy-seq. It > >> seems pretty common to want, in the body of a lazy-seq, a destructured > >> 'first' but an unforced 'rest'. This is already the third or fourth > >> time I've wanted to be able to do something like: > >> > >> (fn thisfn [plseq] > >> (lazy-seq > >> (when-let [[pkey &rest etc] plseq] > >> (cons (new clojure.lang.MapEntry pkey (v pkey)) > >> (thisfn etc) > >> > > > > Yes, sure. It just comes down to the name: > > > > &rest > > && > > > > others? > > Of those I prefer &rest because its meaning is more explicit. Maybe I miss the point totally, but didn't the recent change give the function 'next the meaning of not forcing the seq ? So &next instead of &rest ? ... and maybe either &rest or &next , and not just & anymore ? > > > -- > R. Mark Volkmann > Object Computing, Inc. > > > > --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
Or maybe: &next ??? :- Frantisek On Feb 18, 5:27 pm, Rich Hickey wrote: > On Feb 18, 11:04 am, Chouser wrote: > > > On Wed, Feb 18, 2009 at 12:35 AM, Rob wrote: > > > > I'm wondering if I found a bug. I have the latest source from svn > > > (r1291). > > > > user=> (bean 1) > > > java.lang.IllegalArgumentException: Wrong number of args passed to: > > > core$bean--5161$fn--5179$thisfn > > > You sure did. The conversion to lazy-seq code appears to introduce a > > paren typo and an incorrect nil pun. Patch attached. > > Patch applied, svn 1293 - thanks! > > > Rich, I think it'd be pretty useful to have as you mentioned in IRC a > > variant of & destructuring that provided an unforced lazy-seq. It > > seems pretty common to want, in the body of a lazy-seq, a destructured > > 'first' but an unforced 'rest'. This is already the third or fourth > > time I've wanted to be able to do something like: > > > (fn thisfn [plseq] > > (lazy-seq > > (when-let [[pkey &rest etc] plseq] > > (cons (new clojure.lang.MapEntry pkey (v pkey)) > > (thisfn etc) > > Yes, sure. It just comes down to the name: > > &rest > && > > others? > > Rich --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey wrote: > > On Feb 18, 11:04 am, Chouser wrote: >> On Wed, Feb 18, 2009 at 12:35 AM, Rob wrote: >> >> > I'm wondering if I found a bug. I have the latest source from svn >> > (r1291). >> >> > user=> (bean 1) >> > java.lang.IllegalArgumentException: Wrong number of args passed to: >> > core$bean--5161$fn--5179$thisfn >> >> You sure did. The conversion to lazy-seq code appears to introduce a >> paren typo and an incorrect nil pun. Patch attached. >> > > Patch applied, svn 1293 - thanks! > >> Rich, I think it'd be pretty useful to have as you mentioned in IRC a >> variant of & destructuring that provided an unforced lazy-seq. It >> seems pretty common to want, in the body of a lazy-seq, a destructured >> 'first' but an unforced 'rest'. This is already the third or fourth >> time I've wanted to be able to do something like: >> >> (fn thisfn [plseq] >> (lazy-seq >> (when-let [[pkey &rest etc] plseq] >> (cons (new clojure.lang.MapEntry pkey (v pkey)) >> (thisfn etc) >> > > Yes, sure. It just comes down to the name: > > &rest > && > > others? Of those I prefer &rest because its meaning is more explicit. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
On Feb 18, 11:04 am, Chouser wrote: > On Wed, Feb 18, 2009 at 12:35 AM, Rob wrote: > > > I'm wondering if I found a bug. I have the latest source from svn > > (r1291). > > > user=> (bean 1) > > java.lang.IllegalArgumentException: Wrong number of args passed to: > > core$bean--5161$fn--5179$thisfn > > You sure did. The conversion to lazy-seq code appears to introduce a > paren typo and an incorrect nil pun. Patch attached. > Patch applied, svn 1293 - thanks! > Rich, I think it'd be pretty useful to have as you mentioned in IRC a > variant of & destructuring that provided an unforced lazy-seq. It > seems pretty common to want, in the body of a lazy-seq, a destructured > 'first' but an unforced 'rest'. This is already the third or fourth > time I've wanted to be able to do something like: > > (fn thisfn [plseq] > (lazy-seq > (when-let [[pkey &rest etc] plseq] > (cons (new clojure.lang.MapEntry pkey (v pkey)) > (thisfn etc) > Yes, sure. It just comes down to the name: &rest && others? Rich --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
On Wed, Feb 18, 2009 at 12:35 AM, Rob wrote: > > I'm wondering if I found a bug. I have the latest source from svn > (r1291). > > user=> (bean 1) > java.lang.IllegalArgumentException: Wrong number of args passed to: > core$bean--5161$fn--5179$thisfn You sure did. The conversion to lazy-seq code appears to introduce a paren typo and an incorrect nil pun. Patch attached. Rich, I think it'd be pretty useful to have as you mentioned in IRC a variant of & destructuring that provided an unforced lazy-seq. It seems pretty common to want, in the body of a lazy-seq, a destructured 'first' but an unforced 'rest'. This is already the third or fourth time I've wanted to be able to do something like: (fn thisfn [plseq] (lazy-seq (when-let [[pkey &rest etc] plseq] (cons (new clojure.lang.MapEntry pkey (v pkey)) (thisfn etc) --Chouser --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~--- commit 539242b543c99bf430c5b821f9c4a0ca769a8a26 Author: Chouser Date: Wed Feb 18 10:57:25 2009 -0500 Fix bean lazy-seq diff --git a/trunk/src/clj/clojure/core_proxy.clj b/trunk/src/clj/clojure/core_proxy.clj index 2b2d01d..120ffbf 100644 --- a/trunk/src/clj/clojure/core_proxy.clj +++ b/trunk/src/clj/clojure/core_proxy.clj @@ -340,11 +340,11 @@ (count [] (count pmap)) (assoc [k v] (assoc (snapshot) k v)) (without [k] (dissoc (snapshot) k)) - (seq [] ((fn thisfn [pseq] + (seq [] ((fn thisfn [plseq] (lazy-seq - (when pseq + (when-let [pseq (seq plseq)] (cons (new clojure.lang.MapEntry (first pseq) (v (first pseq))) - (thisfn (rest pseq) (keys pmap))) + (thisfn (rest pseq)) (keys pmap))
bug affecting clojure.core/bean?
Hi, I'm wondering if I found a bug. I have the latest source from svn (r1291). user=> (bean 1) java.lang.IllegalArgumentException: Wrong number of args passed to: core$bean--5161$fn--5179$thisfn It used to show the bean properties of the java.lang.Integer. Rob --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
