n-able-devel team mailing list archive

["Arlo Belshee" <arlo@xxxxxxxxx>]

So, I want a compiler with a lot of metaprogramming capability.
I want most of N-Able to be written in N-Able, including its tools.
I want binary compatability, probably with my own binary formats.

What if the compiler simply compiles code into itself (its own process). The binary format is mostly a dump of the memory; the binary format for a library is a namespace-delimited delta. The compiler is a VM, with the ability to extend itself. Any program is a compiler with the ability to do something else as well (and whose default actions are those something elses, but who can be asked to compile).

I’d implement a small tool, the uN-Able compiler, in some low-level language. I’d write the N-Able compiler and VM in uN-Able (which would be the simplest language that will let me conveniently write the compiler). The rest of the tools would all be written in N-Able, as would most of the language extensions.

>From bootstrap, compilation would consist of compiling uN-Able in a target-specific way. Then you’d run it on the N-Able compiler source, resulting in a bare N-Able compiler, which we wouldn’t write to disk. Instead, we would then compile the language libraries, so that the compiler knew about such things as classes (which will be defined as an extension, not in the core), then dump that as the base compiler.

That compiler would then compile any user program and dump either itself (if compiling an executable), or the delta (if compiling a library). Each program would be onion-layered namespaces, with a core reactor that’ll do whatever it is asked.

The language should probably have some “unimport” decorator, so that an end-user program can turn off, within his context, something that we defined in the standard lib. If he gets annoyed by our parse of “class”, he can write his own – but it’ll only work within the context where he explicitly swaps it in.

That last bit gets into major crazy, and could make source horribly inconsistent between libraries. So it should be shunned in library code. But it’ll also get the hackers and language-players to try out new things (like monkey-patching does for Ruby). As long as the hackability is controlled and only pulled in when a user explicitly asks that it be, we should be fine.

Arlo