https://github.com/Pauan/nulan (project page)

http://pauan.github.io/nulan/doc/tutorial.html (interactive tutorial in the browser)

https://github.com/arclanguage/rainbow-js (project page)

http://arclanguage.github.io/rainbow-js/test/ (interactive REPL)

It's a direct port of Rainbow (https://github.com/conanite/rainbow), but with a hand-rolled parser and a hand-rolled implementation of asynchronous stream I/O. Like Rainbow, it "compiles" Arc code to an intermediate representation and interprets that. Rainbow was already a fast Arc implementation (faster than official Arc!) so Rainbow.js is pretty speedy as well. I used to think it was even faster than Rainbow itself, but then I realized that was due to a bug. :-p

I haven't been motivated to use Rainbow.js myself, because it has many quirks: Some quirks of its own (e.g. no threads), some inherited from Rainbow (e.g. no bignums, and weird call/cc behavior during macroexpansion), and of course all the quirky features of Arc (e.g. ssyntax). It also has some quirks which are truly necessary to make it usable; for instance, its (load ...) implementation loads from the Web, because there is no filesystem. While this (load ...) fix makes some sense, it's not always clear to me what the best behavior would be. Instead of pondering these small design questions and imposing my own decisions on this project, I've been working on other language designs from the ground up instead.

The community here makes updates from time to time, and I think we're pretty responsive to questions and bug reports. But our changes are not 'blessed' by PG or anything. Since PG has said that "future releases can break anything", such a blessing wouldn't be of much use anyway.

Bottomline: It's not for you if you just want features and don't care how they're built. But if you like the idea of gradually mastering the internals of the tools you rely on -- welcome aboard! You don't have to know anything at the start; we try to be very helpful.

  $ mzscheme
  Welcome to Racket v5.2.1.
  > (load "as.scm")
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc> ^Cuser break
  > (acompile "arc.arc")
  [...output elided...]
  > (exit)
  $ head arc.arc.scm
  (begin
    (let ((zz
           (ar-funcall2
            _annotate
            'mac
            (let ((| do| (lambda args `((fn () ,@(ar-nil-terminate args))))))
              | do|))))
      (namespace-set-variable-value! '_do zz)
      zz))

Disabling comments seems a little more involved. You'll need to add an attribute (say allowcomments) to the item deftem, and then check for it in:

a) displaying the commentlink in display-story, and

b) comments-active, which is checked before displaying the comment-form

I'm not sure of my feelings on changing all the asserts to be just one. On one hand, it is simpler to have just the one command. On the other, it seems like a much more complicated interface, as you would never guess how to use it from, for example, the method signature. assert-t, assert-same et. al. seem like a lower conceptual load.

Maybe I'm just tired, but I first took this to mean that it was impossible for assert-same to be defined so that its arguments were (actual expected (o fail-message)). Now I realize that you just mean the positions of your expected/actual values are important.

One design thought: the name assert isn't taken by Arc. You could simplify the interface while generalizing it by just separating assert from the things it's asserting.

So, the basic assert would essentially be assert-t, and the other three could follow. Something like

  (assert-t actual (o fail-message))
  ; becomes
  (assert actual (o fail-message))
  ; or, without the custom message
  (assert actual)

  (assert-nil actual (o fail-message)) 
  ; becomes
  (assert (no actual) (o fail-message))
  ; or, without the custom message
  (assert:no actual)

  (assert-error actual (o expected-error))
  ; becomes
  (assert (error actual (o expected-error)) (o fail-message))
  ; or, without the custom message
  (assert:error actual (o expected-error))

  (assert-same expected actual (o fail-message))
  ; becomes
  (assert (same expected actual) (o fail-message))
  ; or, without the custom message
  (assert:same expected actual)

  (mac assert (condition (o fail-message))
    `(on-err (fn (c) ...fail...)
             (fn () (unless ,condition ...fail...))))

  (mac same (expected actual)
    (w/uniq (e a)
      `(with (,e ,expected ,a ,actual)
         (or (iso-that-works-on-hash-tables ,e ,a)
             (err "" ',actual 'returned ,a 'wanted ,e))))) ; modulo prettiness

  (mac error (expr (o expected-error))
    `(on-err (fn (c) ...pass, modulo expected-error...)
             (fn () ,expr ...fail if we get here without an error...)))

One thing that fell out of this is that there's no built-in way that I know of to check hashes for equality in Arc. Even `iso` doesn't do it (https://bitbucket.org/zck/unit-test.arc/issue/18/make-assert...). So I wrote a way (https://bitbucket.org/zck/unit-test.arc/commits/a007eb6491c3...).

The only big thing that I really want to do for usability right now is to not have a ton of lines of "test X passed!" (https://bitbucket.org/zck/unit-test.arc/issue/20/optionally-...).