Also, if = doesn't work, assign probably would:

  (assign nil '())

  (assign nil 'foo) -> foo
  nil               -> foo
  'nil              -> nil
  ()                -> ()
  '()               -> nil
  (assign nil '())  -> nil
  (is nil ())       -> t
  

  arc> (readc);
  #\;

  arc> (readline);hello there
  ";hello there"

  ; This exploits an Arc 3.1 bug to drop to Racket (as seen at
  ; http://arclanguage.org/item?id=11838). It's unnecessary on Anarki.
  (mac $ (racket-expr)
    `(cdr `(nil . ,,racket-expr)))
  
  (def discard-input ((o str (stdin)))
    " Reads all the characters from the stream, giving up partway if it
      can determine the stream would block. The return value is `nil'. "
    (while:and $.char-ready?.str readc.str))
  
  
  arc>
    (do (pr "enter something> ")
        (discard-input)
        (prn "The first character was " (tostring:write:readc) ".")
        (discard-input))
  enter something> something
  The first character was #\s.
  nil
  arc>

Something I've been thinking about, though I haven't implemented anything yet, is that there's code, and then there's things related to that code such as prerequisites, documents, examples, tests, etc. The usual practice is to stick everything into the source code file: i.e., we start off with some require's or import's to list the prerequisites, doc strings inline with the function definition, and, in my case, tests following the definition because I wanted the tests to run immediately after the definition.

But perhaps it would be better to be able to have things in separate files. I could have a file of tests, and the tests for my definition of "foo" would be marked as tests for "foo".

Not by design, as it happens. I wrote some new tests for code written in Arc, and stuck them into a separate file because I hadn't gotten around to implementing a mechanism to load Arc code without running the tests.

Though I do view writing dependencies-first as a form of scaffolding. You may need or want scaffolding for safety, or because you're working on a large project, or because you're in the midst of rebuilding.

Does that mean that you always need to use scaffolding when you work on a project? Of course not. If you're getting along fine without scaffolding, then you don't need to worry about it.

  (some-let foo (... foo ...)

There are a couple ways to do this.

One way is that you can use different names for some-let to indicate which one you want.

For example, you could have "let" mean to use foo from the enclosing scope (which is what Arc does now), and have "letrec" mean to use the foo that you're defining.

Or, if you prefer, you could have "let" mean to use the foo that you're defining (and so would work like what we've been calling letrec), and make up another name ("let-parent" or something) for the other kind of let which works like Arc's let does now. You might prefer this if you use the former more often than the latter.

Choosing different names for let isn't the only way to distinguish between the two possibilities. You could modify the Arc compiler so that let worked the way it does now, except that you add a syntax to get at the foo being defined:

  (let rec (fn (x) (this.rec x)))

  (let x (+ 1 parent.x) ...)

P.S. I whipped up a quick version of letr; it seems to work okay:

  (mac letr (var val . body)
    `(let ,var nil
       (assign ,var ,val)
       ,@body))

  (letr rec (fn (x) (rec x))
    (rec 3))

  (let rec (afn (x) (self x))
    (rec 3))

?

1) afn is somewhat of an anomaly. When I see "fn" I know "this is a function" but when I see "afn" I have to pause for a split second to realize what it does.

2) Pattern recognition due to redundancy. When I glance at the first version, my eyes quickly notice that there are 3 references to "rec", and thus I immediately form a pattern in my mind. But in the second version, there are two references to the same function: self and rec. This adds an additional cognitive overhead for me.

In other words, the first one appears less cluttered to me because it has fewer unique elements, and because "fn" is more familiar to me than "afn".

I was thinking along these lines as well. How about:

  (let (def rec(x) (rec x))
    (rec x))

In any case, I welcome the ability for people to muck with my code, 'cause it's a good way to experiment with making it better. ^_^ Just because something's exposed doesn't mean it's part of a stable API, especially in Arc where things are assumed unstable by default.

Cluttering up the namespace is still an issue, but the obvious advice is to choose unique names. ;) If you're still very worried about it, like I am, I humbly suggest you look at Lathe's namespace system.

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