(mac accum (accfn . body)
    `(withs (acc@ nil ,accfn [push _ acc@])
       ,@body
       (rev acc@)))

  (accum a
    (accum b
      (...)))

  arc> (mac foo (accfn . body)
         `(withs (acc@ nil ,accfn [push _ acc@])
            ,@body
            (rev acc@)))
  #(tagged mac #<procedure: foo>)
  arc> (foo a
         (each l '(1 2 3)
           (a:foo b
             (each m (list l (+ l 1) (+ l 2))
               b.m))))
  ((1 2 3) (2 3 4) (3 4 5))

For my part, I have had an eye out for it for three years and have yet to encounter such a bug. Here's my hand-wavy reasoning for why I think it can't happen: for it to happen, an outer macro would have to rely on a use of a specific gensym inside a nested macro. I can't imagine how that could happen short of actually trying to use a gensym:

  (macro1
    (macro1
      ..x23..))  ; brittlely relying on the gensym turning into *x23*

The only problem I can think of is something like this:

  `(x@ `(x@))

I'm not sure why he changed it though. There must have been some benefit (maybe the lisp-1 vs lisp-2) which made it easier to write arc.

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?

Almost all existing occurrences of rfn are now switched to use loop. For example, see the new rev: https://github.com/arclanguage/anarki/blob/96a2757190/arc.ar...

The old loop is renamed to the subtly different for which now declares its own variable. Since for is kinda imperative, it supports break and continue out of the box: https://github.com/arclanguage/anarki/blob/96a2757190/arc.ar.... So does while: https://github.com/arclanguage/anarki/blob/96a2757190/arc.ar...

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

  arc> (up i 0 3 prn.i)
  0
  1
  2

As the piece de resistance, compare drain before (https://github.com/arclanguage/anarki/blob/426b07440bb8d8531...):

  (mac drain (expr (o eof nil))
    (w/uniq (gacc gdone gres)
      `(with (,gacc nil ,gdone nil)
	 (while (no ,gdone)
	   (let ,gres ,expr
	     (if (is ,gres ,eof)
	       (= ,gdone t)
	       (push ,gres ,gacc))))
	 (rev ,gacc))))

  (mac drain (expr (o eos nil))
    (w/uniq (gacc gres)
      `(accum ,gacc
	 (whiler ,gres ,expr ,eos
	   (,gacc ,gres)))))

  (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)))

While this makes sense for simple, throw away projects, it becomes much harder to continuously provide a good experience if you are not worried about the design of your code. Just look at HN for an example of keeping nice code making it easy to provide a good end-user experience[0][1].

[0]https://news.ycombinator.com/item?id=7445933

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.

[1] http://en.wikipedia.org/wiki/Technical_debt

[2] http://en.wikipedia.org/wiki/Survivorship_bias

[3] http://paulgraham.com/die.html

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.

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.

https://github.com/arclanguage/anarki/blob/arc2.master/lib/s...

---

Meanwhile, here's a generator library for Arc 2 by rkts: https://github.com/arclanguage/anarki/blob/arc2.master/lib/i...

And here are three relevant libraries I made as part of Lathe:

- A lazy list library, which happens to use a multimethod framework I made: https://github.com/rocketnia/lathe/blob/master/arc/orc/oiter...

- A generator library: https://github.com/rocketnia/lathe/blob/master/arc/iter.arc

- An amb operator library: https://github.com/rocketnia/lathe/blob/master/arc/amb.arc

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.

I've deleted afnwith from anarki: https://github.com/arclanguage/anarki/commit/a0052f031

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)

Post: http://www.arclanguage.org/item?id=14795

I think that's a very old version of Arc2js. There was at least one more version Pauan made after that, from scratch. Nowadays, Pauan's lisp-that-runs-on-JavaScript efforts seem to be focused on Nulan[1], which... seems to use the escodegen library[2] for JS generation.

And here I spent the weekend optimizing my own lisp-to-JS compiler, when I could've used escodegen. :-p Ah well, it'll probably be worth it because I'm very picky about stack overflows and such.

Well, that old version of Arc2js seems to be trapped in an orphaned set of commits that GitHub might garbage-collect at any time. I tried making a local mirror of the whole repo, but those commits don't come with it. Pauan probably wouldn't consider it to be code that's worth rescuing, but now's the time to figure out how to rescue it. :)

[1] https://github.com/Pauan/nulan

[0] http://arclanguage.org/item?id=14795

Motivation: I want to have a lisp which, runs in the browser, interops easily with existing javaScript libraries, and is reasonably fast. clojureScript sort of is this, but its macros are kind of a kludge (clojureScript macros are written in clojure and have to be in a seperate file from the rest of the code, also hygienic only), interop isn't seamless, and I don't want to start a jvm every time I want to compile some code. A straight arc to javaScript compiler would have to be really smart to produce fast code, and interop wouldn't be seamless either. So I decided to try writing my own language.

Implementation: Since macros can call functions which were defined in the same file, the functions needed to be evaluated right after being compiled. So I couldn't just do a simple "jasper code in, javaScript code out" compiler in haskell. So there is a self hosted[1] compiler/repl.

Current status: It is already sort of usable, but I wouldn't recommend anyone else to use it for anything beyond throw away tinkering, because I still might decide to make big changes to the semantics.

Not sure if that are the things you wanted explained.

"Current status: It is already sort of usable, but I wouldn't recommend anyone else to use it for anything beyond throw away tinkering, because I still might decide to make big changes to the semantics."

You could be telling the story of my recent language projects too. :-p

---

"Self hosted compilers are a pain in the behind, one has to mentally switch between the language version the compiler is written in and the language version the compiler is compiling and when you break you compiler you can't use it to compile the fixed version."

That's a really good warning to hear, because I was headed toward having a self-hosted compiler myself.

In theory yes, but it wouldn't be a good idea for jasper because it is a relatively thin layer on top of javaScript. So a backend for a different platform would have to emulate a lot of JS quirks, which would be complicated and produce slow code.

So if you want to make a cross platform language, it should be a thicker layer on the first platform from the beginning.

"Nevertheless, I think I'm still headed in that direction."

BTW, I followed the instructions to run it and was pleasantly surprised by how painless it was.