https://gist.github.com/zck/7d563d3ee1b7baf5bf67558aece6c861

The fact that Bel contains a full description of reading, printing, and even arithmetic and thread arbitrarion means when someone tries to implement Bel in a non-Racket language, they'll have a good idea of how much work they're getting themselves into. They won't get lost in Racket documentation trying to understand how Bel works, and they won't find themselves questioning whether they need to implement every single obscure Racket feature just because a Bel program might use it.

I think some of the specific design choices in Bel are a bit wacky, like using mutable lists to represent numbers, functions, and continuations. Frankly I hope people won't invest their time trying to implement it all with perfect precision. Still, the goalposts are far clearer than trying to implement Arc.

---

I'm seeing a few pairs of design choices in Bel that seem to be in opposition, which might be a sign that one of the two is a bug. I suppose I don't know how many of these will turn out to be actual bugs, how many will turn out to be by design, and how many will turn out to be spurious products of my own misunderstanding.

1. Why do missing arguments to prims like `join` and `car` default to nil? In contrast, why do almost none of the functions defined in bel.bel have arguments that default to nil? It seems like the explanation for one of these would apply just as easily to the other, so I'm curious where the difference comes from.

2. Dynamic binding in Bel is a little surprising: "Dynamic bindings take precendence over lexical bindings, which take precedence over global ones." Does that mean we can set up dynamic bindings that interfere with the local lexical bindings of a function we call, like this?

  > inc.10
  11
  > (dyn n 4 inc.10)
  5

3. Exploring another consequence of dynamic binding: Considering the way Bel's macro calls are expanded at run time, can we can interfere with the local variables of macros' macroexpansion logic as well, like this?

  > (repeat 5 prn!hello)
  hello
  hello
  hello
  hello
  hello
  nil
  > (dyn init 'prn!4 (repeat 5 prn!hello))
  4
  4
  hello
  hello
  nil

Other name ideas:

- (isa bel)

- Rebel -- similar in theme to "Anarki," although there's already an unrelated Racket library called "Rebellion"

- Bombelli -- analogous to the spelling of "Anarki," and it can refer to a mathematician credited for putting complex numbers on solid ground

    arc> (load "lib/client.arc")
    '()

    arc> (mkreq "http://example.com")
    '(("HTTP/1.0 200 OK"
       "Cache-Control: max-age=604800"
    ...

But the experience frustrated me. It was hard for me to understand all the software under me as I provided abstractions above me.

So I spent the last 5 years gradually eliminating all the layers of abstraction that add complexity to my Lisp interpreter. The path passed through one other language for teaching programming: http://akkartik.name/post/mu. The sources for it are archived at https://github.com/akkartik/mu1 (there was an earlier prototype in Arc at https://github.com/akkartik/mu0)

At this point I have a very simple syntax for programming pretty much directly in machine code: https://github.com/akkartik/mu#readme. It can be translated to an ELF binary for Linux using about 250KB of static x86 instructions (80% of which are unit tests, and much else of which is duplicated because I built the translator in multiple passes that run in a shell pipeline:

    $ cat examples/ex1.subx |./tests |./dquotes |./assort |./pack |./survey |./hex > a.elf
    $

The nice thing about the resulting ELF binaries is that they can be run directly on a Linux kernel with no other dependencies. Not even libc.

There's a script in the repo called `gen_iso` that can take a list of .subx files, translate them into an ELF binary and package up the ELF binary with just a Linux kernel into a bootable disk image. You can then boot this image either in Qemu or on a cloud service like Linode (http://akkartik.name/post/iso-on-linode)

This is what I have so far.

By contrast, the screenshot is quite fake. It's just a program that reads a line of text from the keyboard and prints it out to the screen. You can see it running on an emulated computer in Qemu that has nothing but a Linux kernel.

But I'm going to build up from that core into a high-level language. Maybe an Arc-inspired Lisp. Not a toy this time around.

Just give me 5 more years :D

I wouldn't have a problem with that, but I'm probably of a minority opinion, since that seems to be a Lisp thing. When I started with Arc it took me a while to realize that symbols with asterisks in the name weren't something special like pointers, and using angle brackets just seems wrong after years of writing HTML.

Although if it were possible to do something along these lines, one could have the best of both worlds:

    (defgrammar infix ...)
 
    (w/grammar 'infix (do


    ))

I'm speaking out of my depth here, but I think it would be nice if scoped syntax extension were a "first class" feature of Arc. It would be nice to be able to load, say, native support for XML syntax as a library or something, or to easily extend the language through grammar definitions.