In article <
[email protected]>,
Brian Fox <
[email protected]> 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 -
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)