newLISP Fan Club

Thanks Carlos.
A real hardware test is important information for me!

One note about the current direction:

Rebel removes lambda completely.

If existing code uses lambda* symbols, you need to add your own aliases with
(constant (global ...)) or rewrite the scripts:

lambda is fn
lambda-macro is fn-macro
lambda? is fn?

define returns (fn ...),
define-macro returns (fn-macro ...),
macro returns (fn-macro ... expand ...),
macro? returns true for macros defined with define-macro or macro

Documentation will be updated later.
It is not a priority right now.

Ufko

Quote from: ufko on November 22, 2025, 01:09:15 PMRebel is now fully 64‑bit clean and Unix-native.

For anyone interested in a lean,
Unix-focused swiss-knife interpreter,
this is the version to try

Builds and works fine on macOS 26.1 

That project seems relatively unknown and abandoned afaict

What You say about https://github.com/Solant/rebel/
May be You rename project to any another non-conflicting name.
Your project is very good and needs unique name.

Hey guys!

Rebel is now fully 64‑bit clean and Unix-native.
All the archaic cruft has been removed.

Windows support removed
Emscripten support removed
Legacy platform shims removed

New -q flag has been added
Init file is now ~/.init.rbl
(rebel -h)

All other functionality remains unchanged.

QA tests (qa-dot, FFI) run cleanly here:
Github Workflows
You can see Rebel running QA (qa-dot) test
on Ubuntu and macOS

For anyone interested in a lean,
Unix-focused swiss-knife interpreter,
this is the version to try

If you have questions, discuss here:
https://github.com/ufko-org/rebel/discussions

U.

Too bad you don't remember, maybe they're already solved by now
I've been using newLISP for a short time and hadn't worked with
any Lisp-like language before, so I'm a newbie, but those parens
really drew me in

My priorities are as follows:

1. fix all warnings under strict compilation, e.g., with -Wextra
2. create tests for built-in functions
3. create examples for new users
4. create/modify/rebrand documentation (markdown)

I'd love to see some improvements to interacting with CLI programs. It's been a long time since I've done this but I remember that newLISP had issues when it came to managing the input / output of running programs, especially when combining piping data in to the program and getting data back out from both stdout and stderr, and handling errors.

Quote from: ufko on November 16, 2025, 09:53:32 AMI believe Rebel v1.0 is currently the most stable incarnation of the newLISP codebase.

That's awesome. Following 

OK, Rebel v1.0 is out.

Clean build on OpeBSD 7.8 Lenovo x270
Clean build on Ubuntu Linux using Github Actions

$: rebel
Rebel v.1.0 64-bit on BSD IPv4/6 UTF-8 libffi, options: rebel -h

rebel: /home/ufko/me/c/rebel/src
main >
Buffer/Memory overflow warnings/potential errors eliminated.
Strings truncation warnings eliminated.
Ignored return values eliminated.
No linker warnings.
Lutz's Park & Miller algo in my_random() unused now.
C function random() replaced with arc4random() everywhere.

Build Report HERE

I believe Rebel v1.0 is currently the most stable incarnation of the newLISP codebase.
...

Thank you for your kind words, itistoday

Rebel runs on OpenBSD 7.8 and Ubuntu Linux.
For Linux test builds, I use GitHub Actions
(https://github.com/ufko-org/rebel/actions)
because I don't have a Linux machine.

I would appreciate it if someone could test it
on a real Linux machine and report the results:

1. Clone the repo
2. cd src
3. Run `make -f Makefile.linux`
4. Start `./rebel`



There are some compiler warnings and notes on Linux,
but I'm working on fixing them.