21 ms·

Didn't C++ start out as a set of hacks on C? Fairly sure it was originally a preprocess stage ahead of an ordinary c compiler. Raises the question of how usefu

Didn't C++ start out as a set of hacks on C? Fairly sure it was originally a preprocess stage ahead of an ordinary c compiler. Raises the question of how usefully far you can make C twist using macros / preprocessor. Candidates like Forth or Lisp seem possible. A few weekends at most. Might need to take a few liberties. Python... Perhaps if you implement a less dynamic subset? Duck typing may trip you up. To what extent? What about Elixir?

DonaldFisk 7y ago
I wrote my own Lisp. The virtual machine, which is a stack machine, is written in C. The interpreter, which runs until the system compiles itself, is written in C, but makes heavy use of C macros. The rest of the code, including the compiler, is in Lisp. Code in the interpreter is directly converted to byte code, e.g. the macro Car generates the virtual machine instruction Car, rather than executing the code for car. The alternative would have been to generate byte code by hand, would have been error-prone. Here's the code for cons and let: Define("cons", 2) Local1 Local2 Cons Ret Termin DefineF("let") Local1 Car Local2 /* initialize new env */ Prog(1) Ret Params(2) Until Local1 Null Do Local1 Caar /* var */ Local1 Cadar Free12 Call("eval") /* val in old env */ Local2 /* env */ ACons SetLocal2 Pop /* update new env */ PopLocal1 Od Free11 Cdr Local2 Call("progn") /* use new env */ Ret Termin It is actually C, with heavy use of macros. But it can be read as Reverse Polish Lisp. It can also be thought of as a Lispy Forth.
- rs23296008n1 7y ago
  Interesting approach. maybe develop it further into a JIT arrangement or a library builder. Brainf*ck is another classic.
carlmr 7y ago
Nim transpiles to C. It's very cool since there are C compilers for almost every processor.
- rs23296008n1 7y ago
  Nim is very good. I'm using it as a glue language right now and it works out well.

DonaldFisk 7y ago

I wrote my own Lisp. The virtual machine, which is a stack machine, is written in C. The interpreter, which runs until the system compiles itself, is written in C, but makes heavy use of C macros. The rest of the code, including the compiler, is in Lisp. Code in the interpreter is directly converted to byte code, e.g. the macro Car generates the virtual machine instruction Car, rather than executing the code for car. The alternative would have been to generate byte code by hand, would have been error-prone. Here's the code for cons and let: Define("cons", 2) Local1 Local2 Cons Ret Termin DefineF("let") Local1 Car Local2 /* initialize new env */ Prog(1) Ret Params(2) Until Local1 Null Do Local1 Caar /* var */ Local1 Cadar Free12 Call("eval") /* val in old env */ Local2 /* env */ ACons SetLocal2 Pop /* update new env */ PopLocal1 Od Free11 Cdr Local2 Call("progn") /* use new env */ Ret Termin It is actually C, with heavy use of macros. But it can be read as Reverse Polish Lisp. It can also be thought of as a Lispy Forth.

rs23296008n1 7y ago
Interesting approach. maybe develop it further into a JIT arrangement or a library builder. Brainf*ck is another classic.

carlmr 7y ago

Nim transpiles to C. It's very cool since there are C compilers for almost every processor.

rs23296008n1 7y ago
Nim is very good. I'm using it as a glue language right now and it works out well.