A quick survey: Which flavor of Forth are you using?

[lsng....@gmail.com]

I don't intend to start a flame war. But I think I just might.

I just want to know which flavor of Forth has the biggest number of users and which one is growing fastest.

Thank you very much.

[lsng....@gmail.com]

> But I think I just might.

might ==> did

[Helmar Wodtke]

I use basically my own Forth(s). If I write something in ANS, I compare basically to gforth (the version that comes with the Linux-distro) and what is flying around and claims to be ANS-compliant.
I use my own Forths since the 80's - at that time I had not the resources for a Forth cartridge for my Z9001, so I wrote an own...

Regards,
-Helmar

[Lars Brinkhoff]

> I just want to know which flavor of Forth has the biggest number of
> users and which one is growing fastest.

These are my vague impressions:

- Many people are rolling their own.

- SwiftForth and VFX Forth probably have a decent number of users,
or else they'd go out of business.

- Gforth is often mentioned among Linux users.

- SP-Forth is popular in Russia.

- Open Firmware is used to boot many computers.

- Mecrip is popular with some microcontrollers.

- The CamelForth forum indicates there are some users.

- eForth has been widely ported, but I rarely see it mentioned except
for stm8ef.

[c...@forthworks.com]

I use my own implementation. I suspect it does have a fair number of
users, though I can't be very precise. (For privacy reasons, I don't
track http or gopher requests, so can't track downloads, visits, etc).
I do have a little information from the commercial variants (for iOS and
macOS):

Since Q4 2014 there have been 499 sales of my Forth systems on iOS and
6 on macOS. (The macOS version was only released about a week ago).

The macOS version is also available apart from the App Store; I don't
have any statistics on downloads for that.

-- crc

[Mark Humphries]

>A quick survey: Which flavor of Forth are you using?

Homegrown.

[Cecil Bayona]

I use a variety of Forths, everything is in flux right now but I'm
trying to settle down on the choices and eliminate some.

For the desktop I mostly Use VFX and SwiftForth while also using Windows
eForth for cross compilers for embedded targets, since lately I been
working with embedded targets eForth has been used quite a bit. Throw
into the mix 8th for writing more complex Windows tools

For embedded CPUs hosting a local Forth, eForth is the most often used
embedded Forth mostly on FPGA targets with meCrisp on some CPUs mainly
the MSP430 and ARM. For those two CPUs I am planning on switching to VFX
cross compilers instead.

Currently I'm slowly working on my own Forth written in Go to be a
replacement for eForth on Windows due to not having the source code to
eForth. That has been slow going as I have been sick lately with fluid
in the lungs for which doctors have not found the cause yet so the
fluids have been reduced but not eliminated.

I been debating aborting the Go project and use VFX for Windows to
create an cross-compiler for embedded targets. It would be faster but
eForth has the advantage of being available on a lot of targets.

Too many tools gets a little confusing so I'm hoping to cut down on the
number of tools used by late next year. Whatever the outcome my goal
will be to cut down the various tools used to a few simple and reliable
choices.

--
Cecil - k5nwa

[Elizabeth D. Rather]

This is a pretty good answer, though I must note that both FORTH, Inc.
and MPE support interactive cross-compilers for microcontrollers as well.

The problem is that clf is not representative of most professional Forth
users. FORTH, Inc. has a large numbers of users that we are in regular
touch with who are never here. When we occasionally ask if they ever
look in on clf, they say that they are too busy, and too focused on the
projects for which they are being paid. A great deal of the discussion
here revolves around possible changes to the language; professional
users are mainly concerned with using the tools they have in the
projects they're working on. How many professional C programmers do you
know who spend their time discussing how C should be changed?

Cheers,
Elizabeth

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

[NN]

win32forth

NN

[Andreas Klimas]

Am 08.12.17 um 10:16 schrieb lsng....@gmail.com:

> I don't intend to start a flame war. But I think I just might.
>
> I just want to know which flavor of Forth has the biggest number of users and which one is growing fastest.
>
> Thank you very much.
>

SwiftForth for pure FORTH related work (Mac, Linux, Windows).

My own FORTH written in JavaScript running as independent Operating
System inside a WebBrowser.

[rickman]

Win32Forth for desktop work. I use it to control a test fixture.

Mecrisp on ARMs and MSP430s for embedded work. Currently I'm programming a
device to measure battery capacity and solar cells.

--

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

[hughag...@gmail.com]

On Friday, December 8, 2017 at 9:46:30 AM UTC-7, Mark Humphries wrote:
> >A quick survey: Which flavor of Forth are you using?
>
> Homegrown.

I wrote MFX when I was employed at Testra. This targeted their MiniForth processor built on a Lattice isp1048 PLD.
The MiniForth has since been upgraded to the RACE built on an FPGA and MFX continues to be used.

AFAIK, there are only two MFX programmers in the world, which are myself and my coworker at Testra.
AFAIK, the MiniForth and RACE have only been used for one program, which is the motion-control program used in all of Testra's motion-control boards.

By Liang's standards, MFX is a total failure because there are only two MFX users and one of them (myself) hasn't used MFX in over 20 years.

The point that I'm making is that "usefulness" and "popularity" are not the same thing.
Elizabeth Rather considers herself to be a big success because she has a lot of sycophants --- John Passaniti, Julien Fondren, Alex McDonald, Rick Collins, etc.
By comparison, she considers me to be a big failure because I don't have any sycophants --- I don't want sycophants, so I never will have any.
I'm proud of MFX --- the ANS-Forth cult can hate me for that, and I don't care --- Forth programming is not a Miss America contest that measures popularity.

[jo...@planet.nl]

On:
PC: Win32Forth
rPi: Gforth

Jos

[dxf...@gmail.com]

On Saturday, December 9, 2017 at 5:40:57 AM UTC+11, Elizabeth D. Rather wrote:
>
> [...]

> This is a pretty good answer, though I must note that both FORTH, Inc.
> and MPE support interactive cross-compilers for microcontrollers as well.
>
> The problem is that clf is not representative of most professional Forth
> users. FORTH, Inc. has a large numbers of users that we are in regular
> touch with who are never here. When we occasionally ask if they ever
> look in on clf, they say that they are too busy, and too focused on the
> projects for which they are being paid. A great deal of the discussion
> here revolves around possible changes to the language; professional
> users are mainly concerned with using the tools they have in the
> projects they're working on. How many professional C programmers do you
> know who spend their time discussing how C should be changed?
>
> Cheers,
> Elizabeth
>
> --
> Elizabeth D. Rather
> FORTH, Inc.
> 6080 Center Drive, Suite 600
> Los Angeles, CA 90045
> USA

Yet it is c.l.f that has been driving 200x.
Commercial users - who have more at stake than
anyone - have been conspicuous by their absence.
When you can't get commercial users, regardless
of how many may still exist, to take an interest,
then who exactly are you doing it for. I doubt
anyone knows.

[a...@littlepinkcloud.invalid]

dxf...@gmail.com wrote:
> On Saturday, December 9, 2017 at 5:40:57 AM UTC+11, Elizabeth D. Rather wrote:
>>
>> [...]
>> This is a pretty good answer, though I must note that both FORTH, Inc.
>> and MPE support interactive cross-compilers for microcontrollers as well.
>>
>> The problem is that clf is not representative of most professional
>> Forth users. FORTH, Inc. has a large numbers of users that we are
>> in regular touch with who are never here. When we occasionally ask
>> if they ever look in on clf, they say that they are too busy, and
>> too focused on the projects for which they are being paid. A great
>> deal of the discussion here revolves around possible changes to the
>> language; professional users are mainly concerned with using the
>> tools they have in the projects they're working on. How many
>> professional C programmers do you know who spend their time
>> discussing how C should be changed?
>

> Yet it is c.l.f that has been driving 200x. Commercial users - who
> have more at stake than anyone - have been conspicuous by their
> absence. When you can't get commercial users, regardless of how
> many may still exist, to take an interest, then who exactly are you
> doing it for. I doubt anyone knows.

These users' needs are in the main represented on the standard
committee by MPE and Forth, Inc. They talk to their customers, of
course, and have a pretty good idea of what they need. I don't blame
any professional users for avoiding the ugliness that we see in this
newsroup.

Andrew.

[Elizabeth D. Rather]

For the most part, at least the ones I'm in contact with are in the "if
it ain't broke, don't fix it" camp. They don't see much value in the
issues being debated. I can't speak for him, but I suspect that the
reason Leon participates is to try to minimize breakage.

[Alex]

On 09-Dec-17 22:08, Elizabeth D. Rather wrote:
> On 12/9/17 3:21 AM, dxf...@gmail.com wrote:
>> On Saturday, December 9, 2017 at 5:40:57 AM UTC+11, Elizabeth D.
>> Rather wrote:
>>>
>>> [...]
>>> This is a pretty good answer, though I must note that both FORTH, Inc.
>>> and MPE support interactive cross-compilers for microcontrollers as
>>> well.
>>>
>>> The problem is that clf is not representative of most professional Forth
>>> users. FORTH, Inc. has a large numbers of users that we are in regular
>>> touch with who are never here. When we occasionally ask if they ever
>>> look in on clf, they say that they are too busy, and too focused on the
>>> projects for which they are being paid. A great deal of the discussion
>>> here revolves around possible changes to the language; professional
>>> users are mainly concerned with using the tools they have in the
>>> projects they're working on. How many professional C programmers do you
>>> know who spend their time discussing how C should be changed?

http://www.open-std.org/jtc1/sc22/wg14/. Or, if it's C++ you're
tracking, http://www.open-std.org/jtc1/sc22/wg21/. The parent list;
http://www.open-std.org/jtc1/sc22/ (note the fasttrack Forth reference).

This "professional users of X aren't interested in X development" is, to
be frank, complete nonsense. Do you honestly believe that users want
tools & language facilities they had 40 years ago? 20? 10? If you think
the answer's yes, you've become completely disengaged from this industry.

I, for one, am tired of hearing this. It's complete garbage.

>>>
>>> Cheers,
>>> Elizabeth
>>>
>>> --
>>> Elizabeth D. Rather
>>> FORTH, Inc.
>>> 6080 Center Drive, Suite 600
>>> Los Angeles, CA  90045
>>> USA
>>
>> Yet it is c.l.f that has been driving 200x.

Uh, really? I think it lags what the Forth200x folks are doing. That may
explain your lack of understanding.

>> Commercial users - who have more at stake than
>> anyone - have been conspicuous by their absence.

Both major Forth vendors are represented. Users don't tend to have or
want representation; but they do want modern, sharp tools.

>> When you can't get commercial users, regardless
>> of how many may still exist, to take an interest,
>> then who exactly are you doing it for. I doubt
>> anyone knows.

You certainly don't.

>>
>
> For the most part, at least the ones I'm in contact with are in the "if
> it ain't broke, don't fix it" camp. They don't see much value in the
> issues being debated. I can't speak for him, but I suspect that the
> reason Leon participates is to try to minimize breakage.

Ah, that's *so* not what participation should be about. Is that why
Stephen Pelc is there? I doubt it. This is the way to stifle innovation,
which you may consider to be a worthy goal. It's not.

>
> Cheers,
> Elizabeth
>


--
Alex

[Elizabeth D. Rather]

Oh, things have developed quite a lot, and development continues.
SwiftForth and SwiftX have developed far beyond the older systems from
FORTH, Inc., and (like any company that wants to stay in business)
improvements continue. But they involve things like support for more
processors and interfaces, better performance, better development tools,
etc. We are in pretty close touch with our user (and often work along
side them on projects, doing system adaptations while they handle the
application-specific programming. What we *don't* see is interest in
things like recognizers, whizzier locals, and stuff like that, which is
why we haven't implemented some of these things.

As Andrew has pointed out, we represent the interests, needs, and
concerns of our users as well as our own experience. Innovation is a
good thing if it increases users' ability to do their jobs, which is the
kind we focus on. It is *not* about breaking existing code to add a
whizzy feature from the language of the month, which is what a lot of
the stuff proposed here seems to be.

[a...@littlepinkcloud.invalid]

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

> For the most part, at least the ones I'm in contact with are in the "if
> it ain't broke, don't fix it" camp. They don't see much value in the
> issues being debated. I can't speak for him, but I suspect that the
> reason Leon participates is to try to minimize breakage.

I don't speak for him either, but I'm pretty sure that's not the omly
reason, even though it's surely a very big part of it.

Andrew.

[Marcos Cruz]

En/Je/On 2017-12-08, lsng....@gmail.com <lsng....@gmail.com>
escribió/skribis/wrote:

> I just want to know which flavor of Forth has the biggest number of
> users and which one is growing fastest.

- On GNU/Linux: Gforth. In the past I used also lina, SP-Forth and
others for some projects, until I moved from Intel to ARM.

- On ZX Spectrum 128 and compatible machines: my Solo Forth
(http://programandala.net/en.program.solo_forth.html).

[menti...@gmail.com]

I use an old version of Win32Forth,
but I am thinking of moving to a 64-bit Forth.

Meanwhile, MindForth is surging ahead in a
Strawberry Perl Five version called ghost.pl AI.
I am trying to keep the Forth and Perl AI Minds
roughly on a par as the same program in two
programming languages. In recent months the
ghost.pl Perlmind has surged far ahead of the
Forthmind -- which will eventually catch up.

As I continue to promote MindForth for robots,

http://ai.neocities.org/maintainer.html

is a page where I describe the beginning of
a new career path in computer technology,
similar in 24/7 shift requirements to the
work of a nuclear power plant operator.

Imagine powerful AI Minds in Forth and Perl
requiring constant human oversight, lest
the emerging Superintelligence run amok
and become the fabled Skynet or Colossus.

The ghost.pl AI, and soon also the Forth AI,
is like a Mind-in-a-Box, constantly thinking
and calling out occasionally to nearby humans:
TEACH ME SOMETHING!

Arthur
--
http://cyborg.blogspot.com
http://www.reddit.com/r/mentifex
http://wiki.opencog.org/wikihome/index.php/Ghost
http://trollheaven.wordpress.com/2017/12/04/introduction-to-mindforth

[Mark Wills]

TurboForth from TurboForth.net

[David Schultz]

On 12/08/2017 03:39 AM, Lars Brinkhoff wrote:
> - eForth has been widely ported, but I rarely see it mentioned except
> for stm8ef.
>

ARM eForth: http://home.earthlink.net/~schultdw/logger/TeensyLog.html

I also use eForth on the MSP430FR.


--
David W. Schultz
http://home.earthlink.net/~david.schultz

[lsng....@gmail.com]

Your answer sounds very interesting.

I have my own roadmap, "probably" same goal as yours.

https://www.linkedin.com/pulse/end-manual-programming-make-america-free-great-again-ng-ph-d-/

Do you have a PLAN? i.e. When to do what? Who? How? (Management by Objectives)

[Ron Aaron]

8th (https://8th-dev.com)

[Lars Brinkhoff]

David Schultz wrote:
> Lars Brinkhoff wrote:
>> - eForth has been widely ported, but I rarely see it mentioned except
>> for stm8ef.
> ARM eForth: http://home.earthlink.net/~schultdw/logger/TeensyLog.html
> I also use eForth on the MSP430FR.

Thanks, glad to hear it!

[Rob Sciuk]

On Fri, 8 Dec 2017, lsng....@gmail.com wrote:

> Date: Fri, 8 Dec 2017 01:16:06 -0800 (PST)
> From: lsng....@gmail.com
> Newsgroups: comp.lang.forth
> Subject: A quick survey: Which flavor of Forth are you using?

>
> I don't intend to start a flame war. But I think I just might.
>

> I just want to know which flavor of Forth has the biggest number of users and which one is growing fastest.
>

> Thank you very much.
>

A SMALL C based Forth, runs on DOS, Linux, BSD, and native on ARM
with ESP32 native and RISC-V in the works ...

OneFileForth: https://github.com/paraplegic/OneFileForth

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>On 12/9/17 12:37 PM, Alex wrote:
>> On 09-Dec-17 22:08, Elizabeth D. Rather wrote:
>>> On 12/9/17 3:21 AM, dxf...@gmail.com wrote:

[...]

>What we *don't* see is interest in
>things like recognizers, whizzier locals, and stuff like that, which is
>why we haven't implemented some of these things.

Then SwiftForth must have gotten NUMBER-CONVERSION by divine
intervention. That is an extensible recognizer mechanism, and not too
far away from the current proposal.

>>>> Commercial users - who have more at stake than
>>>> anyone - have been conspicuous by their absence.
>>
>> Both major Forth vendors are represented. Users don't tend to have or
>> want representation; but they do want modern, sharp tools.

Actually CCS (a commercial user) has been represented in IIRC all
meetings, and Micross (a commercial user) has been represented in the
first meetings, but apparently feels sufficiently represented by MPE
(their Forth system vendor) that Micross no longer participates.

However, my impression was that the presence of the customers helped
the standards process in at least one case: When I started talking
about xchars and shifting focus from characters to strings, the first
reaction from Stephen Pelc (MPE) was a rejection of the idea. Then,
AFAIK the customers (in particular Micross) told him that they use
strings for internationalized stuff all the time, and Stephen Pelc
embraced the idea.

>It is *not* about breaking existing code to add a
>whizzy feature from the language of the month, which is what a lot of
>the stuff proposed here seems to be.

Such as what?

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

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>>On 12/9/17 12:37 PM, Alex wrote:
>>> On 09-Dec-17 22:08, Elizabeth D. Rather wrote:
>>>> On 12/9/17 3:21 AM, dxf...@gmail.com wrote:
> [...]
>>What we *don't* see is interest in things like recognizers, whizzier
>>locals, and stuff like that, which is why we haven't implemented
>>some of these things.
>
> Then SwiftForth must have gotten NUMBER-CONVERSION by divine
> intervention. That is an extensible recognizer mechanism, and not
> too far away from the current proposal.

NUMBER-CONVERSION is a simple extensible mechanism with very few of
the bells, whistles, and curlicues of the recognizer proposal. Yes,
it can do some of the same things as recognizers. But a main battle
tank, while it can be used to get the groceries from the supermarket,
is not the same kind of thing as a small car. NUMBER-CONVERSION does
precisely what is needed and no more.

Andrew.

[Alex]

A howitzer makes too large a hole but a small drill is perfect for our
needs. This is woodwork, not warfare!

All we need do is leave it to the reader's imagination how many lines of
code it takes to specify a howitzer, how difficult it must be to handle,
and what you might do if it went off in your face while you were simply
looking at it. But a drill; it's doing just the job we asked for, and
look at how neat it is; there must be much less to it and boy, just so
much safer than a howitzer. Job done, point made.

If you think that's a terrible analogy, I have others. How about one
where we go groceries shopping with a tank vs a small car?

--
Alex

[gavino himself]

On Friday, December 8, 2017 at 4:16:08 AM UTC-5, lsng....@gmail.com wrote:
> I don't intend to start a flame war. But I think I just might.
>
> I just want to know which flavor of Forth has the biggest number of users and which one is growing fastest.
>
> Thank you very much.

gforth of course

[Elizabeth D. Rather]

On 12/12/17 6:08 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> On 12/9/17 12:37 PM, Alex wrote:
>>> On 09-Dec-17 22:08, Elizabeth D. Rather wrote:
>>>> On 12/9/17 3:21 AM, dxf...@gmail.com wrote:
> [...]
>> What we *don't* see is interest in
>> things like recognizers, whizzier locals, and stuff like that, which is
>> why we haven't implemented some of these things.
>
> Then SwiftForth must have gotten NUMBER-CONVERSION by divine
> intervention. That is an extensible recognizer mechanism, and not too
> far away from the current proposal.

You recently criticized FORTH, Inc. for not staying completely current
with 20xx.

>>>>> Commercial users - who have more at stake than
>>>>> anyone - have been conspicuous by their absence.
>>>
>>> Both major Forth vendors are represented. Users don't tend to have or
>>> want representation; but they do want modern, sharp tools.
>
> Actually CCS (a commercial user) has been represented in IIRC all
> meetings, and Micross (a commercial user) has been represented in the
> first meetings, but apparently feels sufficiently represented by MPE
> (their Forth system vendor) that Micross no longer participates.
>
> However, my impression was that the presence of the customers helped
> the standards process in at least one case: When I started talking
> about xchars and shifting focus from characters to strings, the first
> reaction from Stephen Pelc (MPE) was a rejection of the idea. Then,
> AFAIK the customers (in particular Micross) told him that they use
> strings for internationalized stuff all the time, and Stephen Pelc
> embraced the idea.

I agree that customers are valuable in the standards process; we
certainly found them to be during the ANS process. I was merely
attempting to explain why there aren't so many currently.

>> It is *not* about breaking existing code to add a
>> whizzy feature from the language of the month, which is what a lot of
>> the stuff proposed here seems to be.
>
> Such as what?

Well, recent suggestions to eliminate S" and the R words.

[a...@littlepinkcloud.invalid]

Alex <al...@rivadpm.com> wrote:
> On 13-Dec-17 11:44, a...@littlepinkcloud.invalid wrote:
>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>> On 12/9/17 12:37 PM, Alex wrote:
>>>>> On 09-Dec-17 22:08, Elizabeth D. Rather wrote:
>>>>>> On 12/9/17 3:21 AM, dxf...@gmail.com wrote:
>>> [...]
>>>> What we *don't* see is interest in things like recognizers, whizzier
>>>> locals, and stuff like that, which is why we haven't implemented
>>>> some of these things.
>>>
>>> Then SwiftForth must have gotten NUMBER-CONVERSION by divine
>>> intervention. That is an extensible recognizer mechanism, and not
>>> too far away from the current proposal.
>>
>> NUMBER-CONVERSION is a simple extensible mechanism with very few of
>> the bells, whistles, and curlicues of the recognizer proposal. Yes,
>> it can do some of the same things as recognizers. But a main battle
>> tank, while it can be used to get the groceries from the supermarket,
>> is not the same kind of thing as a small car. NUMBER-CONVERSION does
>> precisely what is needed and no more.
>

> A howitzer makes too large a hole but a small drill is perfect for our
> needs. This is woodwork, not warfare!
>
> All we need do is leave it to the reader's imagination how many
> lines of code it takes to specify a howitzer, how difficult it must
> be to handle, and what you might do if it went off in your face
> while you were simply looking at it. But a drill; it's doing just
> the job we asked for, and look at how neat it is; there must be much
> less to it and boy, just so much safer than a howitzer. Job done,
> point made.

Quite so.

> If you think that's a terrible analogy, I have others. How about one
> where we go groceries shopping with a tank vs a small car?

Pardon? You've lost me. What is your point?

Andrew.

[Alex]

It appears you liked my analogy, and hence my sarcasm about having one
exactly like yours was lost.

I don't find analogies like the one you employed useful, since they are
meta descriptions and they tend to generate meta facts and meta passions.

Please describe "the bells, whistles, and curlicues" that the recognizer
proposal has over the SwiftForth approach, something I have not seen
discussed here. The we can discuss the relative merits of each without
having to argue about whether the car is easier to drive & has lower
fuel consumption vs the tank allowing you force your way to the front of
the checkout queue.

What does SwiftForth's NUMBER-CONVERSION do, what does it allow, and how
dos that compare with recognizers?

--
Alex

[a...@littlepinkcloud.invalid]

Alex <al...@rivadpm.com> wrote:
>
> It appears you liked my analogy, and hence my sarcasm about having one
> exactly like yours was lost.

It was essentially the same analogy.

> I don't find analogies like the one you employed useful, since they
> are meta descriptions and they tend to generate meta facts and meta
> passions.

It was in response to Anton's suggestion that because Forth Inc had an
extensible numeric converter that they already, in effect, had the
recognizer proposal. That is a nonsensical argument: to make it is to
deny that a quantitative difference, if sufficiently great, can make a
qualitative one.

> Please describe "the bells, whistles, and curlicues"

I believe they're quite adequately described in the proposal. As it
stood last time I read it, it was a disproportionate response to the
problem of extending number conversion. It has features which are
irrelevant to number conversion and because of that it is clumsy in
use. It is now a general-purpose mechanism for language extension
which, as far as I am aware, has little application need.

I know how it happens: you start with something that looks promising,
and over time people say "Hmm, look, if we add this the we can do all
these other things too." Wouldn't It Be Nice Ifs, or WIBNIs.

> that the recognizer proposal has over the SwiftForth approach,
> something I have not seen discussed here. The we can discuss the
> relative merits of each without having to argue about whether the
> car is easier to drive & has lower fuel consumption vs the tank
> allowing you force your way to the front of the checkout queue.
>
> What does SwiftForth's NUMBER-CONVERSION do, what does it allow, and how
> dos that compare with recognizers?

Have a look. It's a mechanism that passes a string to each
"recognizer" in turn, which places the result of the conversion
somewhere unknown to the interpreter. The "recognizer" returns a flag
to indicate success and an XT representing a compile action, which
will be executed by the interpreter if in compile state. That's
pretty much all it does. There is no POSTPONE or interpret action and
no suggestion of making any changes to the interpreter itself, so it's
truly an optional extra rather than something which affects the core
of Forth.

Andrew.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>On 12/12/17 6:08 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>> On 12/9/17 12:37 PM, Alex wrote:
>>>> On 09-Dec-17 22:08, Elizabeth D. Rather wrote:
>>>>> On 12/9/17 3:21 AM, dxf...@gmail.com wrote:
>> [...]
>>> What we *don't* see is interest in
>>> things like recognizers, whizzier locals, and stuff like that, which is
>>> why we haven't implemented some of these things.
>>
>> Then SwiftForth must have gotten NUMBER-CONVERSION by divine
>> intervention. That is an extensible recognizer mechanism, and not too
>> far away from the current proposal.
>
>You recently criticized FORTH, Inc. for not staying completely current
>with 20xx.

Did I? But even assuming I did, I fail to see what this has to do
with the question of who implemented NUMBER-CONVERSION in SwiftForth
and why.

>>> It is *not* about breaking existing code to add a
>>> whizzy feature from the language of the month, which is what a lot of
>>> the stuff proposed here seems to be.
>>
>> Such as what?
>
>Well, recent suggestions to eliminate S" and the R words.

Eliminating S" and the R words is a "whizzy feature" from which
"language of the month"?

It is not necessary to use hyperbole to point to your lack of
technical arguments, the absence of technical arguments speaks for
itself.

[Anton Ertl]

It is not necessary to use hyperbole to point to your lack of
technical arguments, the absence of technical arguments speaks for
itself.

I have needed stuff like

1 postpone literal
s" bla" postpone sliteral
1e postpone fliteral

: ->this to this ;
... postpone ->this ...

and similar stuff a lot over the years. With recognizers and an
enhanced POSTPONE, I can write the same as

postpone 1
postpone "bla"
postpone 1e
postpone ->this

Alternatively, with ]] ... [[ instead of (or in addition to) the
enhanced POSTPONE:

]] 1 [[
]] "bla" [[
]] 1e [[
]] ->this [[

Sure, I can work around the absence of these features, as shown above,
so in some sense, being able to do that is not necessary. But
likewise, instead of writing

1e

in a colon definition, one could write

1 s>f

(and yes, I have done that to work around a lack in some FP packages of
one vendor), or

[ 1e ] fliteral

(the NUMBER-CONVERSION words would be simpler if they did not support
compiling the numbers), or

[f#] 1

(no need for NUMBER-CONVERSION or any other recognizer mechanism at
all, and no STATE-smart word, either).

So, yes, NUMBER-CONVERSION has a few features less. Whether these
features are "bells, whistles, and curlicues" or "precisely what is
needed and no more" is purely subjective. One can work around the
absence of proposed-recognizer features that NUMBER-CONVERSION does
not support (but that I use if I have them), but one could also work
around the absence of all NUMBER-CONVERSION features.

[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:
>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>>On 12/9/17 12:37 PM, Alex wrote:
>>>>> On 09-Dec-17 22:08, Elizabeth D. Rather wrote:
>>>>>> On 12/9/17 3:21 AM, dxf...@gmail.com wrote:
>>> [...]
>>>>What we *don't* see is interest in things like recognizers, whizzier
>>>>locals, and stuff like that, which is why we haven't implemented
>>>>some of these things.
>>>
>>> Then SwiftForth must have gotten NUMBER-CONVERSION by divine
>>> intervention. That is an extensible recognizer mechanism, and not
>>> too far away from the current proposal.
>>
>>NUMBER-CONVERSION is a simple extensible mechanism with very few of
>>the bells, whistles, and curlicues of the recognizer proposal. Yes,
>>it can do some of the same things as recognizers. But a main battle
>>tank, while it can be used to get the groceries from the supermarket,
>>is not the same kind of thing as a small car. NUMBER-CONVERSION does
>>precisely what is needed and no more.
>
> It is not necessary to use hyperbole to point to your lack of
> technical arguments, the absence of technical arguments speaks for
> itself.

LOL! Great opening sentence! Let's see what the rest looks like.

> I have needed stuff like

> ...

> Sure, I can work around the absence of these features, as shown above,
> so in some sense, being able to do that is not necessary.

Yes, yes, I know. But that explanation in no way supports your
contention that the SwiftForth NUMBER-CONVERSION mechanism is not too
far from the current proposal.

> So, yes, NUMBER-CONVERSION has a few features less. Whether these
> features are "bells, whistles, and curlicues" or "precisely what is
> needed and no more" is purely subjective.

Language will always be to a large extent subjective. It is such
subjective issues that make Forth distinct from other programming
languages. "De gustibus non disputandum est" is the cliche
traditionally used when one wants to avoid discussing them, but in
programming language design they really can't be avoided.

> One can work around the absence of proposed-recognizer features that
> NUMBER-CONVERSION does not support (but that I use if I have them),
> but one could also work around the absence of all NUMBER-CONVERSION
> features.

Indeed one could.

Andrew.

[The Beez]

On Friday, December 8, 2017 at 10:27:11 AM UTC+1, Helmar Wodtke wrote:

> I use basically my own Forth(s). If I write something in ANS, I compare basically to gforth (the version that comes with the Linux-distro) and what is flying around and claims to be ANS-compliant.

Ditto. Only, I use my own 4tH. I can use it on any platform. And I tend to recompile newer versions of Gforth, though.

Hans Bezemer

[Anton Ertl]

a...@littlepinkcloud.invalid writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

>> a...@littlepinkcloud.invalid writes:
>>>NUMBER-CONVERSION is a simple extensible mechanism with very few of
>>>the bells, whistles, and curlicues of the recognizer proposal. Yes,
>>>it can do some of the same things as recognizers. But a main battle
>>>tank, while it can be used to get the groceries from the supermarket,
>>>is not the same kind of thing as a small car. NUMBER-CONVERSION does
>>>precisely what is needed and no more.

[Andrew snipped the demonstration of the use of the additional
features of the recognizer proposal]

>> Sure, I can work around the absence of these features, as shown above,
>> so in some sense, being able to do that is not necessary.
>
>Yes, yes, I know. But that explanation in no way supports your
>contention that the SwiftForth NUMBER-CONVERSION mechanism is not too
>far from the current proposal.

Right, you did not dispute the similarity except pointing out in a
long-winded and colourful way that the recognizer proposal has more
features (I concede that), and claiming that these features are
unnecessary. So I demonstrated that I make actual use of these
additional features when I have them; so for me they are not
unnecessary.

Since you like it colourful: At the last EuroForth you learned that
Emperor Franz Josef resisted the installation of a flush toilet.
After all, the chamber pot does precisely what is needed, and no more,
with very few of the bells, whistles, and curlicues of a flush toilet.
And yet, I think even the minimalists in the Forth community prefer
flush toilets over chamber pots when they have the choice.

Anyway, I think the similarities between NUMBER-CONVERSION and the
recognizer proposal are obvious, but I am prepared to explain them to
you if you want.

>"De gustibus non disputandum est" is the cliche
>traditionally used when one wants to avoid discussing them, but in
>programming language design they really can't be avoided.

In that case, discuss them, instead of demonstrating your debate club
skills by writing about curlicues, main battle tanks, and making
unsupported claims about "precisely what is needed and no more".

[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:
>>> a...@littlepinkcloud.invalid writes:
>>>>NUMBER-CONVERSION is a simple extensible mechanism with very few of
>>>>the bells, whistles, and curlicues of the recognizer proposal. Yes,
>>>>it can do some of the same things as recognizers. But a main battle
>>>>tank, while it can be used to get the groceries from the supermarket,
>>>>is not the same kind of thing as a small car. NUMBER-CONVERSION does
>>>>precisely what is needed and no more.
>
> [Andrew snipped the demonstration of the use of the additional
> features of the recognizer proposal]
>
>>> Sure, I can work around the absence of these features, as shown above,
>>> so in some sense, being able to do that is not necessary.
>>
>>Yes, yes, I know. But that explanation in no way supports your
>>contention that the SwiftForth NUMBER-CONVERSION mechanism is not too
>>far from the current proposal.
>
> Right, you did not dispute the similarity except pointing out in a
> long-winded and colourful way that the recognizer proposal has more
> features (I concede that),

The additional features are what separate the recognizer proposal and
the SwiftForth NUMBER-CONVERSION mechanism. Your view is that these
mechanisms are not too far apart. I disagree because, as I said, the
difference in scope and complexity is important.

> and claiming that these features are unnecessary.

I claim that the additional features are unnecessary to do the job
that NUMBER-CONVERSION does.

> So I demonstrated that I make actual use of these additional
> features when I have them; so for me they are not unnecessary.

I believe you. They are necessary if one wants to program in the way
that you do. But they are unnecessary for literal number conversion.

> Since you like it colourful: At the last EuroForth you learned that
> Emperor Franz Josef resisted the installation of a flush toilet.
> After all, the chamber pot does precisely what is needed, and no more,
> with very few of the bells, whistles, and curlicues of a flush toilet.
> And yet, I think even the minimalists in the Forth community prefer
> flush toilets over chamber pots when they have the choice.

I'm sure.

> Anyway, I think the similarities between NUMBER-CONVERSION and the
> recognizer proposal are obvious, but I am prepared to explain them to
> you if you want.

Yes, they are obvious, as are the similarities between a tank and a
car.

>>"De gustibus non disputandum est" is the cliche traditionally used
>>when one wants to avoid discussing them, but in programming language
>>design they really can't be avoided.
>
> In that case, discuss them, instead of demonstrating your debate
> club skills by writing about curlicues, main battle tanks, and
> making unsupported claims about "precisely what is needed and no
> more".

My claim about "precisely what is needed and no more" refers to the
requirement of literal number conversion. The additional features of
the recognizer proposal are not necessary to do that.

I don't dispute that an extensible literal is useful. Any claim that
the additional features of the recognizer proposal are sufficiently
useful to justify standardization is up to its proponents to support.
I don't doubt that you can come up with many examples, and we have
seen some on this list.

Andrew.

[Anton Ertl]

a...@littlepinkcloud.invalid writes:

>Alex <al...@rivadpm.com> wrote:
>> Please describe "the bells, whistles, and curlicues"
>
>I believe they're quite adequately described in the proposal. As it
>stood last time I read it, it was a disproportionate response to the
>problem of extending number conversion. It has features which are
>irrelevant to number conversion and because of that it is clumsy in
>use. It is now a general-purpose mechanism for language extension
>which, as far as I am aware, has little application need.

Let's make this less abstract:

Here's the code from SwiftForth's fpmath.f for recognizing FP numbers:

: FNUMBER? ( addr len 0 | ... xt -- addr len 0 | ... xt )
?DUP ?EXIT BASE @ 10 = IF
R-BUF 2DUP R@ PLACE BL R@ COUNT + C! R> (REAL) IF
2DROP ['] FLITERAL EXIT
ELSE DROP THEN THEN 0 ;

' FNUMBER? NUMBER-CONVERSION <CHAIN

And here's the code from development Gforth using recognizers:

' noop ' fliteral ' fliteral rectype: rectype-float

: rec-float ( addr u -- r rectype-float | rectype-null )
\G recognize floating point numbers
prefix-number rectype-float rectype-null rot select ;

' rec-float forth-recognizer >back

For context, in SwiftForth, (REAL) ( a -- a 0 | -1 ) ( -- r ) does the
actual conversion, in Gforth, PREFIX-NUMBER ( c-addr u -- r true |
false ) does it (and you can define PREFIX-NUMBER as synonym for >FLOAT).

The last line of each piece of code puts the new recognizer in the
Forth recognizer sequence (aka NUMBER-CONVERSION chain). That's the
same here. I don't know the exact capabilities of SwiftForth's
chains, so there might be a difference in what one can do in other
cases.

The major functional difference between NUMBER-CONVERSION and Gforth's
recognizers (which are relatively close to the proposed recognizers)
is that FNUMBER? returns the xt of FLITERAL in addition to the
converted number, while REC-FLOAT returns three xts (wrapped into
RECTYPE-FLOAT): One for interpretation (NOOP), one for compilation
(FLITERAL), one for POSTPONE (FLITERAL).

On interpreting an FP number, the number is put on the FP stack by
REC-FLOAT/FNUMBER?, and nothing else (NOOP) needs to be done. The
NUMBER-CONVERSION mechanism does not allow specifying something extra
to do on interpretation, so you cannot use it to replace TO X (with
e.g., ->X), you cannot use it to recognize ordinary words (so
SwiftForth hard-codes the word recognizer into the text interpreter),
and you cannot use it to implement a dot-parser.

On compiling an FP number, you EXECUTE the compilation xt (FLITERAL)
in both variants.

On POSTPONEing an FP number, you EXECUTE the postpone xt (FLITERAL)
followed by COMPILE,ing the compilation xt. For literals, the two xts
are the same, so a suitably extended SwiftForth could actually
POSTPONE literals that are recognized by NUMBER-CONVERSION. For stuff
like ->X, word recognizers, and dot-parsers, there is a difference
between the compilation and postpone xts, but NUMBER-CONVERSION cannot
do that even interpretively anyway.

Another difference is in the way that a sequence of recognizers is
handled. With number-conversion, each recognizer sees what the
recognizer before produced, and normally exits if the earlier
recognizer was successful, but I guess there is room for creative
variations on that. With Gforth recognizers, the recognizer produces
REC-NULL if it was not successful, and only then the next recognizer
will be called.

>Wouldn't It Be Nice Ifs, or WIBNIs.

Another argument for bullshit bingo. Is there a single change to
Forth (e.g., any of the changes in Forth-94) that could not have been
called a WIBNI, at least at the time (but then there are still people
who argue that fig-Forth or Forth-79 or Forth-83 are better)? It's
original meaning to me is just "The proposal does not come from
Stephen Pelc".

[a...@littlepinkcloud.invalid]

Yes, these are the most important differences, along with the fact
that that the recognizer proposal subsumes dictionary search as a
recognizer.

> On interpreting an FP number, the number is put on the FP stack by
> REC-FLOAT/FNUMBER?, and nothing else (NOOP) needs to be done. The
> NUMBER-CONVERSION mechanism does not allow specifying something extra
> to do on interpretation, so you cannot use it to replace TO X (with
> e.g., ->X), you cannot use it to recognize ordinary words (so
> SwiftForth hard-codes the word recognizer into the text interpreter),
> and you cannot use it to implement a dot-parser.

Exactly so: as I said, NUMBER-CONVERSION is a simple mechanism, and it
cannot do these things. That's what makes it better than recognizers:
rather than a general-purpose language extension mechanism it handles
user-defined literals.

> On compiling an FP number, you EXECUTE the compilation xt (FLITERAL)
> in both variants.
>
> On POSTPONEing an FP number, you EXECUTE the postpone xt (FLITERAL)
> followed by COMPILE,ing the compilation xt. For literals, the two xts
> are the same, so a suitably extended SwiftForth could actually
> POSTPONE literals that are recognized by NUMBER-CONVERSION. For stuff
> like ->X, word recognizers, and dot-parsers, there is a difference
> between the compilation and postpone xts, but NUMBER-CONVERSION cannot
> do that even interpretively anyway.

Yes, that's right, it can't. It has a much smaller scope.

> Another difference is in the way that a sequence of recognizers is
> handled. With number-conversion, each recognizer sees what the
> recognizer before produced, and normally exits if the earlier
> recognizer was successful, but I guess there is room for creative
> variations on that.

I think that's more if an implementation decision than anything
essential.

> With Gforth recognizers, the recognizer produces REC-NULL if it was
> not successful, and only then the next recognizer will be called.
>
>>Wouldn't It Be Nice Ifs, or WIBNIs.
>
> Another argument for bullshit bingo.

Bingo!

> Is there a single change to Forth (e.g., any of the changes in
> Forth-94) that could not have been called a WIBNI, at least at the
> time (but then there are still people who argue that fig-Forth or
> Forth-79 or Forth-83 are better)?

Perhaps not, although allowing 32-bit Forths was such a pressing need
that everybody knew something had to be done.

This is a judgement call, and good judgement is essential for good
language design. You don't make a good language by adding features
that might be useful. It's impossible to prove that Feature X is
detrimental by, say, measuring its length, however much people might
demand "technical reasons", thereby trying to exclude anything that
can't be measured.

> It's original meaning to me is just "The proposal does not come from
> Stephen Pelc".

I'm sure that's what it means to you. However, the WIBNI is a useful
mental tool: whenever you have a program that you're creating and you
think "With a little more work it could be made to do these other
useful things too", that's a WIBNI. It happens when you have a job to
do, you see something that *is not part of the requirements* but you
see that by making your program just a little more complicated you can
implement it. Forth, the language and system, is the result of
resisting that pressure, as explained by Moore in his early writings.

Andrew.

[Alex]

On 16-Dec-17 10:41, a...@littlepinkcloud.invalid wrote:
>> The major functional difference between NUMBER-CONVERSION and Gforth's
>> recognizers (which are relatively close to the proposed recognizers)
>> is that FNUMBER? returns the xt of FLITERAL in addition to the
>> converted number, while REC-FLOAT returns three xts (wrapped into
>> RECTYPE-FLOAT): One for interpretation (NOOP), one for compilation
>> (FLITERAL), one for POSTPONE (FLITERAL).

> Yes, these are the most important differences, along with the fact
> that that the recognizer proposal subsumes dictionary search as a
> recognizer.
>

No, the recognizer proposal does not subsume dictionary search. It is
possible to implement recognizers -- and I did so initially -- to handle
number cases only and leave the default interpreter loop in place. It's
then a choice between RECOGNIZE or a NUMBER-CONVERSION equivalent.

Once I had done that it then became possible to subsume the standard
FIND interpret/compile and take advantage of the additional advantages
it has; but that was a personal choice, and not one dictated by the
proposal.

--
Alex

[a...@littlepinkcloud.invalid]

OK, thanks. I have mixed up some people's dicussion of their version
and the actual proposal.

So it's not necessary for a conforming recognizer implementation to
put the dictionary search into the recognizer stack, and therefore
it's not necessary to provide a facility whereby a user-defined
recognizer can be put in front of the dictionary search. That's good
to know.

Andrew.

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>Once I had done that it then became possible to subsume the standard
>FIND interpret/compile and take advantage of the additional advantages
>it has; but that was a personal choice, and not one dictated by the
>proposal.

The proposal will make the choice for portable programs before we
decide on it. As far as I see, there are the following options:

1) The proposal requires a hard-coded word recognizer in the text
interpreter, and the recognizer sequence is only processed afterwards.

2) The proposal requires the words recognizer to be part of the
recognizer sequence and the first of the default recognizers.

3) The proposal wants to sit on the fence and allows adding
recognizers only at the end.

IMO option 2 is preferable, because it offers more flexibility without
extra implementation complexity. Judging from his recent postings,
Andrew Haley will verbosely reject this option, for the same reasons.

In addition, I would like it if the proposal specified the default
recognizer sequence. Otherwise it becomes at least cumbersome (and
maybe impossible) to configure the recognizer stack for some forms of
input processing. My experience with the underspecified default
search order has been that the underspecification was a hindrance in
some uses that I would otherwise have made.

Unfortunately, in the current discussion climate wrt standards issues,
I expect that the usual suspects will throw "WIBNIs" and "main battle
tank", "language of the month" and the like in to obstruct any
technical discussion. Maybe those who are interested in recognizers
can (virtually) sit together and hash this out, and present the result
to the rest.

[Anton Ertl]

a...@littlepinkcloud.invalid writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

Yes, dictionary search can be implemented as word recognizer in the
Gforth recognizer implementation, and the text interpreter in Gforth
(development version) just calls the recognizer sequence, without
hard-coded dictionary search.

>> On interpreting an FP number, the number is put on the FP stack by
>> REC-FLOAT/FNUMBER?, and nothing else (NOOP) needs to be done. The
>> NUMBER-CONVERSION mechanism does not allow specifying something extra
>> to do on interpretation, so you cannot use it to replace TO X (with
>> e.g., ->X), you cannot use it to recognize ordinary words (so
>> SwiftForth hard-codes the word recognizer into the text interpreter),
>> and you cannot use it to implement a dot-parser.
>
>Exactly so: as I said, NUMBER-CONVERSION is a simple mechanism, and it
>cannot do these things. That's what makes it better than recognizers:
>rather than a general-purpose language extension mechanism it handles
>user-defined literals.

It's better because it can do less? Is this some kind of doublethink?

>> On compiling an FP number, you EXECUTE the compilation xt (FLITERAL)
>> in both variants.
>>
>> On POSTPONEing an FP number, you EXECUTE the postpone xt (FLITERAL)
>> followed by COMPILE,ing the compilation xt. For literals, the two xts
>> are the same, so a suitably extended SwiftForth could actually
>> POSTPONE literals that are recognized by NUMBER-CONVERSION. For stuff
>> like ->X, word recognizers, and dot-parsers, there is a difference
>> between the compilation and postpone xts, but NUMBER-CONVERSION cannot
>> do that even interpretively anyway.
>
>Yes, that's right, it can't. It has a much smaller scope.

>>>Wouldn't It Be Nice Ifs, or WIBNIs.
>>
>> Another argument for bullshit bingo.
>
>Bingo!
>
>> Is there a single change to Forth (e.g., any of the changes in
>> Forth-94) that could not have been called a WIBNI, at least at the
>> time (but then there are still people who argue that fig-Forth or
>> Forth-79 or Forth-83 are better)?
>
>Perhaps not, although allowing 32-bit Forths was such a pressing need
>that everybody knew something had to be done.

Given that every new feature can be declared as a "WIBNI", "WIBNI" is
useless as an argument for determining whether a feature is beneficial
or not (except if you deem every feature detrimental).

>This is a judgement call, and good judgement is essential for good
>language design.

And good judgement in technical issues requires knowing technical
properties, and this can be furthered only by discussing them. My
impression is that the opposition to recognizers knows that
technically they have no leg to stand on, that's why they avoid any
technical discussion of recognizers like the plague, and instead throw
around emotional appeals like "WIBNI", "main battle tank", or
"language of the month", and (not so recently) "make Forth more like
C".

>You don't make a good language by adding features
>that might be useful. It's impossible to prove that Feature X is
>detrimental by, say, measuring its length, however much people might
>demand "technical reasons", thereby trying to exclude anything that
>can't be measured.

"Not measurable" is acceptable, then you have a qualitative argument.
However, emotional appeals don't advance the discussion and therefore
don't have a place there.

[WIBNI]

>> It's original meaning to me is just "The proposal does not come from
>> Stephen Pelc".
>
>I'm sure that's what it means to you.

Actually, I was wrong; it means "The proposal is not already
implemented in or planned for VFX Forth" (so, e.g.,
<http://www.forth200x.org/twos-complement.html> was not WIBNI despite
not coming from Stephen Pelc). And it's what it means to Stephen
Pelc. And given that he introduced the term, it also means that for
the rest of us, including me.

>However, the WIBNI is a useful
>mental tool: whenever you have a program that you're creating and you
>think "With a little more work it could be made to do these other
>useful things too", that's a WIBNI. It happens when you have a job to
>do, you see something that *is not part of the requirements* but you
>see that by making your program just a little more complicated you can
>implement it. Forth, the language and system, is the result of
>resisting that pressure, as explained by Moore in his early writings.

Forth is the result of *not* following this principle. If Moore had
followed this principle, he would not have introduced an extensible
dictionary and a text interpreter, because that can always do more
than is required at any particular moment.

There are different metrics for programs: implementation complexity,
generality, interface complexity, correctness, performance, etc.
Chuck Moore favours minimal implementation complexity over the others
more than most programmers, but as Forth shows, he does not do it
exclusively. More relevant to the present discussion: he does not
avoid generality just for the sake of being less general.

Concerning the requirements, one of the requirements for a text
interpreter that is not a WIBNI (in the original sense) is the ability
to support a dot-parser. NUMBER-CONVERSION cannot do that, the
proposed recognizers can.

And this is not just useful for large systems, but also for small
ones. At the last Forth-Tagung Joerg Voelker talked about programming
a relatively large application on a small microcontroller. One of the
issues he had was the amount of space for stuff like structure field
names. E.g., if he has fields

somename-x
somename-y
somename-z
anothername-w
anothername-x
anothername-y

This takes quite some space on his chip. Instead, one could have two
wordlists:

SOMENAME containing X Y Z
ANOTHERNAME containing W X Y

which saves some space, and then use a dot-parser to access SOMENAME.X
and ANOTHERNAME.X.

So it's not as if the additional features of the proposed recognizers
were for things for which there are no requirements.

[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:
>>> On interpreting an FP number, the number is put on the FP stack by
>>> REC-FLOAT/FNUMBER?, and nothing else (NOOP) needs to be done. The
>>> NUMBER-CONVERSION mechanism does not allow specifying something extra
>>> to do on interpretation, so you cannot use it to replace TO X (with
>>> e.g., ->X), you cannot use it to recognize ordinary words (so
>>> SwiftForth hard-codes the word recognizer into the text interpreter),
>>> and you cannot use it to implement a dot-parser.
>>
>>Exactly so: as I said, NUMBER-CONVERSION is a simple mechanism, and it
>>cannot do these things. That's what makes it better than recognizers:
>>rather than a general-purpose language extension mechanism it handles
>>user-defined literals.
>
> It's better because it can do less? Is this some kind of doublethink?

I don't think it is. There's a great deal to be said for simple
mechanisms which do a single thing in a simple way. I know you don't
much like talk of this kind, but it't the essence of Forth.

>>> Is there a single change to Forth (e.g., any of the changes in
>>> Forth-94) that could not have been called a WIBNI, at least at the
>>> time (but then there are still people who argue that fig-Forth or
>>> Forth-79 or Forth-83 are better)?
>>
>>Perhaps not, although allowing 32-bit Forths was such a pressing need
>>that everybody knew something had to be done.
>
> Given that every new feature can be declared as a "WIBNI", "WIBNI" is
> useless as an argument for determining whether a feature is beneficial
> or not (except if you deem every feature detrimental).

No. I did explain quite carefully what a WIBNI is: it's what happens
when you set out to do one thing, you notice that some other thing
(not actually required by what you set out to do) can be done by
extending your scope a little bit, you think "Wouldn't it be nice if
we did that too", and iterate. It is the proverbial road to hell,
paved with good intentions.

>>This is a judgement call, and good judgement is essential for good
>>language design.
>
> And good judgement in technical issues requires knowing technical
> properties, and this can be furthered only by discussing them.

It's hard to dispute that truism.

> My impression is that the opposition to recognizers knows that
> technically they have no leg to stand on, that's why they avoid any
> technical discussion of recognizers like the plague, and instead
> throw around emotional appeals like "WIBNI", "main battle tank", or
> "language of the month", and (not so recently) "make Forth more like
> C".

I can turn that around easily enough: there is no strictly technical
argument in their favour either. It's a matter of some people who
like to use this kind of language feature and some who don't.

>>You don't make a good language by adding features that might be
>>useful. It's impossible to prove that Feature X is detrimental by,
>>say, measuring its length, however much people might demand
>>"technical reasons", thereby trying to exclude anything that can't
>>be measured.
>
> "Not measurable" is acceptable, then you have a qualitative argument.
> However, emotional appeals don't advance the discussion and therefore
> don't have a place there.

Emotional appeals? Not at all, unless you are to classify all
discussion of language design, elegance, and Forth's extreme
simplicity as "mere emotion", in the vein of Mr Spock. But
programmers are not androids most of them, anyway.

> [WIBNI]
>>> It's original meaning to me is just "The proposal does not come from
>>> Stephen Pelc".
>>
>>I'm sure that's what it means to you.
>
> Actually, I was wrong; it means "The proposal is not already
> implemented in or planned for VFX Forth" (so, e.g.,
> <http://www.forth200x.org/twos-complement.html> was not WIBNI despite
> not coming from Stephen Pelc). And it's what it means to Stephen
> Pelc. And given that he introduced the term,

He didn't. He might even have got it from me; I got it from Chris
Stephens. But it might just have been in the air.

> it also means that for the rest of us, including me.
>
>>However, the WIBNI is a useful mental tool: whenever you have a
>>program that you're creating and you think "With a little more work
>>it could be made to do these other useful things too", that's a
>>WIBNI. It happens when you have a job to do, you see something that
>>*is not part of the requirements* but you see that by making your
>>program just a little more complicated you can implement it. Forth,
>>the language and system, is the result of resisting that pressure,
>>as explained by Moore in his early writings.

> Forth is the result of *not* following this principle. If Moore had
> followed this principle, he would not have introduced an extensible
> dictionary and a text interpreter, because that can always do more
> than is required at any particular moment.

Um, pardon? That makes no sense at all. Are you trying for some kind
of reductio ad absurdum?

> There are different metrics for programs: implementation complexity,
> generality, interface complexity, correctness, performance, etc.
> Chuck Moore favours minimal implementation complexity over the others
> more than most programmers, but as Forth shows, he does not do it
> exclusively. More relevant to the present discussion: he does not
> avoid generality just for the sake of being less general.

No, of course not.

> Concerning the requirements, one of the requirements for a text
> interpreter that is not a WIBNI (in the original sense) is the ability
> to support a dot-parser.

Is it? Says who? You can certainly do OOP without needing such a
thing as a dot parser. The dotted notation of some OOP notations is
from Simula 67, and fits the way its parser works. Smalltalk doesn't
need it because Objects can only access their own fields.

> NUMBER-CONVERSION cannot do that, the proposed recognizers can.
>
> And this is not just useful for large systems, but also for small
> ones. At the last Forth-Tagung Joerg Voelker talked about programming
> a relatively large application on a small microcontroller. One of the
> issues he had was the amount of space for stuff like structure field
> names. E.g., if he has fields
>
> somename-x
> somename-y
> somename-z
> anothername-w
> anothername-x
> anothername-y
>
> This takes quite some space on his chip. Instead, one could have two
> wordlists:
>
> SOMENAME containing X Y Z
> ANOTHERNAME containing W X Y
>
> which saves some space, and then use a dot-parser to access SOMENAME.X
> and ANOTHERNAME.X.
>
> So it's not as if the additional features of the proposed recognizers
> were for things for which there are no requirements.

So, I think the question is about "one shot" wordlists. Are you
really saying that a dot parser is needed for that?

There is no doubt that, for any feature that some Forth programmer has
needed once, there was a need. That's not the issue here, which is
the general applicability of the proposal.

Andrew.

[Alex]

On 18-Dec-17 10:27, a...@littlepinkcloud.invalid wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> a...@littlepinkcloud.invalid writes:
>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>> On interpreting an FP number, the number is put on the FP stack by
>>>> REC-FLOAT/FNUMBER?, and nothing else (NOOP) needs to be done. The
>>>> NUMBER-CONVERSION mechanism does not allow specifying something extra
>>>> to do on interpretation, so you cannot use it to replace TO X (with
>>>> e.g., ->X), you cannot use it to recognize ordinary words (so
>>>> SwiftForth hard-codes the word recognizer into the text interpreter),
>>>> and you cannot use it to implement a dot-parser.
>>>
>>> Exactly so: as I said, NUMBER-CONVERSION is a simple mechanism, and it
>>> cannot do these things. That's what makes it better than recognizers:
>>> rather than a general-purpose language extension mechanism it handles
>>> user-defined literals.
>>
>> It's better because it can do less? Is this some kind of doublethink?
>
> I don't think it is. There's a great deal to be said for simple
> mechanisms which do a single thing in a simple way. I know you don't
> much like talk of this kind, but it't the essence of Forth.

A NUMBER-CONVERSION does two things. It tests if the string has been
converted, and if it has not been converted, it tries to recognize the
string as a specific type of number. If it succeeds, it returns two
parts. It converts the string to a single, double or float for later
use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
it).

A recognizer does just exactly one thing. It tries to recognize the
string as a specific type of thing. If it succeeds, If it succeeds, it
returns two parts. It converts the string to a thing and provides a
thing token for later use. The thing token provides XTs to EXECUTE
COMPILE, and POSTPONE the thing.

The reduced complexity and more rigourous (and useful) specification of
recognizers seems to be a problem, and I wonder why.

>
>>>> Is there a single change to Forth (e.g., any of the changes in
>>>> Forth-94) that could not have been called a WIBNI, at least at the
>>>> time (but then there are still people who argue that fig-Forth or
>>>> Forth-79 or Forth-83 are better)?
>>>
>>> Perhaps not, although allowing 32-bit Forths was such a pressing need
>>> that everybody knew something had to be done.
>>
>> Given that every new feature can be declared as a "WIBNI", "WIBNI" is
>> useless as an argument for determining whether a feature is beneficial
>> or not (except if you deem every feature detrimental).
>
> No. I did explain quite carefully what a WIBNI is: it's what happens
> when you set out to do one thing, you notice that some other thing
> (not actually required by what you set out to do) can be done by
> extending your scope a little bit, you think "Wouldn't it be nice if
> we did that too", and iterate. It is the proverbial road to hell,
> paved with good intentions.

In this case, it's a simplification that has pointed away from the road
to hell, which is paved with STATEs. Recognizers do their parsing at the
right time, rather than at the wrong time; with the result that we have
TO, S" and other standardized parsing words, and Hugh's hellish novice
package which scatters STATE like confetti at Forthzilla's wedding.

>
>> My impression is that the opposition to recognizers knows that
>> technically they have no leg to stand on, that's why they avoid any
>> technical discussion of recognizers like the plague, and instead
>> throw around emotional appeals like "WIBNI", "main battle tank", or
>> "language of the month", and (not so recently) "make Forth more like
>> C".
>
> I can turn that around easily enough: there is no strictly technical
> argument in their favour either. It's a matter of some people who
> like to use this kind of language feature and some who don't.

There is a technical argument. Recognizers provide correct parsing and
uniform treatment of numbers and words, and as such are proposed for
standardization. NUMBER-CONVERSION has not been put forward, but should
it be, I would reckon on it getting exactly nowhere due to its lack of
flexibility and frankly rather plodding way to process numbers.

(And as an aside I would not go back to pre-recognizers and implement
it. In my Forth, recognizers now an integral part of meta-compilation,
where exactly the same recognizers are used to parse the Forth source,
but a different set of action tokens does the meta-compilation. It has
considerably reduced the meta-junk needed to support meta-compilation.)

[snip]

--
Alex

[Albert van der Horst]

In article <p189te$28n$1...@dont-email.me>, Alex <al...@rivadpm.com> wrote:
<SNIP>

>
>A NUMBER-CONVERSION does two things. It tests if the string has been
>converted, and if it has not been converted, it tries to recognize the
>string as a specific type of number. If it succeeds, it returns two
>parts. It converts the string to a single, double or float for later
>use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
>it).

It should be called PARSE-DENOTATION. It can handle all sort of
expressions (denotations) that result in a compile time constant.
Constants are nice because there can be no issue how they are interpreted
compiled or postponed.
But denotations are not only numbers, float or otherwise. They can
be a lambda expression, a string, or the address of a dictionary entry.
<SNIP>

>In this case, it's a simplification that has pointed away from the road
>to hell, which is paved with STATEs. Recognizers do their parsing at the
>right time, rather than at the wrong time; with the result that we have
>TO, S" and other standardized parsing words, and Hugh's hellish novice
>package which scatters STATE like confetti at Forthzilla's wedding.

It is wrong to have parsing word S" to understand an expression
S" aap"
the parsing leads to problems. On the other hand
"aap"
is on the same footing as any other denotation ("number") :
a constant , but you need something to understand the denotation.

And you know my stance. In a simple language like Forth should be,
we must not go beyond prefixes. If that means we cannot have all
the expressions possible in other languages, so be it.

>
>--
>Alex

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

[Alex]

On 18-Dec-17 15:18, Albert van der Horst wrote:
> And you know my stance. In a simple language like Forth should be,
> we must not go beyond prefixes. If that means we cannot have all
> the expressions possible in other languages, so be it.

Yes, but you don't need to follow; recognizers do not demand that you
write code to understand anything other than denotations (that is,
strings that can be prefixed parsed and compiled as constants).

But even you have already made an exception for doubles with their
postfix dot and floats with their infix E. Your parsing purity is
already compromised, and I find it troubling that you would now prefer
to continue with one eye or nine fingers because "we must not go beyond
prefixes". And no-one is proposing standardizing the things recognizers
can recognize (yet, and then you can have that argument).

--
Alex

[dxf...@gmail.com]

On Sunday, December 10, 2017 at 8:57:15 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> Elizabeth D. Rather <era...@forth.com> wrote:
>
> > For the most part, at least the ones I'm in contact with are in the "if
> > it ain't broke, don't fix it" camp. They don't see much value in the
> > issues being debated. I can't speak for him, but I suspect that the
> > reason Leon participates is to try to minimize breakage.
>
> I don't speak for him either, but I'm pretty sure that's not the omly
> reason, even though it's surely a very big part of it.
>
> Andrew.

Can you even pretend to have a 'Forth Standard'
without Forth Inc. Seems to me FI is there to
save friends from embarrassment. FI is stuck
'between a rock and a hard place'.

[a...@littlepinkcloud.invalid]

Alex <al...@rivadpm.com> wrote:
> On 18-Dec-17 10:27, a...@littlepinkcloud.invalid wrote:
>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> a...@littlepinkcloud.invalid writes:

> A NUMBER-CONVERSION does two things. It tests if the string has been
> converted, and if it has not been converted, it tries to recognize the
> string as a specific type of number. If it succeeds, it returns two
> parts. It converts the string to a single, double or float for later
> use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
> it).
>
> A recognizer does just exactly one thing. It tries to recognize the
> string as a specific type of thing. If it succeeds, If it succeeds, it
> returns two parts. It converts the string to a thing and provides a
> thing token for later use. The thing token provides XTs to EXECUTE
> COMPILE, and POSTPONE the thing.

So, the recognizer is not doing exactly one thing, is it? It's doing
one thing, and then one of three things. It can have arbitrary
effects, including even reading ahead in the input stream.
Essentially, rather than the classical Forth interpreter we now have a
user-written interpreter that can do anything at all. The only thing
the system's interpreter has left is a loop: the rest is the
recognizers.

> The reduced complexity and more rigourous (and useful) specification
> of recognizers seems to be a problem, and I wonder why.

I find that very hard to believe. It's been explained enough times.

>> No. I did explain quite carefully what a WIBNI is: it's what happens
>> when you set out to do one thing, you notice that some other thing
>> (not actually required by what you set out to do) can be done by
>> extending your scope a little bit, you think "Wouldn't it be nice if
>> we did that too", and iterate. It is the proverbial road to hell,
>> paved with good intentions.
>
> In this case, it's a simplification that has pointed away from the
> road to hell, which is paved with STATEs. Recognizers do their
> parsing at the right time, rather than at the wrong time; with the
> result that we have TO, S" and other standardized parsing words, and
> Hugh's hellish novice package which scatters STATE like confetti at
> Forthzilla's wedding.

STATE is not a problem, so let's get that out of the way: to avoid
problems with STATE, don't use STATE. Problem solved: it doesn't need
any solution that can be solved by recognizers. That's already been
dealt with at length already. TO and S" should never have been
standardized in their present form. Sure, the problems of TO and S"
can be worked around with recognizers, but you don't get clean and
simple systems by patching up old mistakes with new ones.

>>> My impression is that the opposition to recognizers knows that
>>> technically they have no leg to stand on, that's why they avoid any
>>> technical discussion of recognizers like the plague, and instead
>>> throw around emotional appeals like "WIBNI", "main battle tank", or
>>> "language of the month", and (not so recently) "make Forth more like
>>> C".
>>
>> I can turn that around easily enough: there is no strictly technical
>> argument in their favour either. It's a matter of some people who
>> like to use this kind of language feature and some who don't.
>
> There is a technical argument. Recognizers provide correct parsing
> and uniform treatment of numbers and words, and as such are proposed
> for standardization.

Well, yes, for people who care about that sort of thing. But since
when was "correct parsing and uniform treatment of numbers and words",
whatever that means, one of the desiderata of Forth anyway? It's no
more than an ad hoc rationalization invented by people who like
recognizers.

> NUMBER-CONVERSION has not been put forward, but should it be, I
> would reckon on it getting exactly nowhere due to its lack of
> flexibility and frankly rather plodding way to process numbers.

It's not very exciting, that's true.

As Elizabeth alluded to, there was always a tension between the
industrial users of Forth (who originally were all customers of Forth
Inc.) and the enthusiasts of the Forth Interest Group who loved
Forth's flexibility and had fun playing with language. There's some
scope for that tension to be creative, but there's also the
possibility of Forth 20xx becoming irrelevant to an important group of
users.

> (And as an aside I would not go back to pre-recognizers and
> implement it. In my Forth, recognizers now an integral part of
> meta-compilation, where exactly the same recognizers are used to
> parse the Forth source, but a different set of action tokens does
> the meta-compilation. It has considerably reduced the meta-junk
> needed to support meta-compilation.)

I'm sure you could do it that way, but you could have equally easily
written the interpreter loop. Given that the only thing in the
interpreter loop in a system that uses recognizers is the loop itself,
there can't be much difference.

Andrew.

[a...@littlepinkcloud.invalid]

dxf...@gmail.com wrote:
> On Sunday, December 10, 2017 at 8:57:15 PM UTC+11, a...@littlepinkcloud.invalid wrote:
>> Elizabeth D. Rather <era...@forth.com> wrote:
>>
>> > For the most part, at least the ones I'm in contact with are in the "if
>> > it ain't broke, don't fix it" camp. They don't see much value in the
>> > issues being debated. I can't speak for him, but I suspect that the
>> > reason Leon participates is to try to minimize breakage.
>>
>> I don't speak for him either, but I'm pretty sure that's not the omly
>> reason, even though it's surely a very big part of it.
>

> Can you even pretend to have a 'Forth Standard' without Forth
> Inc.

Not really, no. That would be a split in the community along the
lines of Common Lisp, and no-one wants that.

> Seems to me FI is there to save friends from embarrassment. FI is
> stuck 'between a rock and a hard place'.

In what way?

Andrew.

[Albert van der Horst]

I've demonstrated that Pascal can be parsed using only prefixes,
so prefixes can like recognizers be used for more than simple
denotations.

I can see your point of view. I personally don't object so much
to the use of recognizers, once they are there, as to implementing
them and destroying an elegant design.
Regards having three kinds of numbers that cannot be recognized
unless by looking farther than the first character (recognized
automatically or by humans), I've to say that it bothers me more than
you may think. This is however a problem Forth has in common
with all the programming languages in existance, except those
that make all numbers real for this reason.

I hate the infix E for floats (e even more)
and would replace it by ~.
I would like to forbid . as starting a number if Forth,
because in Forth it means print.

So we got simple rules:
all numbers start with a decimal digit. 2)
if it contains ~ it is a floating point, 1) else
if it contains . it is a double, else single
all numbers observe base and lower case hex is out.

[Maybe if it contains i it is a complex number.]

1) And ciforth detects that with the simple `` 2DUP &~ $^ IF .. ''
2) Wanne get rid of 2SWAP and its ilk, replace by PSWAP
or DSWAP . 1+ is superfluous, 2/ is misleading

>
>--
>Alex

[Alex]

On 19-Dec-17 09:30, a...@littlepinkcloud.invalid wrote:
> Alex <al...@rivadpm.com> wrote:
>> On 18-Dec-17 10:27, a...@littlepinkcloud.invalid wrote:
>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>> a...@littlepinkcloud.invalid writes:
>
>> A NUMBER-CONVERSION does two things. It tests if the string has been
>> converted, and if it has not been converted, it tries to recognize the
>> string as a specific type of number. If it succeeds, it returns two
>> parts. It converts the string to a single, double or float for later
>> use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
>> it).
>>
>> A recognizer does just exactly one thing. It tries to recognize the
>> string as a specific type of thing. If it succeeds, If it succeeds, it
>> returns two parts. It converts the string to a thing and provides a
>> thing token for later use. The thing token provides XTs to EXECUTE
>> COMPILE, and POSTPONE the thing.
>
> So, the recognizer is not doing exactly one thing, is it? It's doing
> one thing, and then one of three things.

As compared with two things and one of two things, neatly avoiding
POSTPONE.

> It can have arbitrary
> effects, including even reading ahead in the input stream.

Any word can do that; it's not specific to recognizers. SwiftForth's
NUMBER-CONVERSION words can do pretty much what they like, and there are
many ANS Forth examples of reading ahead. It is not required but neither
is it prevented (and as I believe you have said before, Forth doesn't
stop you from doing stupid stuff). I don't understand why you call out
recognizers in this regard.

> Essentially, rather than the classical Forth interpreter we now have a
> user-written interpreter that can do anything at all. The only thing
> the system's interpreter has left is a loop: the rest is the
> recognizers.

Here's without, and a system that closely resembles NUMBER-CONVERSION
(it's from Win32Forth):

: INTERPRET ( -- )
BEGIN BL WORD DUP C@
WHILE FIND ?DUP
IF STATE @ =
IF COMPILE, \ COMPILE TIME
ELSE EXECUTE ?STACK \ INTERPRET
THEN
ELSE NUMBER NUMBER,
THEN
REPEAT DROP ;

NUMBER is the equivalent of NUMBER-CONVERSION.

: default-recognize ( addr u -- i*x xt )
forth-recognizer recognize state @ cells- @ ;

: interpreter ( -- )
begin
?stack parse-name dup
while
default-recognize execute
repeat 2drop ;

Which operates in exactly the same way as the current loop and permits
ANS code to be interpreted and compiled exactly the same way; and as
been explained already, the interpreter loop does not need to change if
the system's author doesn't want to provide anything more than number
conversion.

The latter recognizer scheme is extensible. The former is locked into
only supporting whatever can be handled by NUMBER, (which is not
extensible).

>
>> The reduced complexity and more rigourous (and useful) specification
>> of recognizers seems to be a problem, and I wonder why.
>
> I find that very hard to believe. It's been explained enough times.

I still don't get your technical aversion to this.

>
>>> No. I did explain quite carefully what a WIBNI is: it's what happens
>>> when you set out to do one thing, you notice that some other thing
>>> (not actually required by what you set out to do) can be done by
>>> extending your scope a little bit, you think "Wouldn't it be nice if
>>> we did that too", and iterate. It is the proverbial road to hell,
>>> paved with good intentions.
>>
>> In this case, it's a simplification that has pointed away from the
>> road to hell, which is paved with STATEs. Recognizers do their
>> parsing at the right time, rather than at the wrong time; with the
>> result that we have TO, S" and other standardized parsing words, and
>> Hugh's hellish novice package which scatters STATE like confetti at
>> Forthzilla's wedding.
>
> STATE is not a problem, so let's get that out of the way: to avoid
> problems with STATE, don't use STATE. Problem solved: it doesn't need
> any solution that can be solved by recognizers. That's already been
> dealt with at length already. TO and S" should never have been
> standardized in their present form.

But they were standardized, and recognizers provide a solution; the
parse and the action are cleanly separated, and the temptation to use
STATE is eliminated. In fact, the writer of a recognizer can't use STATE
productively at all. To avoid problems with STATE, use recognizers.

> Sure, the problems of TO and S"
> can be worked around with recognizers, but you don't get clean and
> simple systems by patching up old mistakes with new ones.

The proposal is not even suggesting that (although I've shown how it can
be done).

>
>>>> My impression is that the opposition to recognizers knows that
>>>> technically they have no leg to stand on, that's why they avoid any
>>>> technical discussion of recognizers like the plague, and instead
>>>> throw around emotional appeals like "WIBNI", "main battle tank", or
>>>> "language of the month", and (not so recently) "make Forth more like
>>>> C".
>>>
>>> I can turn that around easily enough: there is no strictly technical
>>> argument in their favour either. It's a matter of some people who
>>> like to use this kind of language feature and some who don't.
>>
>> There is a technical argument. Recognizers provide correct parsing
>> and uniform treatment of numbers and words, and as such are proposed
>> for standardization.
>
> Well, yes, for people who care about that sort of thing. But since
> when was "correct parsing and uniform treatment of numbers and words",
> whatever that means, one of the desiderata of Forth anyway? It's no
> more than an ad hoc rationalization invented by people who like
> recognizers.

Which I suspect is the attitude that got us S".

>
>> NUMBER-CONVERSION has not been put forward, but should it be, I
>> would reckon on it getting exactly nowhere due to its lack of
>> flexibility and frankly rather plodding way to process numbers.
>
> It's not very exciting, that's true.

It's not very good either. It's a bodge.

>
> As Elizabeth alluded to, there was always a tension between the
> industrial users of Forth (who originally were all customers of Forth
> Inc.) and the enthusiasts of the Forth Interest Group who loved
> Forth's flexibility and had fun playing with language. There's some
> scope for that tension to be creative, but there's also the
> possibility of Forth 20xx becoming irrelevant to an important group of
> users.

Strangely, this is where we agree.

I don't believe that the proposal is anywhere near ready for
standardization, and I've said so in other posts.

A cautious approach will probably suit the vendors on the Forth200x
committee, since in my experience there's usually little appetite from
vendors for gratuitous change or spandrels and curlicues. I work in the
standards part of my company; we're change averse unless there's a very
demonstrable use case. That is, in general something has to go faster,
be done more cheaply, or there's a need talk to someone else's products
fr example.

But I recognize (excuse the pun) that something very like the
recognizers proposal is inevitable, since it extends the concept of
parsing to flexibly and simply support new forms of representing
numbers, and tokenizing on other than blanks for words like
object.method names. Perhaps even reading ahead in the input stream.
That's a lot from a few lines of code.

That means I'm going to explore it further, and I'll keep commenting on
what I find, time permitting. Time isn't exactly in huge supply at Chez
Alex, so it will be slow.

>
>> (And as an aside I would not go back to pre-recognizers and
>> implement it. In my Forth, recognizers now an integral part of
>> meta-compilation, where exactly the same recognizers are used to
>> parse the Forth source, but a different set of action tokens does
>> the meta-compilation. It has considerably reduced the meta-junk
>> needed to support meta-compilation.)
>
> I'm sure you could do it that way, but you could have equally easily
> written the interpreter loop. Given that the only thing in the
> interpreter loop in a system that uses recognizers is the loop itself,
> there can't be much difference.

That's the way it was.

I'm not a big fan of writing/debugging/maintaining nearly but not quite
the same thing twice. I quite like the idea of having the meta-compiler
use the current version and code already in the compiler, rather than
having to add duplicate but subtly different stuff to the meta-compiler.

Why duplicate S" TO CONSTANT VALUE VARIABLE : and so on as well? Because
they're all parsing words, hence the requirement to meta-recognize them.
There are other issues too around STATE while meta-compiling, but I'll
not bore you with the details.

This support code becomes quite large quite rapidly. It's currently 1600
lines or so, and I reckon it need be no bigger than 1000; that's a big
lump of code.

--
Alex

[Anton Ertl]

dxf...@gmail.com writes:
>Can you even pretend to have a 'Forth Standard'
>without Forth Inc.

Sure. AFAIK Forth-79 is a Forth standard without Forth, Inc.

Of course, every standard is as valuable as its acceptance by the
various actors. The more systems are standard systems, the more
valuable the standard is. The more programs are standard programs,
the more valuable the standard is.

At the moment, we have a situation where a number of mainstream
systems implement Forth-94 and partly the new features of Forth-2012,
while there are relatively few standard programs and standard
libraries.

The standards still have value in usually having more commonality in
the non-standard programs (glorified as "programmer portability" by
those who are happy with this state of affairs).

[Matthias Trute]

Am Dienstag, 19. Dezember 2017 10:30:31 UTC+1 schrieb a...@littlepinkcloud.invalid:

> Essentially, rather than the classical Forth interpreter we now have a
> user-written interpreter that can do anything at all. The only thing
> the system's interpreter has left is a loop: the rest is the
> recognizers.

That sounds like a masterpiece in factoring to me. With less code
and a defined interface between a set of co-words you get more, at
least not less. What went wrong? It cannot be the code size, it is
not affected (proven in amforth).

> STATE is not a problem, so let's get that out of the way: to avoid
> problems with STATE, don't use STATE.

Very true. Recognizers don't deal with STATE. Nowhere. Sure, words
can use a STATE like construct to achieve their goals, even something
like the [[ ]] pair seems to be possible. So what? Recognizers are
still an enabler tool.

> > (And as an aside I would not go back to pre-recognizers and
> > implement it. In my Forth, recognizers now an integral part of
> > meta-compilation, where exactly the same recognizers are used to
> > parse the Forth source, but a different set of action tokens does
> > the meta-compilation. It has considerably reduced the meta-junk
> > needed to support meta-compilation.)

I'd like to see some examples, if possible. PM is ok (NDA assured).


Matthias

[Elizabeth D. Rather]

The major vendors are certainly necessary for a meaningful standard.
FORTH, Inc. is committed to the process.

Cheers,
Elizabeth

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

[Elizabeth D. Rather]

On 12/19/17 12:07 PM, Anton Ertl wrote:
> dxf...@gmail.com writes:
>> Can you even pretend to have a 'Forth Standard'
>> without Forth Inc.
>
> Sure. AFAIK Forth-79 is a Forth standard without Forth, Inc.

Chuck and I both participated in a standards meeting in Utrecht,
although we did not adopt all of the resulting standard.

> Of course, every standard is as valuable as its acceptance by the
> various actors. The more systems are standard systems, the more
> valuable the standard is. The more programs are standard programs,
> the more valuable the standard is.
>
> At the moment, we have a situation where a number of mainstream
> systems implement Forth-94 and partly the new features of Forth-2012,
> while there are relatively few standard programs and standard
> libraries.
>
> The standards still have value in usually having more commonality in
> the non-standard programs (glorified as "programmer portability" by
> those who are happy with this state of affairs).

I think there are a number of programs that are standard in the sense
that they document all the dependencies, etc., that are called for. The
standards achieve their primary purpose if this is done, by highlighting
the things a programmer seeking to port the program to another
environment needs to know about. How many C programs have no compiler or
platform dependencies?

[dxf...@gmail.com]

On Tuesday, December 19, 2017 at 8:34:16 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> dxf...@gmail.com wrote:
> > On Sunday, December 10, 2017 at 8:57:15 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> >> Elizabeth D. Rather <era...@forth.com> wrote:
> >>
> >> > For the most part, at least the ones I'm in contact with are in the "if
> >> > it ain't broke, don't fix it" camp. They don't see much value in the
> >> > issues being debated. I can't speak for him, but I suspect that the
> >> > reason Leon participates is to try to minimize breakage.
> >>
> >> I don't speak for him either, but I'm pretty sure that's not the omly
> >> reason, even though it's surely a very big part of it.
> >
> > Can you even pretend to have a 'Forth Standard' without Forth
> > Inc.
>
> Not really, no. That would be a split in the community along the
> lines of Common Lisp, and no-one wants that.

There never was a community in Forth to split.
It's had individuals who adopted or rejected
ideas as they arose. One of those ideas - a
standard for Forth - Chuck himself rejected.
If Forth users have anything in common, it has
been their refusal to accept the dictates of
a few.

>
> > Seems to me FI is there to save friends from embarrassment. FI is
> > stuck 'between a rock and a hard place'.
>
> In what way?
>
> Andrew.

FI's reluctance to implement 200x features while
at the same time being on the committee.

[lsng....@gmail.com]

As the OP of this thread, I am struck by the arguments over "standards" in this forum.

I first came across Forth not too long ago while searching for a programming language that I can use on the mobile phone -- no punctuations etc.

Eventually I implemented an Application Programming Interface Shell -- a shell embedded within a host program (the host program is written in a third generation programming language (e.g. JavaScript of PHP) ). The shell uses reverse polish syntax (like Forth). Here is a live version:

http://5gl.epizy.com/zh/glv.html

Extending the principle of Reverse Polish Expression (a superset of Forth-like languages and reverse polish notation), I also implemented "arbitrary aliases" within 5GL (the Fifth Generation Graph Language), the name I gave to my Forth like implementation.

At its core, the arbitrary aliases is a JSON table that looks like this:

{"alias":{"g":"fws_g","ll":"fws_ll","fl":"fws_fl","sl":"fws_sl","substr":"fws_substr","ma":"fws_ma","ms":"fws_ms","w":"fws_w","ac":"fws_ac","b":"fws_b","t":"fws_t","n":"fws_n","fn":"fws_fn","c":"fws_c","i":"fws_i","k":"fws_k","each":"fws_each","v":"fws_v","gt":"fws_gt","h":"fws_h","d":"fws_d","je":"fws_je","snl":"fws_snl","ss":"fws_ss","sss":"fws_sss","nc":"fws_nc","j":"fws_j","s":"fws_s","u":"fws_u","a":"fws_a","ar":"fws_ar","es":"fws_es","ta":"fws_ta","jd":"fws_d","ej":"fws_ej","aa":"s_aa","gl":"fws_gl","root":"fws_root","func":"fws_func","glr":"fws_glr","ca":"fws_check_alias","tail":"fws_tail","loop":"fws_loop","dummy":"fws_dummy","ajs":"fws_ajs","vn":"fws_vn","vr":"fws_vr","am":"fws_am","mj":"fws_mj","fi":"fws_fi","文":"fi","dup":"fws_dup","cas":"fws_ca_script","fa":"fws_fa","conflict":"fws_conflict","a2sort":"fws_a2sort","cube":"s_cube","方":"s_cube"}}

The left hand side is a 5GL command or alias (Forth "words") and the right hand side another alias, ultimately the function name (in this case PHP) of the host program.

As you can see, with this, I am able to create aliases in Unicode (Chinese), thus implemented a completely Latin independent language, at least at the user level.

In fact, I thought the Forth standard conflict can easily be resolved using my arbitrary alias method -- every body can keep a t_alias (alias table) -- you can realias any function / word as you like.

(More about Unity Tree, Primitive Tree, Reverse Polish Expression as a Universal Interface Language to all programming languages .... later ....)

[hughag...@gmail.com]

On Tuesday, December 19, 2017 at 2:30:31 AM UTC-7, a...@littlepinkcloud.invalid wrote:
> As Elizabeth alluded to, there was always a tension between the
> industrial users of Forth (who originally were all customers of Forth
> Inc.) and the enthusiasts of the Forth Interest Group who loved
> Forth's flexibility and had fun playing with language. There's some
> scope for that tension to be creative, but there's also the
> possibility of Forth 20xx becoming irrelevant to an important group of
> users.

Andrew Haley worked for Forth Inc. --- he taught the novice class at Forth Inc. when Elizabeth Rather wasn't teaching it herself.
He routinely supports everything that she says, as he is doing in this post.

He is creating a false dichotomy between hobbyists (users of FIG-Forth) and professionals (customers of Forth Inc.).

The truth is that PolyForth from Forth Inc. for MS-DOS was a joke.
PolyForth used a single 64KB segment for:
all of the machine-code (both the compiler and the application code)
all of the threaded-code (both the compiler and the application code)
all of the dictionary headers and other data used by the compiler
all of the application data

This is much worse than QBASIC that used a single 64KB segment for the application code and application data,
but had the machine-code, the compiler and symbol table, etc., in other 64KB segments.
All in all, QBASIC was better than PolyForth in every way! Of course, Quick-BASIC, Quick-C and Quick-Pascal were better than QBASIC, but they cost money.

In MS-DOS days, the primary professional Forth system was UR/Forth from LMI.
There were other good systems, such as Tom Almy's, etc.. All of the free Forth systems, such as FPC and TCOM were superior to PolyForth.
The only exception was FIG-Forth that was worse than PolyForth. FIG-Forth was a pirated version of Charles Moore's original Forth.
Elizabeth Rather wanted to sue FIG and stop them from distributing FIG-Forth --- stop anybody anywhere from distributing any Forth at all.
Charles Moore allowed FIG to continue distributing FIG-Forth on the promise that they wouldn't upgrade it.

I wrote MFX in UR/Forth --- it cross-compiled code for the MiniForth processor ---
the MiniForth was used in motion-control boards in CNC machiens(an "industrial use").

On Tuesday, December 19, 2017 at 4:44:15 PM UTC-7, Elizabeth D. Rather wrote:
> On 12/18/17 4:53 PM, dxf...@gmail.com wrote:
> > On Sunday, December 10, 2017 at 8:57:15 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> >> Elizabeth D. Rather <era...@forth.com> wrote:
> >>
> >>> For the most part, at least the ones I'm in contact with are in the "if
> >>> it ain't broke, don't fix it" camp. They don't see much value in the
> >>> issues being debated. I can't speak for him, but I suspect that the
> >>> reason Leon participates is to try to minimize breakage.
> >>
> >> I don't speak for him either, but I'm pretty sure that's not the omly
> >> reason, even though it's surely a very big part of it.
> >>
> >> Andrew.
> >
> > Can you even pretend to have a 'Forth Standard'
> > without Forth Inc. Seems to me FI is there to
> > save friends from embarrassment. FI is stuck
> > 'between a rock and a hard place'.
>
> The major vendors are certainly necessary for a meaningful standard.
> FORTH, Inc. is committed to the process.

Elizabeth Rather is an awesome sales-person!

[Alex]

On 20-Dec-17 01:47, dxf...@gmail.com wrote:
> There never was a community in Forth to split.
> It's had individuals who adopted or rejected
> ideas as they arose. One of those ideas - a
> standard for Forth - Chuck himself rejected.
> If Forth users have anything in common, it has
> been their refusal to accept the dictates of
> a few.

I think you are misunderstanding Chuck's position (perhaps because of
founder mythology written here and elsewhere over the years).

"This optimism [about work on the ANS BASIS document] abated somewhat
when Charles Moore, the founder of the Forth language, left the meeting
abruptly after one of his proposals was defeated."

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1989/8902/8902n/8902n.htm

Having slammed the door on compromise or consensus in meeting 5, he
didn't return to X3J14 committee meetings until the final meeting 7
where he gave opinion on where the committee had made serious errors.

This was his address:
http://www.complang.tuwien.ac.at/forth/ftp.dei.isep.ipp.pt/pub/forth/docs/cm891023

But then, after all this crash bang wallop, Chuck says right at the end;

"I have the most to gain from a successful standard, even though I
cannot participate in it, except in review or critique"

and

"I think we're here because we think a standard would be good for Forth.
... The standard as a documentation and communication language is a
laudable goal...a useful tool that we've never had."

Chuck appears to have railed against a standard that wasn't in agreement
with his vision. But he did not reject the concept of a Forth standard;
his own words state quite clearly that he thought otherwise.

--
Alex

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>Having slammed the door on compromise or consensus in meeting 5, he
>didn't return to X3J14 committee meetings until the final meeting 7
>where he gave opinion on where the committee had made serious errors.
>
>This was his address:
>http://www.complang.tuwien.ac.at/forth/ftp.dei.isep.ipp.pt/pub/forth/docs/cm891023

I doubt that Meeting 7 in 1989 was the final meeting for Forth-94.

>But then, after all this crash bang wallop, Chuck says right at the end;
>
>"I have the most to gain from a successful standard, even though I
>cannot participate in it, except in review or critique"
>
>and
>
>"I think we're here because we think a standard would be good for Forth.
>... The standard as a documentation and communication language is a
>laudable goal...a useful tool that we've never had."
>
>Chuck appears to have railed against a standard that wasn't in agreement
>with his vision. But he did not reject the concept of a Forth standard;
>his own words state quite clearly that he thought otherwise.

In any case, looking at his further actions (e.g., renaming XOR into
OR in machineForth/ColorForth), he seems to have concluded that the
things that a standard is good for, i.e., program portability and, if
not that, programmer portability, are not relevant to him.

[Alex]

On 20-Dec-17 12:38, Anton Ertl wrote:
> Alex <al...@rivadpm.com> writes:
>> Having slammed the door on compromise or consensus in meeting 5, he
>> didn't return to X3J14 committee meetings until the final meeting 7
>> where he gave opinion on where the committee had made serious errors.
>>
>> This was his address:
>> http://www.complang.tuwien.ac.at/forth/ftp.dei.isep.ipp.pt/pub/forth/docs/cm891023
>
> I doubt that Meeting 7 in 1989 was the final meeting for Forth-94.

Yes, sloppy on my part; I meant to say "until his final meeting". I
believe he resigned then from the official committee. Elizabeth probably
knows the details, since she was chair & present at that meeting (not
that it's of much import tbf).

> In any case, looking at his further actions (e.g., renaming XOR into
> OR in machineForth/ColorForth), he seems to have concluded that the
> things that a standard is good for, i.e., program portability and, if
> not that, programmer portability, are not relevant to him.

From what I've read, Chuck ploughed a one man (plus Jeff Fox?) furrow
for much of the rest of his career, so no, neither of the portability
considerations would appear to have been of interest to him. OR and XOR
appear to have been accidental casualties of his unorthodox approach. I
can think of others; for example, his rejection of most of the keys of a
standard keyboard, where he limited himself to his own particular 27 keys.

There are still some here who think this means that Chuck "cast out all
them that sold and bought in the temple, and overthrew the tables of the
moneychangers". All they're really doing is using his idiosyncrasies to
promote their Forth purity tests.

--
Alex

[Alex]

On 19-Dec-17 18:44, Matthias Trute wrote:
>>> It has considerably reduced the meta-junk
>>> needed to support meta-compilation.)
> I'd like to see some examples, if possible. PM is ok (NDA assured).

I'm modifying it as I write. It's still a bit messy, and when it's
neater, I will put it up on https://github.com/alextangent/wf32 as a new
version.

The idea is simple; instead of the standard recognizer having this
DT:SINGLE;

: plit postpone literal ;

' noop
' plit
:noname plit postpone plit ;
dt-token value dt:single ( n -- )

I can replace it with a meta version.

: mlit postpone mliteral ; \ mliteral builds a meta literal

' noop
' mlit
:noname plit postpone mlit ; \ plit is correct here
dt-token to dt:single ( n -- )

All the recognizers that return DT:SINGLE continue to work in
meta-compilation without having to rewrite them, because the action is
divorced from the parse.

(In practice I replace the FORTH-RECOGNIZER list with META-RECOGNIZER
list, so that there's exactly one place where we switch from standard to
meta compilation.)

Great factoring!

--
Alex

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>On 12/19/17 12:07 PM, Anton Ertl wrote:
>> The standards still have value in usually having more commonality in
>> the non-standard programs (glorified as "programmer portability" by
>> those who are happy with this state of affairs).
>
>I think there are a number of programs that are standard in the sense
>that they document all the dependencies, etc., that are called for.

What number? 10? Probably not more than 100. And who knows if they
really documented all the dependencies? But, as explained below, that
does not matter.

>The
>standards achieve their primary purpose if this is done, by highlighting
>the things a programmer seeking to port the program to another
>environment needs to know about.

I probably have done more porting of Forth programs between systems
than most, and in no case have the program documentation requirements
been a help in that task. Nor have the systems documentation
requirements been a help in that task, or in the task of writing a
program.

> How many C programs have no compiler or
>platform dependencies?

Shifting the goalposts? In practice, I have had much a much better
experience when porting C code between C compilers than when porting
Forth code between Forth compilers. E.g., even Gforth, which was
written to work with gcc actually works with clang, too. And in the
1990s (when there were lots of different Unix variants around, on
various hardware), the typical experience was that a C program
developed for another Unix variant would compile with gcc or the C
compiler for the present hardware, with a few tweaks in config.h (more
advanced programs had a "configure" script, that did the tweaking
automatically).

And the reason is not that the C standard is a better standard (it
isn't), the reason is that C compiler writers show more interest in
program portability than Forth compiler writers and vendors. And the
lack of interest of the Forth compiler vendors is readily visible in
the glorification of "programmer portability" and program
documentation requirements.

[hughag...@gmail.com]

This is why Anton Ertl lost his job as Forth-200x chair-person --- lack of loyalty to Elizabeth Rather.

The purpose of a standard is program portability.
Elizabeth Rather believes that the purpose of the standard is "programmer portability" ---
this means that ANS-Forth is a teaching tool for novices to learn the basics of Forth (DUP SWAP etc.) before they apply for a job at Forth Inc..

Any programmer who claims that his program is "ANS-Forth compliant" because he has documented its dependencies, has only documented his own stupidity!

ANS-Forth is a cult --- Elizabeth Rather says that any Forth without her approval is not "meaningful" --- all cults claim a monopoly on meaningfulness.

[a...@littlepinkcloud.invalid]

Alex <al...@rivadpm.com> wrote:
> On 19-Dec-17 09:30, a...@littlepinkcloud.invalid wrote:
>> Alex <al...@rivadpm.com> wrote:
>>> On 18-Dec-17 10:27, a...@littlepinkcloud.invalid wrote:
>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>> a...@littlepinkcloud.invalid writes:
>>
>>> A NUMBER-CONVERSION does two things. It tests if the string has been
>>> converted, and if it has not been converted, it tries to recognize the
>>> string as a specific type of number. If it succeeds, it returns two
>>> parts. It converts the string to a single, double or float for later
>>> use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
>>> it).
>>>
>>> A recognizer does just exactly one thing. It tries to recognize the
>>> string as a specific type of thing. If it succeeds, If it succeeds, it
>>> returns two parts. It converts the string to a thing and provides a
>>> thing token for later use. The thing token provides XTs to EXECUTE
>>> COMPILE, and POSTPONE the thing.
>>
>> So, the recognizer is not doing exactly one thing, is it? It's doing
>> one thing, and then one of three things.
>
> As compared with two things and one of two things, neatly avoiding
> POSTPONE.

I don't understand this comment.

>> It can have arbitrary effects, including even reading ahead in the
>> input stream.
>
> Any word can do that; it's not specific to recognizers. SwiftForth's
> NUMBER-CONVERSION words can do pretty much what they like, and there
> are many ANS Forth examples of reading ahead. It is not required but
> neither is it prevented (and as I believe you have said before,
> Forth doesn't stop you from doing stupid stuff). I don't understand
> why you call out recognizers in this regard.

An implementation doesn't stop you from doing these things, no. But
there is the question of what the specification should permit.

>> Essentially, rather than the classical Forth interpreter we now have a
>> user-written interpreter that can do anything at all. The only thing
>> the system's interpreter has left is a loop: the rest is the
>> recognizers.
>
> Here's without, and a system that closely resembles NUMBER-CONVERSION
> (it's from Win32Forth):
>
> : INTERPRET ( -- )
> BEGIN BL WORD DUP C@
> WHILE FIND ?DUP
> IF STATE @ =
> IF COMPILE, \ COMPILE TIME
> ELSE EXECUTE ?STACK \ INTERPRET
> THEN
> ELSE NUMBER NUMBER,
> THEN
> REPEAT DROP ;
>
> NUMBER is the equivalent of NUMBER-CONVERSION.

That looks like it.

> : default-recognize ( addr u -- i*x xt )
> forth-recognizer recognize state @ cells- @ ;
>
> : interpreter ( -- )
> begin
> ?stack parse-name dup
> while
> default-recognize execute
> repeat 2drop ;
>
> Which operates in exactly the same way as the current loop and
> permits ANS code to be interpreted and compiled exactly the same
> way; and as been explained already, the interpreter loop does not
> need to change if the system's author doesn't want to provide
> anything more than number conversion.
>
> The latter recognizer scheme is extensible. The former is locked into
> only supporting whatever can be handled by NUMBER, (which is not
> extensible).

Exactly. I'm not sure what your point is?

>>> In this case, it's a simplification that has pointed away from the
>>> road to hell, which is paved with STATEs. Recognizers do their
>>> parsing at the right time, rather than at the wrong time; with the
>>> result that we have TO, S" and other standardized parsing words, and
>>> Hugh's hellish novice package which scatters STATE like confetti at
>>> Forthzilla's wedding.
>>
>> STATE is not a problem, so let's get that out of the way: to avoid
>> problems with STATE, don't use STATE. Problem solved: it doesn't need
>> any solution that can be solved by recognizers. That's already been
>> dealt with at length already. TO and S" should never have been
>> standardized in their present form.
>
> But they were standardized, and recognizers provide a solution; the
> parse and the action are cleanly separated, and the temptation to
> use STATE is eliminated. In fact, the writer of a recognizer can't
> use STATE productively at all. To avoid problems with STATE, use
> recognizers.

There's no need. Like I said.

>> Sure, the problems of TO and S" can be worked around with
>> recognizers, but you don't get clean and simple systems by patching
>> up old mistakes with new ones.
>
> The proposal is not even suggesting that (although I've shown how it can
> be done).

Perhaps not, but your preceding paragraph suggests exactly that. I
don't see how it's possible even to have a conversation if your
paragraphs contradice each other.

>>>>> My impression is that the opposition to recognizers knows that
>>>>> technically they have no leg to stand on, that's why they avoid any
>>>>> technical discussion of recognizers like the plague, and instead
>>>>> throw around emotional appeals like "WIBNI", "main battle tank", or
>>>>> "language of the month", and (not so recently) "make Forth more like
>>>>> C".
>>>>
>>>> I can turn that around easily enough: there is no strictly technical
>>>> argument in their favour either. It's a matter of some people who
>>>> like to use this kind of language feature and some who don't.
>>>
>>> There is a technical argument. Recognizers provide correct parsing
>>> and uniform treatment of numbers and words, and as such are proposed
>>> for standardization.
>>
>> Well, yes, for people who care about that sort of thing. But since
>> when was "correct parsing and uniform treatment of numbers and words",
>> whatever that means, one of the desiderata of Forth anyway? It's no
>> more than an ad hoc rationalization invented by people who like
>> recognizers.
>
> Which I suspect is the attitude that got us S".

No, really it isn't. It's the *exact opposite* of that attitude. S"
(and the whole interpretation/compilation semantics mess) is due to a
misplaced desire to have dual words: those which did different things
in interpret and compile state. On the other hand, CHAR and [CHAR]
are cleanly separated.

>> As Elizabeth alluded to, there was always a tension between the
>> industrial users of Forth (who originally were all customers of Forth
>> Inc.) and the enthusiasts of the Forth Interest Group who loved
>> Forth's flexibility and had fun playing with language. There's some
>> scope for that tension to be creative, but there's also the
>> possibility of Forth 20xx becoming irrelevant to an important group of
>> users.
>
> Strangely, this is where we agree.
>
> I don't believe that the proposal is anywhere near ready for
> standardization, and I've said so in other posts.
>
> A cautious approach will probably suit the vendors on the Forth200x
> committee, since in my experience there's usually little appetite from
> vendors for gratuitous change or spandrels and curlicues. I work in the
> standards part of my company; we're change averse unless there's a very
> demonstrable use case. That is, in general something has to go faster,
> be done more cheaply, or there's a need talk to someone else's products
> fr example.
>
> But I recognize (excuse the pun) that something very like the
> recognizers proposal is inevitable, since it extends the concept of
> parsing to flexibly and simply support new forms of representing
> numbers, and tokenizing on other than blanks for words like
> object.method names. Perhaps even reading ahead in the input stream.
> That's a lot from a few lines of code.

That's true, it is.

> That means I'm going to explore it further, and I'll keep commenting on
> what I find, time permitting.

OK, that sounds good.

>>> (And as an aside I would not go back to pre-recognizers and
>>> implement it. In my Forth, recognizers now an integral part of
>>> meta-compilation, where exactly the same recognizers are used to
>>> parse the Forth source, but a different set of action tokens does
>>> the meta-compilation. It has considerably reduced the meta-junk
>>> needed to support meta-compilation.)
>>
>> I'm sure you could do it that way, but you could have equally easily
>> written the interpreter loop. Given that the only thing in the
>> interpreter loop in a system that uses recognizers is the loop itself,
>> there can't be much difference.
>
> That's the way it was.
>
> I'm not a big fan of writing/debugging/maintaining nearly but not quite
> the same thing twice. I quite like the idea of having the meta-compiler
> use the current version and code already in the compiler, rather than
> having to add duplicate but subtly different stuff to the meta-compiler.

I get that, but it is possible to over-factor code, even in Forth, and
this strikes me as an example of over-factoring.

> Why duplicate S" TO CONSTANT VALUE VARIABLE : and so on as well? Because
> they're all parsing words, hence the requirement to meta-recognize them.
> There are other issues too around STATE while meta-compiling, but I'll
> not bore you with the details.
>
> This support code becomes quite large quite rapidly. It's currently 1600
> lines or so, and I reckon it need be no bigger than 1000; that's a big
> lump of code.

Lordy. I've never seen a Forth meta-compiler that large.

Andrew.

[a...@littlepinkcloud.invalid]

dxf...@gmail.com wrote:
> On Tuesday, December 19, 2017 at 8:34:16 PM UTC+11, a...@littlepinkcloud.invalid wrote:
>> dxf...@gmail.com wrote:
>> > On Sunday, December 10, 2017 at 8:57:15 PM UTC+11, a...@littlepinkcloud.invalid wrote:
>> >> Elizabeth D. Rather <era...@forth.com> wrote:
>> >>
>> >> > For the most part, at least the ones I'm in contact with are in the "if
>> >> > it ain't broke, don't fix it" camp. They don't see much value in the
>> >> > issues being debated. I can't speak for him, but I suspect that the
>> >> > reason Leon participates is to try to minimize breakage.
>> >>
>> >> I don't speak for him either, but I'm pretty sure that's not the omly
>> >> reason, even though it's surely a very big part of it.
>> >
>> > Can you even pretend to have a 'Forth Standard' without Forth
>> > Inc.
>>
>> Not really, no. That would be a split in the community along the
>> lines of Common Lisp, and no-one wants that.
>
> There never was a community in Forth to split.

And you would know this how, exactly?

> It's had individuals who adopted or rejected ideas as they
> arose. One of those ideas - a standard for Forth - Chuck himself
> rejected. If Forth users have anything in common, it has been their
> refusal to accept the dictates of a few.

I do not believe that. Firstly, what does it even mean? What are
these "dictates"? There have been community-creasted standards since
1979. (Even 1978, if you want to count that one.)

>> > Seems to me FI is there to save friends from embarrassment. FI is
>> > stuck 'between a rock and a hard place'.
>>
>> In what way?
>

> FI's reluctance to implement 200x features while at the same time
> being on the committee.

You're making an error here. There never has been any requirement for
anyone to implement all of the standard. The whole idea of optional
worsdets is that they are optional.

Andrew.

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>
>> How many C programs have no compiler or
>>platform dependencies?
>
> Shifting the goalposts? In practice, I have had much a much better
> experience when porting C code between C compilers than when porting
> Forth code between Forth compilers. E.g., even Gforth, which was
> written to work with gcc actually works with clang, too.

That doesn't count because clang has been forced to copy many of
GCC's idiosyncracies.

> And in the 1990s (when there were lots of different Unix variants
> around, on various hardware), the typical experience was that a C
> program developed for another Unix variant would compile with gcc or
> the C compiler for the present hardware, with a few tweaks in
> config.h (more advanced programs had a "configure" script, that did
> the tweaking automatically).

People had to do a ton of work with autoconf and automake (big,
complicated programs) for such advanced programs to work.

Andrew.

[Anton Ertl]

a...@littlepinkcloud.invalid writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> a...@littlepinkcloud.invalid writes:
>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>> On interpreting an FP number, the number is put on the FP stack by
>>>> REC-FLOAT/FNUMBER?, and nothing else (NOOP) needs to be done. The
>>>> NUMBER-CONVERSION mechanism does not allow specifying something extra
>>>> to do on interpretation, so you cannot use it to replace TO X (with
>>>> e.g., ->X), you cannot use it to recognize ordinary words (so
>>>> SwiftForth hard-codes the word recognizer into the text interpreter),
>>>> and you cannot use it to implement a dot-parser.
>>>
>>>Exactly so: as I said, NUMBER-CONVERSION is a simple mechanism, and it
>>>cannot do these things. That's what makes it better than recognizers:
>>>rather than a general-purpose language extension mechanism it handles
>>>user-defined literals.
>>
>> It's better because it can do less? Is this some kind of doublethink?
>
>I don't think it is. There's a great deal to be said for simple
>mechanisms which do a single thing in a simple way.

And there is a great deal to be said for a simple mechanism that can
do more things in a simple way.

>I know you don't
>much like talk of this kind, but it't the essence of Forth.

I don't think that limiting mechanisms to a single thing is the
essence of Forth, on the contrary: being able to use a single
mechanism for more is common in Forth. E.g., the return stack is not
just used for return addresses, but also for counted-loop parameters
and temporary values.

>> Given that every new feature can be declared as a "WIBNI", "WIBNI" is
>> useless as an argument for determining whether a feature is beneficial
>> or not (except if you deem every feature detrimental).
>
>No. I did explain quite carefully what a WIBNI is: it's what happens
>when you set out to do one thing, you notice that some other thing
>(not actually required by what you set out to do) can be done by
>extending your scope a little bit, you think "Wouldn't it be nice if
>we did that too", and iterate. It is the proverbial road to hell,
>paved with good intentions.

So extending the existing return stack (used by docol and ;s) with >R
R> R@, and moreover, with DO LOOP, paved the road to hell? Sure,
there are people who prefer separate stacks for these three purposes,
and it would follow your dogma of "mechanism which do a single thing
in a simple way", but Moore (and the majority of the Forth community)
actually choose to use a combined mechanism for these three purposes,
which requires additional words (i.e., added complexity to the return
stack mechanism), but reduces the overall implementation complexity.

>> My impression is that the opposition to recognizers knows that
>> technically they have no leg to stand on, that's why they avoid any
>> technical discussion of recognizers like the plague, and instead
>> throw around emotional appeals like "WIBNI", "main battle tank", or
>> "language of the month", and (not so recently) "make Forth more like
>> C".
>
>I can turn that around easily enough: there is no strictly technical
>argument in their favour either. It's a matter of some people who
>like to use this kind of language feature and some who don't.

And apparently the opposition to recognizers fear that too many people
like the additional features, that's why they avoid discussing them
and prefer throwing around phrases like "WIBNI", "main battle tank" or

"language of the month", and (not so recently) "make Forth more like
C".

>>>You don't make a good language by adding features that might be
>>>useful. It's impossible to prove that Feature X is detrimental by,
>>>say, measuring its length, however much people might demand
>>>"technical reasons", thereby trying to exclude anything that can't
>>>be measured.
>>
>> "Not measurable" is acceptable, then you have a qualitative argument.
>> However, emotional appeals don't advance the discussion and therefore
>> don't have a place there.
>
>Emotional appeals? Not at all, unless you are to classify all
>discussion of language design, elegance, and Forth's extreme
>simplicity as "mere emotion", in the vein of Mr Spock.

If you discuss them without referring to concrete properties of the
proposal, as you do, it is certainly not a technical discussion, and
obviously you only appeal to the emotions of the audience.

>> [WIBNI]

>> Actually, I was wrong; it means "The proposal is not already
>> implemented in or planned for VFX Forth" (so, e.g.,
>> <http://www.forth200x.org/twos-complement.html> was not WIBNI despite
>> not coming from Stephen Pelc). And it's what it means to Stephen
>> Pelc. And given that he introduced the term,
>
>He didn't. He might even have got it from me; I got it from Chris
>Stephens. But it might just have been in the air.

Whoever came up with the term, and whatever it means to that person,
or to you, it has been "escalator"ed by Stephen Pelc. He used it
frequently and (in my presence) exclusively in recent years, and with
the meaning above.

>>>However, the WIBNI is a useful mental tool: whenever you have a
>>>program that you're creating and you think "With a little more work
>>>it could be made to do these other useful things too", that's a
>>>WIBNI. It happens when you have a job to do, you see something that
>>>*is not part of the requirements* but you see that by making your
>>>program just a little more complicated you can implement it. Forth,
>>>the language and system, is the result of resisting that pressure,
>>>as explained by Moore in his early writings.
>
>> Forth is the result of *not* following this principle. If Moore had
>> followed this principle, he would not have introduced an extensible
>> dictionary and a text interpreter, because that can always do more
>> than is required at any particular moment.
>
>Um, pardon? That makes no sense at all.

Why not?

>> There are different metrics for programs: implementation complexity,
>> generality, interface complexity, correctness, performance, etc.
>> Chuck Moore favours minimal implementation complexity over the others
>> more than most programmers, but as Forth shows, he does not do it
>> exclusively. More relevant to the present discussion: he does not
>> avoid generality just for the sake of being less general.
>
>No, of course not.

But your only complaint that I could identify has been that the
proposal is too general. It has not been about the implementation
complexity or anything else.

>> Concerning the requirements, one of the requirements for a text
>> interpreter that is not a WIBNI (in the original sense) is the ability
>> to support a dot-parser.
>
>Is it? Says who?

Ask Stephen Pelc, whether he thinks that a dot-parser is a WIBNI, and
if so, why VFX implements a dot-parser.

>> And this is not just useful for large systems, but also for small
>> ones. At the last Forth-Tagung Joerg Voelker talked about programming
>> a relatively large application on a small microcontroller. One of the
>> issues he had was the amount of space for stuff like structure field
>> names. E.g., if he has fields
>>
>> somename-x
>> somename-y
>> somename-z
>> anothername-w
>> anothername-x
>> anothername-y
>>
>> This takes quite some space on his chip. Instead, one could have two
>> wordlists:
>>
>> SOMENAME containing X Y Z
>> ANOTHERNAME containing W X Y
>>
>> which saves some space, and then use a dot-parser to access SOMENAME.X
>> and ANOTHERNAME.X.
>>
>> So it's not as if the additional features of the proposed recognizers
>> were for things for which there are no requirements.
>
>So, I think the question is about "one shot" wordlists. Are you
>really saying that a dot parser is needed for that?

Having one-shot vocabularies would be another way to solve this
problem, but is it really better in any way?

Is the implementation complexity lower? Doubtful. You need an extra
hook in the interpreter for either searching the vocabulary, or for
restoring the search order afterwards, and you need some new mechanism
that works at parse time that actually sees that the word sets up a
one-shot vocabulary lookup and deals with it.

Is the interface complexity lower? No. SOMENAME X looks like a
sequence of two Forth words, into which you can insert a comment, or
"1 DROP" etc, but in reality these two lexemes belong together, just
like SOMENAME.X. Only in the latter case it is obvious, and that's
what makes it better.

We put some parts of the implementation for one-shot vocabularies into
Gforth several years ago (resulting in 35 SLOC that contain "prelude",
plus additional code around it), but never finished this work; the
limitations of those things that could be straightforwardly
implemented were too restrictive to make it appear worthwhile to go
further, and I never found a way that was worthwhile.

Gforth has a scope recognizer (not quite as powerful as VFX's
dot-parser, but pretty much in line with what one-shot vocabularies
could do) that takes 13 SLOC.

So if we have a need for something like one-shot vocabularies, is a
dot-parser implemented as a recognizer a good solution? Yes.

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>A NUMBER-CONVERSION does two things. It tests if the string has been
>converted, and if it has not been converted, it tries to recognize the
>string as a specific type of number. If it succeeds, it returns two
>parts. It converts the string to a single, double or float for later
>use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
>it).

Actually one could also use NUMBER-CONVERSION for POSTPONE, but
SwiftForth does not do it.

[Alex]

On 22-Dec-17 15:28, a...@littlepinkcloud.invalid wrote:
> Alex <al...@rivadpm.com> wrote:
>> On 19-Dec-17 09:30, a...@littlepinkcloud.invalid wrote:
>>> Alex <al...@rivadpm.com> wrote:
>>>> On 18-Dec-17 10:27, a...@littlepinkcloud.invalid wrote:

>
>>> It can have arbitrary effects, including even reading ahead in the
>>> input stream.
>>
>> Any word can do that; it's not specific to recognizers. SwiftForth's
>> NUMBER-CONVERSION words can do pretty much what they like, and there
>> are many ANS Forth examples of reading ahead. It is not required but
>> neither is it prevented (and as I believe you have said before,
>> Forth doesn't stop you from doing stupid stuff). I don't understand
>> why you call out recognizers in this regard.
>
> An implementation doesn't stop you from doing these things, no. But
> there is the question of what the specification should permit.

I've worked on a lot of specifications, and I'm struggling to think of
any where the tech committees denied permission for one specific feature
that was generally available elsewhere, because reasons.

The proposal does not suggest that parsing is a requirement; it's
mentioned once in the normative text as a possibility (and the same
possibility is available to any word executed by the interpreter; see \
for example).

----
The parsing word must not change the string. Since it is called from
the interpreter, it may access SOURCE and, if applicable, change >IN. If
>IN is not used, any string may serve as input, otherwise "addr/len" is
assumed to be a substring of the buffer SOURCE.
----

(I don't like the way this part is phrased, but that's a separate issue.)

>
>>> Sure, the problems of TO and S" can be worked around with
>>> recognizers, but you don't get clean and simple systems by patching
>>> up old mistakes with new ones.
>>
>> The proposal is not even suggesting that (although I've shown how it can
>> be done).
>
> Perhaps not, but your preceding paragraph suggests exactly that. I
> don't see how it's possible even to have a conversation if your
> paragraphs contradice each other.

What contradiction? The proposal for recognizers (which I presume you've
at least skimmed) does not supply, demonstrate, recommend or mention TO
S" or "fixing" any other parsing words at all. I'm not suggesting that
the proposal mentions them either.

>>
>> I'm not a big fan of writing/debugging/maintaining nearly but not quite
>> the same thing twice. I quite like the idea of having the meta-compiler
>> use the current version and code already in the compiler, rather than
>> having to add duplicate but subtly different stuff to the meta-compiler.
>
> I get that, but it is possible to over-factor code, even in Forth, and
> this strikes me as an example of over-factoring.

It's certainly less code, which is always less error prone and easier to
maintain.

>
>> Why duplicate S" TO CONSTANT VALUE VARIABLE : and so on as well? Because
>> they're all parsing words, hence the requirement to meta-recognize them.
>> There are other issues too around STATE while meta-compiling, but I'll
>> not bore you with the details.
>>
>> This support code becomes quite large quite rapidly. It's currently 1600
>> lines or so, and I reckon it need be no bigger than 1000; that's a big
>> lump of code.
>
> Lordy. I've never seen a Forth meta-compiler that large.

Yes, it needs to go on a diet.

Building the executable (a PE) takes around 400-500 lines of code alone
(plus a large number of comments.) It doesn't use wrapper code to load
an image; that I know would be much easier.

32 bit executables need to be relocated at load time (huge relocation
tables are needed) or built pre-relocated at meta-compile time (the
method I have chosen). The code to support that is pretty significant;
300-400 lines I reckon. A 64 bit RIP image would be a lot less expensive.

>
> Andrew.
>


--
Alex

[Anton Ertl]

a...@littlepinkcloud.invalid writes:

>Alex <al...@rivadpm.com> wrote:
>> A NUMBER-CONVERSION does two things. It tests if the string has been
>> converted, and if it has not been converted, it tries to recognize the
>> string as a specific type of number. If it succeeds, it returns two
>> parts. It converts the string to a single, double or float for later
>> use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
>> it).
>>
>> A recognizer does just exactly one thing. It tries to recognize the
>> string as a specific type of thing. If it succeeds, If it succeeds, it
>> returns two parts. It converts the string to a thing and provides a
>> thing token for later use. The thing token provides XTs to EXECUTE
>> COMPILE, and POSTPONE the thing.
>
>So, the recognizer is not doing exactly one thing, is it? It's doing
>one thing, and then one of three things.

NUMBER-CONVERSION can be used to do the same (but is not used by
POSTPONE in SwiftForth). The difference is in the kind of things that
can be recognized; NUMBER-CONVERSION can only recognize things where
the compilation semantics is to perform the interpretation semantics
and then some more; typically literals (including non-numbers) where
the compilation semantics is to perform the interpretation semantics
followed by POSTPONE LITERAL or somesuch. The proposed recognizers do
not have this limitation, and can be used for Forth words.

> It can have arbitrary
>effects, including even reading ahead in the input stream.

NUMBER-CONVERSION can do the same. That's not the difference, either.

>Essentially, rather than the classical Forth interpreter we now have a
>user-written interpreter that can do anything at all. The only thing
>the system's interpreter has left is a loop: the rest is the
>recognizers.

Right. A simple structure that gives lots of power - and
responsibility - into the hands of programmers.

>STATE is not a problem, so let's get that out of the way: to avoid
>problems with STATE, don't use STATE.

And don't use any code from anybody else that uses STATE. And given
that many Forth programmers consider the problems of STATE to be
acceptable for the things they want to accomplish, it means not using
a good part of the little code that is available.

We failed to convince these programmers to not use STATE. Why?
Because we provide no alternative. And for a significant part of the
usage of STATE (e.g., words like S" and TO), recognizers are an
alternative.

>That's already been
>dealt with at length already. TO and S" should never have been
>standardized in their present form.

And yet they were; and IS and ACTION-OF, and S\". Maybe you should
adjust your view to reality.

> Sure, the problems of TO and S"
>can be worked around with recognizers, but you don't get clean and
>simple systems by patching up old mistakes with new ones.

Yet another empty phrase that appeals to emotions. You actually do
get clean and simple systems by replacing dirty code (such as code
using STATE) with clean and simple code.

Of course, given that we are talking about a language standard, it
will be a long time before we get rid of S", TO etc. in the standard
(and then they will probably remain in the systems), but if we do not
provide a better alternative, it will never happen.

[Alex]

On 22-Dec-17 16:45, Anton Ertl wrote:
> Alex <al...@rivadpm.com> writes:
>> A NUMBER-CONVERSION does two things. It tests if the string has been
>> converted, and if it has not been converted, it tries to recognize the
>> string as a specific type of number. If it succeeds, it returns two
>> parts. It converts the string to a single, double or float for later
>> use, along with an XT that EXECUTEs or COMPILE,s it (but can't POSTPONE
>> it).
>
> Actually one could also use NUMBER-CONVERSION for POSTPONE, but
> SwiftForth does not do it.

Presumably by extending the sins of STATE to some NUMBER-CONVERSION and
POSTPONE value fro communication between the two; which we could call
EIGENSTATE.

--
Alex

[Anton Ertl]

\ for SwiftForth
: postpone
bl word find dup if
0< if ( non-immediate word )
postpone literal postpone compile,
else ( immediate word )
postpone compile,
then
else ( c-addr 0 )
drop count 0 is-number? dup if
dup >r execute r> compile,
else
." ?" abort
then
then ; immediate

\ testing
: foo postpone 1 postpone + ; immediate
: bar foo ;
see bar

shows

8083A5F 1 # EBX ADD 83C301
8083A62 RET C3 ok

No STATE here. NUMBER-CONVERSION is wrapped in IS-NUMBER?. It is
instructive to compare this to the POSTPONE from the recognizer
proposal:

: POSTPONE ( "name" -- )
PARSE-NAME FORTH-RECOGNIZER RECOGNIZE DUP >R
RECTYPE>POST EXECUTE R> RECTYPE>COMP COMPILE, ;

The recognizer POSTPONE just calls the interpreter loop with
FORTH-RECOGNIZER RECOGNIZE. By contrast, the for-SwiftForth POSTPONE
has to reimplement the body of the interpreter loop, complete with
FIND, immediacy-checking, and number handling. And the thing that
makes POSTPONE different is mixed in somewhere. So the recognizers
lead to better factoring here.

Onwards to what we do for literals: This is slightly more obvious in
the code for SwiftForth:

( num xt ) dup >r execute r> compile,

The xt is the xt for LITERAL or somesuch: we first EXECUTE it to
compile num into the present word, then COMPILE, it to compile it into
the word that is compiled when the present word is executed.

In the recognizer version, the code is almost the same, except that
there is RECTYPE>POST and RECTYPE>COMP inserted to get from the
rectype-token to the right xt. And because the xts may be different
(that's what gives the recognizers their additional flexibility),
there are two different words used here to access them.

[Alex]

On 22-Dec-17 18:11, Anton Ertl wrote:
> Alex <al...@rivadpm.com> writes:
>> On 22-Dec-17 16:45, Anton Ertl wrote:
>>> Actually one could also use NUMBER-CONVERSION for POSTPONE, but
>>> SwiftForth does not do it.
>>
>> Presumably by extending the sins of STATE to some NUMBER-CONVERSION and
>> POSTPONE value fro communication between the two

Thanks Anton.

>
> \ for SwiftForth
> : postpone
> bl word find dup if

but I was trying for a very bad German joke.

eigenstate: a quantum-mechanical state corresponding to an eigenvalue of
a wave equation.

Alternatively

eigen state: own state.

Own vs undecided quantum value. (Sorry, I'll not try that again!)

Or, if STATE can be -2; (the essence is)

: default-recognize ( addr u -- i*x xt )
forth-recognizer recognize state @ cells- @ ;

: postpone ( -<name>- ) \ postpone next word
-2 state !
parse-name default-recognize execute
] ; immediate \ reset state

> By contrast, the for-SwiftForth POSTPONE
> has to reimplement the body of the interpreter loop, complete with
> FIND, immediacy-checking, and number handling. And the thing that
> makes POSTPONE different is mixed in somewhere. So the recognizers
> lead to better factoring here.

That is the whole point. Andrew seems to have some kind of problem with
this; he has described not writing an interpreter loop in the
meta-compiler as over-factoring.

>
> Onwards to what we do for literals: This is slightly more obvious in
> the code for SwiftForth:
>
> ( num xt ) dup >r execute r> compile,
>
> The xt is the xt for LITERAL or somesuch: we first EXECUTE it to
> compile num into the present word, then COMPILE, it to compile it into
> the word that is compiled when the present word is executed.
>
> In the recognizer version, the code is almost the same, except that
> there is RECTYPE>POST and RECTYPE>COMP inserted to get from the
> rectype-token to the right xt. And because the xts may be different
> (that's what gives the recognizers their additional flexibility),
> there are two different words used here to access them.

Yes.

>
> - anton
>


--
Alex

[m...@iae.nl]

On Saturday, December 23, 2017 at 12:09:44 AM UTC+1, Alex wrote:
[..]

> but I was trying for a very bad German joke.
>
> eigenstate: a quantum-mechanical state corresponding to an eigenvalue of
> a wave equation.

Very minor point: 'quantum-mechanical' is overly restrictive.
Eigenvalues and eigenvectors are all over linear algebra.

-marcel

[a...@littlepinkcloud.invalid]

Alex <al...@rivadpm.com> wrote:
> On 22-Dec-17 15:28, a...@littlepinkcloud.invalid wrote:
>> Alex <al...@rivadpm.com> wrote:
>>> On 19-Dec-17 09:30, a...@littlepinkcloud.invalid wrote:
>>>> Sure, the problems of TO and S" can be worked around with
>>>> recognizers, but you don't get clean and simple systems by patching
>>>> up old mistakes with new ones.
>>>
>>> The proposal is not even suggesting that (although I've shown how it can
>>> be done).
>>
>> Perhaps not, but your preceding paragraph suggests exactly that. I
>> don't see how it's possible even to have a conversation if your
>> paragraphs contradice each other.
>
> What contradiction? The proposal for recognizers (which I presume you've
> at least skimmed) does not supply, demonstrate, recommend or mention TO
> S" or "fixing" any other parsing words at all. I'm not suggesting that
> the proposal mentions them either.

Well, I'm baffled. You're either advocating fixing the problems of S"
and TO with recognizers or you're not. You're either saying that's an
advantage of recognizers, and saying that's the way we should go, or
not.

>>> I'm not a big fan of writing/debugging/maintaining nearly but not quite
>>> the same thing twice. I quite like the idea of having the meta-compiler
>>> use the current version and code already in the compiler, rather than
>>> having to add duplicate but subtly different stuff to the meta-compiler.
>>
>> I get that, but it is possible to over-factor code, even in Forth, and
>> this strikes me as an example of over-factoring.
>
> It's certainly less code, which is always less error prone and easier to
> maintain.

Often, but not always.

> Building the executable (a PE) takes around 400-500 lines of code alone
> (plus a large number of comments.) It doesn't use wrapper code to load
> an image; that I know would be much easier.

It would. I would have thought you could generate PIC and save a
binary image, no relocs. I'm aware that PIC is a little slower at
runtime, though.

If PE is a part of your cross-compiler the size makes sense.

Andrew.

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> a...@littlepinkcloud.invalid writes:
>

>>STATE is not a problem, so let's get that out of the way: to avoid
>>problems with STATE, don't use STATE.
>
> And don't use any code from anybody else that uses STATE. And given
> that many Forth programmers consider the problems of STATE to be
> acceptable for the things they want to accomplish, it means not using
> a good part of the little code that is available.
>
> We failed to convince these programmers to not use STATE. Why?
> Because we provide no alternative. And for a significant part of the
> usage of STATE (e.g., words like S" and TO), recognizers are an
> alternative.
>
>>That's already been
>>dealt with at length already. TO and S" should never have been
>>standardized in their present form.
>
> And yet they were; and IS and ACTION-OF, and S\". Maybe you should
> adjust your view to reality.

I know what the situation is; that's not a matter of dispute.

Every programming language has its recommended good practices and its
known bad ones. These days the bad ones are called "anti-patterns".
Purging code of anti-patterns is frequently done in order to improve
code quality, reducing maintenance costs and improving
maintainability. Why should Forth be any different? STATE is an
anti-pattern, that's all.

>>Sure, the problems of TO and S" can be worked around with
>>recognizers, but you don't get clean and simple systems by patching
>>up old mistakes with new ones.
>
> Yet another empty phrase that appeals to emotions.

I't not empty. It's useful advice that benefits everyone involved in
any engineering activity, not just programming. Failure to heed it is
common.

> You actually do get clean and simple systems by replacing dirty code
> (such as code using STATE) with clean and simple code.
>
> Of course, given that we are talking about a language standard, it
> will be a long time before we get rid of S", TO etc. in the standard
> (and then they will probably remain in the systems), but if we do not
> provide a better alternative, it will never happen.

I completely agree.

Andrew.

[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:
>>> a...@littlepinkcloud.invalid writes:
>>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

>>No. I did explain quite carefully what a WIBNI is: it's what happens
>>when you set out to do one thing, you notice that some other thing
>>(not actually required by what you set out to do) can be done by
>>extending your scope a little bit, you think "Wouldn't it be nice if
>>we did that too", and iterate. It is the proverbial road to hell,
>>paved with good intentions.
>
> So extending the existing return stack (used by docol and ;s) with >R
> R> R@, and moreover, with DO LOOP, paved the road to hell?

Of course not.

>>> My impression is that the opposition to recognizers knows that
>>> technically they have no leg to stand on, that's why they avoid any
>>> technical discussion of recognizers like the plague, and instead
>>> throw around emotional appeals like "WIBNI", "main battle tank", or
>>> "language of the month", and (not so recently) "make Forth more like
>>> C".
>>
>>I can turn that around easily enough: there is no strictly technical
>>argument in their favour either. It's a matter of some people who
>>like to use this kind of language feature and some who don't.
>
> And apparently the opposition to recognizers fear that too many
> people like the additional features, that's why they avoid
> discussing them and prefer throwing around phrases like "WIBNI",
> "main battle tank" or "language of the month", and (not so recently)
> "make Forth more like C".

Some people find analogies useful, so try to understand why the writer
is using them. Perhaps you would if you tried. I repeat: there is no
strictly technical argument in favour of recognizers.

>>>>You don't make a good language by adding features that might be
>>>>useful. It's impossible to prove that Feature X is detrimental by,
>>>>say, measuring its length, however much people might demand
>>>>"technical reasons", thereby trying to exclude anything that can't
>>>>be measured.
>>>
>>> "Not measurable" is acceptable, then you have a qualitative argument.
>>> However, emotional appeals don't advance the discussion and therefore
>>> don't have a place there.
>>
>>Emotional appeals? Not at all, unless you are to classify all
>>discussion of language design, elegance, and Forth's extreme
>>simplicity as "mere emotion", in the vein of Mr Spock.
>
> If you discuss them without referring to concrete properties of the
> proposal, as you do, it is certainly not a technical discussion, and
> obviously you only appeal to the emotions of the audience.

You are choosing to restrict the notion of a "technical discussion" so
much that any notion of elegance and simplicity is excluded.

>>> [WIBNI]
>>> Actually, I was wrong; it means "The proposal is not already
>>> implemented in or planned for VFX Forth" (so, e.g.,
>>> <http://www.forth200x.org/twos-complement.html> was not WIBNI despite
>>> not coming from Stephen Pelc). And it's what it means to Stephen
>>> Pelc. And given that he introduced the term,
>>
>>He didn't. He might even have got it from me; I got it from Chris
>>Stephens. But it might just have been in the air.
>
> Whoever came up with the term, and whatever it means to that person,
> or to you, it has been "escalator"ed by Stephen Pelc. He used it
> frequently and (in my presence) exclusively in recent years, and
> with the meaning above.

Good for him. There are always pressures which conspire to add
features to Forth. "After all, it only takes a half-dozen
instructions; so why not? The only opposing pressure is the Basic
Principle, and if you ignore it, there is no opposing pressure."

And no doubt that, too, is an appeal to emotion, and thus invalid.

>>>>However, the WIBNI is a useful mental tool: whenever you have a
>>>>program that you're creating and you think "With a little more work
>>>>it could be made to do these other useful things too", that's a
>>>>WIBNI. It happens when you have a job to do, you see something that
>>>>*is not part of the requirements* but you see that by making your
>>>>program just a little more complicated you can implement it. Forth,
>>>>the language and system, is the result of resisting that pressure,
>>>>as explained by Moore in his early writings.
>>
>>> Forth is the result of *not* following this principle. If Moore had
>>> followed this principle, he would not have introduced an extensible
>>> dictionary and a text interpreter, because that can always do more
>>> than is required at any particular moment.
>>
>>Um, pardon? That makes no sense at all.
>
> Why not?

I don't know why you wrote a paragraph that makes no sense. Moore's
goal was to write an extensible programming language in order to get
more work done.

Andrew.

[Albert van der Horst]

Let's see how that works out, if you don't need not build your headers
from scratch, but just fill them, e.g. ELF fields.

ciforth : building executables takes
-file handling and bookkeeping : one screen common to
all compilation.
It pulls in half a dozen screens with general purpose facilities
that a fat system would likely have in the kernel.
Then:
-SAVE-SYSTEM and TURNKEY
windows: 1 screen, common for 32 and 64 bits
linux : 1 common screen, plus 1 screen for 32 and 64 bits
each (and for OSX).
MSDOS/DPMI: 2 screens (in common)

All the facility on top of the bald kernel are mentioned.
The SAVE-SYSTEM screen would run at most 100 lines
if commented lavishly.

>
>>
>> Andrew.
>>
>
>
>--
>Alex

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

[Alex]

On 23-Dec-17 10:46, a...@littlepinkcloud.invalid wrote:

>
> Well, I'm baffled. You're either advocating fixing the problems of S"
> and TO with recognizers or you're not. You're either saying that's an
> advantage of recognizers, and saying that's the way we should go, or
> not.

I'm showing how something might be done with recognizers, much as I
might show you how to use a pencil to write with (the recognizer
proposal), to poke out your eye (can be extended to cover S"), or use
the eraser on the end to rub out mistakes (woot it's stateless).

You are now saying that I'm advocating fixing the problems of S"
and TO with recognizers or I'm not.

I'm not.

--
Alex

[Albert van der Horst]

In article <7Z6dnbi1lO6fu6DH...@supernews.com>,
<a...@littlepinkcloud.invalid> wrote:
>dxf...@gmail.com wrote:
<SNIP>

>> FI's reluctance to implement 200x features while at the same time
>> being on the committee.
>
>You're making an error here. There never has been any requirement for
>anyone to implement all of the standard. The whole idea of optional
>worsdets is that they are optional.

That doesn't work out in actual porting.
In ciforth I've followed this practice of a small kernel, adding
wordsets as needed. Consequently portability of programs towards
ciforth is low.

A typical example is this.
Anton Ertl expanded my yapcp.frt program and just used fsqrt to
calculate an auxiliary number. Having the facilities in gforth
he was just too lazy to try doing that with only integer arithmetic.
Running it "as is" on ciforth requires pulling in the assembler
then assembling the floating point wordset. At the time that
Anton made the extension there was not even a floating point wordset
to pull in.
Please note that this program ma was originally developed in
ciforth.

Trying to run the noforth metacompiler on ciforth require implementing
the full illusion of a line by line compilation, which wasn't there.
Running the metacompiler on gforth was easy, although it revealed
some mistakes in the metacompiler.
I have implemented an actual line by line compilation in ciforth
(at the expense of one screen) before I now can run the metacompiler
in ciforth too.

Begin lazy is tantamount to programmer productivity.
There is a legitimate pressure towards implementing the whole standard
plus keeping legacy things in order not to break old programs.

WORDSET's are fine for micro controllers to be able to claim
ISO comparability.

>
>Andrew.

[Albert van der Horst]

In article <7Z6dnbu1lO7auqDH...@supernews.com>,

As a (very) experienced C-programmer I can tell you that Anton
Ertl gives a good evaluation of Forth versus C portability.

Nobody says that no effort went into that. Try to get a program
accepted in Debian (I'm actually doing that right now.)

[Anton Ertl]

a...@littlepinkcloud.invalid writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>
>>> How many C programs have no compiler or
>>>platform dependencies?
>>
>> Shifting the goalposts? In practice, I have had much a much better
>> experience when porting C code between C compilers than when porting
>> Forth code between Forth compilers. E.g., even Gforth, which was
>> written to work with gcc actually works with clang, too.
>
>That doesn't count because clang has been forced to copy many of
>GCC's idiosyncracies.

By whom?

And why should it not count? If someone forced, say, Forth, Inc., to
copy many of VFX's, Gforth's or iForth's idiosyncracies in order to
compile more of the programs that are out there, I would certainly
count it as a win for program portability.

>> And in the 1990s (when there were lots of different Unix variants
>> around, on various hardware), the typical experience was that a C
>> program developed for another Unix variant would compile with gcc or
>> the C compiler for the present hardware, with a few tweaks in
>> config.h (more advanced programs had a "configure" script, that did
>> the tweaking automatically).
>
>People had to do a ton of work with autoconf and automake (big,
>complicated programs) for such advanced programs to work.

So what? The end result is that we had many portable C programs in
the 1990s that can do far more, and far easier than the few portable
Forth programs we have now, 20 years later. The attitude that program
portability is desirable and that porting should be easy (C) or that
portability and ease of porting are irrelevant (Forth, at least as
represented by system vendors) has a lot to do with that.

The ton of work was actually mostly due to OS differences, because
Unix vendors, like Forth vendors, tried to differentiate themselves
from each other by providing "unique" (or at least incompatible)
features. This was not quite as bad as in Forth, as can be seen by
the much faster pace of POSIX standardization, but the end result was
still that commercial Unixes were left in the dust by Linux, and
eventually 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:
>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>
>>>> How many C programs have no compiler or
>>>>platform dependencies?
>>>
>>> Shifting the goalposts? In practice, I have had much a much better
>>> experience when porting C code between C compilers than when porting
>>> Forth code between Forth compilers. E.g., even Gforth, which was
>>> written to work with gcc actually works with clang, too.
>>
>>That doesn't count because clang has been forced to copy many of
>>GCC's idiosyncracies.
>
> By whom?

By its uders, I suppose,

> And why should it not count? If someone forced, say, Forth, Inc., to
> copy many of VFX's, Gforth's or iForth's idiosyncracies in order to
> compile more of the programs that are out there, I would certainly
> count it as a win for program portability.

Perhaps. The point I'm making is that clang on Linux and gcc on Linux,
from a practical point of view, aren;t really different platforms.

>>> And in the 1990s (when there were lots of different Unix variants
>>> around, on various hardware), the typical experience was that a C
>>> program developed for another Unix variant would compile with gcc or
>>> the C compiler for the present hardware, with a few tweaks in
>>> config.h (more advanced programs had a "configure" script, that did
>>> the tweaking automatically).
>>
>>People had to do a ton of work with autoconf and automake (big,
>>complicated programs) for such advanced programs to work.
>
> So what?

Such programs had to be adapted to work with autoconf and automake.
Once that was done, they would often run on a wide range of platforms
that were supporte by autoconf and automake. It was usually not the
case that a program developed for other Unix variant would compile
with gcc on Linux, unless that program had already been
autoconfiscated.

Andrew.

[Anton Ertl]

a...@littlepinkcloud.invalid writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> a...@littlepinkcloud.invalid writes:
>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>>
>>>>> How many C programs have no compiler or
>>>>>platform dependencies?
>>>>
>>>> Shifting the goalposts? In practice, I have had much a much better
>>>> experience when porting C code between C compilers than when porting
>>>> Forth code between Forth compilers. E.g., even Gforth, which was
>>>> written to work with gcc actually works with clang, too.
>>>
>>>That doesn't count because clang has been forced to copy many of
>>>GCC's idiosyncracies.
>>
>> By whom?
>
>By its uders, I suppose,

What do you mean "you suppose"? You claimed that "clang has been
forced", but you cannot back it up.

In any case, the end result is that porting between C compilers
usually takes no effort. It's as easy as typing

make CC=clang

or

make CC=gcc

That's less than what Stephen Pelc asks of Forth programmers who copy
source code for VFX Forth to another directory *on the same machine*.

>> And why should it not count? If someone forced, say, Forth, Inc., to
>> copy many of VFX's, Gforth's or iForth's idiosyncracies in order to
>> compile more of the programs that are out there, I would certainly
>> count it as a win for program portability.
>
>Perhaps. The point I'm making is that clang on Linux and gcc on Linux,
>from a practical point of view, aren;t really different platforms.

Exactly! So why should VFX and SwiftForth on Linux be different in
the kinds of programs they run?

>>>> And in the 1990s (when there were lots of different Unix variants
>>>> around, on various hardware), the typical experience was that a C
>>>> program developed for another Unix variant would compile with gcc or
>>>> the C compiler for the present hardware, with a few tweaks in
>>>> config.h (more advanced programs had a "configure" script, that did
>>>> the tweaking automatically).
>>>
>>>People had to do a ton of work with autoconf and automake (big,
>>>complicated programs) for such advanced programs to work.
>>
>> So what?
>
>Such programs had to be adapted to work with autoconf and automake.
>Once that was done, they would often run on a wide range of platforms
>that were supporte by autoconf and automake. It was usually not the
>case that a program developed for other Unix variant would compile
>with gcc on Linux, unless that program had already been
>autoconfiscated.

Based on my ample experience of porting many programs developed for
another Unix variant to Linux, I can attest that this is false. In
the beginning most programs did not have autoconf-generated configure
scripts, and they did compile on Linux, though often not without
change: the typical porting experience for such programs was to follow
the instructions in INSTALL or README and edit config.h (and sometimes
Makefile), and then type make. Some programs used hand-written
configure scripts, and X programs usually used imake (a similar, but
more limited scheme than configure scripts).

The move to configure scripts and autoconf shows that, if you take
program portability serious, you make it as easy for users to build
and install the program as you can. No such nonsense as "edit this
file; it just takes a few seconds".

In any case, the difference was not between the C compilers. Porting
between cc and gcc on HP/UX, Ultrix or Digital Unix took no effort,
just as with gcc and clang on Linux.

[m...@iae.nl]

On Saturday, December 23, 2017 at 6:11:05 PM UTC+1, Anton Ertl wrote:
> a...@littlepinkcloud.invalid writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> a...@littlepinkcloud.invalid writes:
> >>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>>> "Elizabeth D. Rather" <era...@forth.com> writes:
> >>>>
> >>>>> How many C programs have no compiler or
> >>>>>platform dependencies?
> >>>>
> >>>> Shifting the goalposts? In practice, I have had much a much better
> >>>> experience when porting C code between C compilers than when porting
> >>>> Forth code between Forth compilers. E.g., even Gforth, which was
> >>>> written to work with gcc actually works with clang, too.

[..]

Why don't we have autoconf and configure for Forth programs?
AFAIK, on Linux these scripts are not coming from 'vendors.'

There are, of course, your compat library, and the fsl
and ffl solutions. They don't seem to have much of an impact
on standardization, and they are certainly not adopted by all
Forth vendors.

-marcel

[Alex]

On 23-Dec-17 16:31, a...@littlepinkcloud.invalid wrote:
> Anton Ertl<an...@mips.complang.tuwien.ac.at> wrote:
>> a...@littlepinkcloud.invalid writes:

>>> That doesn't count because clang has been forced to copy many of
>>> GCC's idiosyncracies.
>> By whom?
> By its uders, I suppose,
>

I vote this the best typo on clf this year. The image it conjures up
will stay with me for a long time.

Merry Xmas to you all.

--
Alex

[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:
>>> a...@littlepinkcloud.invalid writes:
>>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>>>
>>>>>> How many C programs have no compiler or
>>>>>>platform dependencies?
>>>>>
>>>>> Shifting the goalposts? In practice, I have had much a much better
>>>>> experience when porting C code between C compilers than when porting
>>>>> Forth code between Forth compilers. E.g., even Gforth, which was
>>>>> written to work with gcc actually works with clang, too.
>>>>
>>>>That doesn't count because clang has been forced to copy many of
>>>>GCC's idiosyncracies.
>>>
>>> By whom?
>>

>>By its [users], I suppose,

>
> What do you mean "you suppose"? You claimed that "clang has been
> forced", but you cannot back it up.

What's to back up? Initially it wasn't GNU C-compatible, it now
mostly is. Much of that was due to the fact that so many programs are
written in GNU C.

>>Perhaps. The point I'm making is that clang on Linux and gcc on
>>Linux, from a practical point of view, aren;t really different
>>platforms.
>
> Exactly! So why should VFX and SwiftForth on Linux be different in
> the kinds of programs they run?

Why not? Where's the problem? Should they be the same?

>>Such programs had to be adapted to work with autoconf and automake.
>>Once that was done, they would often run on a wide range of platforms

>>that were supported by autoconf and automake. It was usually not the

>>case that a program developed for other Unix variant would compile
>>with gcc on Linux, unless that program had already been
>>autoconfiscated.
>
> Based on my ample experience of porting many programs developed for
> another Unix variant to Linux, I can attest that this is false.

And based on my experience at Cygnus while we were doing a lot of work
to make practical portability, I know it is true. The lack of
portability between Unix variants was a nightmare. You got the
benefits of Cygnus' work.

> In the beginning most programs did not have autoconf-generated
> configure scripts, and they did compile on Linux, though often not
> without change:

Well, yes. Exactly. My point.

> the typical porting experience for such programs was to follow the
> instructions in INSTALL or README and edit config.h (and sometimes
> Makefile), and then type make. Some programs used hand-written
> configure scripts, and X programs usually used imake (a similar, but
> more limited scheme than configure scripts).

Just so.

> The move to configure scripts and autoconf shows that, if you take
> program portability serious, you make it as easy for users to build
> and install the program as you can. No such nonsense as "edit this
> file; it just takes a few seconds".

Indeed.

> In any case, the difference was not between the C compilers. Porting
> between cc and gcc on HP/UX, Ultrix or Digital Unix took no effort,
> just as with gcc and clang on Linux.

Perhaps, but GNU C was extended way beyond standard C. The difference
is a lot smaller than it was because standard C has caught up, but
it's still there.

Andrew.

[Elizabeth D. Rather]

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. If Forth programmers were really making the attempt to
publish library functions or portable programs, we'd here more about
their successes and failures and needs, rather than the kinds of issues
and complaints we do have. People here complain that there are no
standard programs or libraries, but I don't see them actually trying to
write any; it's all a clamor that "someone" should. Instead, most clf
programmers seem to be most concerned with maintaining their own
idiosyncratic Forth variants.

Cheers,
Elizabeth

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

[Cecil Bayona]

Peer pressure, the few times I spoke about a library, I was insulted for
even speaking about libraries even though SwiftForth and VFX is loaded
with them, so if I had libraries I would not say a thing to this crowd,
who needs the grief, specially from some of the experts that don't write
Forth software.


--
Cecil - k5nwa

[hughag...@gmail.com]

The Forth vendors, Forth Inc. and MPE, want the ANS-Forth programmers to "document implementation dependencies" --- specifically, to document dependency on SwiftForth or VFX --- their goal is vendor lock-in.

Elizabeth Rather says there is no "desire" for portable programs. Really??? What other goal does a language standard have???
Maybe later Elizabeth Rather can design a car with square wheels and no engine, then explain that there is no desire for the car to move forward ---
the car is a decoration for the driveway, similar to a pink flamingo in the yard.

I have said many times that the only way to write an ANS-Forth program that is portable and uses FIND is to first include all of the disambiguifiers.
Many people (Stephen Pelc, Gerry Jackson, etc.) use FIND --- but they also claim that disambiguifiers aren't needed and that their programs are ANS-Forth.
They are liars. They are using the term "ANS-Forth" as a decoration --- the term just means: "approved by Elizabeth Rather" --- it is technically meaningless.

> Peer pressure, the few times I spoke about a library, I was insulted for
> even speaking about libraries even though SwiftForth and VFX is loaded
> with them, so if I had libraries I would not say a thing to this crowd,
> who needs the grief, specially from some of the experts that don't write
> Forth software.

I think it is mostly willful ignorance. Elizabeth Rather doesn't understand that it is possible to have a general-purpose data-structure.
Nobody wants to educate her on this because she will respond by saying that the person doesn't understand the "Forth Way" and will never be a Forth programmer.
Her goal in life is to prevent Forth from supporting general-purpose data-structures --- she has her troll army to attack anybody writing portable Forth.
ANS-Forth is a cult --- people either become cult members and embrace ignorance, or they switch to C --- there are problems with C, but it is not utterly stupid.
When ANS-Forth became the standard in 1994 there was a mass exodus from Forth, especially because LMI went out of business and the majority of professional
Forth programmers were using UR/Forth.

I remember in MS-DOS days that I wrote some programs in 16-bit UR/Forth and also in Turbo-C (Small memory-model) and they ran at almost exactly the same speed.
In those days I mostly wrote programs that did a recursive traversal over all possibilities and calculated probabilities (my LowDraw.4th is an example).
By comparison, PolyForth compared badly to QBASIC (afaik, QBASIC was written in C) --- but QBASIC was a toy language given away for free with MS-DOS.

Essentially every post from Elizabeth Rather opposes general-purpose data-structures --- that is all she really does --- here are a few:

This quote was an attack on my novice package, specifically ASSOCIATION.4TH:
-------------------------------------------------------------------------------
Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often.
If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure.
-------------------------------------------------------------------------------


Some data-structures (the LLRB tree in ASSOCIATION.4TH) are more complicated than an array to implement:
-------------------------------------------------------------------------------
...in Forth it's so easy to build data structures that are exactly right for the particular application at hand that worrying about what pre-built structures
you have and how to use them is just not worth the bother.
-------------------------------------------------------------------------------


I have never seen any evidence that she knows that data-structures other than the array have been invented:
-------------------------------------------------------------------------------
Virtually every Forth application needs some kind of array structures. The reason that some general-purpose one might be "little used" is because
it's so easy to make a version that does *exactly* what the application needs rather than some generic definition. ...
The objective is to master the toolset and be able to think clearly about exactly what kind of arrays will be useful in your application
and then build exactly that kind.
-------------------------------------------------------------------------------


The array is the only data-structure that she knows about, but she doesn't actually know how to implement an array:
-------------------------------------------------------------------------------
On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;
-------------------------------------------------------------------------------
Notice that the indices start at 1 rather than 0 --- this is her COBOL background shining through --- also, there is too much stack-juggling.
Notice that it is not general-purpose because it only works for 1-dimensional arrays and the element size has to be 1 cell.
Notice that it is inefficient because it uses CREATE DOES> and has to fetch the index limit from memory at run-time although this is a constant.

This looks like the kind of Forth that a novice with one week of experience would write --- this is a baby step toward learning how to program in Forth.
Anybody who writes such primitive Forth code has a lot to learn about Forth --- but Elizabeth Rather wants to teach Forth!

[Kerr-Mudd,John]

On Sun, 24 Dec 2017 21:32:58 GMT, hughag...@gmail.com wrote:

[]

>
> This looks like the kind of Forth that a novice with one week of
> experience would write --- this is a baby step toward learning how to
> program in Forth. Anybody who writes such primitive Forth code has a
> lot to learn about Forth --- but Elizabeth Rather wants to teach
> Forth!
>

Give it up, it's a stuck record.

[hughag...@gmail.com]

This is what I said:

On Sunday, December 24, 2017 at 2:33:00 PM UTC-7, hughag...@gmail.com wrote:
> Essentially every post from Elizabeth Rather opposes general-purpose data-structures --- that is all she really does...

This is what you said:

On Sunday, December 24, 2017 at 3:35:44 PM UTC-7, Kerr-Mudd,John wrote:
> Give it up, it's a stuck record.

There are several interpretations of your meaning:

1.) You want me to give up Forth programming because I don't understand the "Forth Way" and I will never become a Forth programmer.

2.) You want me to give up believing that general-purpose data-structures are possible, but continue programming in Forth --- willful ignorance.

3.) You want Elizabeth Rather to give up on attacking the concept of general-purpose data-structures because she sounds like a stuck record.

Am I correct that you chose #2 for yourself? You have never posted code for any general-purpose data-structures yourself.
Or maybe you really don't believe that general-purpose data-structures are possible.
Sometimes it is difficult to distinguish between willful ignorance and stupidity --- as a practical matter, the distinction doesn't matter ---
either way, Elizabeth Rather wins the argument just through sheer perseverance (40 years is a long time to remain ignorant of basic computer-science).

[hughag...@gmail.com]

In VFX Stephen Pelc provides us with daily quotes. Here are two:

"Never attribute to malice that which can be explained by stupidity."
Hanlon's Razor

"Stupidity maintained long enough is a form of malice."
Richard Bos's corollary to Hanlon's Razor.

[Anton Ertl]

m...@iae.nl writes:
>Why don't we have autoconf and configure for Forth programs?

We have them. They work for Forth programs just as they work for C
programs, and can be used to check for and bridge OS differences, just
as in C programs. The reason that they are not used by the Forth
community is that Forth source code portability stops long before we
reach that bridge.

>AFAIK, on Linux these scripts are not coming from 'vendors.'

So, I guess, what you mean is: Why don't we have user-written
libraries that supply the pieces that vendors are unwilling to supply,
and that would enhance portability?

>There are, of course, your compat library, and the fsl
>and ffl solutions.

The compat library limits itself to features that can be implemented
in standard Forth, sometimes with reduced functionality. Another such
library is the set of portable reference implementations for
Forth-200x <http://www.forth200x.org/reference-implementations/>
<http://www.forth200x.org/forth200x-code.zip>.

The FSL and FFL are also pretty much based on standard code (the FSL
has a system-specific fsl-util file, though).

But yes, given the attitude of some vendors against portable Forth
source code, and against standardizing anything but their own
features, it may be a more economical use of our time to actually
implement the features ourselves, without limiting ourselves to
standard code (unlike the libraries mentioned above), and instead
providing implementations of these features for some backwater Forth
systems.