One more page I stumbled upon today: http://t3x.org/t3xforth/

T3XFORTH is an old-school, plain vanilla FORTH system that is mostly
compatible to FORTH-79 with some parts borrowed from FIG FORTH,
FORTH-83, and EFORTH, and taking some inspiration from Leo Brodie's
(classic, 1983) book, "Starting FORTH".

It's the (sub)page of Nils M. Holm, author of several interesting books,
his main page is of course simply https://www.t3x.org/

On Thursday, August 24, 2023 at 4:31:52 PM UTC-4, Zbig wrote:
> One more page I stumbled upon today: http://t3x.org/t3xforth/
>
> T3XFORTH is an old-school, plain vanilla FORTH system that is mostly
> compatible to FORTH-79 with some parts borrowed from FIG FORTH,
> FORTH-83, and EFORTH, and taking some inspiration from Leo Brodie's
> (classic, 1983) book, "Starting FORTH".
>
> It's the (sub)page of Nils M. Holm, author of several interesting books,
> his main page is of course simply https://www.t3x.org/

Very nice. Thanks.

There is a book here that Nils wrote, that Albert might want to see/have.

"Lisp from Nothing" :-)

https://www.t3x.org/lfn/index.html

On Friday, August 25, 2023 at 2:13:48 AM UTC+2, Brian Fox wrote:

> There is a book here that Nils wrote, that Albert might want to see/have.
>
> "Lisp from Nothing" :-)
>
> https://www.t3x.org/lfn/index.html

A really interesting page with exciting pointers for future Forth projects.

-marcel

In article <18816283-c067-42bf-b6fe-b48bdeebff9fn@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Thursday, August 24, 2023 at 4:31:52 PM UTC-4, Zbig wrote:
>> One more page I stumbled upon today: http://t3x.org/t3xforth/
>>
>> T3XFORTH is an old-school, plain vanilla FORTH system that is mostly
>> compatible to FORTH-79 with some parts borrowed from FIG FORTH,
>> FORTH-83, and EFORTH, and taking some inspiration from Leo Brodie's
>> (classic, 1983) book, "Starting FORTH".
>>
>> It's the (sub)page of Nils M. Holm, author of several interesting books,
>> his main page is of course simply https://www.t3x.org/
>
>Very nice. Thanks.
>
>There is a book here that Nils wrote, that Albert might want to see/have.
>
>"Lisp from Nothing" :-)
>
>https://www.t3x.org/lfn/index.html

Certainly interesting. "Nothing" is an exaggeration.
You can generate a lisp if you have already a far more powerful
Scheme lisp. Or you can use the c-file bootstrap file to make a
minimal Scheme as a starting point.

Please note that the c-file bootstrap weights in at 300Kbyte,
more than 25 times the next smaller size file.
So the lisp implementation contains about 65% c.

My efforts are to implement a lisp , but with Forth.
Using idiomatic changes to Forth, notably prefixes and delimiters
to parse arbitrary tokens, my implementation promises at least
3 times shorter that the MAL lisp in gforth.

I have compiled gcc on SPARC's. That makes sense because you generate
a more powerful c-compiler without license burden from a less powerful
c-compiler. Most Forth meta-compilation makes sense in this way.

Groetjes Albert

>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

> I have compiled gcc on SPARC's. That makes sense because you generate
> a more powerful c-compiler

Do you mean gcc running on SPARC generates better code
(shorter? faster?) than on x86(64)?

> without license burden from a less powerful
> c-compiler. Most Forth meta-compilation makes sense in this way.

Which licenses are different, when using SPARC-based hardware?
I have Sun Ultra 10 I keep actually for its Forth-based ROM.

On Friday, August 25, 2023 at 7:39:19 AM UTC-4, none albert wrote:

> Certainly interesting. "Nothing" is an exaggeration.
> You can generate a lisp if you have already a far more powerful
> Scheme lisp. Or you can use the c-file bootstrap file to make a
> minimal Scheme as a starting point.
>
> Please note that the c-file bootstrap weights in at 300Kbyte,
> more than 25 times the next smaller size file.
> So the lisp implementation contains about 65% c.
>
> My efforts are to implement a lisp , but with Forth.
> Using idiomatic changes to Forth, notably prefixes and delimiters
> to parse arbitrary tokens, my implementation promises at least
> 3 times shorter that the MAL lisp in gforth.

With the time you have put into this Albert, do you think it would be
possible to make an RPN "LISP"? In other words a Forth style
language that uses the list a primary data type.
And would it be simpler to implement in your opinion?

In article <066d0de4-0ba8-4392-b8ff-4e17d841a0a7n@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
>> I have compiled gcc on SPARC's. That makes sense because you generate
>> a more powerful c-compiler
>
>Do you mean gcc running on SPARC generates better code
>(shorter? faster?) than on x86(64)?

We were infuriated discovering that buying an extra license
expressly for me (a hired gun) did not work. The license
mechanism refused to run my compiler, when others were compiling.
SPARC had an ANSI c-compiler. So we used this compiler to compile
gcc. Then you could use gcc another time, to be independant of
SPARC once and for all. Comparison with Intel was not in the
picture.
>
>> without license burden from a less powerful
>> c-compiler. Most Forth meta-compilation makes sense in this way.
>
>Which licenses are different, when using SPARC-based hardware?
>I have Sun Ultra 10 I keep actually for its Forth-based ROM.

SPARC enforced license, gcc GPL.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <bbd318df-7b9a-4a0d-b663-41d4d1730543n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Friday, August 25, 2023 at 7:39:19 AM UTC-4, none albert wrote:
>
>> Certainly interesting. "Nothing" is an exaggeration.
>> You can generate a lisp if you have already a far more powerful
>> Scheme lisp. Or you can use the c-file bootstrap file to make a
>> minimal Scheme as a starting point.
>>
>> Please note that the c-file bootstrap weights in at 300Kbyte,
>> more than 25 times the next smaller size file.
>> So the lisp implementation contains about 65% c.
>>
>> My efforts are to implement a lisp , but with Forth.
>> Using idiomatic changes to Forth, notably prefixes and delimiters
>> to parse arbitrary tokens, my implementation promises at least
>> 3 times shorter that the MAL lisp in gforth.
>
>With the time you have put into this Albert, do you think it would be
>possible to make an RPN "LISP"? In other words a Forth style
>language that uses the list a primary data type.
>And would it be simpler to implement in your opinion?
>
Elegant first implementations lisp worked with pairs, where the
second element is a pointer to another list.
That makes no sense for Forth.

Another feature to borrow from lisp is the dynamic allocation.
In ciforth we could allocate the 6-cell headers dynamically.
Most of these are pointers. They could like wise point to dynamic
areas. I'm fond of the build-in SIZE of my ALLOCATE implementation.
The cdfln fields all could be such pointers.
So print the name of the dea:
: ID. >NFA @ ( dynamic pointer) DUP SIZE TYPE ;
Get an array containing the high level code:
>DFA @ DUP SIZE ( addr n)
Get an array containing the low level code:
>CFA @ DUP SIZE ( addr n)
>LFA @ DUP SIZE ( addr 48) (all headers are 6 cells.)

This would be a language (in fact even ANSI standard) that
would copy much of the attractive features of LISP.
E.g. a garbage collect followed by a compaction, could eliminate
all unused words from a Forth application.

I have already >ALLOC

13 \ Make a freshly created object at `HERE permanent.
14 : >ALLOC DUP >R HERE OVER - DUP ALLOCATE THROW
15 DUP >R SWAP MOVE R> R> DP ! ;

Applying >ALLOC for a colon definition three times would do the
trick. One for the name, one for the dictionary entry, one for
the high level code.
That could be introduced gradually, the code field need not be
dynamic, and the link field should link in in the normal fashion.
Dynamical and static definition could coexistent.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -