Rather than compare it to arc, I found it tantalizing to think about how I'd implement that syntax. It looks like he's built objects for modules/namespaces, ranges, etc. But he's somehow supporting infix without spaces and also names like print-line. How does it work?! :)
Edit 8 minutes later: Also, the square brackets around the call to [f 1] are strange. If they're mandatory, there's something there I don't follow.
Interesting direction to take it. It would be interesting to know how he implemented it, so that he can still consider it to be a lisp. In particular that '#include' syntax sticks out a bit.
I also found it ironic how conflicted he is over its relationship with lisp.
Changing the names is a separate matter. We could rename the existing loop to for. Does anybody object to that? It's been baked in since the original arc, so I'm feeling a little cautious about messing with it. Any suggestions for alternative names to the existing for which only works on ranges of numbers? One idea is to call it up since there's already a down just below it that scans downward on ranges of numbers.
For some reason I thought for and while were both implemented using loop. Turns out only for is so that probably led to some confusion. I guess it would make sense to implement while with xloop. I do like the idea of moving the current for to up. What I meant originally was to replace the uses of loop with xloop.
I have to agree with you that the current loop should definitely allow variable declarations as it should be the general case of up/down. The remaining cases should be covered by while (unless we want to put the update and the test in the same place which I see no reason for).
Just a question about some of your code. How is while not infinitely recursive? Are macros substituted at runtime in wart?
Edit: I just realized that we can implement the current loop in terms of xloop.
I've made a subtle change to up and down -- following C, they are no longer inclusive of their second bound. Before:
arc> (up i 0 3 prn.i)
0
1
2
3
After:
arc> (up i 0 3 prn.i)
0
1
2
I think I've caught all their callers and corrected them, but there might be stray bugs in lib/math.arc. (It's amazing how much cleaner math.arc has gotten with the saner, C-inspired bounds.)
(mac drain (expr (o eos nil))
(w/uniq (gacc gres)
`(accum ,gacc
(whiler ,gres ,expr ,eos
(,gacc ,gres)))))
I'm still concerned about changing the semantics of loop and for, especially with the prospect of updates from pg. Fortunately it's easy to roll back these changes :)
A final, more speculative change: for loops are named, so you can break and continue multiple loops at once using the name of the loop variable. Both these fragments have identical output:
(up i 0 3
(up j 0 3
(if (> j i) (break))
(prn i " " j)))
(up i 0 3
(up j 0 3
(if (> j i) (continue-i))
(prn i " " j)))
Yeah. Technical debt[1] is a real phenomenon, and it's easy to under-estimate if you just look at nascent projects. After looking at a few short-term successes you may be tempted to assume you can just do what you think they did to get their results. But that approach is susceptible to survivor bias[2]. In reality doing anything on your own is a risky endeavor, and one way to inarguably reduce risk is to get time on your side[3]. If you take on too much technical debt time starts working against you.
The real problem is that we still have only a hazy understanding of what technical debt entails. I suspect many of the things we worry about aren't the biggest sources of technical debt or incidental complexity[4]. So yes, sometimes doing a lot of conventional 'engineering' turns out to be unnecessary. But that is a case for being more thoughtful, not less.
I definitely have to agree with you that being thoughtful is important. If anything that's what programming is about. Knowing which tools of those available to you are the best for each situation.
On the other hand, he does have a point in the bit you quoted: there's a lot of different considerations one has to deal with, and you're often doing something wrong if your focus is on architecture.
My incomplete answer at this point is to try to always record the scenarios I considered when building, in hopes that it'll keep the code easy to rewrite later on without causing regressions. By taking on that burden I hope to drop the larger burden of worrying about architecture too prematurely.
This is why almost all my thinking lately has been around how to increase the surface area that can be covered by tests: http://akkartik.name/prose (especially http://akkartik.name/post/tracing-tests). Eventually I want us to be able to easily write tests for performance, concurrency, fault tolerance, UI layout, etc., etc.
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.
That reminds me: I never did get around to adding your test harness to anarki like I promised. I'll do that if I get around to adding some lazy tests this weekend. Otherwise feel free to do so when you look at this again.
Now that anarki has its first suite of tests using your harness, I've designated all prior tests as "old tests" to encourage us to move away from our patchwork of prior solutions.
I love rosetta code. I spent a few weeks adding samples for my arc-like dialect: http://rosettacode.org/wiki/Category:Wart. I'd meant to add samples for arc as well, but never got around to it. Glad to see someone else taking charge!
I was just looking at some of the older posts here and came across the discussion of arc2js[0]. When that link didn't work I used Google and came across another post[1] where he mentioned an updated page and that one had a link that worked. I must have accidentally copied the broken link instead of the one to the actual page.
