Hmm, I think you need to do more to redefine scar and scdr:
arc> (= x '(1 2 3))
arc> x
(1 2 3)
arc> (= car.x 4)
4
arc> x
(4 2 3)
arc> (load "lib/streams.arc")
*** redefining scar
*** redefining scdr
nil
arc> (= car.x 5)
scar: arity mismatch;
the expected number of arguments does not match the given number
expected: 1
given: 2
arguments...:
'(4 2 3 . nil)
5
The problem is that prior uses of scar and scdr (such as assignment to car[1]) will try to call your version. It's usually a bad idea to repurpose names for something unrelated. At the least we need to go through and fix callers of the old name.
Not a huge deal at the moment since your library isn't loaded by default. So we have some time to think about how to fix this.
The simplest fix would be to overload scar/scdr based on the number of arguments. While it's a nice quick fix, I do not like the idea of using the same name for two different functions.
Yeah, especially since one of them is destructive and one isn't!
If we can get regular car and cdr to handle lazy streams then this issue will be moot. I'm investigating this. I didn't understand your point 1 above regarding when to tag, so I'm trying to recreate the primes example from SICP 3.5 to better understand the issue.
Can you point me at any sample calls to your library, maybe things you tried on the commandline while you built it?
Thanks for the links! Too bad none of them show example usage.. :) But no matter, I'll add some to this version. It's looking promising so far, I'll push it later today.
Ok, I've turned streams into a tagged type. I had to just support them in car and cdr and carif to get common list operations to work. However, existing operations still return regular (eager) lists when you pass them lazy streams, so I followed malisper's idea of creating lazy variants that preserve laziness in the result.
I've also added unit tests for them in lib/streams.arc.t, which is my first serious attempt at using zck's nice unit-test harness with suites.
malisper, I took some liberties with your code, such as renaming the 's' prefix to 'lazy-'. I'm not attached to these things, so feel free to revert any of my changes you don't like. Thanks for a fun exercise!
I'm not sure how you're measuring overhead, but let me know if it seems slower than before.
Well, you need it for cons and the generator lazy-gen and other functions that don't take a stream. Maybe the others don't, but it seemed to me that sometimes it makes sense to return a list and sometimes not. So especially since functions like firstn do something useful without changing anything, maybe we should keep that behavior around. But it's just an idea. What do you think? Since you're using them for project Euler, it'll be good to hear your experiences.
I'm a little surprised to see 'afnwith. Anarki also has aw's 'xloop, which is the exact same thing as 'afnwith but with the "self" anaphoric variable renamed to "next".
In wart the name can be nicer still -- just loop since for does what arc's loop does, in the footsteps of classical C.
Edit 20 minutes later: I ended up going with recur instead of next, to form a loop.. recur pair. I also considered with loop.. recur to strengthen the connection with with for the alternating var/val syntax. (The other pair of keywords in wart is collect.. yield in place of accum acc.) https://github.com/akkartik/wart/commit/b7b822f4fb has has an example use, which had me hankering for absz's w/afn (though with a better name; http://arclanguage.org/item?id=10125)
Edit 25 minutes later: It turns out xloop nests surprisingly cleanly. This does what you expect:
loop (a 0)
loop (b 0)
prn a " " b
if (b < 5) (recur ++b)
if (a < 5) (recur ++a)
Edit 29 minutes later: Oh, loop.. recur is precisely what clojure uses!
I don't know what I was thinking. Of couse we could just tag the streams when they are created with scons. If we really wanted to we could just extend all of the basic operations for working with lists.
There still is the problem of efficiency though. For what I have been using them for (project euler) efficiency is a big deal.
