On 12/28/2021, dxforth wrote:

> "We choose to go to the Moon [...] and do the other things, not because
> they are easy, but because they are hard;

https://archive.org/details/DidWeLandOnTheMoon
https://archive.org/details/EndgameVostfr
https://archive.org/details/DidWeReallyLandMenOnTheMoon
http://archive.org/details/WasItOnlyAPaperMoonApolloHoaxJamesM.Collier1997
http://archive.org/details/BillKaysingRawInterview
http://archive.org/details/RalphReneRawInterview
https://archive.org/details/BartSibrelMoonMyths
https://archive.org/details/Season2Episode8BartSibrel
https://archive.org/details/LunarConspiracy

--
DELTA OMICRON =
MEDIA CONTROL

On 1/02/2022 13:12, Robert L. wrote:
> On 12/28/2021, dxforth wrote:
>
>> "We choose to go to the Moon [...] and do the other things, not because
>> they are easy, but because they are hard;
>
> https://archive.org/details/DidWeLandOnTheMoon
> https://archive.org/details/EndgameVostfr
> https://archive.org/details/DidWeReallyLandMenOnTheMoon
> http://archive.org/details/WasItOnlyAPaperMoonApolloHoaxJamesM.Collier1997
> http://archive.org/details/BillKaysingRawInterview
> http://archive.org/details/RalphReneRawInterview
> https://archive.org/details/BartSibrelMoonMyths
> https://archive.org/details/Season2Episode8BartSibrel
> https://archive.org/details/LunarConspiracy
>

When it comes to beliefs, I choose the easy ones because they are easy.

On 12/24/2021, Andy Valencia wrote:

> counting the number of words in the diction with an "a" in them

variable na
s" words" r/o open-file throw Value f

variable buf
: read-ch buf 1 f read-file throw 0= throw
buf c@ ;

: matches ( char -- char bool ) dup read-ch = ;

: read-till ( char -- ) begin matches until drop ;

: count-a-words
begin
[char] a read-till
1 na +!
10 read-till
again ;

' count-a-words catch drop na ?
f close-file throw

--
archive.org/details/nolies

On 2/1/22 7:05 AM, Robert L. wrote:
> variable na
> s" words" r/o open-file throw Value f
>
> variable buf
> : read-ch buf 1 f read-file throw 0= throw
> buf c@ ;
>
> : matches ( char -- char bool ) dup read-ch = ;
>
> : read-till ( char -- ) begin matches until drop ;
>
> : count-a-words
> begin
> [char] a read-till
> 1 na +!
> 10 read-till
> again ;
>
> ' count-a-words catch drop na ?
> f close-file throw

You used library code in the other languages you presented. Seems to me
that library code could(should) also be used in a Forth solution:

https://github.com/DouglasBHoffman/FMS2
include FMS2VT.f
include array.f
include string.f
include file.f

s" /usr/share/dict/words" file f r/o f :fam
0 [: 'a' swap :chsearch if 1+ then ;] f :apply .

Granted, with Forth everyone seems to use their own library code.

The :apply HOF will step through each line of the file and pass that to
the quotation as a string object.

-Doug

Doug Hoffman schrieb am Dienstag, 1. Februar 2022 um 13:46:46 UTC+1:
> On 2/1/22 7:05 AM, Robert L. wrote:
> > variable na
> > s" words" r/o open-file throw Value f
> >
> > variable buf
> > : read-ch buf 1 f read-file throw 0= throw
> > buf c@ ;
> >
> > : matches ( char -- char bool ) dup read-ch = ;
> >
> > : read-till ( char -- ) begin matches until drop ;
> >
> > : count-a-words
> > begin
> > [char] a read-till
> > 1 na +!
> > 10 read-till
> > again ;
> >
> > ' count-a-words catch drop na ?
> > f close-file throw
> You used library code in the other languages you presented. Seems to me
> that library code could(should) also be used in a Forth solution:
>
> https://github.com/DouglasBHoffman/FMS2
> include FMS2VT.f
> include array.f
> include string.f
> include file.f
>
> s" /usr/share/dict/words" file f r/o f :fam
> 0 [: 'a' swap :chsearch if 1+ then ;] f :apply .
>
> Granted, with Forth everyone seems to use their own library code.
>
> The :apply HOF will step through each line of the file and pass that to
> the quotation as a string object.
>

Impressive! Thanks for this example.

And once again you nailed down the "crux of standard Forth": meagre libraries
force Forth programmers to roll their own DSL. Babylonian confusion of
languages is the result.

IMHO your FMS2 should become part of Forth203X ...

On 1 Feb 2022 at 20:51:37 CET, "minforth@arcor.de" <minforth@arcor.de> wrote:
>
> And once again you nailed down the "crux of standard Forth": meagre libraries
> force Forth programmers to roll their own DSL. Babylonian confusion of
> languages is the result.
>
> IMHO your FMS2 should become part of Forth203X ...

Some while ago, I attempted to promote a standard for Forth OOP, regardless of
whether it came from Neon of FMS (my personal favourite). Now that I am no
longer
the Forth 200x chair, I can apply what energy I have to libraries. IMHO the
Forth
200x kernel is adequate - modifications will introduce as many problems as
they
solve.

The first libraries I will focus on are strings and FMS.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

Stephen Pelc schrieb am Dienstag, 1. Februar 2022 um 22:33:10 UTC+1:
> On 1 Feb 2022 at 20:51:37 CET, "minf...@arcor.de" <minf...@arcor.de> wrote:
> >
> > And once again you nailed down the "crux of standard Forth": meagre libraries
> > force Forth programmers to roll their own DSL. Babylonian confusion of
> > languages is the result.
> >
> > IMHO your FMS2 should become part of Forth203X ...
> Some while ago, I attempted to promote a standard for Forth OOP, regardless of
> whether it came from Neon of FMS (my personal favourite). Now that I am no
> longer
> the Forth 200x chair, I can apply what energy I have to libraries. IMHO the
> Forth
> 200x kernel is adequate - modifications will introduce as many problems as
> they
> solve.
>
> The first libraries I will focus on are strings and FMS.
>

Right. What spurned my response (among other things) is the seamless coexistence
of objects in the dictionary and in the heap. There are even two words dict> and
heap> for fine control.

Standard Forth has just a generic but otherwise empty notion of heap memory
through the memory wordset. To improve/extend Forth's string wordset by dynamic
strings would call quite naturally for heap objects.

On 2/1/22 2:51 PM, minf...@arcor.de wrote:

> And once again you nailed down the "crux of standard Forth": meagre libraries
> force Forth programmers to roll their own DSL. Babylonian confusion of
> languages is the result.
>
> IMHO your FMS2 should become part of Forth203X ...

Some Forthers detest oop.
Some have written their own string and oop extensions. There are already
several of each available.
Some say mini-oof is all the oop they need/want.

Regardless, thanks for the feedback.

-Doug

Doug Hoffman schrieb am Mittwoch, 2. Februar 2022 um 10:28:39 UTC+1:
> On 2/1/22 2:51 PM, minf...@arcor.de wrote:
>
> > And once again you nailed down the "crux of standard Forth": meagre libraries
> > force Forth programmers to roll their own DSL. Babylonian confusion of
> > languages is the result.
> >
> > IMHO your FMS2 should become part of Forth203X ...
> Some Forthers detest oop.
> Some have written their own string and oop extensions. There are already
> several of each available.
> Some say mini-oof is all the oop they need/want.
>
> Regardless, thanks for the feedback.
>
> -Doug

You are welcome. I guess even in Babylon everybody spoke his/her mother tongue
at home. Nothing bad about it.

However for successfully doing work and trade and shopping one needs
one common language understood and spoken by all. IIRC in Babylonian time
it was Accadian spoken and kuneiform written, today it is mostly English all
over the world. Even within China, Mandarin is not spoken everywhere.

The analogy to one common OOP language for Forth is obvious. He who can
work fine with mini-oof has only mini-oo requirements. Nothing bad about it.

If I could do my math with fixed-point numbers, I won't need any fat floating-point
number wordset. But still I am glad that I have it ready - battle-proven
(also by other people!!) and well documented and accepted by customers
because it had been standardized - should I ever need it in future.

Andreas

On Wed, 2 Feb 2022 02:48:46 -0800 (PST)
"minf...@arcor.de" <minforth@arcor.de> wrote:

> Doug Hoffman schrieb am Mittwoch, 2. Februar 2022 um 10:28:39 UTC+1:
> > On 2/1/22 2:51 PM, minf...@arcor.de wrote:
> >
> > > And once again you nailed down the "crux of standard Forth": meagre libraries
> > > force Forth programmers to roll their own DSL. Babylonian confusion of
> > > languages is the result.
> > >
> > > IMHO your FMS2 should become part of Forth203X ...
> > Some Forthers detest oop.
> > Some have written their own string and oop extensions. There are already
> > several of each available.
> > Some say mini-oof is all the oop they need/want.
> >
> > Regardless, thanks for the feedback.
> >
> > -Doug
>
> You are welcome. I guess even in Babylon everybody spoke his/her mother tongue
> at home. Nothing bad about it.
>
> However for successfully doing work and trade and shopping one needs
> one common language understood and spoken by all. IIRC in Babylonian time
> it was Accadian spoken and kuneiform written, today it is mostly English all
> over the world. Even within China, Mandarin is not spoken everywhere.
>
> The analogy to one common OOP language for Forth is obvious. He who can
> work fine with mini-oof has only mini-oo requirements. Nothing bad about it.
>
> If I could do my math with fixed-point numbers, I won't need any fat floating-point
> number wordset. But still I am glad that I have it ready - battle-proven
> (also by other people!!) and well documented and accepted by customers
> because it had been standardized - should I ever need it in future.
>
> Andreas

There are n diffrent implementation of x. You decide to set a standard; there are now x+1 versions to choose from.

--
Bah, and indeed Humbug.

On Wednesday, February 2, 2022 at 10:28:39 AM UTC+1, Doug Hoffman wrote:
> Some Forthers detest oop.
Agreed - I developed it, but apart from making "design patterns" I do very little with it. Agreed, some libs would IMHO benefit from a more beautiful and elegant API, but it's not worth the burden and hassle OOP brings along. In many (not all!) instances, it would simply convert "STRUCT WORD" to "OBJECT -> METHOD".

> Some have written their own string and oop extensions. There are already
> several of each available.
True. FOOS (4tH OOP) has been there since 2013 - and vastly improved ever since. It features all your usual OOP junk (incl. inheritance) and lately even constructors, destructors and forwarding of classes. And it uses 4tH's strengths. I find most Forth OOP syntaxes quite ugly. So you won't see me switch pretty quickly. Too much work has gone into that.

> Some say mini-oof is all the oop they need/want.
Well, I started out with this one ;-) Still, I don't wanna go back to the home plate.

Hans Bezemer

On 2/02/2022 20:28, Doug Hoffman wrote:
> On 2/1/22 2:51 PM, minf...@arcor.de wrote:
>
>> And once again you nailed down the "crux of standard Forth": meagre libraries
>> force Forth programmers to roll their own DSL. Babylonian confusion of
>> languages is the result.
>>
>> IMHO your FMS2 should become part of Forth203X ...
>
> Some Forthers detest oop.
> Some have written their own string and oop extensions. There are already
> several of each available.
> Some say mini-oof is all the oop they need/want.
>
> Regardless, thanks for the feedback.
>
> -Doug

It's never stopped 200x. You need to be more pushy. 'Consensus' may be
how it's advertised but the gameplay is a combination of 'Who dares wins'
and 'Whack-a-mole'. Much like regular politics.

the.bee...@gmail.com schrieb am Mittwoch, 2. Februar 2022 um 12:06:40 UTC+1:
> On Wednesday, February 2, 2022 at 10:28:39 AM UTC+1, Doug Hoffman wrote:
> > Some Forthers detest oop.
> Agreed - I developed it, but apart from making "design patterns" I do very little with it. Agreed, some libs would IMHO benefit from a more beautiful and elegant API, but it's not worth the burden and hassle OOP brings along. In many (not all!) instances, it would simply convert "STRUCT WORD" to "OBJECT -> METHOD".
> > Some have written their own string and oop extensions. There are already
> > several of each available.
> True. FOOS (4tH OOP) has been there since 2013 - and vastly improved ever since. It features all your usual OOP junk (incl. inheritance) and lately even constructors, destructors and forwarding of classes. And it uses 4tH's strengths. I find most Forth OOP syntaxes quite ugly. So you won't see me switch pretty quickly. Too much work has gone into that.
> > Some say mini-oof is all the oop they need/want.
> Well, I started out with this one ;-) Still, I don't wanna go back to the home plate.
>

IMO it all boils down to "I wanna share my OO applications
plus I wanna benefit from other people's ideas and code".
Then one common OO language is absolutely necessary.

If FOOS can be be ANSI-fied and plays in the same quality
ballpark as FMS, fine by me to let FOOS become that new
standard OO language. At least finally we have one.

All the other talks are just a matter of personal preference,
or often within c.l.f. ole redneck programmers' stubborness
(not meaning you personally, there are others...)

On 2/2/22 6:06 AM, Hans Bezemer wrote:
> On Wednesday, February 2, 2022 at 10:28:39 AM UTC+1, Doug Hoffman wrote:
>> Some Forthers detest oop.
> Agreed - I developed it, but apart from making "design patterns" I do
> very little with it. Agreed, some libs would IMHO benefit from a more
> beautiful and elegant API, but it's not worth the burden and hassle
> OOP brings along. In many (not all!) instances, it would simply
> convert "STRUCT WORD" to "OBJECT -> METHOD".

Without objects and methods one must do something like:

structa array-insert
structs string-insert
structh hashtable-insert
structj json-insert
etc.

structa array-each
structs string-each
structh hashtable-each
structj json-each
structf file-each
etc.
: someWord ( structx -- ) each ; \ not possible, each must be qualified

With objects and methods:

objectx insert
objectx each
etc.
: someWord ( objectx -- ) each ; \ easy

There is encapsulation and more.
My point:
It's not simply "STRUCT WORD" to "OBJECT -> METHOD" ( -> is superfluous)

-Doug

On Wednesday, February 2, 2022 at 5:31:04 PM UTC+1, Doug Hoffman wrote:
> My point:
> It's not simply "STRUCT WORD" to "OBJECT -> METHOD" ( -> is superfluous)
Wow. This is completely new to me. And of course there is NO OTHER WAY than OO to implement that. Without OOP you're COMPLETELY unable to achieve such abstraction.

And yes, "->" in 4tH compiles to exactly NOTHING. It is my way to note you're working with a member of a structure (or a property or a method). It is there because I think:

begin-structure person
field: ->Length
field: ->Age
field: ->Zipcode
end-structure

Is REALLY butt ugly code. There is a reason for everything.

Hans Bezemer

On Wednesday, February 2, 2022 at 1:49:01 PM UTC+1, minf...@arcor.de wrote:
> IMO it all boils down to "I wanna share my OO applications
> plus I wanna benefit from other people's ideas and code".
> Then one common OO language is absolutely necessary.
Yes. But I think the Forth community has waited too long. You can nick my code if you want to - free license. You may have to put in some effort. Some FOOS programs are ported as well - often from vastly different languages. Ridiculous argument, if you ask me.
> If FOOS can be be ANSI-fied and plays in the same quality
> ballpark as FMS, fine by me to let FOOS become that new
> standard OO language. At least finally we have one.
I never created it to make it a standard - so I don't expect it to. I created it, because I saw mini-OOF and thought - "ME WANT, ME WANT, ME WANT!" and that's all there is to it.
> All the other talks are just a matter of personal preference,
> or often within c.l.f. ole redneck programmers' stubbornness
> (not meaning you personally, there are others...)
It's not stubbornness - it's that 4tH has a completely different architecture - and sometimes it just can't follow stuff that is designed for a traditional Forth architecture. E.g. hard to do dictionary stuff if you don't have a dictionary. Just saying..

Hans Bezemer

On Friday, December 24, 2021 at 9:01:50 PM UTC, Andy Valencia wrote:
> So if you wanted a "descendent of Forth" which fit the hand nicely in the
> current compute environment, how about strings? I thought of the toy problem
> of counting the number of words in the diction with an "a" in them:
>
> >>> f = open("/usr/share/dict/words", "r")
> >>> na = 0
> >>> for l in f:
> ... if "a" in l:
> ... na += 1
> ...
> >>> print na
> 52849
> >>>
>
> (Python, obviously, and it took .13 CPU seconds on an arm64
> device, the RockPRO64. The file is 102,401 lines.)
>
> I typed it in just on the fly, no IDE or any dev references needed, and got
> it right on the first go--not too surprising.
>
> It could go shorter:
>
> >>> print len([l for l in f if ("a" in l)])
> 52849
> >>>
>
> And--I was surprised--using the same amount of CPU.
>
> Forth as hand written assembly code for a stack machine will never touch
> this. I've tried many times to find the language which brings higher level
> of expressiveness. Failed every time so far.
>
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html

This is apples and oranges. You said it yourself, Andy... Forth is an assembly language for a virtual processor. Python is a high-level language that can execute on any processor. Apples to apples would be to implement Python in Forth.

Andy Valencia <vandys@vsta.org> writes:
>>>> print len([l for l in f if ("a" in l)])
> And--I was surprised--using the same amount of CPU.
> Forth as hand written assembly code for a stack machine will never
> touch this. I've tried many times to find the language which brings
> higher level of expressiveness. Failed every time so far.

The inner loop of the Python code is ("a" in l), which scans the line l
for the letter a. That scanning is done in a Python primitive written
in C, the same primitive for both Python versions. So that is why the
cpu is about the same. The C code is compiled with a fancy optimizing
compiler such as GCC, so of course interpreted Forth will be a lot
slower.

If you have a Forth with a primitive to read a line from a file, and
another primitive for the SEARCH word, that might get comparable speed
to Python.

As for languages more expressive than Python, try Erlang or Elixir for
better concurrency primitives, Haskell for better datatypes and
invariants, Ruby for maybe more consistent syntax and better support for
EDSL's, etc. I want to try using Elixir for some of my own stuff but I
don't have a real use for it right now.

Paul Rubin schrieb am Mittwoch, 2. Februar 2022 um 20:59:40 UTC+1:
> As for languages more expressive than Python, try Erlang or Elixir for
> better concurrency primitives, Haskell for better datatypes and
> invariants, Ruby for maybe more consistent syntax and better support for
> EDSL's, etc. I want to try using Elixir for some of my own stuff but I
> don't have a real use for it right now.

I'm on the same language exploration turf, but always shied away when
I learnt that a fat VM is required (eg Elixir compiles for an Erlang VM).

To build a Forth that requires a fat compiler backend or compiles to an
overly complex IL (eg LLVM) did so far not seem worth the effort or seem
just clumsy. Assembler is no option for other reasons.

So at the end of the day it stays with old C, perhaps Ada or Rust
in future for systems programming. For higher level stuff I like Julia.
For very high level stuff: amazing Prolog (I haven't tested F# so far).

"minf...@arcor.de" <minforth@arcor.de> writes:
> I'm on the same language exploration turf, but always shied away when
> I learnt that a fat VM is required (eg Elixir compiles for an Erlang VM).

Idk if a fat VM is really required: BEAM is fat, but in principle there
could be a thinner VM that Elixir could use. Look at Go, which comes
fairly close.

Because of BEAM's size, I probably wouldn't use Elixir for a small
script, but for a long running network server it is pretty reasonable.
I've programmed in Erlang (Elixir is sort of a Ruby-like skin on Erlang)
and it is pleasant if you don't mind the weird syntax.

On 1/31/2022, Robert L. wrote:

> On 12/24/2021, Andy Valencia wrote:
>
> > I thought of the toy problem
> > of counting the number of words in the diction with an "a" in them:
> >
> > >>> f = open("/usr/share/dict/words", "r")
> > >>> na = 0
> > >>> for l in f:
> > ... if "a" in l:
> > ... na += 1
> > ...
> > >>> print na
> > 52849
> > > > >
> >
> > (Python, obviously,
>
> Nonsense. Not everyone is so unfortunate as to know Python.
>
> > and it took .13 CPU seconds on an arm64
> > device, the RockPRO64. The file is 102,401 lines.)
>
> Python certainly makes it look difficult.
>
> Awk:
>
> /a/ {na++} END {print na}
>
> Invocation:
>
> awk "/a/ {na++} END {print na}" words

ruby -e"p ARGF.grep(/a/).size" words

or

ruby -e"p $<.grep(/a/).size" words

Paul Rubin schrieb am Donnerstag, 3. Februar 2022 um 01:24:58 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > I'm on the same language exploration turf, but always shied away when
> > I learnt that a fat VM is required (eg Elixir compiles for an Erlang VM).
> Idk if a fat VM is really required: BEAM is fat, but in principle there
> could be a thinner VM that Elixir could use. Look at Go, which comes
> fairly close.
>

AFAIK Go compiles to native code. However its executables are rather fat.
I think this will not improve anytime soon because unlike Rust, Golang
does not see apps for small devices within their domain. Even their notion
of 'systems programming' is more geared towards distributed systems.

On Thursday, February 3, 2022 at 11:22:50 AM UTC+3, minf...@arcor.de wrote:
> Paul Rubin schrieb am Donnerstag, 3. Februar 2022 um 01:24:58 UTC+1:
> > "minf...@arcor.de" <minf...@arcor.de> writes:
> > > I'm on the same language exploration turf, but always shied away when
> > > I learnt that a fat VM is required (eg Elixir compiles for an Erlang VM).
> > Idk if a fat VM is really required: BEAM is fat, but in principle there
> > could be a thinner VM that Elixir could use. Look at Go, which comes
> > fairly close.
> >
> AFAIK Go compiles to native code. However its executables are rather fat.
> I think this will not improve anytime soon because unlike Rust, Golang
> does not see apps for small devices within their domain. Even their notion
> of 'systems programming' is more geared towards distributed systems.

- https://tinygo.org/
- https://www.rust-lang.org/what/embedded

"minf...@arcor.de" <minforth@arcor.de> writes:
> AFAIK Go compiles to native code. However its executables are rather fat.

They are around 1MB iirc, fat compared with C programs but small
compared with BEAM. 1MB is of course huge for embedded, but for server
side programming it's comparable to using Python or Ruby. Also, I don't
think the runtime is inherently that large. It needs a lot of stuff
that a C or Forth runtime doesn't, but it could be smaller than it is.

"minf...@arcor.de" <minforth@arcor.de> writes:
> I'm on the same language exploration turf, but always shied away when
> I learnt that a fat VM is required (eg Elixir compiles for an Erlang VM).

I'm just finishing a deployment for a highly stressed web application server,
and for the first time did it in Go. And... wow. Good type checking, high
performance compiled code, and SMP threading with impressive scaling. Lots
of modules to start from.

There's no VM, although the runtime is more bloated than I'd like. Still,
all in all, I think it's the direction I'll be moving. Use one of the many
code examples out there, otherwise write it as you would in C and chase the
compiler errors out to stackoverflow to find out how it's done now.

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