[Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Fellow Chickeneers, a few weeks ago I (more or less silently) released the lazy-seq egg which I hereby retroactively announce to the public. For a bit of discussion on why I made it and how it compares to SRFI 41 streams, read my blog article about it here: http://ceaude.twoticketsplease.de/articles/lazy-sequences-in-scheme.html Hope it's useful to someone! Moritz ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
This is great, Moritz; thanks! I've missed the transparent laziness of seqs in Scheme, too; I never use SRFI-41 because of the bizarre parallel-universe SRFI-1 that they had to create. In fact, SRFI-41 is a parallel Scheme due to the fundamental things they had to re-implement: cons, lambda, let, null, match, &c. Stream-cons, stream-lambda, &c. are so fucking verbose! Quoth Moritz Heidkamp on Pungenday, the 7th of Confusion: > Fellow Chickeneers, > > a few weeks ago I (more or less silently) released the lazy-seq egg > which I hereby retroactively announce to the public. For a bit of > discussion on why I made it and how it compares to SRFI 41 streams, read > my blog article about it here: > http://ceaude.twoticketsplease.de/articles/lazy-sequences-in-scheme.html > > Hope it's useful to someone! > > Moritz > > ___ > Chicken-users mailing list > Chicken-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-users > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Peter Danenberg writes: > This is great, Moritz; thanks! You're welcome, glad you like it! > In fact, SRFI-41 is a parallel Scheme due to the fundamental things > they had to re-implement: cons, lambda, let, null, match, &c. > > Stream-cons, stream-lambda, &c. are so fucking verbose! Exactly my sentiment. I really wonder what went wrong in the design process of that SRFI. Or perhaps we're overlooking something fundamental and it's really the best way to do it? > Quoth Moritz Heidkamp on Pungenday, the 7th of Confusion: Happy belated Syaday Moritz ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Peter Danenberg scripsit: > Stream-cons, stream-lambda, &c. are so fucking verbose! Only two letters longer than lazy-length, lazy-map, lazy-head, lazy-tail, etc. Why not a macro with-lazy that rewrites car, cdr, lambda, cons, etc. within its body? -- Here lies the Christian,John Cowan judge, and poet Peter, http://www.ccil.org/~cowan Who broke the laws of God co...@ccil.org and man and metre. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
On Sun, Jun 3, 2012 at 4:05 PM, John Cowan wrote: > Peter Danenberg scripsit: > >> Stream-cons, stream-lambda, &c. are so fucking verbose! > > Only two letters longer than lazy-length, lazy-map, lazy-head, lazy-tail, etc. > > Why not a macro with-lazy that rewrites car, cdr, lambda, cons, etc. within > its body? Unhygienic! Heathen! :) Although you have the right idea. First, the srfi-41 vs. lazy-seq comparison in the blog post was an apples to oranges comparison of a clumsy letrec vs a compact named let. If we rewrite the srfi-41 version in the same style as the lazy-seq one, then we get: (define multiples-of-three (let next ((n 3)) (stream-cons n (next (+ n 3) This is actually more compact - just _remove_ the lazy-seq reference, and s/cons/stream-cons/. Now, if we have a whole program or library which consistently uses lazy streams instead of lists, we can import srfi-41 renaming all the stream-* bindings by removing the stream- prefix (this is where the drop-prefix you like comes in handy). Then you have a normal Scheme library using car/cdr/cons etc. which happens to be using streams (and you could change the import if needed to toggle between the two). Introducing an extra syntactic wrapper just makes this more complicated. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Quoth Alex Shinn on Prickle-Prickle, the 8th of Confusion: > Now, if we have a whole program or library which consistently uses > lazy streams instead of lists, we can import srfi-41 renaming all > the stream-* bindings by removing the stream- prefix. Interesting idea; the attached program will, however, reliably cause Chicken to SIGSEGV. (require-library srfi-41) (import (rename srfi-41 (stream? list?) (stream-pair? pair?) (stream-null? null?) (stream-occupied? occupied?) (stream-null null) (stream-cons cons) (stream-lambda lambda) (stream-car car) (stream-cdr cdr) (stream-of constantly) (stream-let let) (stream-match match) (stream-append append) (stream-concat concat) (stream-drop drop) (stream-drop-while drop-while) (stream-filter filter) (stream-fold fold) (stream-for-each for-each) (stream-map map) (stream-from from) (stream-iterate iterate) (stream-length length) (stream-range range) (stream-ref ref) (stream-reverse reverse) (stream-scan scan) (stream-unfold unfold) (stream-unfolds unfolds) (stream-zip zip) (stream-intersperse intersperse) (stream-split split) (stream-member member) (stream-partition partition) (stream-finds finds) (stream-find find) (stream-remove remove) (stream-every every) (stream-any any) (stream-and and) (stream-or or) (stream-fold-right fold-right) (stream-fold-right-one fold-right-one) (stream-assoc assoc) (stream-equal? equal?) (stream-quick-sort quick-sort) (stream-insertion-sort insertion-sort) (stream-maximum maximum) (stream-minimum minimum) (stream-max max) (stream-min min) (stream-sum sum) (odd-numbers-stream odd-numbers) (even-numbers-stream even-numbers) (cardinal-numbers-stream cardinal-numbers) (natural-numbers-stream natural-numbers) (prime-numbers-stream prime-numbers) (hamming-sequence-stream hamming-sequence))) (define (factorial n) (ref (scan * 1 (from 1))) n) (factorial 3) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
On Sun, Jun 3, 2012 at 5:31 PM, Peter Danenberg wrote: > Quoth Alex Shinn on Prickle-Prickle, the 8th of Confusion: >> Now, if we have a whole program or library which consistently uses >> lazy streams instead of lists, we can import srfi-41 renaming all >> the stream-* bindings by removing the stream- prefix. > > Interesting idea; the attached program will, however, reliably cause > Chicken to SIGSEGV. You mis-matched your parens - it should be: (define (factorial n) (ref (scan * 1 (from 1)) n)) ^^^ Presumably you compiled to get a segfault - the interpreter gives an arity error. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Quoth Alex Shinn on Prickle-Prickle, the 8th of Confusion: > You mis-matched your parens - it should be: > > (define (factorial n) > (ref (scan * 1 (from 1)) n)) >^^^ > > Presumably you compiled to get a segfault - the interpreter gives an > arity error. Interesting; I took the example straight off of the wiki.[1] It gives a segfault for me in csi, even with the adjusted placement of n. Footnotes: [1] http://wiki.call-cc.org/eggref/4/srfi-41#examples ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
* Peter Danenberg [120603 11:12]: > Quoth Alex Shinn on Prickle-Prickle, the 8th of Confusion: > > You mis-matched your parens - it should be: > > > > (define (factorial n) > > (ref (scan * 1 (from 1)) n)) > >^^^ > > > > Presumably you compiled to get a segfault - the interpreter gives an > > arity error. > > Interesting; I took the example straight off of the wiki.[1] It gives a > segfault for me in csi, even with the adjusted placement of n. Which version of chicken is this? I get the arity error for both csi and compiled version for chicken master. I have fixed the example on the wiki. Thanks for noticing it! Christian -- 9 out of 10 voices in my head say, that I am crazy, one is humming. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Quoth Christian Kellermann on Prickle-Prickle, the 8th of Confusion: > Which version of chicken is this? I get the arity error for both csi > and compiled version for chicken master. It's a vanilla 4.7.0: λ ~/prg/scm/aima-chicken/ master* chicken -version (c)2008-2011 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.7.0 linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] compiled 2011-08-10 on localhost.localdomain (Linux) It segfaults on compiled as well as interpreted Chicken; as someone mentioned in #chicken, by the way, we've been seeing a lot of SEGVs lately. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
* Peter Danenberg [120603 11:30]: > Quoth Christian Kellermann on Prickle-Prickle, the 8th of Confusion: > > Which version of chicken is this? I get the arity error for both csi > > and compiled version for chicken master. > > It's a vanilla 4.7.0: > > ?? ~/prg/scm/aima-chicken/ master* chicken -version > (c)2008-2011 The Chicken Team > (c)2000-2007 Felix L. Winkelmann > Version 4.7.0 > linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] > compiled 2011-08-10 on localhost.localdomain (Linux) > > It segfaults on compiled as well as interpreted Chicken; as someone > mentioned in #chicken, by the way, we've been seeing a lot of SEGVs > lately. Yes, as we have turned on specialisation for chicken core by default. This uncovers bugs in the specialisation pass itself. The situation should be back to normal soon. In your case however, this seems to be an old bug that has been fixed in master. Thanks again, Christian -- 9 out of 10 voices in my head say, that I am crazy, one is humming. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Alex Shinn writes: > First, the srfi-41 vs. lazy-seq comparison in the > blog post was an apples to oranges comparison > of a clumsy letrec vs a compact named let. If we > rewrite the srfi-41 version in the same style as > the lazy-seq one, then we get: > > (define multiples-of-three > (let next ((n 3)) > (stream-cons n (next (+ n 3) Ah, thanks for pointing this out -- I was really surprised that I couldn't find a simpler way to express this with SRFI 41. I'll update the blog article accordingly. > Now, if we have a whole program or library which > consistently uses lazy streams instead of lists, > we can import srfi-41 renaming all the stream-* > bindings by removing the stream- prefix (this is > where the drop-prefix you like comes in handy). > Then you have a normal Scheme library using > car/cdr/cons etc. which happens to be using > streams (and you could change the import if > needed to toggle between the two). Fair enough. I was actually considering to provide a module which exports the functions without the `lazy-' prefix, perhaps with a `*' suffix so that it can be conviently loaded alongside regular Scheme. The same could be done with SRFI 41, of course. What I don't quite understand is why SRFI 41 also defines stream-let, stream-lambda etc. Do you know of a good reason why one would want those? Moritz ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
Alex Shinn scripsit: > Now, if we have a whole program or library which consistently uses > lazy streams instead of lists, we can import srfi-41 renaming all the > stream-* bindings by removing the stream- prefix (this is where the > drop-prefix you like comes in handy). Yes, it allows Scheme to participate in the "one interface, multiple implementations" pattern. But it would work a lot better if we had syntactic, embeddable modules. -- John Cowanhttp://www.ccil.org/~cowan "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
On Sun, Jun 3, 2012 at 8:31 PM, Moritz Heidkamp wrote: > Alex Shinn writes: >> First, the srfi-41 vs. lazy-seq comparison in the >> blog post was an apples to oranges comparison >> of a clumsy letrec vs a compact named let. If we >> rewrite the srfi-41 version in the same style as >> the lazy-seq one, then we get: >> >> (define multiples-of-three >> (let next ((n 3)) >> (stream-cons n (next (+ n 3) > > Ah, thanks for pointing this out -- I was really surprised that I > couldn't find a simpler way to express this with SRFI 41. I'll update > the blog article accordingly. > > >> Now, if we have a whole program or library which >> consistently uses lazy streams instead of lists, >> we can import srfi-41 renaming all the stream-* >> bindings by removing the stream- prefix (this is >> where the drop-prefix you like comes in handy). >> Then you have a normal Scheme library using >> car/cdr/cons etc. which happens to be using >> streams (and you could change the import if >> needed to toggle between the two). > > Fair enough. I was actually considering to provide a module which > exports the functions without the `lazy-' prefix, perhaps with a `*' > suffix so that it can be conviently loaded alongside regular Scheme. The > same could be done with SRFI 41, of course. What I don't quite > understand is why SRFI 41 also defines stream-let, stream-lambda etc. Do > you know of a good reason why one would want those? For the specific case of stream-cons I believe they're useless, because stream-cons is syntax and so works well with normal let and lambda. However if you had another lazy computation not based on some constructor, say a tree, you could use stream-lambda instead of introducing a new stream-tree syntax. For a better comparison to srfi-41, you could compare using your lazy-seq against stream-lambda for some infinite tree. Internally, stream-lambda is implemented with a utility stream-lazy which is basically the same as lazy-seq. Bewig decided not to expose this utility with the following reasoning: Besides hiding lazy and making the types work out correctly, stream-lambda is obvious and easy-to-use for competent Scheme programmers, especially when augmented with the syntactic sugar of define-stream and named stream-let. The alternative of exposing stream-lazy would be less clear and harder to use. It seems for you at least the opposite was the case, and it would have been better to expose stream-lazy after all :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
On Jun 3, 2012, at 5:06 AM, Christian Kellermann wrote: > * Peter Danenberg [120603 11:30]: >> Quoth Christian Kellermann on Prickle-Prickle, the 8th of Confusion: >>> Which version of chicken is this? I get the arity error for both csi >>> and compiled version for chicken master. >> >> It's a vanilla 4.7.0: > In your case however, this seems to be an old bug that has been fixed > in master. Works ok for me in stability as well. Could be the list-tail bug fixed in 4.7.0.1-st (e03847a). ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
