The primary spark that led me to make Rainbow.js was a desire to respond constructively to threads like this one.
Using Rainbow was a side effect because I wanted to wow people with the execution speed, which conanite had already meticulously worked on in Rainbow. This was still tied into the desire to help those forum threads along: Between speed and portability, what possible excuse could there be not to use it? ^_^
Once I committed to particular technical goals involving consistency with Rainbow, the 20,000 lines of code were basically predetermined. It's kind of unfortunate that it would fail to be helpful in threads like this one, but it's not all a loss.
Thank you so much for this!! arc-js looks great. I'm able to define and run Arc macros with it.
Thanks for sharing, rocketnia! I’ve been looking into ways of getting started, and Arc.js looks like the most novice-friendly implementation so far. Node.js and browser is what I use for hobby coding anyway. :)
The only drawback would be speed; a more directly compiled lisp would probably have better performance.
I'm pretty sure it has macros. Even if it didn't, their effects are easily duplicated with fexprs.
Rather, a macro can be described as an extension of the compiler, while a fexpr is an extension of the interpreter. In a compiled language, macros can be an optimization tool, because they can perform arbitrary computation at compile time.
In wat.js, which I believe is interpreted, macros provide relatively little value. They can still perform slightly better, because they only need to be expanded once. To quote directly from manuel:
"To fexprs I also add macros. When a macro is used as the operator of a form, the form's code gets changed to the macro's output when the macro is first called, a technique I learned from here. I like macros because they make syntactic abstraction cost-free - with fexprs alone there is always an interpretative overhead. Still, Wat macros, like fexprs, do not work with quoted identifiers, but with first-class values, so many hygiene problems are avoided."
So generating HTML with the same kind of dsl that arc uses should be fairly painless. Either that, or I misunderstood what you were saying entirely.
I must have missed the macros then. The biggest problem I had with wat-js is that... I couldn't figure out how to run it. I wish it had a single shell script that you ran and brought up a repl. So one doesn't have to spent time copy-pasting stuff from a text file into an html file and firing up a browser, or typing their code within double quotes or doing anything else.
I tried them now and was able to get up a Wat VM. But I haven't been able to figure out how to run macros in there.
I wish there were examples. Snippets you can copy paste that do lots of useful stuff like http://ycombinator.com/arc/tut.txt. It shouldn't take anyone more than 10secs to find how to do things. It's disheartening to hear such good work remains unused only because there are no examples but I suspect it's the truth. That's what happened to me.
Language designers think some cool esoteric feature is the killer feature of a language but a more useful feature might be examples: an implementation of an application developers want, like Arc did by providing a webserver and a blog.arc. If you are writing a language, ship a useful app with it, like C did with UNIX.
I would look at the boot.js file. It's kind of like arc.arc is for arc, in that it is a lisp-based bootstrap of all of the basic functions made available in the default environment.
It should give you basic examples of how to write code in wat, as well as show you which functions are defined. Of course, most of them don't actually have examples in the file, as it's merely defining the standard library, but it's a start. There's also test.wat, and the authors blog: http://axisofeval.blogspot.com/search/label/wat (which unfortunately mostly uses the underlying json representation for most of its code).
And the 'killer feature' of wat.js is not that it has first class environments or fexpr, which are admittedly very cool, but that the core language implementation that supports all of these and more is only a few hundred lines of code. There's more in the repository of course, but all of that is to provide the standard library or add sexpression parsing, etc. This makes wat a very good minimal platform for building a custom language.