TUNIX Lisp (continued)
Posted: Thu Dec 12, 2024 8:23 am
I didn't post recent releases as it's working on POSIX-compatibles and the C64 only. https://github.com/SvenMichaelKlose/tun ... angelog.md
TUNIX Lisp https://github.com/SvenMichaelKlose/tun ... /manual.md is an interpreter designed to run on systems with next to no CPU stack, like the 6502, and it's written in ANSI-C (cc65). Unless it can compile itself to bytecode it's too slow to for even small apps on CBMs or CP/Ms or whatever else in danger of getting sucked up by the vacuum cleaner. Theoretically it could all be running on any slide rule with an ANSI-C compiler's support. The development history will probably entertain mental health professionals for decades to come. It'll be great.
Because:
# Autoloader
Works very well. Throw out macros and functions if running out of heap and have things re-loaded on demand. Priceless on constrained systems and bringing more comfort.
# 6502 assembler
I've been using my own Lisp-based assembler where no-one should have. A new way of integrating it into Lisp, with no messy parsing, is simplifying the task a lot and that's fun to hack with. Especially when it comes to generate speed code. No compiling Lisp to native code intended (yet). Ideal for a constrained system.
# Dot-notation
Having been around for ages (in tré) it helps to muffle 1B transformer comments like "too many parens": (car x) is x., (cdr x) is .x, (cadr x) is .x, (cddr x) is ..x, and so on and object.method translates to "(slot-value object 'method)" which is actually "(cdr (assoc 'method object))".
# Object system
SLOT-VALUE treating associative lists is no accident. It's the basis for a weirdly inheriting nerd-typed object system (if you poke it and it bites it's a nerd). Also done with a handful lines of code. Here comes the cute thing: the tré Lisp compiler is using STRUCTs. It's super-noisy code for which I deserve to get bitch-slapped around, and it has no object system for its Common LISP target. So that object system is going in to tré as well. That's already working compiler code becoming available for TUNIX more readily.
# Packaging
You can have symbols of a package prefixed with the package name to make a relative path for AUTOLOAD, so apps can be placed in subdirectories of the environment. Also, just a handful of code.
# What to do with it?
You can launch the C64 version, type "(test-all)" into it and meditate for 15 minutes, or launch the Linux version for more heap and actual development.
You're also welcome to rant and recommend. https://github.com/SvenMichaelKlose/tunix/tree/main.
The C64 version is seconds away from becoming ultra-slow to keep things simple until we get our bytecode compiler to remove performance issues anyway.
Have fun!
TUNIX Lisp https://github.com/SvenMichaelKlose/tun ... /manual.md is an interpreter designed to run on systems with next to no CPU stack, like the 6502, and it's written in ANSI-C (cc65). Unless it can compile itself to bytecode it's too slow to for even small apps on CBMs or CP/Ms or whatever else in danger of getting sucked up by the vacuum cleaner. Theoretically it could all be running on any slide rule with an ANSI-C compiler's support. The development history will probably entertain mental health professionals for decades to come. It'll be great.
Because:# Autoloader
Works very well. Throw out macros and functions if running out of heap and have things re-loaded on demand. Priceless on constrained systems and bringing more comfort.
# 6502 assembler
I've been using my own Lisp-based assembler where no-one should have. A new way of integrating it into Lisp, with no messy parsing, is simplifying the task a lot and that's fun to hack with. Especially when it comes to generate speed code. No compiling Lisp to native code intended (yet). Ideal for a constrained system.
# Dot-notation
Having been around for ages (in tré) it helps to muffle 1B transformer comments like "too many parens": (car x) is x., (cdr x) is .x, (cadr x) is .x, (cddr x) is ..x, and so on and object.method translates to "(slot-value object 'method)" which is actually "(cdr (assoc 'method object))".
# Object system
SLOT-VALUE treating associative lists is no accident. It's the basis for a weirdly inheriting nerd-typed object system (if you poke it and it bites it's a nerd). Also done with a handful lines of code. Here comes the cute thing: the tré Lisp compiler is using STRUCTs. It's super-noisy code for which I deserve to get bitch-slapped around, and it has no object system for its Common LISP target. So that object system is going in to tré as well. That's already working compiler code becoming available for TUNIX more readily.
# Packaging
You can have symbols of a package prefixed with the package name to make a relative path for AUTOLOAD, so apps can be placed in subdirectories of the environment. Also, just a handful of code.
# What to do with it?
You can launch the C64 version, type "(test-all)" into it and meditate for 15 minutes, or launch the Linux version for more heap and actual development.
You're also welcome to rant and recommend. https://github.com/SvenMichaelKlose/tunix/tree/main.
The C64 version is seconds away from becoming ultra-slow to keep things simple until we get our bytecode compiler to remove performance issues anyway.
Have fun!