On 30/12/2021 17:00, Hans Bezemer wrote:
> On Tuesday, December 21, 2021 at 6:05:06 PM UTC+1, minf...@arcor.de wrote:
>> 2) ISO/ANS Forth with little progress and barely usable for real world apps
>> 3) hundreds of personal/hobby/academic Forths or VMs, often severely
>> crippled and unmaintained
>
> That's because it's extremely easy to make a Forth compiler - but quite a steep path in learning how to program it. After having played with the toy, kids gets bored. That's how it is.
> Still, I don't think 2) and 3) are true categories - since lots of "hobby" Forths adhere to the standard.
>
>> Ad 2) and 3) There seems a tendency towards permanently reinventing
>> or retuning old wheels. Hence no progress there as well.
> I don't agree here as well. Know that there are TWO Forth's: the architecture and the language. NASA still uses the Forth architecture in some of their development systems. Factor is my no means Forth language-wise, but it uses its architecture. Even ColorForth is more of an architecture descendant than a language one. So don't say architecture wise there are no developments.
>
> Forths "standards" have always been problematic IMHO and while ANS did clear up the sky a bit, I think Forth 20xx is AGAIN a step in the wrong direction. It adds the same "pragmatic" constraints to the language that e.g. Forth-83 did, doesn't fill the gaps that need to be filled (stringwise, anybody?) and adds wordsets which universal usefulness is at least questionable.
>
> Coming from C, I've never questioned the usefulness of libraries in general. It's true that you can make several variants - depending on certain requirements like speed, compactness or features - but that doesn't mean you have to reinvent the wheel each and every time. I learned quite a few things from Chuck, but here I do absolutely not agree. And I've found no circumstances in which I had to change my mind in that regard. Most often than not - if it happened, I merely added another library to the arsenal.
>
> Like C, it is hard to distinguish the extensions to the language from the language itself. My own C-libraries need an inclusion of the prototypes and are linked in a similar fashion. Forth is the same thing. Every Forth compiler has at least some "extra" words attached to it. When talking about the "core" words, I don't think you've seen much development in C during that period as well. Even more, I think - even when comparing just the years '70-'90 - Forth has seen much more development - CELLS, CHAR+, ?DO, CASE..ENDCASE, just to name a few. Add [: and ;] for good measure.

ISTM that the problem with libraries is that people have their own
libraries with different words and names, albeit providing more or less
the same functionality. Assuming a miracle happens and a string library,
say, is agreed everybody with their own string library would be
unwilling to change their existing software to use the new string
library. The same goes for OO packages.

The big mistake in Forth 200X is that it is open to all and sundry to
comment and vote on whether something is accepted into the standard.
This invariably results in an outcry from the rabid standard haters who
object to anything new. Sometimes the 'discussion' is so vicious and
offensive that potential proposers of a new feature are reluctant to
write an RfD. This also results in progress on Forth 200X proceeding in
seemingly geological timescales.

The anti-standard brigade make the nonsense claim that Forth 200X is a
closed group and complain about that group dictating what forthers can
and can't do, despite the fact that membership is open and that many
forthers go their own way.

IMHO the best way forward is to do what they claim and form a small
closed group to develop a new system - don't call it a standard but a
project. This group should probably have no more than 4 or 5 members and
keep their work private until they have something significant to
announce. Perhaps even keep the group membership secret. Also it would
be best to exclude commercial vendors because they have little incentive
to change anything for good commercial reasons.

I suggest that starting with a clean sheet would not be a good idea,
best is to start with Forth 2012 and accepted RFDs and ruthlessly
discard things that are probably little used such as the Block word set
and eliminate restrictions that are there for historical reasons, the
main one being lack of processor resources in the early days of Forth.
An example could be removal of restricions on use of the R stack due to
the R stack being used for DO LOOPs and locals. But to do it in such a
way that backward compatibility is maintained - old code would run but
new code could ignore the former restrictions. Other things like the
block wordset could be recommended as a standard library.

--
Gerry

On Friday, December 31, 2021 at 9:19:23 PM UTC+1, Gerry Jackson wrote:
[..]
> IMHO the best way forward is to do what they claim and form a small
> closed group to develop a new system - don't call it a standard but a
> project. This group should probably have no more than 4 or 5 members and
> keep their work private until they have something significant to
> announce. Perhaps even keep the group membership secret. Also it would
> be best to exclude commercial vendors because they have little incentive
> to change anything for good commercial reasons.
>
> I suggest that starting with a clean sheet would not be a good idea,
> best is to start with Forth 2012 and accepted RFDs and ruthlessly
> discard things that are probably little used such as the Block word set
> and eliminate restrictions that are there for historical reasons, the
> main one being lack of processor resources in the early days of Forth.
> An example could be removal of restricions on use of the R stack due to
> the R stack being used for DO LOOPs and locals. But to do it in such a
> way that backward compatibility is maintained - old code would run but
> new code could ignore the former restrictions. Other things like the
> block wordset could be recommended as a standard library.

IMHO it runs the danger that it will end up as just another incompatible
Forth variant. However, as it will (initially) be non-standard anyway, why
not aim higher? One might set the goal that it brings the power
of Forth to smart-phones (a new, maybe hard-ware enhanced I/O method
would be needed, like Google glass with Oculus gloves). Or one could
develop a multi-threaded Forth intended to run on GPU's :--)

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
> One might set the goal that it brings the power of Forth to
> smart-phones

Forth like any language has all sorts of powers. Is there a particular
power of Forth that would be of benefit to smart-phone programmers, that
is absent from whatever they are using now?

On Friday, December 31, 2021 at 11:45:37 PM UTC+1, Paul Rubin wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> > One might set the goal that it brings the power of Forth to
> > smart-phones
> Forth like any language has all sorts of powers. Is there a particular
> power of Forth that would be of benefit to smart-phone programmers, that
> is absent from whatever they are using now?

I mentioned this because I personally would love to have my Forth
dev environment with me in train and bus. A phone has become
practically impossible to live without, and even I have to carry
one at all times.

I think that the time has come that the above is possible *without
technical compromises.*

Forth might make it a bit easier to hack and debug the hardware
and software.

-marcel

On Friday, December 31, 2021 at 5:10:02 PM UTC-6, Marcel Hendrix wrote:
> On Friday, December 31, 2021 at 11:45:37 PM UTC+1, Paul Rubin wrote:
> > Marcel Hendrix <m...@iae.nl> writes:
> I mentioned this because I personally would love to have my Forth
> dev environment with me in train and bus. A phone has become

I have that with a small chromebook but a phone, yuk. Had Forth on a PDA and
never used it. Liked the PDA but not as a programming environment.
--
me

On Saturday, January 1, 2022 at 1:28:02 AM UTC+1, S Jack wrote:
> On Friday, December 31, 2021 at 5:10:02 PM UTC-6, Marcel Hendrix wrote:
> > On Friday, December 31, 2021 at 11:45:37 PM UTC+1, Paul Rubin wrote:
> > > Marcel Hendrix <m...@iae.nl> writes:
> > I mentioned this because I personally would love to have my Forth
> > dev environment with me in train and bus. A phone has become
> I have that with a small chromebook but a phone, yuk. Had Forth on a PDA and
> never used it. Liked the PDA but not as a programming environment.

That's why I wrote "a new, maybe hard-ware enhanced I/O method
would be needed, like Google glass with Oculus gloves".

-marcel

On Friday, December 31, 2021 at 6:47:00 PM UTC-6, Marcel Hendrix wrote:
> On Saturday, January 1, 2022 at 1:28:02 AM UTC+1, S Jack wrote:
> > On Friday, December 31, 2021 at 5:10:02 PM UTC-6, Marcel Hendrix wrote:
> > > On Friday, December 31, 2021 at 11:45:37 PM UTC+1, Paul Rubin wrote:
> > > > Marcel Hendrix <m...@iae.nl> writes:
> > > I mentioned this because I personally would love to have my Forth
> > > dev environment with me in train and bus. A phone has become
> > I have that with a small chromebook but a phone, yuk. Had Forth on a PDA and
> > never used it. Liked the PDA but not as a programming environment.
> That's why I wrote "a new, maybe hard-ware enhanced I/O method
> would be needed, like Google glass with Oculus gloves".
>
> -marcel
you would look strange on that bus waving your hands in the air.
--
me

On 2021-12-31, Marcel Hendrix <mhx@iae.nl> wrote:
> I mentioned this because I personally would love to have my Forth
> dev environment with me in train and bus. A phone has become
> practically impossible to live without, and even I have to carry
> one at all times.

This is exactly why I was inquiring earlier about Forth Android
stuff. I think gForth's Android implementation is actually a great
starting point.

- meff

On 1/01/2022 07:19, Gerry Jackson wrote:
>
> I suggest that starting with a clean sheet would not be a good idea,
> best is to start with Forth 2012 and accepted RFDs and ruthlessly
> discard things that are probably little used such as the Block word set
> and eliminate restrictions that are there for historical reasons, the
> main one being lack of processor resources in the early days of Forth.

The 200x TC is little used. You can start with that :)

On 1/01/2022 10:10, Marcel Hendrix wrote:
> On Friday, December 31, 2021 at 11:45:37 PM UTC+1, Paul Rubin wrote:
>> Marcel Hendrix <m...@iae.nl> writes:
>> > One might set the goal that it brings the power of Forth to
>> > smart-phones
>> Forth like any language has all sorts of powers. Is there a particular
>> power of Forth that would be of benefit to smart-phone programmers, that
>> is absent from whatever they are using now?
>
> I mentioned this because I personally would love to have my Forth
> dev environment with me in train and bus. A phone has become
> practically impossible to live without, and even I have to carry
> one at all times.

What's wrong with pen and paper - you know - before computers.
In the 90's I was coding DX-Forth that way on the train going to
work. They don't make enthusiasts like they used to :)

Gerry Jackson schrieb am Freitag, 31. Dezember 2021 um 21:19:23 UTC+1:
>
> The big mistake in Forth 200X is that it is open to all and sundry to
> comment and vote on whether something is accepted into the standard.
> This invariably results in an outcry from the rabid standard haters who
> object to anything new. Sometimes the 'discussion' is so vicious and
> offensive that potential proposers of a new feature are reluctant to
> write an RfD. This also results in progress on Forth 200X proceeding in
> seemingly geological timescales.
>

One has to take what is there as "unifying entity" because there is no big
company (or individual) to simply set de-facto standards. The only
"unifying entity" for Forth that I can see is the 200x group, and they are
perhaps too democratic and slow, trying to please too many people.

And there is nothing like CPython for Forth as reference implementation
and testbed for concepts, library interface etc. IMHO gforth would be
too heavy and already too complex to take this role. So incompatibilities
grow like mushrooms.

Not blaiming anybody or whining, just an observation.

On Saturday, January 1, 2022 at 3:20:16 AM UTC+1, dxforth wrote:
[..]
> What's wrong with pen and paper - you know - before computers.
> In the 90's I was coding DX-Forth that way on the train going to
> work. They don't make enthusiasts like they used to :)

A text editor with a 40'' screen, full-size keyboard and
wireless mouse, and access to one's cloud repository
is vastly superior to pencil, eraser, and paper. However,
PP&E is so small that one can have access to it
anywhere, and no additional resources like battery
power are needed. Also, PP&E is superior if the piece
of paper is large, because an incredible amount of data
can be stored and organized in a very small space. On the
negative side, PP&E needs a surface to write on (walking,
bus, train?), and more than one sheet of paper is a crime.

What is needed is a desktop editor squeezed into a
matchbook. The problem is how to miniaturize
the input and output devices. Suitable technology is
now there or around the corner.

It continuously amazes me that computer technology
is focusing so much on the chips and that there is hardly
any progress with displays, keyboards, mice, and
power/heat issues. (There is plenty of decay in the
opposite direction.)

-marcel

On 1/01/2022 19:59, minf...@arcor.de wrote:
> Gerry Jackson schrieb am Freitag, 31. Dezember 2021 um 21:19:23 UTC+1:
>>
>> The big mistake in Forth 200X is that it is open to all and sundry to
>> comment and vote on whether something is accepted into the standard.
>> This invariably results in an outcry from the rabid standard haters who
>> object to anything new. Sometimes the 'discussion' is so vicious and
>> offensive that potential proposers of a new feature are reluctant to
>> write an RfD. This also results in progress on Forth 200X proceeding in
>> seemingly geological timescales.
>>
>
> One has to take what is there as "unifying entity" because there is no big
> company (or individual) to simply set de-facto standards. The only
> "unifying entity" for Forth that I can see is the 200x group, and they are
> perhaps too democratic and slow, trying to please too many people.

"Too democratic ... trying to please everyone". Who would have guessed :)
Clearly they haven't pleased you. Whom do you suggest as a suitable
replacement given the present lot have been such easy push-overs?

On 1/1/22 4:03 AM, Marcel Hendrix wrote:
> What is needed is a desktop editor squeezed into a
> matchbook. The problem is how to miniaturize
> the input and output devices. Suitable technology is
> now there or around the corner.

Maybe we once had something sort of like that.
http://quartus.net/products/forth/

I still have one of these in perfect working order
with Quartus Forth installed:
https://en.wikipedia.org/wiki/Treo_755p

I like the form of the 755p (it actually fits in the palm of
your hand). Between the hardware keyboard and stylus/touchscreen,
input was/is surprisingly good. Small screen though. Could display
14 lines of 32 chars/line using the standard font.

Sprint stopped supporting it as a cell phone around 2012, I think.
:-)

-Doug

On 1/01/2022 20:03, Marcel Hendrix wrote:
> On Saturday, January 1, 2022 at 3:20:16 AM UTC+1, dxforth wrote:
> [..]
>> What's wrong with pen and paper - you know - before computers.
>> In the 90's I was coding DX-Forth that way on the train going to
>> work. They don't make enthusiasts like they used to :)
>
> A text editor with a 40'' screen, full-size keyboard and
> wireless mouse, and access to one's cloud repository
> is vastly superior to pencil, eraser, and paper. However,
> PP&E is so small that one can have access to it
> anywhere, and no additional resources like battery
> power are needed. Also, PP&E is superior if the piece
> of paper is large, because an incredible amount of data
> can be stored and organized in a very small space. On the
> negative side, PP&E needs a surface to write on (walking,
> bus, train?), and more than one sheet of paper is a crime.

To this day if I encounter a problem I can't resolve in mindless
program mode then I go for the scrap of paper. Better still if
there's a carpeted floor nearby. A change of inclination is as
good as a holiday.

>
> What is needed is a desktop editor squeezed into a
> matchbook. The problem is how to miniaturize
> the input and output devices. Suitable technology is
> now there or around the corner.
>
> It continuously amazes me that computer technology
> is focusing so much on the chips and that there is hardly
> any progress with displays, keyboards, mice, and
> power/heat issues. (There is plenty of decay in the
> opposite direction.)
>
> -marcel

Brian Fox <brian.fox@brianfox.ca> writes:
>Could the Hayes tester be used to write such "contracts" for a Forth project?

The spirit is similar, but the Hayes tester specifies the correct
behaviour only for specific test cases, while more ambitious systems
(both formal verification ones and fuzz testing) need a more general
specification of the correct behaviour.

E.g., you could use the following lines with the Hayes tester:

create arr 2 , 3 , 1 , 4 ,
{ arr 4 sort arr @ arr cell+ @ arr 2 cells + @ arr 3 cells + @ -> 1 2 3 4 }

while for a more ambitious approach you have to specify what
acceptable inputs are (or how to generate them), and what the
corresponding output is (i.e., the output is a permutation of the
input, and the output is sorted).

>It might appear to be self-referential but if the entire system and the application
>were tested as they compiled it would be pretty solid wouldn't it?

It all depends on how comprehensive the tests are. Comprehensive
testing is certainly the most practical approach in a lot of software
development today (i.e., formal verification still requires more
effort (and time-to-market) than most clients want to pay. Example:
the first Ariane 5 was exploded because it was deemed too expensive to
reverify a component that had already been verified for the Ariane 4.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 01/01/2022 08:59, minf...@arcor.de wrote:
> Gerry Jackson schrieb am Freitag, 31. Dezember 2021 um 21:19:23 UTC+1:
>>
>> The big mistake in Forth 200X is that it is open to all and sundry to
>> comment and vote on whether something is accepted into the standard.
>> This invariably results in an outcry from the rabid standard haters who
>> object to anything new. Sometimes the 'discussion' is so vicious and
>> offensive that potential proposers of a new feature are reluctant to
>> write an RfD. This also results in progress on Forth 200X proceeding in
>> seemingly geological timescales.
>>
>
> One has to take what is there as "unifying entity" because there is no big
> company (or individual) to simply set de-facto standards. The only
> "unifying entity" for Forth that I can see is the 200x group, and they are
> perhaps too democratic and slow, trying to please too many people.

No 'perhaps' about that in my view.

>
> And there is nothing like CPython for Forth as reference implementation
> and testbed for concepts, library interface etc. IMHO gforth would be
> too heavy and already too complex to take this role.

Why do you think that it is too heavy and complex. ISTM that building
GForth from source code seems complex but as GForth is primarily an
ANS/Forth 2012/x system why does using it make it any more complex than
use of another standard system?

GForth would appear to be a good starting point (apart from being
covered by the GNU licence). Another system that could provide a good
start could be using your MinForth to build a system

> So incompatibilities grow like mushrooms.

Yes and I suspect that started as soon as someone developed the second
Forth system and has never stopped.

>
> Not blaiming anybody or whining, just an observation.

Understood, that's the way discussions should proceed.

--
Gerry

On 31/12/2021 21:08, Marcel Hendrix wrote:
> On Friday, December 31, 2021 at 9:19:23 PM UTC+1, Gerry Jackson wrote:
> [..]
>> IMHO the best way forward is to do what they claim and form a small
>> closed group to develop a new system - don't call it a standard but a
>> project. This group should probably have no more than 4 or 5 members and
>> keep their work private until they have something significant to
>> announce. Perhaps even keep the group membership secret. Also it would
>> be best to exclude commercial vendors because they have little incentive
>> to change anything for good commercial reasons.
>>
>> I suggest that starting with a clean sheet would not be a good idea,
>> best is to start with Forth 2012 and accepted RFDs and ruthlessly
>> discard things that are probably little used such as the Block word set
>> and eliminate restrictions that are there for historical reasons, the
>> main one being lack of processor resources in the early days of Forth.
>> An example could be removal of restricions on use of the R stack due to
>> the R stack being used for DO LOOPs and locals. But to do it in such a
>> way that backward compatibility is maintained - old code would run but
>> new code could ignore the former restrictions. Other things like the
>> block wordset could be recommended as a standard library.
>
> IMHO it runs the danger that it will end up as just another incompatible
> Forth variant. However, as it will (initially) be non-standard anyway, why
> not aim higher? One might set the goal that it brings the power
> of Forth to smart-phones (a new, maybe hard-ware enhanced I/O method
> would be needed, like Google glass with Oculus gloves). Or one could
> develop a multi-threaded Forth intended to run on GPU's :--)
>

One less ambitious thing to do would be to improve displays of a Forth
system beyond a simple text console by using software designed for the
purpose e.g Forth to feed HTML and CSS files into an internet browser
like Firefox etc. I've no idea how to do that or, indeed, if it is possible.

--
Gerry

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> And then he uses enforced run-time guarding to guarantee that control
> flow never reaches the words unless the type is correct. I.e.,
>
> empty-board (board-empty) 1 1 x-move ( board ) 0 0 o-move
>
> would result in a type error at the second move, because move just
> returns the board supertype, but not one of the types that MOVE
> accepts.

The idea is that an X move returns a board state waiting for an O move
and vice versa. So that example would be

empty-board ( board-empty ) 1 1 x-move ( board-next-o ) 0 0 o-move

> he did not give a convincing (to me) reason why a programmer would
> want to comply with his rules.

It was a somewhat artificial example, not totally persuasive, but
as plausible as most other programming exercises.

> Something like having o-move in the board-next-o wordlist, and having
> a guarding word, used like this:
>
> ( board ) 0 0 rot guard-board-next-o o-move 2drop

1) this still seems like a runtime check since initial board state
doesn't say whose turn it is,

2) the board state is passed on the (untyped) Forth stack, so even if
its state was once known, stack operations can interfere with the
wordlist based type checking,

3) the API "o-move" is now replaced by two words that must be invoked
consecutively, one of which is part of the official API and the other of
which is not. Maybe that is ok, but it leaves the API client to (maybe
incorrectly) implement guard-board-next-o. The original premise of the
exercise was for the API implementer to hand over some type declarations
and say "if the compiler doesn't accept that your data satisfies those
types, then something is wrong with your data". Thus it places faith
in the compiler's typechecker that it doesn't place in the API client
implementation.

Here, it is again up to the client to do the typechecking, reopening API
implementer's original complaint.

> this proof-of-concept is good enough to show that it can be done in
> Forth

I think as shown, some parts are still missing, but maybe those gaps
could be filled with enough contortion.

Paul Rubin <no.email@nospam.invalid> writes:
> empty-board ( board-empty ) 1 1 x-move ( board-next-o ) 0 0 o-move

Oh actually you write, x-move must contain a wrapped object containing
either board-next-o or board-finished. So the client must distinguish
those two at runtime and only call o-move in the event that the X move
returned board-next-o.

My Haskell solution did the above with a GADT and type refinement using
a case statement, iirc. Someday I would like to know how a fancier
language like Coq or Idris would do it.

On Thursday, December 23, 2021 at 4:00:01 PM UTC+3, minf...@arcor.de wrote:
> Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 13:38:02 UTC+1:
> > On Thursday, December 23, 2021 at 3:11:23 PM UTC+3, minf...@arcor.de wrote:
> > > Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 11:46:57 UTC+1:
> > > > On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> > > > > On 23/12/2021 17:37, Nickolay Kolchin wrote:
> > > > > >
> > > > > > P.S. But we kinda moved away from Forth again.
> > > > > Here was I thinking you and Paul were done giving reasons why
> > > > > Forth was no longer suited to anything. There's more? :)
> > > > I thought he was giving reasons why C is obsolete.
> > > >
> > > > Imagine, if Forth has tools like LDRA and Frama-C. Will it become
> > > > acceptable for modern development?
> > > AFAIU Frama-C builds its own abstract syntax tree from C sources.
> > > Given that Forth is practically grammar-free, that won't work well.
> > > BTW Frama-C itself is written in OCAML.
> > We can perform analyse on compiled bytecode. Forth can be treated as
> > kind of assembler language. So, no real problem here. Also, due to simpler
> > language -- less things need to be checked.
> Are you really saying that assembly language is no real problem for certification??
>
> Even on higher Forth level, analyse:
> : TEST
> POSTPONE IF ] R> ?DUP DROP ; IMMEDIATE
> It compiles hassle-free in gforth ...

Lets say "this is doable". For some parts of certification process, we already
perform binary level analyzation.

On Tuesday, December 28, 2021 at 9:32:49 PM UTC+3, Anton Ertl wrote:
> Today's niches are filled by today's Forths. But one may wonder what
> potential niches for Forth exist, and if Forth is missing something
> for that niche.
>

Name at least one niche that is filled with Forth at 2022.

On Tuesday, December 28, 2021 at 10:13:44 PM UTC+3, minf...@arcor.de wrote:
> Anton Ertl schrieb am Dienstag, 28. Dezember 2021 um 19:32:49 UTC+1:
> > What Forth needs for that is more performance and IMO better
> > guarantees (C moves away from the niche by telling low-level
> > programmers that they should not have relied on properties that the C
> > standard does not guarantee).
> There are very few applications that need more processing speed in a single CPU.
> Programmer time has become much more important.
>
> This implies eg
> - compiler performance for high semantical expressiveness
> - catching as meany errors as possible in an early development stage
> (most users/customers don't accept crashing as "bug detection facility")
> - good integration with powerful development and maintenance tools

And at present time, Forth suck in all three, unfortunately...

On Wednesday, December 29, 2021 at 6:45:30 PM UTC+3, Anton Ertl wrote:
>
> Concerning libraries, you don't need big companies for that, as Python
> demonstrates. But you need a community and system implementors that
> want libraries, understand what features are needed for libraries, and
> are willing to add the features that are needed for libraries.

Or you can look what other languages provide out of the box.

On Thursday, December 30, 2021 at 6:48:41 AM UTC+3, Hugh Aguilar wrote:
> On Wednesday, December 29, 2021 at 9:45:06 AM UTC-7, Anton Ertl wrote:
> > dxforth <dxf...@gmail.com> writes:
> > >You say Forth lacks ready-to-use libraries. If they've not materialized
> > >with what's been added thus far, then what
> > ...
> > Ideally time-travel back to the 1980s, spread these ideas, get them in
> > the '94 standard, and a community will grow around it that builds the
> > libraries. Instead, we lost many so-minded people to other languages,
> > resulting in a Forth community where many (not all) have an
> > anti-library sentiment.
> It is certainly true that Elizabeth Rather has an anti-library sentiment,
> and all ANS-Forth cult members are required to also hate libraries.
>

Was she the the only one?