I hotlink to everything just so that I can keep it down to one file; as a side effect, if you push a new lava.js (not lava.coffee) to GitHub, it'll automatically use the new one.

There are a few nifty REPL variables. The variable "thatexpr" refers to the previous compiled command string. The variables "that" and "thaterror" refer to the most recent normal result and the most recent exception respectively. Would "thatunparsedexpr" and "thatparsedexpr" be worthwhile additions to this?

I see no way to hack in a stdin or stdout, or to fix the copy-and-paste issue, thanks to the way jQuery-console works. Now I understand why Try Arc has that trouble. ^_^;

https://gist.github.com/837840

http://rocketnia.kodingen.com/af/try-lava-script/

A couple of other things:

1. I like that you made it full screen.

2. I was pleasantly surprised you kept the same REPL pattern!

  > [input]
  [compiled]
  => [evaluated]

That part took a bunch of fiddling! XD I tried to use it on some Android browsers though, and it's not so friendly there.... Using an online REPL from a mobile device would be pretty nifty. ^_^

Hmm, jQuery-console's manual keypress checking makes it especially Android-unfriendly. A slide-out keyboard technically works, but I'd be lost without it. :/

2. I was pleasantly surprised you kept the same REPL pattern!

My original intent was to hack your REPL to work with the console. Actually, my original intent was to have an input box with "compile" and "now evaluate that" buttons, but I liked your REPL much better. :-p

One thing I was on the fence about was using '>' for the input prompt instead of 'lava>'. The former just felt less cluttered to me.

If you don't have quasiquotation yet, but you do have Arc's mac working, macros can be written without quasiquotation by expanding the quasiquotes by hand:

  (mac foo (x y . body)
    `(bar ,x ,y ,@body))

  (mac foo (x y . body)
    (cons 'bar (cons x (cons y body))))

I think you've gotten to the central issue here, which I failed to explain in the OP. Not supporting quasiquote is actually just a consequence of not supporting eval.

The reason for not supporting eval is that this is a source-to-source compiler like CoffeeScript, not a run-time environment. I do not know how to support eval (and perhaps even a meaningful quote operator) without introducing run-time dependencies.

Perhaps an example can illustrate. Here's an expression with lisp on the left and javascript output on the right:

  (+ 1 2)          1+2

  '(+ 1 2)         '1+2'

  '(+ 1 2)         ['+', 1, 2]

What I was suggesting in the OP is that the lack of eval and quasiquotation doesn't actually rule out macros. Rather it forces your macro system to be of a more limited, basic templating variety, but this is still useful. For example, here's how you define def and let using the proposed system [1]:

  (mac def (name parms body...)
    (= name (fn parms @body)))

  (mac let (var val body...)
    ((fn (var) @body) val))

Great, thanks! And you're already helping by talking with me about it. :)

---

Ohhhh, nice limitation.

Technically, if your compile phase ran the code in a LavaScript-capable environment and you kept a running total of all the compiled code in order to output it at the end, then macros should be fine. They're almost never called by the compiled code (just by the thing that was compiling that code earlier), so they're just cruft. I'd be surprised if there weren't a minifier that could cut them out of the result automatically.

On the other hand, if you did that, it would mean running the code in order to set up any definitions the macros use, and thus you would have to have all your run time libraries loaded at compile time--perhaps including the DOM and such--so maybe that's not what you're going for.

Your templating macro system is something that doesn't take advantage of any run time definitions, and is therefore usable from a completely different compile-time environment. Macros that can't execute arbitrary code are pretty dull, though. Maybe what you need is a phase control macro:

  ## (This is just a sketch. Please don't bother crediting me.)
  
  realMacros = {}
  
  realMacros.atCompileTime = (body) ->
    each body, (expr) ->
      eval lc(expr)
    'null'  ## or whatever makes sense as an ignored result
  
  (->
    orig = lc
    lc = (s) ->
      if isList(s) and (s[0] of realMacros)
        realMacros[s[0]](s[1..])
      else orig(s)
  )()

> Technically, if your compile phase ran the code in a LavaScript-capable environment and you kept a running total of all the compiled code in order to output it at the end, then macros should be fine.

That and atCompileTime were almost independent trains of thought, but yeah, I think you understand it. The compiler would compile a command, write the compiled command to the output file, evaluate the command itself, then repeat with the next command.

  for command in input
    let compiled = compile( command ) in
      output-file.write compiled
      execute compiled

Not sure :-) To put it in my own words, macros and quasiquotation are expanded at compile-time. Thus there is a compile-time dependency: in whatever language you write your macros in, you need to be able to be able to call functions written in that language from your compiler.

Take Arc as an example. A macro in Arc is an association between the macro name and a function that does the work of expanding the macro. Saying

  (mac foo ()
    `(+ 1 2))

  (def expand-foo ()
    `(+ 1 2))
  (assign foo (annotate 'mac expand-foo))

So, if you want to write full-strength macros in LavaScript, you need some way for your compiler to be able to call, during compilation, a function you've previously written in LavaScript.

Which, if LavaScript functions are compiled into Javascript, means if you can call Javascript functions from your compiler.

If you can do that, then you'll also get quasiquotation, because quasiquotation can be implemented as a macro.

The reason for not supporting eval is that this is a source-to-source compiler like CoffeeScript, not a run-time environment.

I wasn't paying attention and thought you meant LavaScript was written in CoffeeScript...

but I'm starting to doubt that this language can (or should) support full-fledged quasiquotation