Recent posts

#11
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by hapco - January 03, 2026, 05:49:31 AM
Ok, I apologize. I did say it was no big deal and I never said anything about losing me a a potential user. I'll continue to follow your project with interest and look forward to seeing what you can make of it.
#12
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by ufko - January 02, 2026, 10:56:49 PM
Hi.

Losing users who consider long function
names to be language expressiveness is,
in my view, an extremely drastic change.

Rebel is not a subject of discussion;
my post was only an announcement.

Ufko.
#13
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by hapco - January 02, 2026, 04:21:18 PM
Thanks, your post made it seem more drastic.

Just for the sake of discussion, though, I think I prefer write-file and append-file to fwrite and fappend. the latter might be more concise, but they are less expressive and not as natural to type. No biggie though. :-)
#14
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by ufko - January 02, 2026, 09:32:58 AM
Hi,

Nothing broke functionally. Rebel keeps the same
language semantics; the changes are primarily in
function naming, not in behavior.

Rebel intentionally diverged to establish a concise,
more Unix/C-like naming for core functions.

There are two straightforward options for existing
newLISP code:

 - Rename function calls to the new Rebel names.
 - Define aliases for the original names.

Both approaches are fully supported and idiomatic.

The authoritative reference is primes.h, which
documents the active Rebel interface and naming.
See the header comment for orientation:

https://github.com/ufko-org/rebel/blob/main/src/primes.h

For renamed functions, the original newLISP name
can usually be inferred from the C primitive name,
which has not changed so far.

For example, new fwrite maps to p_writeFile, meaning
the original function name was write-file.

Regarding GitHub discussions/issues: they were disabled
intentionally to keep development focused.

Ufko
#15
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by hapco - January 02, 2026, 07:37:41 AM
Hi ufko,

What broke? Will any modification of existing newlisp code allow it to run in rebel?

https://github.com/ufko-org/rebel/discussions gets a 404, btw.

#16
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by ufko - December 25, 2025, 11:58:58 PM
Rebel is no longer newLISP-compatible.
The break is mainly about function naming,
not features.
From here on, Rebel goes its own way.

Ufko.
#17
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by ufko - December 20, 2025, 08:55:15 PM
TL;DR: From now on, set is the only way to assign or
mutate anything in Rebel. There is no separate
set ', setq, setf family.


Thanks for testing, Hapco.

You cloned a short transitional commit where the new
assignment semantics were already in place, but the
explicit error behavior was not yet implemented.

In Rebel, set is now the only assignment primitive.
Internally, set is equivalent to setf.

This means that assignments always operate on places.
Quoted symbols are not accepted as assignment targets.

Rebel v1.0 64-bit on BSD IPv4/6 UTF-8 libffi, options: rebel -h

> (set 'a '("hello" "there"))
ERR: quoted symbol used in function set

> (set a '("hello" "there"))
("hello" "there")
> a
("hello" "there")

Using (set 'a ...) is rejected by design. Everyone
who uses the (set 'sym ...) syntax in newLISP
has been doing it completely unnecessarily
the whole time.
Current versions emit a clear error in this case.

Until the new assignment semantics are fully documented,
the behavior of set can be considered equivalent to
the existing newLISP setf documentation.

Existing newLISP code that relies on the original
set 'symname, setq, or setf forms must be rewritten to
use the unified set form in order to run on Rebel.

As a temporary migration aid, it is possible to define
an alias for setf or setq, for example in
~/.init.rbl

(constant (global 'setf) set)
(constant (global 'setq) set)

Ufko
#18
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by hapco - December 20, 2025, 02:12:39 PM
Yes, this is (potentially) great!

There is this, though:

Rebel v1.0 64-bit on Linux IPv4/6 UTF-8 libffi, options: rebel -h

> (set 'a '("hello" "there"))
("hello" "there")
> a
nil
>


newLISP v.10.7.6 64-bit on Linux IPv4/6 UTF-8 libffi, options: newlisp -h

> (set 'a '("hello" "there"))
("hello" "there")
> a
("hello" "there")
>
#19
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by boris - December 14, 2025, 02:46:26 AM
Best Christmas present ever, exactly what I have wanted for a long time.
And can I just say the wiki is a model of clarity!
Built quickly with no errors and briefly tested on MX-Linux 23.6
#20
newLISP newS / Re: Forked newLISP – Meet Rebe...
Last post by ufko - December 10, 2025, 11:56:10 AM
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