ulisp VS ecl

I love his projects too. He's also the creator of uLisp.

http://www.ulisp.com/

Not CL, but there is ulisp (http://www.ulisp.com/) for microcontrollers, supposed to be really tiny, and there is Carp (https://github.com/carp-lang/Carp) which is without a GC so seems suitable for real-time stuff.

There's also ulisp (for Arduino projects etc.): http://www.ulisp.com/

This is larger, because there are functions for accessing peripherals, and the core is more standard lispy with 'caadr' et.al., and it has a compacting GC, so images can be saved as a compact blob.

Agreed - the interactivity is good. Lisp is close (have you seen http://www.ulisp.com/ - I can't believe they got into into that small a target!). Python is ok, but for some reason I don't use the REPL in the same way I do in Forth - I think calling functions is just harder somehow. Mostly is exploring valves from the Python REPL.

For 'hobbists' there are lots of amazing Forths, some examples: Zeptoforth has proper threading primitives, optional FAT SD card support and is MIT licensed (important for semi-commercial binary builds), Mecrisp Forth has a native register-colouring compiler is 20K and supports ARM, RISCV, FPGA and others, Flashforth support AVR and PIC. If you like ESP32, then ESP32Forth (an eForth variant) has a ton of features worth looking at. The interactivity is amazing. Of course on PCs or embedded Linux we can do this with shells and scripting languages with REPL - but with deeply embedded microcontroller the only other thing I've seen that's close is http://www.ulisp.com/ - and although it's amazing to get Lisp this small and the developer has done cool things, mostly it's still a toy project that relies on recompiling and adding to C to do any real work. No where near the maturity of the above Forth systems.

Have you looked at uLisp? Or perhaps Mezzano? The latter doesn't run on bare metal yet, but does have arm64 support.

There's also ulisp to take a look at. Might suit some of your needs.

Thanks!

I suspect the work is still ongoing. But maybe not on priority.

This diff from around 3 months ago shows it's likely possible to run it in the browser currently but with a lot of caveats (pretty great nonetheless!).

https://gitlab.com/embeddable-common-lisp/ecl/-/commit/6af4b...

The correct one would be https://gitlab.com/embeddable-common-lisp/ecl

Related issue: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/394. That's not exactly this bug, but if that issue were fixed, I think it would also fix this.

> I would love to program my fleet of ESP8266s with anything but C.

Have you looked into Embeddable Common-Lisp? (https://gitlab.com/embeddable-common-lisp/ecl)

> I don't think ECL uses GCC as a JIT; most common lisps use an incremental AOT compiler, which is different

https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...

What is the difference?

> No, but new javascript programs are frequently loaded.

This is probably what confuses a lot of people into thinking that program distribution has anything to do with JIT. JavaScript is the only programming language for which the main method of program distribution is source-code-only, and why all the trade-offs of adaptive optimization seem necessary, to the point that now people are making its necessity into a virtue. Likewise for Java stealing credit for popularizing portable bytecode as the main method of program distribution - although Gosling coined the term JIT years before Java had a JIT compiler.

> If (for instance) I write a script in c and run it with tcc -run

And what happens when you use libtcc?

> Compilation should occur concurrently with execution

Execution of what? You do not need an interpreter or a bytecode VM to have a JIT compiler.

> usually accompanied by some heuristic for deciding what to compile first (e.g. tracing)

That is adaptive optimization, and is orthogonal to compiling (you can have adaptive optimizations in an interpreter or a bytecode VM). Tracing (which is not a heuristic btw) is a variation of profile-guided optimization, which is orthogonal to JIT.

> Even if it is not, however, ECL does not JIT c, but produces it statically.

I posted this elsewhere in this thread:

https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...

Can you explain why you think that is not a JIT.