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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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. (?)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27/05/2023 18:00, 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

Couldn't the Rosetta Code website be used to compare C and Forth
solutions to a variety of problems.

https://rosettacode.org/wiki/Category:Programming_Tasks

Presumably the solutions were written by people who knew the strengths
of the language used

--
Gerry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, May 31, 2023 at 6:00:58 PM UTC+2, Gerry Jackson wrote:
[..]

Couldn't the Rosetta Code website be used to compare C and Forth
solutions to a variety of problems.

I don't think so: Rosetta's point appears to be "...illustrate factors that relate or separate languages..."

Even the original question is not very precise: what does "efficient"
mean exactly? Less energy used to flip bits?

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <7f127372-5c63-45d3-afa5-f0eca00d1b3en@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:

On Wednesday, May 31, 2023 at 6:00:58 PM UTC+2, Gerry Jackson wrote:
[..]

Couldn't the Rosetta Code website be used to compare C and Forth
solutions to a variety of problems.

I don't think so: Rosetta's point appears to be "...illustrate factors that >relate or separate languages..."

Even the original question is not very precise: what does "efficient"
mean exactly? Less energy used to flip bits?

Rosetta shows the strengths or weaknesses of the different languages.
However I'm annoyed with the imprecise problem statements.
Also the problems are too small to be really an indication for projects.

-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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

none albert schrieb am Mittwoch, 31. Mai 2023 um 20:54:23 UTC+2:

In article <7f127372-5c63-45d3...@googlegroups.com>,
Marcel Hendrix <m...@iae.nl> wrote:

On Wednesday, May 31, 2023 at 6:00:58 PM UTC+2, Gerry Jackson wrote: >[..]

Couldn't the Rosetta Code website be used to compare C and Forth
solutions to a variety of problems.

I don't think so: Rosetta's point appears to be "...illustrate factors that >relate or separate languages..."

To get a feeling of which size I'm talking about. There are aprox. 100 tables (persistent data types) and 200 dialoges. The requirement is absolutely clear. GUI is realized as WebGui.
No GUI Framework is used. I think a Web GUI builder in Forth should be a snap.


Best wishes
Andi

Even the original question is not very precise: what does "efficient"
mean exactly? Less energy used to flip bits?

Rosetta shows the strengths or weaknesses of the different languages. However I'm annoyed with the imprecise problem statements.
Also the problems are too small to be really an indication for projects.

-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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/06/2023 3:45 am, Marcel Hendrix wrote:

On Wednesday, May 31, 2023 at 6:00:58 PM UTC+2, Gerry Jackson wrote:
[..]

Couldn't the Rosetta Code website be used to compare C and Forth
solutions to a variety of problems.

I don't think so: Rosetta's point appears to be "...illustrate factors that relate or separate languages..."

Even the original question is not very precise: what does "efficient"
mean exactly? Less energy used to flip bits?

The original question and title implies using forth results in less LOCs
(1% of the code and all that).

Forth was the product of a person whose thinking had radically changed.
The idea we can pick up their tools and we'll change with it is wishful thinking at best. If our LOCs haven't radically changed it's because
our thinking hasn't.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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. (?)

My premise is that INTERPRET (the Forth parser) is powerful
enough to parse lisp. I reject the idea of a tedious
character by character parser, such as seen in Schani lisp
or in the mal example.

If harnessing the Forth power to parse lisp,
there are two questions to address.
I replace the nomenclature for word by token that is more
suitable, and can be used for Forth too.

Look at the lisp expression
(+ 1 (* 3 10))
This is equivalent to : 3 10 * 1 +

We need to parse this, splitting it into tokens, that map to
language concept/type/whatever.

I. The '(' in '(+' is a token in their own right.
This is solved in ciforth by making "(" a prefix.
II. The '10' in '10))' is a token.
This is solved in ciforth by making ')' a delimiter character.

I have discussed how adding PREFIX to a Forth costs a mere 5
lines or less (in a well designed Forth) and this is not repeated
here. This is present in ciforth since 2001.

You can imagine a word ?START that return whether a character is
a delimiter. Approximately
: lisp-delimiters ":[](){};" ;

Previous NAME (formerly known as "BL WORD" ) looked like as follows.
It uses PP@@ . This fetches the next character, leaves a pointer
to the character and advances PP (approximately >IN)
NAME leaves a string constant (adr len) with the advantage that
the string is not copied.
: NAME ( -- sc)
BEGIN PP@@ ?BLANK WHILE DROP REPEAT ( first non blank )
BEGIN PP@@ ?BLANK NOT WHILE DROP REPEAT ( first blank )
( start end -- sc ) OVER - ;

Now we need this replaced by
: ?DELIM DUP ?BLANK SWAP ?START OR ;
: TOKEN ( -- sc)
BEGIN PP@@ ?BLANK WHILE DROP REPEAT ( first non blank )
BEGIN PP@@ DUP ?DELIM NOT WHILE DROP REPEAT ( first delim)
( start end -- string ) OVER - ;

Now lisp can be parsed by INTERPRET once the wordlist are created
and installed and NAME is revectored to TOKEN.

This is all the words that need to be present in
the wordlist lisp-ns :
----------------------------------------
lisp-ns SET-CURRENT
\ An empty prefix matches everything, sealing the `lisp-ns namespace.
: catch-all lisp-symbol ; PREFIX "" LATEST >NFA @ $!
'lisp-number aliases: 0 1 2 3 4 5 6 7 8 9
: ( lisp-list ; PREFIX
'EXIT ALIAS ) PREFIX
IMPORT FORTH .l .S .symtab inc lisp-off

FORTH-WORDLIST SET-CURRENT
----------------------------------------

lisp-list lisp-number lisp-list are part of lisp proper, not of the
parser, they build data structures that may differ among lisp, and
they are not the subject.

Let us start at the bottom.
Following the IMPORT are words that are alien words that are
recognized even in lisp. e.g. FORTH escapes to Forth, .S shows
a stack dump etc. They can be left out.

The word ( build a lisp-list, like so

: lisp-list #list INTERPRET \ #list is used as a sentinel.
0 BEGIN OVER #list <> WHILE BUILD-pair REPEAT NIP ;

So tokens are accumulated on the stack using a recursive(!) call
of INTERPRET that observes the input stream .
It ends with the token ) , that is just an alias of EXIT
such that this call of INTERPRET ends.

Then there is the meat.
'lisp-number aliases: 0 1 2 3 4 5 6 7 8 9
Single digit prefixes parse a number. No surprise there, familiar
technique in ciforth.
And then the surprising
: catch-all lisp-symbol ; PREFIX "" LATEST >NFA @ $!

catch-all catches the remaining tokens such as + .
But you say "+" doesn't match "catch-all" at all!
Changing the >NFA however to an empty string, and making
it a prefix, changes that, matching everything.
"+" is "" followed by "+" , check!
lisp-symbol does the rest.

The 5-line lisp parser qualifies for a Jeff Fox hyped 100 times increase
of compactness, compared the parser presented in mal-forth.

NOTE: I have reworked the Schani lisp interpreter (gforth). https://github.com/schani/forthlisp
This parser has been lifted from the reworked lisp.
In the Clojure I expect to add a few more lines, for e.g. fixed object
like : false true nill .

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)

On Thursday, June 1, 2023 at 2:37:45 PM UTC+2, none albert wrote:
[..]

Here is an exercise to make a LISP interpreter in many languages.

[..]

If harnessing the Forth power to parse lisp,
there are two questions to address.

Just throw gray at it. Gray is a Really Good Program.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <bff6d8c0-f166-4f03-9a9d-a51045706633n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:

On Thursday, June 1, 2023 at 2:37:45 PM UTC+2, none albert wrote:
[..]

Here is an exercise to make a LISP interpreter in many languages.

[..]

If harnessing the Forth power to parse lisp,
there are two questions to address.

Just throw gray at it. Gray is a Really Good Program.

I demonstrated that a ciforth with minimal expansion
can do a lisp parser in 5 lines.

There is more needed before I give up this rather successful
approach, than an unqualified promotion.

It helps if you can explain how Gray parses
(+ 1 (*3 10))

-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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix <mhx@iae.nl> writes:

Just throw gray at it. Gray is a Really Good Program.

Thank you. But I think it's overkill for parsing S-Expressions (Lisp
Syntax).

- 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 proceedings: http://www.euroforth.org/ef22/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 1, 2023 at 8:37:45 AM UTC-4, 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

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. (?)

My premise is that INTERPRET (the Forth parser) is powerful
enough to parse lisp. I reject the idea of a tedious
character by character parser, such as seen in Schani lisp
or in the mal example.

If harnessing the Forth power to parse lisp,
there are two questions to address.
I replace the nomenclature for word by token that is more
suitable, and can be used for Forth too.

Look at the lisp expression
(+ 1 (* 3 10))
This is equivalent to : 3 10 * 1 +

We need to parse this, splitting it into tokens, that map to
language concept/type/whatever.

I. The '(' in '(+' is a token in their own right.
This is solved in ciforth by making "(" a prefix.
II. The '10' in '10))' is a token.
This is solved in ciforth by making ')' a delimiter character.

I have discussed how adding PREFIX to a Forth costs a mere 5
lines or less (in a well designed Forth) and this is not repeated
here. This is present in ciforth since 2001.

You can imagine a word ?START that return whether a character is
a delimiter. Approximately
: lisp-delimiters ":[](){};" ;

Previous NAME (formerly known as "BL WORD" ) looked like as follows.
It uses PP@@ . This fetches the next character, leaves a pointer
to the character and advances PP (approximately >IN)
NAME leaves a string constant (adr len) with the advantage that
the string is not copied.
: NAME ( -- sc)
BEGIN PP@@ ?BLANK WHILE DROP REPEAT ( first non blank )
BEGIN PP@@ ?BLANK NOT WHILE DROP REPEAT ( first blank )
( start end -- sc ) OVER - ;

Now we need this replaced by
: ?DELIM DUP ?BLANK SWAP ?START OR ;
: TOKEN ( -- sc)
BEGIN PP@@ ?BLANK WHILE DROP REPEAT ( first non blank )
BEGIN PP@@ DUP ?DELIM NOT WHILE DROP REPEAT ( first delim)
( start end -- string ) OVER - ;

Now lisp can be parsed by INTERPRET once the wordlist are created
and installed and NAME is revectored to TOKEN.

This is all the words that need to be present in
the wordlist lisp-ns :
----------------------------------------
lisp-ns SET-CURRENT
\ An empty prefix matches everything, sealing the `lisp-ns namespace.
: catch-all lisp-symbol ; PREFIX "" LATEST >NFA @ $!
'lisp-number aliases: 0 1 2 3 4 5 6 7 8 9
: ( lisp-list ; PREFIX
'EXIT ALIAS ) PREFIX
IMPORT FORTH .l .S .symtab inc lisp-off

FORTH-WORDLIST SET-CURRENT
----------------------------------------

lisp-list lisp-number lisp-list are part of lisp proper, not of the
parser, they build data structures that may differ among lisp, and
they are not the subject.

Let us start at the bottom.
Following the IMPORT are words that are alien words that are
recognized even in lisp. e.g. FORTH escapes to Forth, .S shows
a stack dump etc. They can be left out.

The word ( build a lisp-list, like so

: lisp-list #list INTERPRET \ #list is used as a sentinel.
0 BEGIN OVER #list <> WHILE BUILD-pair REPEAT NIP ;

So tokens are accumulated on the stack using a recursive(!) call
of INTERPRET that observes the input stream .
It ends with the token ) , that is just an alias of EXIT
such that this call of INTERPRET ends.

Then there is the meat.
'lisp-number aliases: 0 1 2 3 4 5 6 7 8 9
Single digit prefixes parse a number. No surprise there, familiar
technique in ciforth.
And then the surprising
: catch-all lisp-symbol ; PREFIX "" LATEST >NFA @ $!

catch-all catches the remaining tokens such as + .
But you say "+" doesn't match "catch-all" at all!
Changing the >NFA however to an empty string, and making
it a prefix, changes that, matching everything.
"+" is "" followed by "+" , check!
lisp-symbol does the rest.

The 5-line lisp parser qualifies for a Jeff Fox hyped 100 times increase
of compactness, compared the parser presented in mal-forth.

NOTE: I have reworked the Schani lisp interpreter (gforth). https://github.com/schani/forthlisp
This parser has been lifted from the reworked lisp.
In the Clojure I expect to add a few more lines, for e.g. fixed object
like : false true nill .

Albert I am wondering if you built the primitive operations as postfix operations
could you make the whole thing look "LISPy" with:

50 LIFO: XSTK \ a stack

: ( ' XSTK PUSH ;
: ) XSTK POP EXECUTE ;

I know it works with Forth primitives but LISP may push this simple idea too hard.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2023Jun1.182516@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

Marcel Hendrix <mhx@iae.nl> writes:

Just throw gray at it. Gray is a Really Good Program.

Thank you. But I think it's overkill for parsing S-Expressions (Lisp >Syntax).

Thank *you*. I suspected it was overkill, but I now have
it an good authority that it is. Save me time.

- anton

--
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)

In article <2e33c5e9-b37b-4393-b3e5-4318509afce0n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
<SNIP>

So tokens are accumulated on the stack using a recursive(!) call
of INTERPRET that observes the input stream .
It ends with the token ) , that is just an alias of EXIT
such that this call of INTERPRET ends.

Then there is the meat.
'lisp-number aliases: 0 1 2 3 4 5 6 7 8 9
Single digit prefixes parse a number. No surprise there, familiar
technique in ciforth.
And then the surprising
: catch-all lisp-symbol ; PREFIX "" LATEST >NFA @ $!

catch-all catches the remaining tokens such as + .
But you say "+" doesn't match "catch-all" at all!
Changing the >NFA however to an empty string, and making
it a prefix, changes that, matching everything.
"+" is "" followed by "+" , check!
lisp-symbol does the rest.

The 5-line lisp parser qualifies for a Jeff Fox hyped 100 times increase
of compactness, compared the parser presented in mal-forth.

NOTE: I have reworked the Schani lisp interpreter (gforth).
https://github.com/schani/forthlisp
This parser has been lifted from the reworked lisp.
In the Clojure I expect to add a few more lines, for e.g. fixed object
like : false true nill .

Albert I am wondering if you built the primitive operations as postfix operations
could you make the whole thing look "LISPy" with:

50 LIFO: XSTK \ a stack

: ( ' XSTK PUSH ;
: ) XSTK POP EXECUTE ;

I know it works with Forth primitives but LISP may push
this simple idea too hard.

This is more or less what I plan to do with the mal build.
However XSTK can't be global, for (A B (C D)) is recursive.

Remember how evaluate works:
: EVALUATE SAVE SET-SRC INTERPRET RESTORE RESTORE ;
SAVE remembers the current io-state.
SET-SRC makes the (addr len) the input buffer, i.e. source
INTERPRET compiles/interpret the source until exhausted.
RESTORE restores the saved io-state.

The plan for mal is
I ( generates an empty list, leave it on the stack,
start a recursive / nested INTERPRET 1] .
Then finishes off the list, and leave it as a lisp-object
II* number / symbol / .... generate a lisp-object, tuck it to the
end of the list
III ) abandons the nested INTERPRET

The * means that step II is repeated.

There is a difference to EVALUATE; the parsing
has effect on the input stream, but going on where
the previous word left off.

A nested list can be part of the ...
That solves the parsing of expressions like (+ 2 (* 3 10))
More importantly you can add a [ ] pair that handles
an array. There is no change needed for ( ) , as long
as it leaves behind a lisp-object. Of course [ ] probably
uses a recursive INTERPRET.

1] This is fundamentally different from EXECUTE-PARSING.
I use the INTERPRET as is. EXECUTE-PARSING requires
a dedicated interpreter for each object type.
The proposed handling is also more powerful.
The ( ) doesn't change if I add a #T that generates a bool-object or
allow a nested () object or [] object.
This would affect the dedicated interpreter greatly.
--
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)

I think it also depends on coding style. In C, I put multiple statements when doing so doesn't make it look cluttered. Many people only put one statement per line.

Also, IMO, Forth lends itself to single, multiple statement lines.

In the end though, I'd guess it would probably be somewhere around 1/5 of the number of lines of C code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ccur...@gmail.com schrieb am Montag, 5. Juni 2023 um 15:22:34 UTC+2:

I think it also depends on coding style. In C, I put multiple statements when doing so doesn't make it look cluttered. Many people only put one statement per line.
Also, IMO, Forth lends itself to single, multiple statement lines.
In the end though, I'd guess it would probably be somewhere around 1/5 of the number of lines of C code.

What meets the eye as lines is rather irrelevant for modern C compilers. Preprocessor, libraries, AST, conversion to some IL with or without first optimizations
like constant folding, et cetera, make a big hodgepodge from any source.

When you really want expressiveness, use a higher level language than C.
But within Forth's tiny niche, Forth is a fit choice. ;o)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/06/2023 12:30 am, minforth wrote:

ccur...@gmail.com schrieb am Montag, 5. Juni 2023 um 15:22:34 UTC+2:

I think it also depends on coding style. In C, I put multiple statements when doing so doesn't make it look cluttered. Many people only put one statement per line.
Also, IMO, Forth lends itself to single, multiple statement lines.
In the end though, I'd guess it would probably be somewhere around 1/5 of the number of lines of C code.

What meets the eye as lines is rather irrelevant for modern C compilers. Preprocessor, libraries, AST, conversion to some IL with or without first optimizations
like constant folding, et cetera, make a big hodgepodge from any source.

When you really want expressiveness, use a higher level language than C.

Over which the programmer has even less control and influence.

But within Forth's tiny niche, Forth is a fit choice. ;o)

Forth requires one to 'line up your ducks' in a way C doesn't. I recently
had a forth word that was rather clumsy and comprised:

13 logical steps (let's call them LOCs)
43 tokens (@ ! etc)
166 bytes

After two days work (involved reworking support functions) got it down to:

11 logical steps
21 tokens
72 bytes

'LOCs' remained relatively unchanged but a very different outcome. I don't know whether C lets one write bad code (perhaps it's all bad :) but Forth certainly does.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxforth schrieb am Dienstag, 6. Juni 2023 um 04:06:54 UTC+2:

On 6/06/2023 12:30 am, minforth wrote:

ccur...@gmail.com schrieb am Montag, 5. Juni 2023 um 15:22:34 UTC+2:

I think it also depends on coding style. In C, I put multiple statements when doing so doesn't make it look cluttered. Many people only put one statement per line.
Also, IMO, Forth lends itself to single, multiple statement lines.
In the end though, I'd guess it would probably be somewhere around 1/5 of the number of lines of C code.

What meets the eye as lines is rather irrelevant for modern C compilers. Preprocessor, libraries, AST, conversion to some IL with or without first optimizations
like constant folding, et cetera, make a big hodgepodge from any source.

When you really want expressiveness, use a higher level language than C.

Over which the programmer has even less control and influence.

But within Forth's tiny niche, Forth is a fit choice. ;o)

Forth requires one to 'line up your ducks' in a way C doesn't. I recently
had a forth word that was rather clumsy and comprised:

13 logical steps (let's call them LOCs)
43 tokens (@ ! etc)
166 bytes

After two days work (involved reworking support functions) got it down to:

11 logical steps
21 tokens
72 bytes

'LOCs' remained relatively unchanged but a very different outcome. I don't know whether C lets one write bad code (perhaps it's all bad :) but Forth certainly does.

I learnt the hard and long way to prefer code readability and maintainability anytime over short and clever trick programming.

Only you can estimate when your two days invested for optimization work
will break even by some gained nanoseconds of speed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/06/2023 4:57 pm, minforth wrote:

dxforth schrieb am Dienstag, 6. Juni 2023 um 04:06:54 UTC+2:

On 6/06/2023 12:30 am, minforth wrote:

ccur...@gmail.com schrieb am Montag, 5. Juni 2023 um 15:22:34 UTC+2:

I think it also depends on coding style. In C, I put multiple statements when doing so doesn't make it look cluttered. Many people only put one statement per line.
Also, IMO, Forth lends itself to single, multiple statement lines.
In the end though, I'd guess it would probably be somewhere around 1/5 of the number of lines of C code.

What meets the eye as lines is rather irrelevant for modern C compilers. >>> Preprocessor, libraries, AST, conversion to some IL with or without first optimizations
like constant folding, et cetera, make a big hodgepodge from any source. >>>
When you really want expressiveness, use a higher level language than C.

Over which the programmer has even less control and influence.

But within Forth's tiny niche, Forth is a fit choice. ;o)

Forth requires one to 'line up your ducks' in a way C doesn't. I recently
had a forth word that was rather clumsy and comprised:

13 logical steps (let's call them LOCs)
43 tokens (@ ! etc)
166 bytes

After two days work (involved reworking support functions) got it down to: >>
11 logical steps
21 tokens
72 bytes

'LOCs' remained relatively unchanged but a very different outcome. I don't >> know whether C lets one write bad code (perhaps it's all bad :) but Forth
certainly does.

I learnt the hard and long way to prefer code readability and maintainability anytime over short and clever trick programming.

Only you can estimate when your two days invested for optimization work
will break even by some gained nanoseconds of speed.

In this case the application was such that Forth's much vaunted claim to fame
- 'smaller faster code' - was actually needed. No room for implementing locals for folks who can't put their ducks in row.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, June 6, 2023 at 8:57:21 AM UTC+2, minforth wrote:
[..]

I learnt the hard and long way to prefer code readability and maintainability anytime over short and clever trick programming.

Only you can estimate when your two days invested for optimization work
will break even by some gained nanoseconds of speed.

For the past 40 years I have struggled with slow computers and code that is
too slow for what I want to do. Given doubled speed every 18 months,
my present computer is 40 12 * 18 / 1+ 2^x . or 134,217,728 times more powerful than the one I had in 1983 (It's probably only 10^5 times faster because software has become 10^5 times less efficient). I think we can
safely say that more computing power allows to, or uncovers,
bigger problems we want to solve.
I agree that we have a budget of 10,000x to improve readability
and maintainability.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix schrieb am Dienstag, 6. Juni 2023 um 09:23:56 UTC+2:

On Tuesday, June 6, 2023 at 8:57:21 AM UTC+2, minforth wrote:
[..]

I learnt the hard and long way to prefer code readability and maintainability
anytime over short and clever trick programming.

Only you can estimate when your two days invested for optimization work will break even by some gained nanoseconds of speed.

For the past 40 years I have struggled with slow computers and code that is too slow for what I want to do. Given doubled speed every 18 months,
my present computer is 40 12 * 18 / 1+ 2^x . or 134,217,728 times more powerful than the one I had in 1983 (It's probably only 10^5 times faster because software has become 10^5 times less efficient). I think we can safely say that more computing power allows to, or uncovers,
bigger problems we want to solve.
I agree that we have a budget of 10,000x to improve readability
and maintainability.

-marcel

I started with Forth "professionally" around 1979 doing motor control
using a SYM-1 board. The speed was barely up to the task, but requirements
had been less then. You had to check the running Forth with an oscilloscope. :)

Today's digital motor control centers have become gigantic beasts, with many layers of software, running at different cycles and runtime priorities, often with
on-board diagnostic and external communication functions.

In practice only a portion of all that stuff is really used, depending on the customer.
Many functions are in administrative or background tasks, or rarely used (booting,
shutdown, error handling).

Reminds me of my new "smart" phone ... I am missing the keys ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2e47b4e3-a5d1-4b72-8635-98b0b6d03dd4n@googlegroups.com>,
minforth <minforth@arcor.de> wrote:
<SNIP>

I learnt the hard and long way to prefer code readability and maintainability >anytime over short and clever trick programming.

I guess I'm a lucky guy. My programming talent is so low that
I'm never tempted to do clever tricks. I'm forced to not only maintain readibility but meticulously document specification for every
word I write. Of lately I tend to write several tests for every word.

Only you can estimate when your two days invested for optimization work
will break even by some gained nanoseconds of speed.

Most of my optimisation work in maintenance consisted is burning down
clever tricks, unexpectedly resulting with a gain in speed.

The clojure/mal project progresses. I have completed step zero and one.
Step one is understanding expressions and printing the tree back.

~/PROJECT/ciforths/ciforth/LISPAOL/mal-forth$ step
user> (1 2 3)
[1 2 3 ]user> (a v c (1 2)(1 ()))
[a *v *c *[1 2 ][1 []]]user>

I generate empty Forth headers with a type, properly stored in the
FFA (flag field). Currently there are symbols,numbers and lists.
symbols have the payload in the NFA (name field)
numbers have the payload in the DFA (data field)
lists have a pointer to an ALLOCATEd array in the DFA.
This array contains the dictionary entry addresses of symbols,numbers
and nested lists.

The code is separated between lexer, parser, builder and printer.
They are short and functionally cohesive.

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)

On Tuesday, June 6, 2023 at 9:10:56 AM UTC+1, minforth wrote:

Marcel Hendrix schrieb am Dienstag, 6. Juni 2023 um 09:23:56 UTC+2:

On Tuesday, June 6, 2023 at 8:57:21 AM UTC+2, minforth wrote:
[..]

I learnt the hard and long way to prefer code readability and maintainability
anytime over short and clever trick programming.

Only you can estimate when your two days invested for optimization work will break even by some gained nanoseconds of speed.

For the past 40 years I have struggled with slow computers and code that is
too slow for what I want to do. Given doubled speed every 18 months,
my present computer is 40 12 * 18 / 1+ 2^x . or 134,217,728 times more powerful than the one I had in 1983 (It's probably only 10^5 times faster because software has become 10^5 times less efficient). I think we can safely say that more computing power allows to, or uncovers,
bigger problems we want to solve.
I agree that we have a budget of 10,000x to improve readability
and maintainability.

-marcel

I started with Forth "professionally" around 1979 doing motor control
using a SYM-1 board. The speed was barely up to the task, but requirements had been less then. You had to check the running Forth with an oscilloscope. :)

coo ... I had a SYM-1 user manual around then, and lusted after one of the boards.
I ended up with one about ten years later. Sadly I left if in a loft during a house
move, I think. It was an impressive board with great monitor SW, much better than
the better-known KIM-1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/06/2023 8:31 pm, albert wrote:

In article <2e47b4e3-a5d1-4b72-8635-98b0b6d03dd4n@googlegroups.com>,
minforth <minforth@arcor.de> wrote:
<SNIP>

I learnt the hard and long way to prefer code readability and maintainability
anytime over short and clever trick programming.

I guess I'm a lucky guy. My programming talent is so low that
I'm never tempted to do clever tricks. I'm forced to not only maintain readibility but meticulously document specification for every
word I write. Of lately I tend to write several tests for every word.

No tricks. If somebody has a problem with good concise forth then perhaps
they should be looking for a language better suited to their sensibilities.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

none albert schrieb am Dienstag, 6. Juni 2023 um 12:31:48 UTC+2:

In article <2e47b4e3-a5d1-4b72...@googlegroups.com>,
minforth <minf...@arcor.de> wrote:
<SNIP>

Only you can estimate when your two days invested for optimization work >will break even by some gained nanoseconds of speed.

Most of my optimisation work in maintenance consisted is burning down
clever tricks, unexpectedly resulting with a gain in speed.

In my experience there is also a psychological effect in this. Clearly worded and
well structured code illustrates the underlying algorithm, which appeals better to the human
analytical mind than obfuscated stack juggling code.

Now comes creativity: with the algorithm visibly in front of my eyes I sometimes
"out of the blue" just "detect or invent" new ways or shorter paths through the algorithm.
It is well known that improved algorithms are the best way towards speed gain.

It cannot be planned and sometimes just happens, with or without longer thought process.
My guess is that human intelligence is basically associative and uses pattern recognition
subconsciously.

Whereas a stack machine can serially digest ROTs and OVERs just fine, but lacks any intuition. ;-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, June 6, 2023 at 1:28:21 PM UTC+2, minforth wrote:
[..]

Now comes creativity: with the algorithm visibly in front of my eyes I sometimes
"out of the blue" just "detect or invent" new ways or shorter paths through the algorithm.
It is well known that improved algorithms are the best way towards speed gain.

[..]

I'm currently working on least-squares methods, and take a bit more
time than usual to try and understand the algorithms by implementing
them from scratch. Some illustrations to your statements:

Mathematical notation is quite good at hiding details that are critical
to *real* understanding. A case in point is something like
"I - phi^T * gamma" which can be read with an "Oh, yeah" attitude, but
actually 1. is not obvious when phi is a vector of functions pointers,
and 2. the size of "I" is (in my textbook) not stated explicitly. Worse,
some authors use the symbol I for *any size* matrices (including 1 x 1), anywhere in the code.

By not using the canned routines, surprising nuggets can be found. E.g.,
the standard LS routine works with all the data at once and potentially
has humongous space and time complexity. By use of the Sherman–Morrison–Woodbury formula it is possible to unwind the
code to a recursive RLS routine that only needs the current input and
output plus a few state variables, with matrix inversion degenerated to
a single division. This idea is of course useful in many places, and maybe
it also works to transform recursion into a massive linear equation.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix schrieb am Dienstag, 6. Juni 2023 um 19:29:25 UTC+2:

On Tuesday, June 6, 2023 at 1:28:21 PM UTC+2, minforth wrote:
[..]

Now comes creativity: with the algorithm visibly in front of my eyes I sometimes
"out of the blue" just "detect or invent" new ways or shorter paths through the algorithm.
It is well known that improved algorithms are the best way towards speed gain.

[..]

I'm currently working on least-squares methods, and take a bit more
time than usual to try and understand the algorithms by implementing
them from scratch. Some illustrations to your statements:

Mathematical notation is quite good at hiding details that are critical
to *real* understanding. A case in point is something like
"I - phi^T * gamma" which can be read with an "Oh, yeah" attitude, but actually 1. is not obvious when phi is a vector of functions pointers,
and 2. the size of "I" is (in my textbook) not stated explicitly. Worse, some authors use the symbol I for *any size* matrices (including 1 x 1), anywhere in the code.

By not using the canned routines, surprising nuggets can be found. E.g.,
the standard LS routine works with all the data at once and potentially
has humongous space and time complexity. By use of the Sherman–Morrison–Woodbury formula it is possible to unwind the
code to a recursive RLS routine that only needs the current input and
output plus a few state variables, with matrix inversion degenerated to
a single division. This idea is of course useful in many places, and maybe it also works to transform recursion into a massive linear equation.

A fascinating topic!

My 5 cents (with far from being an expert here):

Adaptive filtering is only as good as the input signal quality is, with the system
having to be nearly ergodic. Non-linear noise like spikes, A/D conversion jitter,
or transient process behaviour devalidate RLS results in the same way as
using unfiltered input signals for FFT. IOW the found coefficients are often useless despite correct linear algebra routines.

Therefore we often used hybrid concepts:
a) Butterworth filtering (sometimes with adaptive bandwidth) to smoothen inputs with minimal phase detortion
b) Simple stable forward controls (eg through curve generators) as fallback in error and transient situations
c) ergodicity supervision
d) when ergodic, using the adaptive filter; above item b) is crucial here: the parallel
active forward path brings the controller closer to its operating point, so that
a linear system approximation becomes more representative; or IOW the cyclically calculated RLS filter coefficients are stabler and of better quality.

So far for un-Forthish coding styles ... ;-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, June 6, 2023 at 8:41:39 PM UTC+2, minforth wrote:

Marcel Hendrix schrieb am Dienstag, 6. Juni 2023 um 19:29:25 UTC+2:

On Tuesday, June 6, 2023 at 1:28:21 PM UTC+2, minforth wrote:

[..]

A fascinating topic!

My 5 cents (with far from being an expert here):

Adaptive filtering is only as good as the input signal quality is, with the system
having to be nearly ergodic. Non-linear noise like spikes, A/D conversion jitter,
or transient process behaviour devalidate RLS results in the same way as using unfiltered input signals for FFT. IOW the found coefficients are often useless despite correct linear algebra routines.

Therefore we often used hybrid concepts:

[..]
That goes quite a bit farther than my copy of Astrom and Wittenmark,
"Adaptive Control" 2nd Ed. ... Do you have a pointer for me?

So far for un-Forthish coding styles ... ;-)

Do you really think so?

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix schrieb am Dienstag, 6. Juni 2023 um 21:20:09 UTC+2:

On Tuesday, June 6, 2023 at 8:41:39 PM UTC+2, minforth wrote:

Marcel Hendrix schrieb am Dienstag, 6. Juni 2023 um 19:29:25 UTC+2:

On Tuesday, June 6, 2023 at 1:28:21 PM UTC+2, minforth wrote:

[..]

A fascinating topic!

My 5 cents (with far from being an expert here):

Adaptive filtering is only as good as the input signal quality is, with the system
having to be nearly ergodic. Non-linear noise like spikes, A/D conversion jitter,
or transient process behaviour devalidate RLS results in the same way as using unfiltered input signals for FFT. IOW the found coefficients are often
useless despite correct linear algebra routines.

Therefore we often used hybrid concepts:

[..]
That goes quite a bit farther than my copy of Astrom and Wittenmark, "Adaptive Control" 2nd Ed. ... Do you have a pointer for me?

That hybrid technique is a more hands-on art and developed over decades.
I don't know a good textbook, but Smith predictors for short delays come close to it,
It's a kind of MPC borne more from practical experience than mathematical formulation (which is difficult anyhow when you use non-linear elements like dead-bands or switches in the model; you use simulation instead).

Off topic: in recent years some experiments with fuzzy logics or neural networks in the
forward predictive path took place. But although excellent in theory and with phantastic
results in stable demo systems, maintenance and trouble shooting IS A HOG !!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.lisp

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. (?)

I'm easily going to step3 a calculator implemented in this way.

Then I stumble upon this gem
"


Add the quasiquote function. The quasiquote function takes a parameter ast and has the following conditional.

If ast is a list starting with the "unquote" symbol, return its second element.

If ast is a list failing previous test, the result will be a list populated by the following process.

The result is initially an empty list. Iterate over each element elt of ast in reverse order:
If elt is a list starting with the "splice-unquote" symbol, replace the current result with a list containing: the "concat" symbol, the second element of elt, then the previous result.
Else replace the current result with a list containing: the "cons" symbol, the result of calling quasiquote with elt as argument, then the previous result.

This process can also be described recursively:
If ast is empty return it unchanged. else let elt be its first element.
If elt is a list starting with the "splice-unquote" symbol, return a list containing: the "concat" symbol, the second element of elt, then the result of processing the rest of ast.
Else return a list containing: the "cons" symbol, the result of calling quasiquote with elt as argument, then the result of processing the rest of ast.

If ast is a map or a symbol, return a list containing: the "quote" symbol, then ast.

Else return ast unchanged. Such forms are not affected by evaluation, so you may quote them as in the previous case if implementation is easier.

"
If a language needs such things I doubt its usefulness.

I suspect this has to do with the decision that a list
(a b c ) requires that a is a function (prohibiting a simple list
denotation as "(1 2 3)" ) and that b and c are "evaluated".
In this example "b" cannot be a symbol (no evaluation possible)
but has to be contrived to be a variable via a key-value hash map,
then it has to replaced by the value.

The mal quote continues :
"sets the stage for the next very exciting step: macros."

I come to suspect that macro's are in fact immediate words,
but more difficult to use.
We are experiencing a surge in artificial intelligence.
It is because of neural nets, not computer languages.

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)

"ccur...@gmail.com" <ccurl609@gmail.com> writes:

Also, IMO, Forth lends itself to single, multiple statement lines.

One of my most recent "aha!" moments with Forth was when I started to
use multiple spaces around sequences of words in order to express
the logical phrasing of the operations.

: myword ( u -- u' ) 1+ 2* dup . ;

Like that.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix <mhx@iae.nl> writes:

For the past 40 years I have struggled with slow computers and code that is >too slow for what I want to do. Given doubled speed every 18 months,

How did you measure that? I certainly have seen much less speedup in
the past 20 years for the stuff I care about.

my present computer is 40 12 * 18 / 1+ 2^x . or 134,217,728 times more >powerful than the one I had in 1983 (It's probably only 10^5 times faster >because software has become 10^5 times less efficient).

In the case of Gforth's small benchmarks, the software has become
slightly more efficient. So let's see (the numbers are times in
seconds):

sieve bubble matrix fib
25.87 29.96 23.25 29.98 i486 DX2/66 256KB cache; 0.4.9-20000726i486; gcc-2.95.1
0.189 0.176 0.148 0.201 Ryzen 5800X; 0.5.0 fast (no-dynamic) 32-bit; gcc-2.95
0.139 0.132 0.121 0.136 Ryzen 5800X; 0.7.9_20230601 fast --no-dynamic; gcc-10.2
0.057 0.055 0.033 0.045 Ryzen 5800X; 0.7.9-20210218 fast; gcc-10.2

The top line is from a CPU that was released in August 1992 (sorry, no comparison from 1983 available). The other lines are for a CPU that
was released in November 2020.

The second line is running the 5800X on a pretty similar binary to
what was run on the 486 (the 486 was run on a 0.5.0 pre-release, also
a 32-bit binary, also using gcc-2.95). The speedup over the 486 is a
factor 137-170 (with a clock rate increase by a factor of ~72).

The third line uses a 64-bit binary for a recent development Gforth,
but disables a number of optimizations (pretty much the major
difference since 0.5.0) with --no-dynamic. I expected the result to
have a speed compariable to 0.5.0, but there is a speedup of
1.22-1.48.

The last line uses the same binary as the third line, but without
disabling dynamic native code and all the optimizations based on it.
This produces another factor of 2.4-3.67 of speedup.

The total speedup over 0.5.0 (32-bit) is a factor 3.2-4.48, the total
speedup over the 486 with the 0.5.0 prerelease is 454-705. Your
fomula predicts a factor of 524288.

- 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 proceedings: http://www.euroforth.org/ef22/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl schrieb am Mittwoch, 7. Juni 2023 um 18:32:30 UTC+2:

Marcel Hendrix <m...@iae.nl> writes:

For the past 40 years I have struggled with slow computers and code that is >too slow for what I want to do. Given doubled speed every 18 months,

How did you measure that? I certainly have seen much less speedup in
the past 20 years for the stuff I care about.

<snip>

The total speedup over 0.5.0 (32-bit) is a factor 3.2-4.48, the total
speedup over the 486 with the 0.5.0 prerelease is 454-705. Your
fomula predicts a factor of 524288.

Just for perspective:

Sadly desktop/laptop PCs have not changed in any fundamental way since
their first market introduction, which can explain the observed factor difference.

But other bottlenecks like memory lane throughput, or physical effects
of wavelength limitation at higher clock frequencies play another role.

Nevertheless today PCs lag grossly behind available technology. See: https://www.offgridweb.com/preparation/infographic-the-growth-of-computer-processing-power/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.lisp

On 2023-06-07, albert@cherry.(none) (albert) <albert@cherry> wrote:

We are experiencing a surge in artificial intelligence.
It is because of neural nets, not computer languages.

Probably since I was a child, I took it for granted that sufficiently
large neural networks will show intelligence: that it's just a number
crunching problem requiring the hardware to have lots of space (and
parallel computing power in order to work in anything resembling real
time).

Not only that, but also that I will likely see this, or the start of it,
well within my lifetime. That dawn is here, pretty much.

I also already decided then that I wasn't interested in massive number crunching, regardless of its results.

The intelligence that results from it can at most be about as
interesting as people. We've had people for millennia, and only
a few of them have been interesting, so ...

I like my computations to be nice and tight, using a small amount of
resources in order to produce a precise, repeatable result, whose
every aspect can be explained and traced to a piece of code, which
can be traced to a requirement.

Groetjes Albert

You should open your mind more. Firstly, the MAL ("make a lisp") project
isn't a good way to learn about Lisp. It has a specific educational
goal and focus: to guide people through implementing Lisp-like
evaluation in any programming language, by following a certain recipe.

Production Lisps are not built according to such a recipe.

Quasiquation is something necessary and useful in Lisp because it's a
language which exhibits nested syntax. Just because you don't
have that in Forth doesn't mean it's nonsense. (Or that Forth is
nonsense due to not having that.)

MAL doesn't properly explain what quasiquotation is; it assumes you
know about it from somewhere else and just want to get it working
by following the steps in MAL.

Quotation allows a Lisp program to refer to a piece of its syntax
as a literal value. For instance whereas (+ 4 4) is an expression
that calculates 8, '(+ 4 4), which means exactly the same thing
as (quote (+ 4 4)) produces the value (+ 4 4): a list of three
elements, those being the + symbol, and the integer 4 appearing twice.

We can produce the same list in another way, for instance by
calling the list function with three arguments, which are evaluated expressions: (list '+ 4 4). The symbol + is quoted, otherwise
it is treated as the variable + whose value is to be referenced.
The advantage of list is that we can stick in variable material,
for instance

(defun make-funny-list (arg)
(list arg 4 4))

Now we can call (make-funny-list 3) to produce (3 4 4),
or (make-funny-list '-) to produce (- 4 4).

Quasiquotation lets us use a visual template to do the same thing.
Instead of the quote, a different character is used, typically
the backquote.

(defun make-funny-list (arg)
`(,arg 4 4))

Everything in the backquote is literal-like constant material,
except for the parts indicated by the comma unquote, like ,arg.
Those expressions are evaluated and the value is inserted.

The quasiquote is a templating language for creating nested
lists using a notation which looks like those lists, rather
than hard-to-read nested constructor calls.
A quasiquote can be nested and it can insert material into
any level of nesting.

This templating notation is heavily used in writing macros,
and other code-to-code transformation situations.
Sometimes it is used in manipulating data which isn't code, too.

Manipulating syntax is an different approach to metaprogramming than
what is going on in Forth; you're only selling yourself short
if you dismiss that casually without learning anything about it.
(And then dismissing it, if you're still inclined.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, June 7, 2023 at 6:32:30 PM UTC+2, Anton Ertl wrote:

Marcel Hendrix <m...@iae.nl> writes:

For the past 40 years I have struggled with slow computers and code that is >too slow for what I want to do. Given doubled speed every 18 months,

How did you measure that? I certainly have seen much less speedup in
the past 20 years for the stuff I care about.

[..]

The total speedup over 0.5.0 (32-bit) is a factor 3.2-4.48, the total speedup over the 486 with the 0.5.0 prerelease is 454-705. Your
fomula predicts a factor of 524288.

I found the "2x in 18 months" figure somewhere. Evidently, it's slightly exaggerated. If run time were proportional to clock speed, I could
have calculated a doubling of runspeed every 38 months, say every
3 years. (In 1983 I had a 1MHz Z80, nowadays a 5.5GHz AMD 5800X).

With that figure I get a speedup of 64 over 18 years (2020-1992), which
means Gforth is doing better than expected (not surprising).

The way technology unfolds, I don't expect to see 11GHz (or another brute-force way to get 2x faster) in the coming 3 years, which is rather worrisome.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, June 7, 2023 at 11:03:34 AM UTC-4, Andy Valencia wrote:

"ccur...@gmail.com" <ccur...@gmail.com> writes:

Also, IMO, Forth lends itself to single, multiple statement lines.

One of my most recent "aha!" moments with Forth was when I started to
use multiple spaces around sequences of words in order to express
the logical phrasing of the operations.

: myword ( u -- u' ) 1+ 2* dup . ;

Like that.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

I also use extra spaces to logically separate words that go together. (y)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <a202db94-3dbd-4a0f-85ef-e01e0386a0f8n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:

On Wednesday, June 7, 2023 at 6:32:30 PM UTC+2, Anton Ertl wrote:

Marcel Hendrix <m...@iae.nl> writes:

For the past 40 years I have struggled with slow computers and code that is >> >too slow for what I want to do. Given doubled speed every 18 months,

How did you measure that? I certainly have seen much less speedup in
the past 20 years for the stuff I care about.

[..]

The total speedup over 0.5.0 (32-bit) is a factor 3.2-4.48, the total
speedup over the 486 with the 0.5.0 prerelease is 454-705. Your
fomula predicts a factor of 524288.

I found the "2x in 18 months" figure somewhere. Evidently, it's slightly >exaggerated. If run time were proportional to clock speed, I could
have calculated a doubling of runspeed every 38 months, say every
3 years. (In 1983 I had a 1MHz Z80, nowadays a 5.5GHz AMD 5800X).

With that figure I get a speedup of 64 over 18 years (2020-1992), which
means Gforth is doing better than expected (not surprising).

The way technology unfolds, I don't expect to see 11GHz (or another >brute-force way to get 2x faster) in the coming 3 years, which is rather >worrisome.

I'm not worried about 11 Ghz. Exciting techniques replace it
neural nets, photonic chips, quantum computing.

-marcel

--
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)

On Thursday, June 8, 2023 at 12:05:39 PM UTC+2, none albert wrote:
[..]

The way technology unfolds, I don't expect to see 11GHz (or another >brute-force way to get 2x faster) in the coming 3 years, which is rather >worrisome.

I'm not worried about 11 Ghz. Exciting techniques replace it
neural nets, photonic chips, quantum computing.

Neural nets, yes. It was one of the first demo's I did in Forth, 40 years ago. Let's hope photons and quantums come faster.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix schrieb am Donnerstag, 8. Juni 2023 um 12:15:42 UTC+2:

On Thursday, June 8, 2023 at 12:05:39 PM UTC+2, none albert wrote:
[..]

The way technology unfolds, I don't expect to see 11GHz (or another >brute-force way to get 2x faster) in the coming 3 years, which is rather >worrisome.

I'm not worried about 11 Ghz. Exciting techniques replace it
neural nets, photonic chips, quantum computing.

Neural nets, yes. It was one of the first demo's I did in Forth, 40 years ago.
Let's hope photons and quantums come faster.

With the avarage IQ continuously decreasing on this planet, I have my doubts.

Neural nets require _substantial_ amounts of resources (input data, kilowatts and
human brain) that are scarce and expensive. Poor nets or poor data quality requires
even more.

There are guys who implement neural nets just for non-working backpropagation to compensate poor or noisy inputs... When this doesn't work, they add another layer
and apply for more funding... It's a phantastic career driver.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 8, 2023 at 12:38:34 PM UTC+2, minforth wrote:

With the avarage IQ continuously decreasing on this planet, I have my doubts.

On that, I have no worries: it will always be 100.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

minforth <minforth@arcor.de> writes:

Sadly desktop/laptop PCs have not changed in any fundamental way since
their first market introduction, which can explain the observed factor difference.

What fundamental way do you have in mind? When I compare my current
system with my C64 or an IBM 5150 (the orginal IBM PC), I see a lot of
changes.

But other bottlenecks like memory lane throughput,

Throughput in general has increased more than what I measure with the
Gforth benchmarks.

or physical effects
of wavelength limitation at higher clock frequencies play another role.

Wavelength limitation? What's that?

I know of two important factors that slowed down the clock rate
increases when the process sizes shrank down to 130nm, 90nm and below.

* Voltage reduction did not scale down as fast as earlier (and has
reached pretty much a standstill), which means that faster switching
would increase power dissipation. And power density increases as

* Wires rather than transistors become the dominant cause of latency.
And signals on wires become slower as the processes shrink (they
become slower even if you take the shrinking into account). They
seem to be able to work around that with an ever-increasing number
of metal layers. And, I expect that for the long distances, they
use wider wires, but they have to drive them with more power to
actually see a speed increase from the width.

Nevertheless today PCs lag grossly behind available technology. See: >https://www.offgridweb.com/preparation/infographic-the-growth-of-computer-processing-power/

I assume you mean the MFlops number on this page. The fastest
supercomputers on which these numbers were measured will run the
Gforth benchmarks at roughly the same speed as the Ryzen 5800X I used
(probably a little slower, because they run at lower clock speed).

OTOH, if you are interested in multiplying FP matrices, you will see
larger speedups between the 486 and the Ryzen 5800X, thanks to stuff
like:

* SIMD instructions (AVX)
* multi-core

and generally, modern hardware has improved more on throughput
(i.e. parallel) jobs than on latency-oriented stuff like the Gforth
benchmarks.

- 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 proceedings: http://www.euroforth.org/ef22/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix <mhx@iae.nl> writes:

On Wednesday, June 7, 2023 at 6:32:30=E2=80=AFPM UTC+2, Anton Ertl wrote:

Marcel Hendrix <m...@iae.nl> writes:=20

For the past 40 years I have struggled with slow computers and code that=

is=20

too slow for what I want to do. Given doubled speed every 18 months,

How did you measure that? I certainly have seen much less speedup in=20
the past 20 years for the stuff I care about.

[..]

The total speedup over 0.5.0 (32-bit) is a factor 3.2-4.48, the total=20
speedup over the 486 with the 0.5.0 prerelease is 454-705. Your=20
fomula predicts a factor of 524288.

I found the "2x in 18 months" figure somewhere.

You probably found the 1975 version of Moore's law. But it refers to transistors per chip, not performance.

Evidently, it's slightly
exaggerated.

Moore originally predicted this development speed for 10 years (for
more details, read <http://jimgray.azurewebsites.net/moore_law.html>).
Looking at DRAM sizes, it held up much longer, but even DRAM growth
seems to have slowed down in recent years. OTOH, looking at flash
growth, we may still be seeing Moore at work (but I have not looked at
the exact numbers).

If run time were proportional to clock speed, I could
have calculated a doubling of runspeed every 38 months, say every
3 years. (In 1983 I had a 1MHz Z80, nowadays a 5.5GHz AMD 5800X).

1MHz Z80? Even the very first Z80 in 1976 clocked at 2.5MHz.

In any case, there was not a constant growth rate during these times.
We see this nicely with Intel CPUs:

year CPU clock factor
1978 8086 5MHz
5
1989 i486 25MHz
60
2000 Pentium 4 1500MHz
2.6
2011 i7-2700K 3900MHz
1.5
2022 i7-13900K 5800MHz

With that figure I get a speedup of 64 over 18 years (2020-1992), which
means Gforth is doing better than expected (not surprising).

That was 28 years, but the clock rate increase is indeed 72. The
Ryzen 5800X also executes more instructions per cycle, as can be seen
when looking at the 0.5.0 results.

The way technology unfolds, I don't expect to see 11GHz (or another=20 >brute-force way to get 2x faster) in the coming 3 years, which is rather >worrisome.

We have recently seen a factor 1.5 in 11 years, so a factor of 2 in
the next 3 years would be very surprising.

One interesting advance in recent years has been a significant
increase in the number of cores: 2016 Intel sold 4-core CPUs in the
desktop, now they sell 24 (8P and 16E cores, but still). For performance-sensitive software the benefit of going for
parallelization increases.

- 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 proceedings: http://www.euroforth.org/ef22/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 8, 2023 at 4:29:21 PM UTC+2, Anton Ertl wrote:

Marcel Hendrix <m...@iae.nl> writes:

[..]

1MHz Z80? Even the very first Z80 in 1976 clocked at 2.5MHz.

[..]
My Sinclair ZX80 had a 3.25MHz clock. It's 'slow mode' gave 80%
of the CPU time to the display. So my '1MHz' is already much to generous.

And yes, the 1kB memory was plenty enough for me (I wasn't interested
in home computers and gaming at all, and just wanted to learn a bit of
BASIC).

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 8, 2023 at 4:59:02 PM UTC+2, Anton Ertl wrote:
[..]

OTOH, if you are interested in multiplying FP matrices, you will see
larger speedups between the 486 and the Ryzen 5800X, thanks to stuff
like:

* SIMD instructions (AVX)
* multi-core

and generally, modern hardware has improved more on throughput
(i.e. parallel) jobs than on latency-oriented stuff like the Gforth benchmarks.

For NGSPICE, recompiling for AVX hardware makes zero difference.
I did some experiments coding my own SIMD matrix multiply in
assembler, but lots of effort only gave me a factor of ~2 increase
(others may do better), and no guarantee that my architecture-dependent
tricks would still work after a few years.

For circuit simulation, the best algorithms/programs I have seen scale
up to about 6 cores (with horrendous effort), then very quickly level off.
And of course, there is (or that is) Amdahl's law.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <885524f0-f70f-47e2-bae0-33fc83412828n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:

On Thursday, June 8, 2023 at 4:59:02 PM UTC+2, Anton Ertl wrote:
[..]

OTOH, if you are interested in multiplying FP matrices, you will see
larger speedups between the 486 and the Ryzen 5800X, thanks to stuff
like:

* SIMD instructions (AVX)
* multi-core

and generally, modern hardware has improved more on throughput
(i.e. parallel) jobs than on latency-oriented stuff like the Gforth
benchmarks.

For NGSPICE, recompiling for AVX hardware makes zero difference.
I did some experiments coding my own SIMD matrix multiply in
assembler, but lots of effort only gave me a factor of ~2 increase
(others may do better), and no guarantee that my architecture-dependent >tricks would still work after a few years.

For circuit simulation, the best algorithms/programs I have seen scale
up to about 6 cores (with horrendous effort), then very quickly level off. >And of course, there is (or that is) Amdahl's law.

I'm tempted to buy a double xeon (refurbished) on aliexpress ($1200 )
Two time 22 cores 44 thread and 256 Gbyte ECC memory.
I hope the prime counting programs fare better in parallelization.

Profit of the novelties in chips is mainly restricted to c-compiler
builders closely tied to the manufacturers nowadays, I guess.

-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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix <mhx@iae.nl> writes:

For NGSPICE, recompiling for AVX hardware makes zero difference.

Auto-vectorization is a hit-or-miss thing (with frequent misses).

I did some experiments coding my own SIMD matrix multiply in
assembler, but lots of effort only gave me a factor of ~2 increase
(others may do better), and no guarantee that my architecture-dependent >tricks would still work after a few years.

As it happens, I also experimented with matrix multiply. You can read
about it (in German) on <http://www.complang.tuwien.ac.at/anton/lvas/effizienz/matmul/>.
Switching from scalar to AVX bought a factor 2.12 (already from auto-vectorization); further optimizations bought another factor of 4;
no assembly language involved.

For circuit simulation, the best algorithms/programs I have seen scale
up to about 6 cores (with horrendous effort), then very quickly level off. >And of course, there is (or that is) Amdahl's law.

Yes, not every problem is parallelizable.

- 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 proceedings: http://www.euroforth.org/ef22/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 8, 2023 at 9:16:06 PM UTC+2, none albert wrote:
[..]

I'm tempted to buy a double xeon (refurbished) on aliexpress ($1200 )
Two time 22 cores 44 thread and 256 Gbyte ECC memory.

I bought a refurbished HP Z840 from Creoserver in Zwolle. A real tank.
You won't get 256 GByte ECC for that price, but their stuff is fully
tested and they deliver it personally at your door.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/06/2023 10:53 pm, Marcel Hendrix wrote:

On Thursday, June 8, 2023 at 12:38:34 PM UTC+2, minforth wrote:

With the avarage IQ continuously decreasing on this planet, I have my doubts.

On that, I have no worries: it will always be 100.

It will need to be your AI since the organism wears out.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix <mhx@iae.nl> writes:

On Thursday, June 8, 2023 at 4:29:21=E2=80=AFPM UTC+2, Anton Ertl wrote:

Marcel Hendrix <m...@iae.nl> writes:

[..]

1MHz Z80? Even the very first Z80 in 1976 clocked at 2.5MHz.

[..]
My Sinclair ZX80 had a 3.25MHz clock. It's 'slow mode' gave 80%
of the CPU time to the display. So my '1MHz' is already much to generous.

According to <https://en.wikipedia.org/wiki/ZX81>, the ZX81 in slow
mode gives the majority of the memory bandwidth to the display,
starving the CPU. The CPU still runs at 3.25MHz, and in fast mode you
get the full performance. The ZX80 has no slow mode, so I guess you
owned a ZX81.

- 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 proceedings: http://www.euroforth.org/ef22/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.lisp

In article <20230607130305.691@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:

On 2023-06-07, albert@cherry.(none) (albert) <albert@cherry> wrote:

We are experiencing a surge in artificial intelligence.
It is because of neural nets, not computer languages.

Probably since I was a child, I took it for granted that sufficiently
large neural networks will show intelligence: that it's just a number >crunching problem requiring the hardware to have lots of space (and
parallel computing power in order to work in anything resembling real
time).

Not only that, but also that I will likely see this, or the start of it,
well within my lifetime. That dawn is here, pretty much.

I too saw it coming, I've similar idea's but was nowhere near
able to implement it. There were machines in factories, then
machine to build this machines, then computers to design these
machines, and now ai to design factories around this.
The only problems to solve are overpopulation, global warming and
energy.

I also already decided then that I wasn't interested in massive number >crunching, regardless of its results.

The intelligence that results from it can at most be about as
interesting as people. We've had people for millennia, and only
a few of them have been interesting, so ...

What is more interesting is to see an intelligence develop,
say the first 10 years of a child. That is possible in a
smaller time frame, if not overnight.

There is no communication possible with an ai caused by
a speed discrepancy. If you converse with an ai, she can
learn mandarin while you formulate your next thought.

I like my computations to be nice and tight, using a small amount of >resources in order to produce a precise, repeatable result, whose
every aspect can be explained and traced to a piece of code, which
can be traced to a requirement.

Groetjes Albert

You should open your mind more. Firstly, the MAL ("make a lisp") project >isn't a good way to learn about Lisp. It has a specific educational
goal and focus: to guide people through implementing Lisp-like
evaluation in any programming language, by following a certain recipe.

Rest assured. I use it as a programming challenge only.
Forth is supposed to extend the language. This should mean that
you don't write an interpreter for mal, you should morph Forth
into mal.
For example let ';' be the comment symbol as in mal.
";" now becomes a Forth word, reading to the end of line and
discard it.

Production Lisps are not built according to such a recipe.

All compilers are based on C, because the chip manufacturers
target c-compilers. I know.

<SMIP >Quasiquation explained>

Thank you. That clears things up, and inspires me to go on
with mal.

This templating notation is heavily used in writing macros,
and other code-to-code transformation situations.
Sometimes it is used in manipulating data which isn't code, too.

This reminds me of a trick ^H^H^H^H^H technique I use to
generate classes via a sort of template.
The name is duplicated several times and filled in at the %s.
NAME$ $@ 2DUP 2DUP 2DUP
": %s CREATE BUILD-%s ^%s ! DOES> ^%s ! ;" FORMAT&EVAL
Resulting in the source code for class rectangle
: rectangle CREATE BUILD-rectangle ^rectangle ! DOES> ^rectangle ! ; The %s is similar to quasicode, I guess. 1]
The line is then compiled to add rectangle to the keywords.

Manipulating syntax is an different approach to metaprogramming than
what is going on in Forth; you're only selling yourself short
if you dismiss that casually without learning anything about it.
(And then dismissing it, if you're still inclined.)

Certainly willing to learn from your explanation.


Groetjes Albert
1] Looks primitive and it is. The source code for class is
one block 16 lines by 64 chars. It is supported by formatting
that is also one block, but is useful in its own right.
--
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)

In article <88f7087a-3875-463e-a2a4-ac42055bea00n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:

On Thursday, June 8, 2023 at 9:16:06 PM UTC+2, none albert wrote:
[..]

I'm tempted to buy a double xeon (refurbished) on aliexpress ($1200 )
Two time 22 cores 44 thread and 256 Gbyte ECC memory.

I bought a refurbished HP Z840 from Creoserver in Zwolle. A real tank.
You won't get 256 GByte ECC for that price, but their stuff is fully
tested and they deliver it personally at your door.

I have an offer here from Maas. 256 Gbyte 2 * Xeon 13 core.
potent graphics card. Euro 1600. Should I do it?

-marcel

--
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)

On Wednesday, June 14, 2023 at 5:54:11 PM UTC+2, none albert wrote:

In article <88f7087a-3875-463e...@googlegroups.com>,
Marcel Hendrix <m...@iae.nl> wrote:

I bought a refurbished HP Z840 from Creoserver in Zwolle. A real tank.
You won't get 256 GByte ECC for that price, but their stuff is fully >tested and they deliver it personally at your door.

I have an offer here from Maas. 256 Gbyte 2 * Xeon 13 core.
potent graphics card. Euro 1600. Should I do it?

That's a Z640, not a Z840. A 13 core Xeon? Either 12 or 14.
They look like low clockspeed, maybe the RAM won't work with the
faster ones, or the PSU is too small for the maximum layout.
The vendor looks sound enough.

IIRC, the 640 has a lower power PSU that is difficult to replace.
The heatsinks on the CPU's are lower quality than those on the
840. Check out Youtube, it has sterling advice from real experts.

It's just my opinion, that rock probably does all you want it to do.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <9b2d9502-ec36-45c2-999c-6688fa88c687n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:

On Wednesday, June 14, 2023 at 5:54:11 PM UTC+2, none albert wrote:

In article <88f7087a-3875-463e...@googlegroups.com>,
Marcel Hendrix <m...@iae.nl> wrote:

I bought a refurbished HP Z840 from Creoserver in Zwolle. A real tank.
You won't get 256 GByte ECC for that price, but their stuff is fully
tested and they deliver it personally at your door.

I have an offer here from Maas. 256 Gbyte 2 * Xeon 13 core.
potent graphics card. Euro 1600. Should I do it?

That's a Z640, not a Z840. A 13 core Xeon? Either 12 or 14.
They look like low clockspeed, maybe the RAM won't work with the
faster ones, or the PSU is too small for the maximum layout.
The vendor looks sound enough.

IIRC, the 640 has a lower power PSU that is difficult to replace.
The heatsinks on the CPU's are lower quality than those on the
840. Check out Youtube, it has sterling advice from real experts.

It's just my opinion, that rock probably does all you want it to do.

It has arrived. The cooling looks terrific, and it is a Z840.
It has about as many fans as the 64 transputer 17' inch rack.

-marcel

--
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)