Because FORTH Code is far more condensed and efficient, how many lines of FORTH Code would I need to recode a 10000 LOC C application?
Only as a raw estimation. I'm sure people there are people around here who have recoded some C apps.

Thank you
Best Wishes
Andreas

OK, let's see:

„Hello, world” program in C:

#include <stdio.h>
int main()
{ printf("Hello, world!");
return 0;
}

„Hello, world” program in Forth:

..( Hello, world! )

It seems the Forth program will take about 1/6 lines of similar C program.

On Saturday, May 27, 2023 at 2:04:47 PM UTC-4, Zbig wrote:
> OK, let's see:
>
> „Hello, world” program in C:
>
> #include <stdio.h>
> int main()
> {
> printf("Hello, world!");
> return 0;
> }
>
> „Hello, world” program in Forth:
>
> .( Hello, world! )
>
> It seems the Forth program will take about 1/6 lines of similar C program..

It's been a while since I looked at LOC much, but don't they actually use SLOC, which removes the cruft and only counts functional lines?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Andreas Neuner <andreas.neuner@w3group.de> writes:
>Because FORTH Code is far more condensed and efficient, how many lines of FORTH Code would I need to recode a 10000 LOC C application?

Depends on what you mean by "recode". Wil Baden has taken some
"profane" (as he put it) code and recoded it in Forth, with the result
looking unidiomatic IMO (in particular, long definitions). If you
want to go this way, you may compare the code sizes of Forth and C for
the stuff he did. Another exercise in that direction is Gilbreath's
Sieve, which he wrote in a number of languages, including Forth.

Another approach is to write the application from requirements.
Somewhat in that direction is
http://www.euroforth.org/ef99/ertl99.pdf, where I compared parser
generators written in different languages; the requirements were not
the same, but the formal nature of the subject causes relatively
similar requirements (e.g., they all take grammars as inputs and
produce programs as output).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

> It's been a while since I looked at LOC much, but don't they actually use SLOC, which removes the cruft and only counts functional lines?

;)

More seriously: I hope you see the question doesn't make much sense?

Anton Ertl schrieb am Samstag, 27. Mai 2023 um 21:53:14 UTC+2:
> Andreas Neuner <andreas...@w3group.de> writes:
> >Because FORTH Code is far more condensed and efficient, how many lines of FORTH Code would I need to recode a 10000 LOC C application?
> Depends on what you mean by "recode". Wil Baden has taken some

Not a simple 1:1 translation. Implementing the same requirements in Forth.

> Another approach is to write the application from requirements.
> Somewhat in that direction is
> http://www.euroforth.org/ef99/ertl99.pdf, where I compared parser

yes! thats it.
Thank you Anton.

Best wishes
Andi

> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: https://forth-standard.org/
> EuroForth 2022: https://euro.theforth.net

Andreas Neuner schrieb am Samstag, 27. Mai 2023 um 19:00:02 UTC+2:
> Because FORTH Code is far more condensed and efficient, how many lines of FORTH Code would I need to recode a 10000 LOC C application?
> Only as a raw estimation. I'm sure people there are people around here who have recoded some C apps.

That's no fun job if there's no real good reason behind.

I would probably just call libtcc from Forth and use the C sources as they are:
https://bellard.org/tcc/tcc-doc.html#Libtcc

On Saturday, May 27, 2023 at 7:00:02 PM UTC+2, Andreas Neuner wrote:
> Because FORTH Code is far more condensed and efficient, how many lines
> of FORTH Code would I need to recode a 10000 LOC C application?
> Only as a raw estimation. I'm sure people there are people around here who have recoded some C apps.

Very difficult to say without more information on what needs to be done.
The Forth code can be very compact because normally Forth will be extended
to fullfil the requirements of the application. Size also depends on the amount of
special libraries that are needed and of course, the programmer.

An (atypical) example is a SPICE-like circuit simulator. In iForth this is 10,000
LOC (including comments) in 5 files. The open source ngspice simulator
counts 16,481 source files with a total size of 2.4 GB.

-marcel

On Saturday, May 27, 2023 at 1:00:02 PM UTC-4, Andreas Neuner wrote:
> Because FORTH Code is far more condensed and efficient, how many lines of FORTH Code would I need to recode a 10000 LOC C application?
> Only as a raw estimation. I'm sure people there are people around here who have recoded some C apps.
>
> Thank you
> Best Wishes
> Andreas

I am not an expert but when I have looked at C code compared to Forth
the results can be quite varied on which is smaller.
It seems to depend on if the problem plays to the strengths of one or the other.

And sometimes (maybe most of the time?) Forth coders build a solution that
would not make sense in C. My favourite example is making an Assembler.

The C program will be a substantial project because it has to create everything.

A Forth assembler is normally a set of tiny "assemblers" for each instruction.
These little "assembler" are knitted together to make programs.

These kind of solutions can cause a cry of "foul" in 'C' camp because the
project is not complete by their standards and from the conventional
perspective this is true however for the Forth world it's all we need.

I know Stephen Pelc has commented in that past that on the Europay
project the Forth programs were smaller than the equivalents written by
competent 'C' programmers. I don't remember the exact ratio nor do
I remember if that was the final binary or the source size or both.

Perhaps Stephen can refresh our memories.

On 28/05/2023 3:00 am, Andreas Neuner wrote:
>
> I'm sure people there are people around here who have recoded some C apps.

I've done that one or twice and the result was (unsurprisingly) much like C.
It's very difficult to un-see the map put in front of you.

Brian Fox <brian.fox@brianfox.ca> writes:
>And sometimes (maybe most of the time?) Forth coders build a solution tha=
>t
>would not make sense in C. My favourite example is making an Assembler.
>
>The C program will be a substantial project because it has to create everyt=
>hing.
>
>A Forth assembler is normally a set of tiny "assemblers" for each instructi=
>on.
>These little "assembler" are knitted together to make programs.=20

One way to emulate the Forth approach in C is to have a library with a
bunch of definitions for assembler functions/macros and then write the
assembly-language program like this:

#include <asm.h>
int main()
{ global("start");
movrm(rax,disp(8,rdi));
addrm(rax,idx(0,rsi,rcx,8));
ret();
return 0;
}

then compile and run this program, and get the object file as result.
I have seen such techniques used by C++ programmers, but it's not
really idiomatic in C. I think there are several reasons for this:

* As we can see, it results in a not-so-nice syntax. C++ has ways to
make the syntax look nicer.

* When C started, compiling it was slow, so you wanted to avoid that
additional step. So you bit the bullet, and wrote a parser for the
assembly language, which then called these functions/macros without
needing to compile a program to do it. When C++ came in full swing,
machines were faster and had much more RAM, so the practical costs
of such techniques were more acceptable.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

To sum up: ANY Forth program can be written in a single* line
of code; just the length of that line may vary. :)

*) (Proper) Forth screens don't contain end-of-line characters.

In article <fb7e7f22-2b83-48e2-9f48-f2febaab027an@googlegroups.com>,
Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
>On Saturday, May 27, 2023 at 2:04:47 PM UTC-4, Zbig wrote:
>> OK, let's see:
>>
>> „Hello, world” program in C:
>>
>> #include <stdio.h>
>> int main()
>> {
>> printf("Hello, world!");
>> return 0;
>> }
>>
>> „Hello, world” program in Forth:
>>
>> .( Hello, world! )
>>
>> It seems the Forth program will take about 1/6 lines of similar C program.
>
>It's been a while since I looked at LOC much, but don't they actually
use SLOC, which removes the cruft and only counts functional lines?

In forth I look at WOC's (words of code) similarly stripping comments.
----------
#!/bin/sh

cat $1 |\
sed -e 's/\\ .*//' |\
sed -e 's/( [^)]*)//g' |\
sed -e '/\<DOC\>/,/\<ENDDOC\>/d'|\
sed -e 's/\\D .*//' |\
wc -w

exit
----------
My crc facility is 62 woc.

But look at the code, the table is generated on the fly,
a table included in c has dozens of loc's or 512 woc's.
This cannot be done in c.

----------------------------------------------------
( CRC-MORE CRC ) CF: ?32 \ AvdH C2feb27

"BOUNDS" WANTED "-scripting-" WANTED HEX
\ Well the polynomial
EDB8,8320 CONSTANT CRC32_POLYNOMIAL \ CRC-32K
\ Auxiliary table with values for single bytes.
CREATE CRCTable
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC32_POLYNOMIAL XOR THEN
LOOP , LOOP
\ For initial CRC and BUFFER COUNT pair, leave the updated CRC
: CRC-MORE BOUNDS ?DO DUP I C@ XOR 0FF AND CELLS CRCTable + @
SWAP 8 RSHIFT XOR LOOP ;
\ For BUFFER COUNT pair, leave the CRC .
: CRC -1 ROT ROT CRC-MORE INVERT ;
DECIMAL
----------------------------------------------------

I think any "fair" comparison is bound to give c an unfair
advantage.

> Rick C.

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 <9214c492-d28a-43fa-bc94-a6f32a3a3ca8n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:
>On Saturday, May 27, 2023 at 7:00:02 PM UTC+2, Andreas Neuner wrote:
>> Because FORTH Code is far more condensed and efficient, how many lines
>> of FORTH Code would I need to recode a 10000 LOC C application?
>> Only as a raw estimation. I'm sure people there are people around here who have recoded some C apps.
>
>Very difficult to say without more information on what needs to be done.
>The Forth code can be very compact because normally Forth will be extended
>to fullfil the requirements of the application. Size also depends on the amount of
>special libraries that are needed and of course, the programmer.
>
>An (atypical) example is a SPICE-like circuit simulator. In iForth this is 10,000
>LOC (including comments) in 5 files. The open source ngspice simulator
>counts 16,481 source files with a total size of 2.4 GB.

I want to draw attention to another thread. I like to port an editor to
Forth. It has a facility to compile escape sequences to list of
actions, that are interpreted. I expect that an order of magnitude easier in
Forth, and also way more compact. (The editor is sort of a cross between
emacs and vim, with lots of disadvantages removed.)

>
>-marcel

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 -

On Sunday, May 28, 2023 at 7:01:02 AM UTC-4, none albert wrote:
> In article <fb7e7f22-2b83-48e2...@googlegroups.com>,
> Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
> >On Saturday, May 27, 2023 at 2:04:47 PM UTC-4, Zbig wrote:
> >> OK, let's see:
> >>
> >> „Hello, world” program in C:
> >>
> >> #include <stdio.h>
> >> int main()
> >> {
> >> printf("Hello, world!");
> >> return 0;
> >> }
> >>
> >> „Hello, world” program in Forth:
> >>
> >> .( Hello, world! )
> >>
> >> It seems the Forth program will take about 1/6 lines of similar C program.
> >
> >It's been a while since I looked at LOC much, but don't they actually
> use SLOC, which removes the cruft and only counts functional lines?
> In forth I look at WOC's (words of code) similarly stripping comments.
> ----------
> #!/bin/sh
>
> cat $1 |\
> sed -e 's/\\ .*//' |\
> sed -e 's/( [^)]*)//g' |\
> sed -e '/\<DOC\>/,/\<ENDDOC\>/d'|\
> sed -e 's/\\D .*//' |\
> wc -w
>
> exit
> ----------
> My crc facility is 62 woc.
>
> But look at the code, the table is generated on the fly,
> a table included in c has dozens of loc's or 512 woc's.
> This cannot be done in c.
>
> ----------------------------------------------------
> ( CRC-MORE CRC ) CF: ?32 \ AvdH C2feb27
>
> "BOUNDS" WANTED "-scripting-" WANTED HEX
> \ Well the polynomial
> EDB8,8320 CONSTANT CRC32_POLYNOMIAL \ CRC-32K
> \ Auxiliary table with values for single bytes.
> CREATE CRCTable
> 100 0 DO I 8 0 DO
> DUP >R 1 RSHIFT R> 1 AND IF CRC32_POLYNOMIAL XOR THEN
> LOOP , LOOP
> \ For initial CRC and BUFFER COUNT pair, leave the updated CRC
> : CRC-MORE BOUNDS ?DO DUP I C@ XOR 0FF AND CELLS CRCTable + @
> SWAP 8 RSHIFT XOR LOOP ;
> \ For BUFFER COUNT pair, leave the CRC .
> : CRC -1 ROT ROT CRC-MORE INVERT ;
> DECIMAL
> ----------------------------------------------------
>
> I think any "fair" comparison is bound to give c an unfair
> advantage.

I think that is adequately self contradictory. Certainly, it would be more useful with a clear explanation.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On Saturday, May 27, 2023 at 1:00:02 PM UTC-4, Andreas Neuner wrote:
> Because FORTH Code is far more condensed and efficient, how many lines of FORTH Code would I need to recode a 10000 LOC C application?
> Only as a raw estimation. I'm sure people there are people around here who have recoded some C apps.
>
> Thank you
> Best Wishes
> Andreas

This may be of some use to compare C to Forth in a real project.
Here is an exercise to make a LISP interpreter in many languages.

https://github.com/kanaka/mal/tree/master/impls

I was surprised to see a GForth implementation there.

The wild card is that these LISPs are built to a recipe for the course
and so might not fully use idiomatic methods that take advantage
of the implementation language's features. (?)

On 29/05/2023 12:50 pm, Brian Fox wrote:
> ...
> The wild card is that these LISPs are built to a recipe for the course
> and so might not fully use idiomatic methods that take advantage
> of the implementation language's features. (?)

"There used to be, perhaps still is, a distinction between programmers and
coders. Programmers understand the problem; coders are grunt labour." - CM

In article <00e4b748-0cc2-4143-9cd4-ebcb443feb43n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Saturday, May 27, 2023 at 1:00:02 PM UTC-4, Andreas Neuner wrote:
>> Because FORTH Code is far more condensed and efficient, how many lines
>of FORTH Code would I need to recode a 10000 LOC C application?
>> Only as a raw estimation. I'm sure people there are people around here
>who have recoded some C apps.
>>
>> Thank you
>> Best Wishes
>> Andreas
>
>This may be of some use to compare C to Forth in a real project.
>Here is an exercise to make a LISP interpreter in many languages.
>
>https://github.com/kanaka/mal/tree/master/impls
>
>I was surprised to see a GForth implementation there.
>
>The wild card is that these LISPs are built to a recipe for the course
>and so might not fully use idiomatic methods that take advantage
>of the implementation language's features. (?)

That was the point of my post. In almost every situation imaginable
there is a Forth exploit, not possible in most other languages,
that may be considered by others as cheating.
My 100 line Pentium I (inclusive floating point) assembler is an example.

The convincing examples were by E. Rather were actual commercial
applications were involved.

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 <00e4b748-0cc2-4143-9cd4-ebcb443feb43n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Saturday, May 27, 2023 at 1:00:02 PM UTC-4, Andreas Neuner wrote:
>> Because FORTH Code is far more condensed and efficient, how many lines
>of FORTH Code would I need to recode a 10000 LOC C application?
>> Only as a raw estimation. I'm sure people there are people around here
>who have recoded some C apps.
>>
>> Thank you
>> Best Wishes
>> Andreas
>
>This may be of some use to compare C to Forth in a real project.
>Here is an exercise to make a LISP interpreter in many languages.
>
>https://github.com/kanaka/mal/tree/master/impls

This is why github sucks.
1. There is no way to estimate the size of source files
2. There is no description of source files

You have to click on files to see the content and were it fits in the whole.
All the source combined for dozens as languages takes only 3.6 Mbyte
(that is byte with an M not byte with a G)
That is indicative of only toy lisp.

>
>I was surprised to see a GForth implementation there.
>
>The wild card is that these LISPs are built to a recipe for the course
>and so might not fully use idiomatic methods that take advantage
>of the implementation language's features. (?)
>
--
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 -

On Monday, 29 May 2023 at 11:33:41 UTC+1, none albert wrote:
> In article <00e4b748-0cc2-4143...@googlegroups.com>,
> Brian Fox <bria...@brianfox.ca> wrote:
> >On Saturday, May 27, 2023 at 1:00:02 PM UTC-4, Andreas Neuner wrote:
> >> Because FORTH Code is far more condensed and efficient, how many lines
> >of FORTH Code would I need to recode a 10000 LOC C application?
> >> Only as a raw estimation. I'm sure people there are people around here
> >who have recoded some C apps.
> >>
> >> Thank you
> >> Best Wishes
> >> Andreas
> >
> >This may be of some use to compare C to Forth in a real project.
> >Here is an exercise to make a LISP interpreter in many languages.
> >
> >https://github.com/kanaka/mal/tree/master/impls
> This is why github sucks.
> 1. There is no way to estimate the size of source files
> 2. There is no description of source files
>
> You have to click on files to see the content and were it fits in the whole.
> All the source combined for dozens as languages takes only 3.6 Mbyte
> (that is byte with an M not byte with a G)
> That is indicative of only toy lisp.
> >
> >I was surprised to see a GForth implementation there.
> >
> >The wild card is that these LISPs are built to a recipe for the course
> >and so might not fully use idiomatic methods that take advantage
> >of the implementation language's features. (?)
> >
> --
> 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 -

His name is Joel Martin, and you can find videos documenting the process on
youtube.

Heres an example if you are interested https://youtu.be/jVhupfthTEk

In article <00e4b748-0cc2-4143-9cd4-ebcb443feb43n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Saturday, May 27, 2023 at 1:00:02 PM UTC-4, Andreas Neuner wrote:
>> Because FORTH Code is far more condensed and efficient, how many lines
>of FORTH Code would I need to recode a 10000 LOC C application?
>> Only as a raw estimation. I'm sure people there are people around here
>who have recoded some C apps.
>>
>> Thank you
>> Best Wishes
>> Andreas
>
>This may be of some use to compare C to Forth in a real project.
>Here is an exercise to make a LISP interpreter in many languages.
>
>https://github.com/kanaka/mal/tree/master/impls
>
>I was surprised to see a GForth implementation there.

It is supposed to be clojure style of lisp.

Most of the language are supposed to load a version of the mother
language but that fails, unsurprisingly.
If I have a language that is available, (say c) it isn't even
compiling most of the time.

The forth and python implementation seems to works
in the sense that
(+ 1 2)
gives
3
The project is overly ambitious, it is surprising that the gforth
version works this far.
Note it is a gforth version, gforth is explicitly
called and there is nothing to cater for a supposedly ISO program.

>
>The wild card is that these LISPs are built to a recipe for the course
>and so might not fully use idiomatic methods that take advantage
>of the implementation language's features. (?)
>
That is 100% true. That make the reference to this site contribute little
to this discussion.

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 <1b72a450-8166-41a0-9528-69d11694c3a8n@googlegroups.com>,
NN <november.nihal@gmail.com> wrote:
>On Monday, 29 May 2023 at 11:33:41 UTC+1, none albert wrote:
>> In article <00e4b748-0cc2-4143...@googlegroups.com>,
>> Brian Fox <bria...@brianfox.ca> wrote:
>> >On Saturday, May 27, 2023 at 1:00:02 PM UTC-4, Andreas Neuner wrote:
>> >> Because FORTH Code is far more condensed and efficient, how many lines
>> >of FORTH Code would I need to recode a 10000 LOC C application?
>> >> Only as a raw estimation. I'm sure people there are people around here
>> >who have recoded some C apps.
>> >>
>> >> Thank you
>> >> Best Wishes
>> >> Andreas
>> >
>> >This may be of some use to compare C to Forth in a real project.
>> >Here is an exercise to make a LISP interpreter in many languages.
>> >
>> >https://github.com/kanaka/mal/tree/master/impls
>> This is why github sucks.
>> 1. There is no way to estimate the size of source files
>> 2. There is no description of source files
>>
>> You have to click on files to see the content and were it fits in the whole.
>> All the source combined for dozens as languages takes only 3.6 Mbyte
>> (that is byte with an M not byte with a G)
>> That is indicative of only toy lisp.

First impression, probably not true.

>> >
>> >I was surprised to see a GForth implementation there.
>> >
>> >The wild card is that these LISPs are built to a recipe for the course
>> >and so might not fully use idiomatic methods that take advantage
>> >of the implementation language's features. (?)
>> >
>> --
>> 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 -
>
>
>His name is Joel Martin, and you can find videos documenting the process on
>youtube.
>
>Heres an example if you are interested https://youtu.be/jVhupfthTEk

I studied the source of forth further. *This is not a toy lisp.*
Despite having a number of languages in a 3.6 mbyte archive.

He follows Schani that he puts parameters into local values where
that is not needed. It remains to be seen if that inflates the
source code substantially. Otherwise I can't see much that
can be trimmed much for now.

In the first inspection I missed the step by step instructions
with debugging.
That is the way to bring it up using any language c but possibly ciforth.

ciforth features the code/date/name/link/flag headers. Once that is
harnessed to store the type information of lisp, one can have compiled
programs that are subsequently be optimised with Forth tools.

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 made this sheet using the Github LOC and size data for the LISP project.

Forth uses 59% less code in the "CORE" file but not as much in the "step" lesson files.
I can't be sure but this might indicate that there was less Forth style factoring
in the "recipe" to build the project. ?

https://docs.google.com/spreadsheets/d/1BHJY-odMvyV2e5MhcfVPlctEaMGz9hdlLDkGZyx7CzI/edit?usp=sharing

In article <1bbf1f53-f3e1-4843-be65-5db291995cd9n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>I made this sheet using the Github LOC and size data for the LISP project.
>
>Forth uses 59% less code in the "CORE" file but not as much in the "step" lesson files.
>I can't be sure but this might indicate that there was less Forth style factoring
>in the "recipe" to build the project. ?
>
>https://docs.google.com/spreadsheets/d/1BHJY-odMvyV2e5MhcfVPlctEaMGz9hdlLDkGZyx7CzI/edit?usp=sharing
>

I'd say it is a wash. Realize that step_A contains the whole clojure
and that steps are incremental.
E.g going from 9 to A there are only 18 lines different.
diff step9_try.fs stepA_mal.fs | wc -l
18

run contains:
gforth stepA_mal.fs

At the start forth looses when going up to speed building the
necessary structures, which is about normal.

I'm going to attempt it in ciforth, mapping the lisp objects to
Forth header structures, mapping using the fields {code data link name flags }
appropriately.
Environments map to wordlist defined by links.
In ciforth they can be chained and be nested.
Possibly use my mini classes.

Lesson 1 and 2 taught me why my previous attempt to lisp failed.
It is absolutely mandatory to first build the parse tree,
then the next step. If you attempt to do it the Forth
fashion step by step that is hard (or even impossible).

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 -

On Tuesday, May 30, 2023 at 12:45:49 PM UTC-4, none albert wrote:
> I'd say it is a wash. Realize that step_A contains the whole clojure
> and that steps are incremental.
> E.g going from 9 to A there are only 18 lines different.
> diff step9_try.fs stepA_mal.fs | wc -l
> 18
>
> run contains:
> gforth stepA_mal.fs
>
> At the start forth looses when going up to speed building the
> necessary structures, which is about normal.
>
> I'm going to attempt it in ciforth, mapping the lisp objects to
> Forth header structures, mapping using the fields {code data link name flags }
> appropriately.
> Environments map to wordlist defined by links.
> In ciforth they can be chained and be nested.
> Possibly use my mini classes.
>
> Lesson 1 and 2 taught me why my previous attempt to lisp failed.
> It is absolutely mandatory to first build the parse tree,
> then the next step. If you attempt to do it the Forth
> fashion step by step that is hard (or even impossible).
> 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 am very interested to see how yours works. I notice the Forth version
uses locals a great deal, but I can understand that it might have been
the simplest way to translate the reference material.

I was thinking about using Forth headers as well. That could give faster
search times I suspect.