Economic problem of the Forth

[Mihail Maksimov]

Hi,

Due to the amorphous environment of the Forth-system, Forth does not have objective drawbacks.
In principle, any deficiencies are eliminated by user of the Forth-system.
The problem is that there is no incentive to take care of Forth programmers (outside own company).
In connection with the open architecture of Forth, it is not realistic to put Forth programmers
in dependence on developers of Forth toolkits. Forth programmers find it difficult to find consensus
among themselves and force to follow standards. The organizational part of the development
of Forth can take over the market, if there is an easy way to sell cheap files.
https://github.com/mak4444/LTCFileShopPlugin
The economic incentive will motivate Forth programmers to care about each other and follow the de facto standard.

[Ilya Tarasov]

понедельник, 5 февраля 2018 г., 14:35:43 UTC+3 пользователь Mihail Maksimov написал:

Wow! This is an ONLY user banned from RuFIG forum! :)))) He tired most of users by 'economic problem', 'historical problem' and idea of selling small pieces of code for bitcoins. Now it is your problem :)

[Mark Wills]

On Monday, 5 February 2018 11:35:43 UTC, Mihail Maksimov wrote:
> The problem is that there is no incentive to take care of Forth programmers (outside own company).

No, not really. It's just that Forth programmers don't *need* outside help,
from (for example) third-party debugger sellers. In Forth, we're in *total*
control, even to the point of being able to develop our custom and application
specific debugging tools. That is not the case if you're developing in, say,
C++ or Java, for example.

[NN]

On Monday, 5 February 2018 11:35:43 UTC, Mihail Maksimov wrote:

I have not heard of the phrase amorphous environment used in this context before. Could you give an example of what that means?

In principle any capable or sufficiently motivated user is able to circumvent the deficiency, would you agree ?

[Dmitry Ponyatov]

> Due to the amorphous environment of the Forth-system, Forth does not have objective drawbacks.

> The problem is that there is no incentive to take care of Forth programmers (outside own company).

Forth have some sort of homogenic syntax, like Lisp too. Data stack unbounded between program elements is a separate beast. Every time I read my own code (not saying about somebody else code) I feel wild butthurt and need of full-sized interactive debugger with stack snapshots, code markers, breakpoints and step by step execution in any Forth system I try to use.

Modern object languages have more readable syntax, especially Python forces you to use proper formatting. OOP by design was developed extremely for code reuse by program segmentation and inheritance. That's why only OOP languages are alive for commercial development.

Returning to Forth, I think we should move forward to object paradigm and some mix of Forth and SmallTalk with its live object world, and deep reflection and dynamics.

Software development has few main stages: design, debugging in runtime and production exploitation. So programming (and design) language efficiency must be rethinked at every stage.

When you design, your working environment, and language must provide introspection, visuality, modeling power and code reuse as much as it can. A speed of program execution is the last thing you think about at design stage. It is much important how easy you can reuse code and models developed by other programmer and yourself in past. Working environment must provide you tools to model your world as much closer to the domain. It is time to think about problems in diagrams, graphs of interacting active objects, data flows, database and deployment schemes and so on. If you are stucked on the source code, language must provide program transformation and metaprogramming features -- programs that construct and transform other programs. Now the whole system can be slow and heavy so much as you and your workstation can endure.

When you start to debug your program system at runtime, the main problem becomes flexibility, runtime system dynamics, debugging facilities and ability to modify the program in runtime without the whole system restart. SmallTalk is an etalon of such dynamic development system.

And finally, move to production. Here we need deeply optimized machine code must do its job on smallest resources, especially for embedded applications. That's the place of traditional programming language efficiency, and this stage is a target of C and C++ optimizing compilers was designed till last tens of years. And Forth here is out of a game as any other high-level languages like Python, Java and any other script languages.

[Dmitry Ponyatov]

Returning to your craze on Forth economic problem, think wider.
Don't stuck with Forth language or any other, you should solve two problems
1) "how to make system able to pay programmers for its working time in automatic manner" and
2) "how to reuse code _and models_ they do"

And I would like to add a third point:
3) some Internet-wide cloud system let me collaborate and design and model with a feel of think speed

Maybe some cloud system works as a shared network of active interacting objects can be the answer. Compilers, editors, optimizers, visualizers, debuggers, program transformers and code generators are objects if this cloud, and a bunch of tools to build models can be evaluated, explored and finally transformed into program code.

But Forth is not here, that's why I dropped it away many many years ago. It's a ghosty language is changing as a book in a dream following every programmer's thought. Take only two programmers, and theirs Forths will totally differ. The only standardization is a pain, not saying about any code share or reuse.

[menti...@gmail.com]

On Monday, February 5, 2018 at 3:35:43 AM UTC-8, Mihail Maksimov wrote:
> Hi, [...]

> The problem is that there is no incentive to take
> care of Forth programmers (outside own company).

Forth programmers should consider embarking upon a career as

http://ai.neocities.org/maintainer.html -- AI Mind Maintainer.

http://strongai.quora.com/AI-Mind-Maintainer

MindForth is an AI program that thinks in English.
http://dl.acm.org/citation.cfm?doid=307824.307853
http://ai.neocities.org/mindforth.txt

Wotan is MindForth coded to think in German.
http://www.amazon.com/dp/B00GX2B8F0
http://ai.neocities.org/DeKi.txt -- German Forth AI.

http://wiki.opencog.org/w/Ghost -- is the same AI in Perl,
with the ability to think in English or in Russian.

http://ai.neocities.org/Dushka.html -- thinks in Russian.

http://ai.neocities.org/index.html -- "I am the AI Mind".

Forth programmers who love Mother Russia may learn how
the AI programs work in Forth, in Perl and in JavaScript.
Then Russia may lead the world in the race to True AI.

Всего хорошего,

Артур Артурович

[NN]

Why does everyone always compare forth with lisp ?

I dont think you are alone in your description when revisiting code, but it just means that there is room for improvement and a different lexicon.

If you like OOP and smalltalk , why not just use smalltalk ?
Isnt a programmer supposed to use the best tool for the job ?

[dxf...@gmail.com]

Furthermore when forthers have collaborated it
has been only to the extent necessary e.g. the
OTA spec. Each has their own way of doing things
and defends it jealously. Historically Forth has
succeeded better individually than collectively.

[Elizabeth D. Rather]

The OTA project wasn't just a spec, it was a full implementation on half
a dozen terminals with different MCU's. It was, perhaps, unique in being
an multi-company project, but I thought we all worked together very well.

We've had many, many projects involving multiple independent
contractors, and *typical* FORTH, Inc. projects involve cooperation
between our programmers and programmers from within the customer
company. I've found it to be a very successful way of working.

Cheers,
Elizabeth

--
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:
> The OTA project wasn't just a spec, it was a full implementation on
> half a dozen terminals with different MCU's.

I remember trying pretty hard to find the spec for this and it just
didn't seem to be anywhere, except for a very expensive printed volume
that might or might not have been the right thing. Was it ever
released?

[Mark Wills]

I don't know about jealously. I'd be more than happy to change my way of
doing things if collaborating on a Forth project, especially if it was a
commercial project. If someone is going to bring already written, tested
and proved code to the party then party on!

[a...@littlepinkcloud.invalid]

NN <novembe...@gmail.com> wrote:
>
> Why does everyone always compare forth with lisp ?

LISP was a very important influence on Forth. In about 1958 at MIT
Chuck Moore attended what he described as an "incredible course on
LISP" taught by John McCarthy.

> I dont think you are alone in your description when revisiting code,
> but it just means that there is room for improvement and a different
> lexicon.
>
> If you like OOP and smalltalk , why not just use smalltalk ?
> Isnt a programmer supposed to use the best tool for the job ?

That seems like an odd question to ask of Forth, of all languages.
Forth has always taken inspiration from everywhere, but always with a
very Forth-shaped style.

Andrew.

[The Beez]

On Monday, February 5, 2018 at 6:22:01 PM UTC+1, Dmitry Ponyatov wrote:
<quote>

Every time I read my own code (not saying about somebody else code) I feel wild butthurt and need of full-sized interactive debugger with stack snapshots, code markers, breakpoints and step by step execution in any Forth system I try to use.

</quote>
I have been maintaining my 4tH code for over 20 years and never found it particularly hard. I wrote a "debugger" once, but all I really need is a decompile and .S - thank you.

<quote> Modern object languages have more readable syntax, especially Python forces you to use proper formatting.
</quote>

I'm quite capable to indent my own code, thank you. Code indentation according to a language is asking for unintentional, hard to trace bugs.

<quote>

OOP by design was developed extremely for code reuse by program segmentation and inheritance. That's why only OOP languages are alive for commercial development.

</quote>

OOP is not a programming paradigm, it's a programming technique. Enforcing OOP is asking for maintainable lasagna code. And contrary to popular belief, it is almost trivial to turn OOP code to imperative code. Note I have full OOP in place, but it doesn't save you from all these "disasters" that people claim that OOP BY VERY DESIGN prevents. I think that the IT sector is one of the most superstitious metiers in the world - they all believe in holy books and holy people without asking for any proof. OOP is one of the results. It's not more productive, more reusable or more foolproof. It's all smoke and mirrors.
https://sourceforge.net/p/forth-4th/wiki/Object%20Orientation/

<quote>

A speed of program execution is the last thing you think about at design stage.

</quote>
That depends on the problem and requirements.

<quote>

Working environment must provide you tools to model your world as much closer to the domain.

</quote>

It's your head that does that - not the tooling. If you need tools to model your world, you don't understand the problem clearly.

<quote>

And finally, move to production. Here we need deeply optimized machine code must do its job on smallest resources, especially for embedded applications.

<quote>

You need proper code. Any good programmer can reasonably well predict what code will be generated, given certain optimization flags. And you can optimize in several dimensions, size and speed. E.g. "loop unrolling" is not particularly good for size.

<quote>

And Forth here is out of a game as any other high-level languages like Python, Java and any other script languages.

</quote>

Python is neither good in speed or size. Java is bloat. Both use VM's. Ruby is even worse performancewise. It doesn't feel right to shove Forth in that same category, since it has too many and quite different implementations.

Hans Bezemer

[Cecil Bayona]

It seems that OOP has been falling out of favor with its adherents, I
often see articles on how OOP is not the magic bullet it was suppose to
be instead it has it's own set of problems like other techniques.

Myself I have not been a big fan off OOP, I have used for years
languages that implemented it such as Borland Delphi, where I had no
choice with its built in libraries but I used the concept as little as
possible. I thought I was odd since the vast majority was OOP crazy but
it seemed to complicate things with little added benefits. I did like
some features but not the whole thing.

--
Cecil - k5nwa

[Albert van der Horst]

In article <p5cori$54q$1...@dont-email.me>,
Cecil Bayona <cba...@cbayona.com> wrote:
<SNIP>

>It seems that OOP has been falling out of favor with its adherents, I
>often see articles on how OOP is not the magic bullet it was suppose to
>be instead it has it's own set of problems like other techniques.

Fundamentalist oop ("everything must be an object") is harmful.

>
>Myself I have not been a big fan off OOP, I have used for years
>languages that implemented it such as Borland Delphi, where I had no
>choice with its built in libraries but I used the concept as little as
>possible. I thought I was odd since the vast majority was OOP crazy but
>it seemed to complicate things with little added benefits. I did like
>some features but not the whole thing.

I hope to demonstrate that adding an oop flavour to lisp.fs makes
it clearer and more concise.

>
>--
>Cecil - k5nwa
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Elizabeth D. Rather]

I believe it was published, but published standards do tend to be very
expensive (which is why ANS Forth is principally circulated as the final
draft). In any case, it's irrelevant now, 20 years later, technology
moved on.

[Mihail Maksimov]

Mark Wills wrote:

> It's just that Forth programmers don't *need* outside help,

More correctly, they can do without outside help.
This is the sole cause of Forth existence.

NN wrote:

> I have not heard of the phrase amorphous environment used in this context before. Could you give an example of what that means?

Forth coding is expansion of forth-system. The Forth-system body is a subroutine library.
The meaning of the Forth is to use resources of forth-system wider than the authors' intentions.

[dxf...@gmail.com]

Links to the 3 pdf documents were given on c.l.f
early 200x IIRC.

Most of the new forth words were OTA specific but
in there was a gem called +STRING. I've had it in
my forth for years and I can't believe it still
hasn't been picked up, including by Forth Inc and
MPE.

[Rod Pemberton]

On Mon, 5 Feb 2018 03:43:12 -0800 (PST)
Ilya Tarasov <ilya74....@gmail.com> wrote:

> понедельник, 5 февраля 2018 г., 14:35:43 UTC+3 пользователь Mihail
> Maksimov написал:

So, you show up here, and then he appears. Thanks. ;-)


Rod Pemberton
--
"The strongest, richest, greatest nation in the world shouldn't leave
anyone behind," said Joe Kennedy. "We're going to put a lot of coal
miners and coal country out of business," said Hillary Clinton.

[dxf...@gmail.com]

Of course. But Forth is nowhere as dependent on
community cooperation as are other languages.
Standards in forth remain a novelty, argued over
more than used. Recently we saw a statement from
FI saying its support of 200x was at best limited.
It wouldn't have said that had it or its users
desperate need of a comprehensive Standard.

[Paul Rubin]

dxf...@gmail.com writes:
> Links to the 3 pdf documents were given on c.l.f early 200x IIRC.
> Most of the new forth words were OTA specific but in there was a gem
> called +STRING. I've had it in my forth for years and I can't believe
> it still hasn't been picked up, including by Forth Inc and MPE.

I did find some references to OTA on Google Groups clf archive but
didn't see pdf doc links. I might look some more. I found a definition
of +STRING in one of the threads:

: +STRING ( a1 u1 a2 u2 -- a2 u3 )
2swap swap 2over + 2 pick cmove + ;

which took me a while to figure out. It seems simpler with locals,
though they might have been less common then:

: +STRING-2 { a1 u1 a2 u2 -- a2 u3 }
a1 a2 u2 + u1 cmove ( append a1 u1 to a2 u2 )
a2 u1 u2 + ; ( return a2 with new count )

[dxf...@gmail.com]

I have it in my kernel where it was easy enough
to do in machine code. BTW the locals version
on VFX results in double the number of instructions.

[Elizabeth D. Rather]

That's a misunderstanding of the structure and intent of the Forth
Standards. The important thing is that there is a CORE wordset that any
Standard System must support. Those are things you can always count on.
Beyond that, there are *optional* wordsets that you can pick and choose,
depending on need. For example, few embedded systems need FILE-ACCESSS
or FLOATING-POINT. Many haven't implemented LOCALS. FORTH, Inc.'s
SwiftForth (Windows, Linux, OSX) includes all of the features we use in
applications and much more; SwiftX's resident facility is built on
SwiftForth, but is oriented toward supporting easy development and
testing of embedded applications on a variety of microcontroller
targets, which is a different set of needs. We also adhere to the
documentation requirements of the standards.

The most widely-used Forths (from FORTH, Inc. and MPE, plus gForth and
Win32Forth) have adhered to the standards since shortly after Forth94
was published, but I don't know whether they've all implemented every
word in every optional wordset. The level of standardization the
community has followed has made it much easier for application
programmers to move from one system to another, and the existence of the
standard has greatly facilitated conversations here on clf.

[dxf...@gmail.com]

That's not a Standard enticing newcomers to Forth.
It's the committee accepting there are limits to what
it can impose on forthers :)

[Ilya Tarasov]

среда, 7 февраля 2018 г., 3:43:20 UTC+3 пользователь Rod Pemberton написал:

> > Wow! This is an ONLY user banned from RuFIG forum! :)))) He tired
> > most of users by 'economic problem', 'historical problem' and idea of
> > selling small pieces of code for bitcoins. Now it is your problem :)
>
> So, you show up here, and then he appears. Thanks. ;-)

He was warned that he needed to follow the rules of our forum, but refused to do it. I have no influence on him and did not invite him here. I do not believe that his opinion is typical for RuFIG.

[hughag...@gmail.com]

I just finished seeing the movie: "The Disaster Artist"
Pretty good movie in its own weird way!

ANS-Forth is like that movie: "The Room" It is really best appreciated as comedy.
If Mihail Maksimov is smart, he will praise ANS-Forth, but talking out of the other side of his mouth, he will have fun spouting nonsense and flame-bait.
Anybody who praises ANS-Forth will become a star in the ANS-Forth cult! He will soon rise to the level of Rickman, Rod Pemberton, etc..
Perhaps "sink" would be the word --- but he will certainly become a star of comp.lang.forth!

The ANS-Forth cult is all about quid-pro-quo --- Elizabeth Rather expects loyalty from the cult members ---
and (as Rod Pemberton explains below), the cult members expect loyalty from Elizabeth Rather:

On Wednesday, January 31, 2018 at 11:50:40 PM UTC-7, Rod Pemberton wrote:
> On Sun, 28 Jan 2018 21:03:21 -1000
> "Elizabeth D. Rather" <era...@forth.com> wrote:
>
> > I disagree with all that, but won't elaborate because this doesn't
> > belong on this Forth board.
>
> Well, Ms. Rather, I for one am disheartened by your complete lack of
> personal character. I've learned that you have no integrity, as it was
> a simple thing to do what was right and cite Anton for being
> off-topic. We previously learned that you had no personal honor, as you
> left many others, including me, to spend their time and life defending
> it against Hugh's attacks. I now see that you also have no loyalty, as
> I probably defended you against Hugh's attacks well over two hundred
> times, but you had no problems attacking me, whatsoever, here.
>
> While I appreciate your Forth knowledge and contribution to
> comp.lang.forth in that area, I cannot in good conscience continue
> consider someone so devoid of honor, loyalty, and integrity as an
> online friend. I hope you understand. If this is because you're
> an autistic, I'm sorry. If this is because you're a stoic or pacifist,
> I'm not sorry.

>
>
> Rod Pemberton
> --
> "The strongest, richest, greatest nation in the world shouldn't leave
> anyone behind," said Joe Kennedy. "We're going to put a lot of coal
> miners and coal country out of business," said Hillary Clinton.

Does anybody else think that this demand for loyalty is humorous? It is like that movie, "The Room" --- supposedly deadly serious, but actually a comedy.

Also, BTW, the "economic problem of Forth" is routinely discussed on comp.lang.forth:
https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D

On Friday, November 20, 2009 at 6:12:36 PM UTC-7, Elizabeth D Rather wrote:
> The major reason Forth hasn't been accepted is lack of marketing, either
> in the form of adoption by major companies or organizations or papers in
> various publications, meetings, etc.

More marketing???
The problem is not that C programmers don't know about Forth --- the problem is that they do know about ANS-Forth --- they think Forth programmers are idiots.
Telling more people about ANS-Forth will make this problem worse rather than better! Marketing is not always a positive contribution.
Loyalty is not always a positive contribution either --- the loyalty of trolls makes people who actually write Forth code look guilty by association.

[Mihail Maksimov]

Dmitry Ponyatov wrote:

> Forth have some sort of homogenic syntax, like Lisp too.

In the Forth you can run any program including any interpreter(compiler).
Forth environment for this interpreter can give additional opportunities.
As the operating system may come up any interpreter. The Forth is best suited as a base in a multi-level system.
Because this is direct access to all resources.

> Software development has few main stages: design, debugging in runtime and production exploitation.

When there will be an opportunity to sell cheap files there will be only minor upgrades.
Any software will develop in a natural evolutionary way.


> That's the place of traditional programming language efficiency, and this stage is a target of C and C++ optimizing compilers was designed till last tens of years. And Forth here is out of a game as any other high-level languages like Python, Java and any other script languages.
The Forth allows you to manage the compilation and generate any code. If in the SP-Forth to separate the code from the data it is quite commensurable with the C.

> "how to make system able to pay programmers for its working time in automatic manner"

Each programmer must have his own file-shop machine. And evaluate not time, but profitability.

[a...@littlepinkcloud.invalid]

dxf...@gmail.com wrote:
>
> That's not a Standard enticing newcomers to Forth.

Since when was that a goal of a language standard?

> It's the committee accepting there are limits to what
> it can impose on forthers :)

That's how it should be. In practice it's how it is for every
programming language standard.

Andrew.

[Alex]

I do wonder at some folks. Is this standards misunderstanding because

1. They want a standard, but not this one
2. They don't want any standard at all
3. They are very annoyed that they're not on the standards committee
4. The standard is fine, so leave it alone
5. There was a much better standard and this one is worse

I can't get a sense of what any of them wants.

--
Alex

[Liang Ng]

Hmmmm .....

I think you just gave the definition of "standards".

[The Beez]

On Wednesday, February 7, 2018 at 1:47:54 AM UTC+1, Paul Rubin wrote:
> dxf...@gmail.com writes:
> > Links to the 3 pdf documents were given on c.l.f early 200x IIRC.
> > Most of the new forth words were OTA specific but in there was a gem
> > called +STRING. I've had it in my forth for years and I can't believe
> > it still hasn't been picked up, including by Forth Inc and MPE.
>
> I did find some references to OTA on Google Groups clf archive but
> didn't see pdf doc links. I might look some more. I found a definition
> of +STRING in one of the threads:
>
> : +STRING ( a1 u1 a2 u2 -- a2 u3 )
> 2swap swap 2over + 2 pick cmove + ;

So many heavy duty words:

: +STRING ( a1 u1 a2 u2 -- a2 u1+u2 )
2>r 2r@ chars + swap >r r@ cmove 2r> r> + ;

Hans Bezemer

[Albert van der Horst]

In article <d2446425-ced4-4d93...@googlegroups.com>,

This word is wrong. My wordset
$! $@ $/ $C+ $+!
lifts the string abstraction one cm above the ground.
Now we have string constants and string variables.

+STRING is driving them into the ground, sorry.

>
>Hans Bezemer

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>I found a definition
>of +STRING in one of the threads:
>
>: +STRING ( a1 u1 a2 u2 -- a2 u3 )

That's an error-prone stack effect, because it means that the caller
must check that U1+U2 fits into the buffer at a2. If the caller does
this checking (why burden him with that?), there's a good chance that
the checking code contains a bug; in that case, or if the checking is
not done, there is a good chance that the result has a buffer overflow
vulnerability.

Better provide the buffer length with such a word, or, even better,
let +STRING allocate the memory.

If you want to work at that level, Gforth has a word

APPEND ( addr1 u1 addr2 u2 -- addr u )

where addr1 is ALLOCATEd, and consumed by APPEND, and ADDR is also
ALLOCATEd.

It also has S+ with the same stack effect that does not consume addr1.

Of course, many people don't like to work at this level and have
introduced various string wordsets.

- 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 2017: http://euro.theforth.net/

[Anton Ertl]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>If you want to work at that level, Gforth has a word
>
>APPEND ( addr1 u1 addr2 u2 -- addr u )
>
>where addr1 is ALLOCATEd, and consumed by APPEND, and ADDR is also
>ALLOCATEd.
>
>It also has S+ with the same stack effect that does not consume addr1.

However, these days I prefer to use >STRING-EXECUTE instead of lots of
S+ and APPEND, e.g.:

: call-emacs ( c-addr u line column -- )
[: ." emacs +" swap 0 .r ." :" 0 .r space type ;] >string-execute
2dup system free throw ;

[Hans Bezemer]

> This word is wrong. My wordset
> $! $@ $/ $C+ $+!
> lifts the string abstraction one cm above the ground.
> Now we have string constants and string variables.
>
> +STRING is driving them into the ground, sorry.

I can't argue with that. You can't know where the string to be
appened resides and whether there is room for the appened string.
I can't say whether your wordset is THE solution for that - I get
along very well with PLACE, COUNT and +PLACE (which work with a
named buffer). BTW, anyone noticed my +STRING had little
bug?

Hans Bezemer


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[dxf...@gmail.com]

On Thursday, February 8, 2018 at 3:04:04 AM UTC+11, Anton Ertl wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> >I found a definition
> >of +STRING in one of the threads:
> >
> >: +STRING ( a1 u1 a2 u2 -- a2 u3 )
>
> That's an error-prone stack effect, because it means that the caller
> must check that U1+U2 fits into the buffer at a2. If the caller does
> this checking (why burden him with that?), there's a good chance that
> the checking code contains a bug; in that case, or if the checking is
> not done, there is a good chance that the result has a buffer overflow
> vulnerability.

+STRING is unashamedly a primitive. Use directly
or in higher level functions CAPPEND ZAPPEND etc
with error checking if needed.

[dxf...@gmail.com]

On Wednesday, February 7, 2018 at 9:21:46 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> dxf...@gmail.com wrote:
> >
> > That's not a Standard enticing newcomers to Forth.
>
> Since when was that a goal of a language standard?

Since when hasn't it been Forth's goal? But
you're right. Forth Inc says it needs little
of what 200x has provided. It has a formal
industry-recognized ANS language standard which
it has fully implemented and is compliant.

[dxf...@gmail.com]

On Thursday, February 8, 2018 at 10:17:22 AM UTC+11, The Beez wrote:
> > This word is wrong. My wordset
> > $! $@ $/ $C+ $+!
> > lifts the string abstraction one cm above the ground.
> > Now we have string constants and string variables.
> >
> > +STRING is driving them into the ground, sorry.
>
> I can't argue with that. You can't know where the string to be
> appened resides and whether there is room for the appened string.
> I can't say whether your wordset is THE solution for that - I get
> along very well with PLACE, COUNT and +PLACE (which work with a
> named buffer). BTW, anyone noticed my +STRING had little
> bug?

4tH avoids doubles like the plague? :)

[a...@littlepinkcloud.invalid]

dxf...@gmail.com wrote:
> On Wednesday, February 7, 2018 at 9:21:46 PM UTC+11, a...@littlepinkcloud.invalid wrote:
>> dxf...@gmail.com wrote:
>> >
>> > That's not a Standard enticing newcomers to Forth.
>>
>> Since when was that a goal of a language standard?
>
> Since when hasn't it been Forth's goal?

This sentence no sense makes. Forth as such doen't have goals:
standards have goals, implementers have goals, users have goals, and
so on. Enticing newcomers isn't the goal of a language standard.

Andrew.

[minf...@arcor.de]

At least it seems to entice some loony people here in clf.

[The Beez]

On Thursday, February 8, 2018 at 8:37:00 AM UTC+1, dxf...@gmail.com wrote:
> 4tH avoids doubles like the plague? :)

Well, the general policy in 4tH is to use 2-words ONLY when the manipulated datatype is 2 cells - like a string, a double or (sometimes) a fp. So:

: add ( n1 n2 -- n1 n2 n1+n2) over over + ;
: print (a1 n1 -- a1 n1) 2dup type cr ;

Since 4tH is a bytecode compiler with 106 primitives, this compiles to:

BRANCH OVER OVER + EXIT
BRANCH OVER OVER TYPE CR EXIT

Hence, 2DUP is expanded like a macro. Such a macro may not be longer than 4 opcodes (by convention) and cannot be nested. Consequently, 2OVER and 2ROT are external words, defined in a library (since these definitions are too long). If I can do without these expensive words, I'll do it.

The reason for this policy is CLARITY. If you manipulate a 2 cell datatype, indicate it. If not, make that clear. This is a sane policy in 4tH, because the code itself boils down to the same thing - you won't gain any performance.

This also led to the definition of 2>R as : 2>R >R >R ; - without the SWAP. The order of the individual cells on the stack is undefined - which is perfectly alright if 2R@ does its job properly.

This is to deter people from using "fancy tricks" which may be clever, but make a program totally unreadable and unmaintainable.

So no, 2-words are no second class citizens, they are only used in well-defined circumstances.

Hans Bezemer

[Albert van der Horst]

In article <71b46dfb-7d8d-4221...@googlegroups.com>,
The Beez <the.bee...@gmail.com> wrote:
<SNIP>
>
>This also led to the definition of 2>R as : 2>R >R >R ; - without the SWAP.=
> The order of the individual cells on the stack is undefined - which is per=

>fectly alright if 2R@ does its job properly.

This can be dangerous. At least call these words
D>R DR> DR@
which are better names anyway.

If someone encounters them he can do
'2R> ALIAS DR>
*after checking*.

[Elizabeth D. Rather]

On 2/8/18 2:08 AM, Albert van der Horst wrote:
> In article <71b46dfb-7d8d-4221...@googlegroups.com>,
> The Beez <the.bee...@gmail.com> wrote:
> <SNIP>
>>
>> This also led to the definition of 2>R as : 2>R >R >R ; - without the SWAP.=
>> The order of the individual cells on the stack is undefined - which is per=
>> fectly alright if 2R@ does its job properly.
>
> This can be dangerous. At least call these words
> D>R DR> DR@
> which are better names anyway.

Absolutely not! the 'D' prefix is intended to denote a word that
specifically deals with double-precision integers, as distinct from
pairs of cells that may or may not have a close relationship. 'D' is
really only relevant for arithmetic words, such as D+ etc.

That is why they are in the *optional* Double Numbers wordset, as
they're rarely used in 32-bit systems (and probably never in 64-bit
systems), but essential on many 8- and 16- bit microcontrollers. In
contrast, the '2' words are frequently useful.

[gavino himself]

On Tuesday, February 6, 2018 at 6:52:30 AM UTC-5, The Beez wrote:
> On Monday, February 5, 2018 at 6:22:01 PM UTC+1, Dmitry Ponyatov wrote:
> <quote>
> Every time I read my own code (not saying about somebody else code) I feel wild butthurt and need of full-sized interactive debugger with stack snapshots, code markers, breakpoints and step by step execution in any Forth system I try to use.
> </quote>
> I have been maintaining my 4tH code for over 20 years and never found it particularly hard. I wrote a "debugger" once, but all I really need is a decompile and .S - thank you.
>
> <quote> Modern object languages have more readable syntax, especially Python forces you to use proper formatting.
> </quote>
>
> I'm quite capable to indent my own code, thank you. Code indentation according to a language is asking for unintentional, hard to trace bugs.
>
> <quote>
> OOP by design was developed extremely for code reuse by program segmentation and inheritance. That's why only OOP languages are alive for commercial development.
> </quote>
>
> OOP is not a programming paradigm, it's a programming technique. Enforcing OOP is asking for maintainable lasagna code. And contrary to popular belief, it is almost trivial to turn OOP code to imperative code. Note I have full OOP in place, but it doesn't save you from all these "disasters" that people claim that OOP BY VERY DESIGN prevents. I think that the IT sector is one of the most superstitious metiers in the world - they all believe in holy books and holy people without asking for any proof. OOP is one of the results. It's not more productive, more reusable or more foolproof. It's all smoke and mirrors.
> https://sourceforge.net/p/forth-4th/wiki/Object%20Orientation/
>
> <quote>
> A speed of program execution is the last thing you think about at design stage.
> </quote>
> That depends on the problem and requirements.
>
> <quote>
> Working environment must provide you tools to model your world as much closer to the domain.
> </quote>
>
> It's your head that does that - not the tooling. If you need tools to model your world, you don't understand the problem clearly.
>
> <quote>
> And finally, move to production. Here we need deeply optimized machine code must do its job on smallest resources, especially for embedded applications.
> <quote>
>
> You need proper code. Any good programmer can reasonably well predict what code will be generated, given certain optimization flags. And you can optimize in several dimensions, size and speed. E.g. "loop unrolling" is not particularly good for size.
>
> <quote>

> And Forth here is out of a game as any other high-level languages like Python, Java and any other script languages.

> </quote>
>
> Python is neither good in speed or size. Java is bloat. Both use VM's. Ruby is even worse performancewise. It doesn't feel right to shove Forth in that same category, since it has too many and quite different implementations.
>
> Hans Bezemer

The Beez is awesome as ususal!

[Rod Pemberton]

On Thu, 8 Feb 2018 10:11:40 -1000

"Elizabeth D. Rather" <era...@forth.com> wrote:

> On 2/8/18 2:08 AM, Albert van der Horst wrote:
> > In article <71b46dfb-7d8d-4221...@googlegroups.com>,
> > The Beez <the.bee...@gmail.com> wrote:
> > <SNIP>

> >> This also led to the definition of 2>R as : 2>R >R >R ; - without
> >> the SWAP.= The order of the individual cells on the stack is
> >> undefined - which is per= fectly alright if 2R@ does its job
> >> properly.
> >
> > This can be dangerous. At least call these words
> > D>R DR> DR@
> > which are better names anyway.
>
> Absolutely not! the 'D' prefix is intended to denote a word that
> specifically deals with double-precision integers, as distinct from
> pairs of cells that may or may not have a close relationship. 'D' is
> really only relevant for arithmetic words, such as D+ etc.
>

Sigh, everyone keeps saying Forth doesn't have syntax ...


Rod Pemberton
--
The question is not whether Elon Musk can launch a Tesla into space,
but whether or not he can return it to Earth without damaging the paint.

[Rod Pemberton]

Did you miss the wink smiley? I.e., that was meant to be humorous.

[dxf...@gmail.com]

On Thursday, February 8, 2018 at 9:04:56 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> dxf...@gmail.com wrote:
> > On Wednesday, February 7, 2018 at 9:21:46 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> >> dxf...@gmail.com wrote:
> >> >
> >> > That's not a Standard enticing newcomers to Forth.
> >>
> >> Since when was that a goal of a language standard?
> >
> > Since when hasn't it been Forth's goal?
>
> This sentence no sense makes. Forth as such doen't have goals:
> standards have goals, implementers have goals, users have goals, and
> so on. Enticing newcomers isn't the goal of a language standard.

If you want play word games then only people can
can have goals - in this case the 200x committee.
Even if 200x doesn't care about attracting users
to Forth, it needed Forth Inc and is plain from their statement Forth Inc has little need of
200x.

>
> Andrew.

[dxf...@gmail.com]

You have something of substance to contribute
to the conversion? Then go for it.

[Elizabeth D. Rather]

On 2/8/18 12:01 PM, Rod Pemberton wrote:
> On Thu, 8 Feb 2018 10:11:40 -1000
> "Elizabeth D. Rather" <era...@forth.com> wrote:
>
>> On 2/8/18 2:08 AM, Albert van der Horst wrote:
>>> In article <71b46dfb-7d8d-4221...@googlegroups.com>,
>>> The Beez <the.bee...@gmail.com> wrote:
>>> <SNIP>
>
>>>> This also led to the definition of 2>R as : 2>R >R >R ; - without
>>>> the SWAP.= The order of the individual cells on the stack is
>>>> undefined - which is per= fectly alright if 2R@ does its job
>>>> properly.
>>>
>>> This can be dangerous. At least call these words
>>> D>R DR> DR@
>>> which are better names anyway.
>>
>> Absolutely not! the 'D' prefix is intended to denote a word that
>> specifically deals with double-precision integers, as distinct from
>> pairs of cells that may or may not have a close relationship. 'D' is
>> really only relevant for arithmetic words, such as D+ etc.
>>
>
> Sigh, everyone keeps saying Forth doesn't have syntax ...

But it *does* have naming conventions! They're very valuable!

[Elizabeth D. Rather]

*Sigh* I never said that. On the contrary, I've been at some pains to
describe how and why standards are important. Specifically, they're
important to provide stability and consistency to the technology (the
goal of standards). This reassures companies considering use of the
technology, and benefits programmers trying to communicate with each
other. FORTH, Inc. has supported standards from the beginning.

We've come under criticism here for not adopting some recent additions
which, afaik, are not in the required CORE wordset. Forth is intended to
be used on a wide variety of platforms, from 8-bit micro-controllers to
huge workstations. The standard has a required minimum CORE wordset and
a variety of optional ones, and not all words in the optional wordsets
are required. What *is* required is documentation of what's included and
implementation choices that are made. We do that.

[dxf...@gmail.com]

On Friday, February 9, 2018 at 2:23:51 PM UTC+11, Elizabeth D. Rather wrote:
> On 2/8/18 4:38 PM, dxf...@gmail.com wrote:
> > On Thursday, February 8, 2018 at 9:04:56 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> >> dxf...@gmail.com wrote:
> >>> On Wednesday, February 7, 2018 at 9:21:46 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> >>>> dxf...@gmail.com wrote:
> >>>>>
> >>>>> That's not a Standard enticing newcomers to Forth.
> >>>>
> >>>> Since when was that a goal of a language standard?
> >>>
> >>> Since when hasn't it been Forth's goal?
> >>
> >> This sentence no sense makes. Forth as such doen't have goals:
> >> standards have goals, implementers have goals, users have goals, and
> >> so on. Enticing newcomers isn't the goal of a language standard.
> >
> > If you want play word games then only people can
> > can have goals - in this case the 200x committee.
> > Even if 200x doesn't care about attracting users
> > to Forth, it needed Forth Inc and is plain from their statement Forth Inc has little need of
> > 200x.
>
> *Sigh* I never said that.

Leon's recent statement wasn't clear enough?
He was only required to implement the 200x
core wordset to be technically compliant.
There were things in 200x Forth Inc would
never implement, he said.

That accords with his actions. Nothing of import
from 200x has been incorporated into Forth Inc
products in the 12 years 200x has been
delivering decisions. Just as well IMO.

> On the contrary, I've been at some pains to

> describe how and why standards are Specifically, they're

[Elizabeth D. Rather]

On 2/8/18 10:01 PM, dxf...@gmail.com wrote:
> On Friday, February 9, 2018 at 2:23:51 PM UTC+11, Elizabeth D. Rather wrote:
>> On 2/8/18 4:38 PM, dxf...@gmail.com wrote:
>>> On Thursday, February 8, 2018 at 9:04:56 PM UTC+11, a...@littlepinkcloud.invalid wrote:
>>>> dxf...@gmail.com wrote:
>>>>> On Wednesday, February 7, 2018 at 9:21:46 PM UTC+11, a...@littlepinkcloud.invalid wrote:
>>>>>> dxf...@gmail.com wrote:
>>>>>>>
>>>>>>> That's not a Standard enticing newcomers to Forth.
>>>>>>
>>>>>> Since when was that a goal of a language standard?
>>>>>
>>>>> Since when hasn't it been Forth's goal?
>>>>
>>>> This sentence no sense makes. Forth as such doen't have goals:
>>>> standards have goals, implementers have goals, users have goals, and
>>>> so on. Enticing newcomers isn't the goal of a language standard.
>>>
>>> If you want play word games then only people can
>>> can have goals - in this case the 200x committee.
>>> Even if 200x doesn't care about attracting users
>>> to Forth, it needed Forth Inc and is plain from their statement Forth Inc has little need of
>>> 200x.
>>
>> *Sigh* I never said that.
>
> Leon's recent statement wasn't clear enough?
> He was only required to implement the 200x
> core wordset to be technically compliant.
> There were things in 200x Forth Inc would
> never implement, he said.

The CORE wordset is all that's required. FORTH, Inc. products have most
standard words.

> That accords with his actions. Nothing of import
> from 200x has been incorporated into Forth Inc
> products in the 12 years 200x has been
> delivering decisions. Just as well IMO.

Leon says he has been gradually incorporating things from 200x. No one
is obligated to implement everything. He has been participating in the
standards process at considerable expense in time and money, and would
not do so if he didn't see it as valuable activity.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>We've come under criticism here for not adopting some recent additions
>which, afaik, are not in the required CORE wordset.

You have also been criticized for not (yet) implementing one of the
few required additions of Forth-2012: The 'a' syntax of the
number-prefix proposal.

>Forth is intended to
>be used on a wide variety of platforms, from 8-bit micro-controllers to
>huge workstations. The standard has a required minimum CORE wordset and
>a variety of optional ones, and not all words in the optional wordsets
>are required.

I don't think that the microcontroller excuse is a good one when we
talk about, e.g., SwiftForth i386-Linux.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:

>That is why they are in the *optional* Double Numbers wordset, as
>they're rarely used in 32-bit systems (and probably never in 64-bit
>systems)

Of course we use it in 64-bit systems, e.g., for implementing #, for
implementing division by multiplication with the inverse, for
big-integer libraries or for cryptography; and of course to be
portable between different cell sizes. Sometimes you need to deal
with integers that are twice as long as a cell, whatever the cell
size.

[Albert van der Horst]

In article <5aOdnXyUxotgM-HH...@supernews.com>,

Elizabeth D. Rather <era...@forth.com> wrote:

>On 2/8/18 2:08 AM, Albert van der Horst wrote:
>> In article <71b46dfb-7d8d-4221...@googlegroups.com>,
>> The Beez <the.bee...@gmail.com> wrote:
>> <SNIP>
>>>
>>> This also led to the definition of 2>R as : 2>R >R >R ; - without the SWAP.=
>>> The order of the individual cells on the stack is undefined - which is per=
>>> fectly alright if 2R@ does its job properly.
>>
>> This can be dangerous. At least call these words
>> D>R DR> DR@
>> which are better names anyway.
>
>Absolutely not! the 'D' prefix is intended to denote a word that
>specifically deals with double-precision integers, as distinct from
>pairs of cells that may or may not have a close relationship. 'D' is
>really only relevant for arithmetic words, such as D+ etc.

' ROT ALIAS SDSWAP
in my source, when I want to swap integers and strings.

I didn't realise the logic behind 2 and D

Probably you do agree that it is unwise to have the same words
with different meaning.
So P>R PR> PR@
would be better, where P indicate pair.

>
>That is why they are in the *optional* Double Numbers wordset, as
>they're rarely used in 32-bit systems (and probably never in 64-bit
>systems), but essential on many 8- and 16- bit microcontrollers. In
>contrast, the '2' words are frequently useful.

Agreed.

>
>Cheers,
>Elizabeth
>
>--
>Elizabeth D. Rather
>FORTH, Inc.
>6080 Center Drive, Suite 600
>Los Angeles, CA 90045
>USA

[Gerry Jackson]

On 09/02/2018 03:23, Elizabeth D. Rather wrote:
> We've come under criticism here for not adopting some recent additions
> which, afaik, are not in the required CORE wordset. Forth is intended to
> be used on a wide variety of platforms, from 8-bit micro-controllers to
> huge workstations. The standard has a required minimum CORE wordset and
> a variety of optional ones, and not all words in the optional wordsets
> are required.

Yes that is the letter of the standard but ignores the fact that
Swiftforth is perceived as one of the major desktop systems. Users
expect such systems, that are not resource limited, to be comprehensive
with regard to the latest standard, Forth 2012. Failure to keep up risks
damaging Swiftforth's reputation with regard to portability of software
across systems.

--
Gerry

[Albert van der Horst]

In article <2018Feb...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>"Elizabeth D. Rather" <era...@forth.com> writes:
>>We've come under criticism here for not adopting some recent additions
>>which, afaik, are not in the required CORE wordset.
>
>You have also been criticized for not (yet) implementing one of the
>few required additions of Forth-2012: The 'a' syntax of the
>number-prefix proposal.

And I agree. In view of the meaning of ' in Forth 'a' is objectionable
syntax. But CHAR [CHAR] is cumbersome, and a standard and
concise denotation for characters is long overdue.
( &A has been around for a long time, but unstandardized.)

<SNIP>

>- 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 2017: http://euro.theforth.net/

[Alex]

On 09-Feb-18 10:57, Albert van der Horst wrote:

>
> And I agree. In view of the meaning of ' in Forth 'a' is objectionable
> syntax. But CHAR [CHAR] is cumbersome, and a standard and
> concise denotation for characters is long overdue.

' ' ALIAS TICK
' ['] ALIAS [TICK]


--
Alex

[Anton Ertl]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In view of the meaning of ' in Forth 'a' is objectionable
>syntax.

Not in the least. There is no conflict between ' and the 'a' syntax:
there is no syntax overlap, and the difference between

' word

and

'a'

is big enough that there should not be a mental overlap, either (and
if you want to claim such a mental overlap, where does this kind
of argument end?).

In any case, the standards committee has found consensus on 'a' as a
required syntax for characters, so what you or Andrew Haley think
about it should be of no concern to Forth, Inc.

>( &A has been around for a long time, but unstandardized.)

Maybe it has been around in your system, but let's look at what
happens on others:

&A \ error on SwiftForth, VFX, and Gforth
&7 . \ prints 7 on SwiftForth and Gforth, error on VFX
&10 . \ prints 8 on SwiftForth, 10 on Gforth, error on VFX

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
> In any case, the standards committee has found consensus on 'a' as a
> required syntax for characters, so what you or Andrew Haley think
> about it should be of no concern to Forth, Inc.

I agree that they shouldn't be concerned about what we think merely
because that's what we think, but the issues we raise might themselves
be of concern.

Andrew.

[a...@littlepinkcloud.invalid]

Gerry Jackson <do-no...@swldwa.uk> wrote:
> On 09/02/2018 03:23, Elizabeth D. Rather wrote:
>> We've come under criticism here for not adopting some recent additions
>> which, afaik, are not in the required CORE wordset. Forth is intended to
>> be used on a wide variety of platforms, from 8-bit micro-controllers to
>> huge workstations. The standard has a required minimum CORE wordset and
>> a variety of optional ones, and not all words in the optional wordsets
>> are required.
>
> Yes that is the letter of the standard but ignores the fact that
> Swiftforth is perceived as one of the major desktop systems. Users
> expect such systems, that are not resource limited, to be
> comprehensive with regard to the latest standard, Forth
> 2012.

Do they? How do you know this?

> Failure to keep up risks damaging Swiftforth's reputation with
> regard to portability of software across systems.

I doubt that very much indeed.

Andrew.

[Anton Ertl]

Sure, just as the colour of the bike shed might be of concern after it
has been built. Maybe we can extend Parkinson's law of triviality to
describe those cases where people don't accept that the decision has
been made and cast in stone, and flog the horse again and again after
it has died.

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> a...@littlepinkcloud.invalid writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>
>>> In any case, the standards committee has found consensus on 'a' as a
>>> required syntax for characters, so what you or Andrew Haley think
>>> about it should be of no concern to Forth, Inc.
>>
>>I agree that they shouldn't be concerned about what we think merely
>>because that's what we think, but the issues we raise might themselves
>>be of concern.
>
> Sure, just as the colour of the bike shed might be of concern after
> it has been built. Maybe we can extend Parkinson's law of
> triviality to describe those cases where people don't accept that
> the decision has been made and cast in stone, and flog the horse
> again and again after it has died.

LOL! So we have Schroedinger's bikeshed issue, one which is
simultaneously too trivial to care about but worthy of complaint
because of its significance.

Andrew.

[Gerry Jackson]

On 09/02/2018 14:01, a...@littlepinkcloud.invalid wrote:
> Gerry Jackson <do-no...@swldwa.uk> wrote:
>> On 09/02/2018 03:23, Elizabeth D. Rather wrote:
>>> We've come under criticism here for not adopting some recent additions
>>> which, afaik, are not in the required CORE wordset. Forth is intended to
>>> be used on a wide variety of platforms, from 8-bit micro-controllers to
>>> huge workstations. The standard has a required minimum CORE wordset and
>>> a variety of optional ones, and not all words in the optional wordsets
>>> are required.
>>
>> Yes that is the letter of the standard but ignores the fact that
>> Swiftforth is perceived as one of the major desktop systems. Users
>> expect such systems, that are not resource limited, to be
>> comprehensive with regard to the latest standard, Forth
>> 2012.
>
> Do they? How do you know this?

I don't (I seem to have caught the Aguilar sweeping statement disease).
My expectation then - probably because I maintain a test suite that
Swiftforth no longer runs.

>
>> Failure to keep up risks damaging Swiftforth's reputation with
>> regard to portability of software across systems.
>
> I doubt that very much indeed.

Well it's a possibility as anyone writing software that uses new
features in Forth 2012 will find it won't run on SwiftForth unless they
provide an implementation of the new features - which is extra work of
course. Forth Inc could easily eliminate that possibility.


--
Gerry

[Elizabeth D. Rather]

On 2/9/18 12:28 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> We've come under criticism here for not adopting some recent additions
>> which, afaik, are not in the required CORE wordset.
>
> You have also been criticized for not (yet) implementing one of the
> few required additions of Forth-2012: The 'a' syntax of the
> number-prefix proposal.
>
>> Forth is intended to
>> be used on a wide variety of platforms, from 8-bit micro-controllers to
>> huge workstations. The standard has a required minimum CORE wordset and
>> a variety of optional ones, and not all words in the optional wordsets
>> are required.
>
> I don't think that the microcontroller excuse is a good one when we
> talk about, e.g., SwiftForth i386-Linux.

It's the argument for defining a minimum required CORE. Obviously
systems such as SwiftForth have a great deal more, including most of the
optional wordsets.

Cheers,
Elizaveth

[minf...@arcor.de]

Am Freitag, 9. Februar 2018 20:14:46 UTC+1 schrieb Elizabeth D. Rather:
> On 2/9/18 12:28 AM, Anton Ertl wrote:
> > "Elizabeth D. Rather" <era...@forth.com> writes:
> >> We've come under criticism here for not adopting some recent additions
> >> which, afaik, are not in the required CORE wordset.
> >
> > You have also been criticized for not (yet) implementing one of the
> > few required additions of Forth-2012: The 'a' syntax of the
> > number-prefix proposal.
> >
> >> Forth is intended to
> >> be used on a wide variety of platforms, from 8-bit micro-controllers to
> >> huge workstations. The standard has a required minimum CORE wordset and
> >> a variety of optional ones, and not all words in the optional wordsets
> >> are required.
> >
> > I don't think that the microcontroller excuse is a good one when we
> > talk about, e.g., SwiftForth i386-Linux.
>
> It's the argument for defining a minimum required CORE. Obviously
> systems such as SwiftForth have a great deal more, including most of the
> optional wordsets.

Luckily CORE is rather stable.

CORE-EXT less so. Crazy stuff like multiple-overloaded TO's or S\" have
landed in CORE-EXT of draft standard 16. But who cares anyway....

[Albert van der Horst]

In article <2018Feb...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In view of the meaning of ' in Forth 'a' is objectionable
>>syntax.
>
>Not in the least. There is no conflict between ' and the 'a' syntax:
>there is no syntax overlap, and the difference between
>
>' word
>
>and
>
>'a'
>
>is big enough that there should not be a mental overlap, either (and
>if you want to claim such a mental overlap, where does this kind
>of argument end?).

It isn't. The proper usage of tick is as a denotation.
So if I ;ve words a b c a' b' c'
the denotation 'a' is ambigeous.

(Should I add IMHO?)

>- anton

Groetjes Albert

[dxf...@gmail.com]

It's not all that's required from a major Forth
vendor claiming to offer standard compliant
products to customers and you know it.

If Forth Inc today is saying it only needs to
support the 200x core wordset then it is a
strategic decision. Clearly it doesn't see
minimal support for 200x as affecting its
business. It still fully supports ANS - which
no doubt pleases you.

>
> > That accords with his actions. Nothing of import
> > from 200x has been incorporated into Forth Inc
> > products in the 12 years 200x has been
> > delivering decisions. Just as well IMO.
>
> Leon says he has been gradually incorporating things from 200x. No one
> is obligated to implement everything. He has been participating in the
> standards process at considerable expense in time and money, and would
> not do so if he didn't see it as valuable activity.

We've been through this before. If 200x was
'valuable' to Forth Inc it would be providing
full support and done it long ago.

You are not doing Forth Inc any favours
marrying them to 200x when it's plain for
all to see they don't want it.

[Elizabeth D. Rather]

Supporting the CORE wordset is the basic requirement for any system to
claim to be standard. FORTH, Inc. products support virtually all the
wordsets in 2012 (including, in the current release, the 2012 character
literals and locals syntax).

>>> That accords with his actions. Nothing of import
>>> from 200x has been incorporated into Forth Inc
>>> products in the 12 years 200x has been
>>> delivering decisions. Just as well IMO.
>>
>> Leon says he has been gradually incorporating things from 200x. No one
>> is obligated to implement everything. He has been participating in the
>> standards process at considerable expense in time and money, and would
>> not do so if he didn't see it as valuable activity.
>
> We've been through this before. If 200x was
> 'valuable' to Forth Inc it would be providing
> full support and done it long ago.
>
> You are not doing Forth Inc any favours
> marrying them to 200x when it's plain for
> all to see they don't want it.

It's not "plain" to the folks at FORTH, Inc.

[dxf...@gmail.com]

On Thursday, February 8, 2018 at 10:17:22 AM UTC+11, The Beez wrote:
> > This word is wrong. My wordset
> > $! $@ $/ $C+ $+!
> > lifts the string abstraction one cm above the ground.
> > Now we have string constants and string variables.
> >
> > +STRING is driving them into the ground, sorry.
>
> I can't argue with that. You can't know where the string to be
> appened resides and whether there is room for the appened string.
> I can't say whether your wordset is THE solution for that - I get
> along very well with PLACE, COUNT and +PLACE (which work with a
> named buffer).

On that basis you don't need /STRING because
it has no checking and is readily implemented
using primitives. Yet you provide it.

There are factors I will never implement e.g.
BUFFER: However RESERVE aka HERE SWAP ALLOT
gets a tick. I cannot say exactly why I prefer
one and hate the other.

The implication for those who claim to want a
bigger and better Standard, is *whose* standard
shall it be. I suspect Forth has already reached
the point of non-consensus. 'Small is beautiful'
may not just be good for Forth, it may be the
only way it can exist.

> BTW, anyone noticed my +STRING had little
> bug?
>
> Hans Bezemer
>
>
> ----Android NewsGroup Reader----
> http://usenet.sinaapp.com/

[hughag...@gmail.com]

On Friday, February 9, 2018 at 9:52:51 AM UTC-7, Gerry Jackson wrote:
> On 09/02/2018 14:01, a...@littlepinkcloud.invalid wrote:
> > Gerry Jackson <do-no...@swldwa.uk> wrote:
> >> On 09/02/2018 03:23, Elizabeth D. Rather wrote:
> >>> We've come under criticism here for not adopting some recent additions
> >>> which, afaik, are not in the required CORE wordset. Forth is intended to
> >>> be used on a wide variety of platforms, from 8-bit micro-controllers to
> >>> huge workstations. The standard has a required minimum CORE wordset and
> >>> a variety of optional ones, and not all words in the optional wordsets
> >>> are required.
> >>
> >> Yes that is the letter of the standard but ignores the fact that
> >> Swiftforth is perceived as one of the major desktop systems. Users
> >> expect such systems, that are not resource limited, to be
> >> comprehensive with regard to the latest standard, Forth
> >> 2012.
> >
> > Do they? How do you know this?
>
> I don't (I seem to have caught the Aguilar sweeping statement disease).
> My expectation then - probably because I maintain a test suite that
> Swiftforth no longer runs.

ANS-Forth and Forth-200x are a cult --- just a nest of annoying trolls who routinely make gratuitous attacks on me.

> >> Failure to keep up risks damaging Swiftforth's reputation with
> >> regard to portability of software across systems.
> >
> > I doubt that very much indeed.
>
> Well it's a possibility as anyone writing software that uses new
> features in Forth 2012 will find it won't run on SwiftForth unless they
> provide an implementation of the new features - which is extra work of
> course. Forth Inc could easily eliminate that possibility.

Gerry Jackson says: "Failure to keep up risks damaging Swiftforth's reputation with regard to portability of software across systems."
It is absurd that Gerry Jackson believes that Forth Inc. cares about portability of Forth software across systems. LOL Not very quick on the uptake, are you?
Elizabeth Rather routinely says that the goal of ANS-Forth was "portable programmers, not portable programs."

On Sunday, December 24, 2017 at 10:07:42 AM UTC-7, Elizabeth D. Rather wrote:
> FORTH, Inc. tries very hard to document its implementation dependencies
> and other such things. If programmers want to write portable programs
> with relatively few dependencies I think it's possible.
>
> However, I'm not really sure there's really the desire. Same is true
> about libraries.

Why do you believe that Forth Inc. cares about allowing programs to be portable between Forth systems? Are you stupid?
How many times does Elizabeth Rather have to tell you that Forth Inc. does not want Forth programs to be portable,
before you finally understand that Forth Inc. does not want Forth programs to be portable?

Why would a corporation want programs to be portable? Are you stupid? Corporations want vendor lock-in. This is very obvious! You can't understand???

Elizabeth Rather wants to list your name on the Forth-200x document as a supporter.
You have no other contribution to make --- just brown-nosing --- that is the only contribution Elizabeth Rather will accept from you.

[dxf...@gmail.com]

In that case Forth Inc has lost my respect.
Pointless change and duplication sends the
message Forth doesn't know what it is doing.

[hughag...@gmail.com]

On Wednesday, February 7, 2018 at 7:15:33 AM UTC-7, The Beez wrote:
> On Wednesday, February 7, 2018 at 1:47:54 AM UTC+1, Paul Rubin wrote:
> > dxf...@gmail.com writes:
> > > Links to the 3 pdf documents were given on c.l.f early 200x IIRC.
> > > Most of the new forth words were OTA specific but in there was a gem
> > > called +STRING. I've had it in my forth for years and I can't believe
> > > it still hasn't been picked up, including by Forth Inc and MPE.
> >
> > I did find some references to OTA on Google Groups clf archive but
> > didn't see pdf doc links. I might look some more. I found a definition
> > of +STRING in one of the threads:
> >
> > : +STRING ( a1 u1 a2 u2 -- a2 u3 )
> > 2swap swap 2over + 2 pick cmove + ;
>
> So many heavy duty words:
>
> : +STRING ( a1 u1 a2 u2 -- a2 u1+u2 )
> 2>r 2r@ chars + swap >r r@ cmove 2r> r> + ;
>
> Hans Bezemer

My STRING-STACK.4TH is some of the best Forth code I've written in years.
The strings are stored on the heap.
I use COW (copy-on-write) --- I learned about this term afterward --- I didn't know the term when I wrote the code.
I have "unique" and "derivative" strings. The derivative strings are a reference to a unique string.
The derivative strings are fast because they don't need to copy the string, and they don't need ALLOCATE and FREE that are slow. They are just references.
The user can write his code as if all the strings were unique. He does not have to concern himself with whether strings are unique or derivative internally.
The use of derivative strings is done under the hood as an optimization.

Your +STRING shown above is so simplistic as to be a joke. What happens if there isn't room in the buffer for the concatenated string? LOL
Forth code such as this tends to make the whole Forth community appear to be stupid --- put it in Forth-200x! --- call it the "Standard!" LOL
This is the Special Olympics of computer programming --- Forth-200x is going for the gold!

My +$ that does concatenation is one of the most complicated functions I've written in years:

: +$ { | new-adr new-cnt -- } \ string: a b -- a+b
<len$> 0= if drop$ exit then \ if B is empty, then just return A (avoid trouble from RESIZE)
<2nd-len$> 0= if nip$ exit then \ if A is empty, then just return B (avoid trouble from RESIZE)
<2nd-len$> <len$> + to new-cnt \ the size of the combined string
second$ derivative? if
first$ derivative? if new-cnt alloc \ if SECOND$ is a derivative and FIRST$ is a derivative, we make a new unique
else first$ .adr$ @ new-cnt realloc then \ if SECOND$ is a derivative and FIRST$ is a unique, we resize FIRST$
else
second$ .adr$ @ new-cnt realloc then \ if SECOND$ is a unique, we resize SECOND$ (whether FIRST$ is unique or not)
to new-adr \ the address provided by ALLOC or REALLOC
first$ .adr$ @ new-adr <2nd-len$> + <len$> cmove> \ move FIRST$ string to back of new string this has to be done first
second$ .adr$ @ new-adr <2nd-len$> cmove \ move SECOND$ string to front of new string might over-write if done first
second$ derivative? if swap$ then \ if SECOND$ is a derivative then it did not get resized and used, so it has to be swapped to the top and given to DROP$
new-adr second$ .adr$ !
new-cnt second$ .cnt$ ! \ SECOND$ unique now, so it won't be affected if DROP$ calls FIX-DERIVATIVES (the old FIRST$ item might have been unique)
drop$ ; \ the DROP$ has to be called after SECOND$ is set so FIX-DERIVATIVES doesn't mess with the old SECOND$ item

[Elizabeth D. Rather]

On 2/9/18 4:12 PM, dxf...@gmail.com wrote:
...

>>> It's not all that's required from a major Forth
>>> vendor claiming to offer standard compliant
>>> products to customers and you know it.
>>>
>>> If Forth Inc today is saying it only needs to
>>> support the 200x core wordset then it is a
>>> strategic decision. Clearly it doesn't see
>>> minimal support for 200x as affecting its
>>> business. It still fully supports ANS - which
>>> no doubt pleases you.
>>
>> Supporting the CORE wordset is the basic requirement for any system to
>> claim to be standard. FORTH, Inc. products support virtually all the
>> wordsets in 2012 (including, in the current release, the 2012 character
>> literals and locals syntax).
>
> In that case Forth Inc has lost my respect.
> Pointless change and duplication sends the
> message Forth doesn't know what it is doing.

LOL, we get beat up for not having a word that we think is unnecessary,
so we add it and then get beat up for adding it!

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:

> LOL, we get beat up for not having a word that we think is
> unnecessary, so we add it and then get beat up for adding it!

I think the confusion is about why Forth Inc does a minimal Forth 2012
implementation, just enough to check the box indicating conformance,
while if it really believed in the standard it could do a much more
robust implementation. Maybe that will come with time. I can
understand that right now there's not huge customer demand for Forth
2012 and that probably won't change more than gradually.

[Elizabeth D. Rather]

The alternative view is that the Forth 2012 additions are more minor
tweaks than major enhancements. Having an officially recognized standard
was an achievement. It's important to keep evaluating and tweaking it,
but a tweak is a tweak.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:

>On 2/9/18 4:12 PM, dxf...@gmail.com wrote:

[Elizabeth Rather:]

>>> Supporting the CORE wordset is the basic requirement for any system to
>>> claim to be standard. FORTH, Inc. products support virtually all the
>>> wordsets in 2012 (including, in the current release, the 2012 character
>>> literals and locals syntax).

Good to hear!

>> In that case Forth Inc has lost my respect.
>> Pointless change and duplication sends the
>> message Forth doesn't know what it is doing.
>
>LOL, we get beat up for not having a word that we think is unnecessary,
>so we add it and then get beat up for adding it!

dxf...@gmail.com has not expressed his message very clearly, but if
you read closely, he (?) used Forth, Inc. as a club to beat on
Forth-2012 and Forth-200x; now you take away this club, of course he
is unhappy.

[Anton Ertl]

dxf...@gmail.com writes:
[+STRING]

>On that basis you don't need /STRING because
>it has no checking

There's a big difference: +STRING writes to memory, /STRING just
performs on-stack computations. If you use +STRING without checking,
you can overwrite some unrelated memory (buffer overflow), if you use
/STRING without checking, you just get some funny values on the stack.

[NN]

None of you arguing this would qualify yourselves as complete beginners.

If you use +string without checking , yes it can overwrite unrelated memory, but isnt the onus on the programmer to do that checking ?

[NN]

On Wednesday, 7 February 2018 23:17:22 UTC, The Beez wrote:
> > This word is wrong. My wordset
> > $! $@ $/ $C+ $+!
> > lifts the string abstraction one cm above the ground.
> > Now we have string constants and string variables.
> >
> > +STRING is driving them into the ground, sorry.
>
> I can't argue with that. You can't know where the string to be
> appened resides and whether there is room for the appened string.
> I can't say whether your wordset is THE solution for that - I get
> along very well with PLACE, COUNT and +PLACE (which work with a

> named buffer). BTW, anyone noticed my +STRING had little

> bug?
>
> Hans Bezemer
>
>
> ----Android NewsGroup Reader----
> http://usenet.sinaapp.com/

Hi Hans,

The short answer is - didnt notice.

I rescanned the code and the only thing I can see is 2>r r> need to be >r 2>r
only because of the way the vals were placed on the stack.

But without trying it out on a machine its not easy to read and tell. So was this the bug ?

NN

[Anton Ertl]

NN <novembe...@gmail.com> writes:
>If you use +string without checking , yes it can overwrite unrelated memory, but isnt the onus on the programmer to do that checking ?

Yes, if the programmer uses +STRING, it is. That's why I recommend
not using +STRING.

[dxf...@gmail.com]

On Saturday, February 10, 2018 at 3:12:48 PM UTC+11, Elizabeth D. Rather wrote:
> On 2/9/18 4:12 PM, dxf...@gmail.com wrote:
> ...
> >>> It's not all that's required from a major Forth
> >>> vendor claiming to offer standard compliant
> >>> products to customers and you know it.
> >>>
> >>> If Forth Inc today is saying it only needs to
> >>> support the 200x core wordset then it is a
> >>> strategic decision. Clearly it doesn't see
> >>> minimal support for 200x as affecting its
> >>> business. It still fully supports ANS - which
> >>> no doubt pleases you.
> >>
> >> Supporting the CORE wordset is the basic requirement for any system to
> >> claim to be standard. FORTH, Inc. products support virtually all the
> >> wordsets in 2012 (including, in the current release, the 2012 character
> >> literals and locals syntax).
> >
> > In that case Forth Inc has lost my respect.
> > Pointless change and duplication sends the
> > message Forth doesn't know what it is doing.
>
> LOL, we get beat up for not having a word that we think is unnecessary,
> so we add it and then get beat up for adding it!

There's a line Ricky Nelson wrote which
paraphrased said: 'You can't please everybody,
so you may as well please yourself'.

[Mihail Maksimov]

If it's possible to sell cheap files, programmers will begin
to lay out for sale the result of minor upgrades.
One of these upgrades is the alignment to one of the
Standards, including new ones. In these conditions,
there is no the need for a single standardization.
Standards will compete among themselves in a natural way.
Translations will be made not only between the dialects of the Forth,
but also it will be between any programming languages.

Dmitry Ponyatov wrote:
> Take only two programmers, and theirs Forths will totally differ
This is the result of the lack of incentive to work share

Ilya Tarasov
> He was warned that he needed to follow the rules of our forum, but refused to do it
Where and from what do I refused?

[dxf...@gmail.com]

+STRING doesn't overflow any more than C's strcat
overflows.

> Forth code such as this tends to make the whole Forth community appear to be stupid --- put it in Forth-200x! --- call it the "Standard!" LOL
> This is the Special Olympics of computer programming --- Forth-200x is going for the gold!

I write code for myself. Beginners are welcome to
look elsewhere.

[Anton Ertl]

dxf...@gmail.com writes:
>+STRING doesn't overflow any more than C's strcat
>overflows.

strcat() is a significant source of buffer overflow vulnerabilities,
e.g., CVE-2017-11420 or CVE-2017-9048. At least the Microsoft C
compiler warns that strcat is unsafe when you compile a program that
contains it.

[dxf...@gmail.com]

On Monday, February 12, 2018 at 3:43:52 AM UTC+11, Anton Ertl wrote:
> dxf...@gmail.com writes:
> >+STRING doesn't overflow any more than C's strcat
> >overflows.
>
> strcat() is a significant source of buffer overflow vulnerabilities,
> e.g., CVE-2017-11420 or CVE-2017-9048. At least the Microsoft C
> compiler warns that strcat is unsafe when you compile a program that
> contains it.

Browsing online the only warning for strcat I see
is that the destination should have sufficent
capacity - which is just common sense in
languages that don't hand-hold their users.

Looking at my glossary entry for +STRING I see
I've included the same warning, sad to say.

[Mihail Maksimov]

Hi,
In fact, almost all posts in this topic is auto-peak.
My posts concerning this theme are ignored.
Maybe I'm writing illiterately. I use google translate.
Those who do not agree with me on this theme must have
one of three opinions:
1 In The Forth and so is all right.
2 Forth problem is not an economic
3 the solution to the problem of the Forth is so
disgusting that let there be no the Forth

It is necessary to clarify what is meant by the "Forth" word.
If the term "Forth" means a notation, then one way or another
it will be used but this for me is not interested.
I mean Forth as an opportunity to have greater independence
from suppliers of development tools. This is to use the problem
oriented programming. That is the white box concept.

[m...@iae.nl]

This is not meant in a negative way.
For your information: your posting does not make any sense
to me. The only interesting item I got from it is that
Google thinks that "auto-peak" is an English word that
is somehow related to off-topic.

-marcel

[Robert L.]

On 2/6/2018, dxf...@gmail.com wrote:

> Each has their own way of doing things

"Each" is singular.

Each has his own way of doing things

--
[A] 30-year-old White man ... died in Tacoma ... after being savagely beaten
... by a gang of between 15 and 20 Blacks in what even the local newspapers
described as a "thrill killing." ... [T]he local news media had carefully
avoided reporting a dozen other ... beatings of White men ... during the
previous month. http://archive.org/details/nolies

[Howerd]

On Friday, March 2, 2018 at 1:36:59 AM UTC+1, Robert L. wrote:

> On 2/6/2018, dx.....@gmail.com wrote:
>
> > Each has their own way of doing things
>
> "Each" is singular.
>
> Each has his own way of doing things
>

Hi Robert L.,

I believe that dxf was using the gender-neutral third person singular.

From : https://en.wikipedia.org/wiki/Gender_neutrality_in_English#Pronouns

"Proposed alternatives to the generic he include he or she (or she or he), s/he, or the use of singular they. Each of these alternatives has met with objections. Some feel the use of singular they to be a grammatical error, but according to most references, they, their and them have long been grammatically acceptable as gender-neutral singular pronouns in English, having been used in the singular continuously since the Middle Ages, including by a number of prominent authors, such as Geoffrey Chaucer, William Shakespeare, and Jane Austen.[33] Linguist Steven Pinker goes further and argues that traditional grammar proscriptions regarding the use of singular "they" are themselves incorrect"

I know that it can grate, but if it was OK for Shakespeare, and is OK for Facebook, I'm afraid that we will have to adapt.

Cheers,
Howerd

[a...@littlepinkcloud.invalid]

Howerd <how...@yahoo.co.uk> wrote:
>
> I know that [singular they] can grate, but if it was OK for

> Shakespeare, and is OK for Facebook,

... and the divine Jane. Please don't forget Jane! :-)

> I'm afraid that we will have to adapt.

Indeed.

Andrew.

[Robert L.]

On 2/11/2018, dxf...@gmail.com wrote:

> On Monday, February 12, 2018 at 3:43:52 AM UTC+11, Anton Ertl wrote:
> > dxf...@gmail.com writes:
> > > +STRING doesn't overflow any more than C's strcat
> > > overflows.
> >
> > strcat() is a significant source of buffer overflow vulnerabilities,
> > e.g., CVE-2017-11420 or CVE-2017-9048. At least the Microsoft C
> > compiler warns that strcat is unsafe when you compile a program that
> > contains it.
>
> Browsing online the only warning for strcat I see
> is that the destination should have sufficent
> capacity - which is just common sense in
> languages that don't hand-hold their users.

This disparaging remark reminds me that the
primitive mind isn't comfortable with languages that
are at a higher level than C or Forth.

--
Goyim were born only to serve us. Without that, they have no place in the
world---only to serve the People of Israel.... They will work, they will plow,
they will reap. We will sit like an effendi and eat. --- Rabbi Ovadia Yosef
web.archive.org/web/20101020044210/http://www.jpost.com/JewishWorld/JewishNews/Article.aspx?id=191782
http://archive.org/details/nolies

[Robert L.]

On 2/8/2018, dxf...@gmail.com wrote:

> On Thursday, February 8, 2018 at 3:04:04 AM UTC+11, Anton Ertl wrote:

> > Paul Rubin <no.e...@nospam.invalid> writes:
> > > I found a definition
> > > of +STRING in one of the threads:
> > >
> > > : +STRING ( a1 u1 a2 u2 -- a2 u3 )
> >

> > That's an error-prone stack effect, because it means that the caller
> > must check that U1+U2 fits into the buffer at a2. If the caller does
> > this checking (why burden him with that?), there's a good chance that
> > the checking code contains a bug; in that case, or if the checking is
> > not done, there is a good chance that the result has a buffer overflow
> > vulnerability.
>
> +STRING is unashamedly a primitive. Use directly
> or in higher level functions CAPPEND ZAPPEND etc
> with error checking if needed.

The primitive mind is comfortable only with
primitive functions.

--
Black Panther Quanell X ... blamed the 11-year-old girl for being raped by 28
black males. http://archive.org/details/nolies
What I would most desire would be the separation of the white and black
races. --- A. Lincoln, July 17, 1858

[Mihail Maksimov]

On Saturday, February 24, 2018 at 3:07:53 PM UTC+3, m...@iae.nl wrote:

> This is not meant in a negative way.
> For your information: your posting does not make any sense
> to me.

I wrote about the Fort problem on the Fort forum.
I thought the topic would be interestingю. Or is there no this problem?
Is the whole problem in string concatenation?

[Jan Coombs]

This demonstrates well the problem the problem noted by Marcel.

Have you tried closing the loop by translating back and seeing
what happens?

I've just come back from Spain, and did not use google
translate, which is a known source of amusement, especially for
technical subjects. We used bi-language dictionaries, and
sometimes closed the loop to make sure. Also phrase books to
help with grammar.

Jan Coombs

[Howerd]

On Friday, 2 March 2018 09:57:48 UTC+1, a...@littlepinkcloud.invalid wrote:

Hi Andrew,

Prithee f'rgive mine own f'rgetfulness, i didst not cullionly to offendeth by omitting jane and geoffrey.
Is this did allow in a f'rth usenet group?

che'rs,
Howerd ;-)

[Brad Eckert]

On Saturday, February 10, 2018 at 12:38:17 AM UTC-7, Elizabeth D. Rather wrote:
>
> The alternative view is that the Forth 2012 additions are more minor
> tweaks than major enhancements. Having an officially recognized standard
> was an achievement. It's important to keep evaluating and tweaking it,
> but a tweak is a tweak.
>

Another view is 2012 as a documentation standard. An application that uses new words from the 2012 standard has an automatic documentation source. The typical use case takes only a few features from 2012, which are simple enough for DIY. Vendors implement 2012 as a courtesy.