Making a Mini-Lisp: Introduction to Transpilers in JavaScript

Maybe the transpiler is just a spackled polyfill enabling splats because dunders are unreliable?

I'm with you. A transpiler is exactly a compiler.

While as you point out there's not necessarily an academic difference, the notion that your target language will itself require a compiler and/or runtime is useful to know up front. Transpilers also usually attempt close to 1-to-1 translation. Functions become functions, constants become constants, etc.

As someone who has written many compilers before, I'd almost feel it would be a slight disservice to call a transpiler a compiler, mostly because their architecture and goals are often different.

I don't see the need for a word beyond "translator" for what you describe. It's a well known word and used correctly, I think, if I say "this program translates Lisp into Javascript."

You make an interesting and important point, but to be honest the article's intended audience is people who are intimidated by language translation or just have never done it before. The "Minilisp" is not really a language so much as a tool to demonstrate the concepts of tokenizing, parsing and recursion. It is unfortunate if the result is a mischaracterization of real Lisp, but I was trying to cut a balance between being accurate and filling the article with tangential information.

To expand a little on this, the article shows the parsed AST:

   {
     type: 'function',
     value: 'defn',
     children: [ 
       { type: 'function_name', value: 'average' },
       { type: 'arguments', children: [
                             { value: 'x' },
                             { value: 'y'}
                            ]
       },
       { type: 'function', value: '/', children: [...] }
     ]
   }

The parenthesis-based surface syntax is directly translated into the above, which is IMO more verbose and contains no additional information. On the other hand, it is valid Javascript data.

So it looks like it is equivalent to manipulate the above form. Now, suppose you want to define a function which returns a form which performs a function call. We won't use macros, but simply a function that builds an AST. We can't write Javascript directly with this parser, so let's say there are primitive Lispy functions to build equivalent javascript trees:

    (defn my-funcall ()
      (js%hash (js%kv "type" "function")
               (js%kv "value" "my-fn")
               (js%kv "children"
                      (js%vector 
                        (js%hash 
                          (js%kv "value" 3))))))

... whereas, a lisp-based approach would be:

    (defn my-function (list 'my-fun 3))

Just transform it to continuation-passing style[1] and call/cc is no problem (neither are non-local exits). Granted your compiled code will be somewhat large and not much like 'regular' code in the language. That can be solved by doing selective CPS transform (IcedCoffeeScript[2] does this), but that gets slightly less straightforward.

Compiling continuations to a dynamic language is actually really easy.

--

1: https://en.wikipedia.org/wiki/Continuation-passing_style

2: http://maxtaco.github.io/coffee-script/

Does Javascript's try...catch and error count as non-local exit?

For playing around with languages I'd actually recommend writing your own lexer and parser. It isn't hard, and writing a recursive descent parser really helps understanding grammars and BNF. Before you have a solid grasp of how context-free grammars work, parser generators aren't much of a time saver IMO.

In my experience getting a BNF grammar right is something of an art which you pick up after having written a few parsers.