C to Forth (was Ting)

Stephen Pelc

unread,

May 13, 2016, 4:05:57 PM5/13/16

to

On Fri, 6 May 2016 17:36:24 -0400, Walter Banks <wal...@bytecraft.com>
wrote:

>We were looking at using forth as an intermediate compiled step as a
>possible way to create an easily ported C compiler to a new ISA. Kind of
>like the old stage2 approach.
>w..

The Europay OTA project used a two-stack virtual machine for which
there were both Forth and C compilers. The VM was designed to be
kind to C as well as to Forth. Europay became a part of Mastercard
and the OTA documents may be hard to find. If you do not already
have them and need/want them, send me an email.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Paul Rubin

unread,

May 13, 2016, 5:06:30 PM5/13/16

to

ste...@mpeforth.com (Stephen Pelc) writes:
> Europay became a part of Mastercard and the OTA documents may be hard
> to find. If you do not already have them and need/want them, send me
> an email.

I tried to find them a year or two ago (including posting a query here)
with no success. If they're available now and don't involve an
expensive purchase, that's great. I'll email you. Thanks!

hughag...@gmail.com

unread,

May 13, 2016, 5:33:53 PM5/13/16

to

On Friday, May 13, 2016 at 1:05:57 PM UTC-7, Stephen Pelc wrote:
> On Fri, 6 May 2016 17:36:24 -0400, Walter Banks <wal...@bytecraft.com>
> wrote:
>
> >We were looking at using forth as an intermediate compiled step as a
> >possible way to create an easily ported C compiler to a new ISA. Kind of
> >like the old stage2 approach.
> >w..
>
> The Europay OTA project used a two-stack virtual machine for which
> there were both Forth and C compilers. The VM was designed to be
> kind to C as well as to Forth. Europay became a part of Mastercard
> and the OTA documents may be hard to find. If you do not already
> have them and need/want them, send me an email.

None of this is ANS-Forth! This seems highly hypocritical, that your job as a Forth-200x committee member is to force ANS-Forth down everybody's throat by damning anybody who refuses to brown-nose as being non-standard --- yet your own efforts at making money invariably abandon ANS-Forth on the first day of the project.

I get the impression that ANS-Forth and Forth-200x are purposely crippled to prevent anybody from using them in competition with MPE --- the whole idea is that anybody who wants to learn Forth gets stuck in gForth hell, and they can never write any commercial-grade programs --- but if they abandon ANS-Forth (as I did in MFX) then you immediately damn them for being non-standard.

ANS-Forth is a cult --- it has no practical value whatsoever --- ANS-Forth is just a collection of brown-nosers who want to be big internet experts on Forth without ever writing any Forth code (due to gForth being useless for writing commercial programs).

Rod Pemberton

unread,

May 14, 2016, 12:27:23 AM5/14/16

to

Why is it that no one ever asks me? ...

I've found all four files archived at least twice by Wayback Archive.
FYI, I'm not sure what is on page 4 of Overview.pdf. Both of the pdf
viewers (ePDFviewer and Zathura) that I have for Linux can't seem to
handle that page, or they're taking an excessively long time. They
will go to the other pages. The first two links have four files.

Rod Pemberton

Archive of MLG directory (possibly CLF regular M.L. Gassanenko? ...)
http://web.archive.org/web/20041021061206/http://www.forth.org.ru/~mlg/std/OTA/

Archived files from "Watson" under section "Open Terminal Architecture"
http://web.archive.org/web/20041110203830/http://hedgehogs.softjoys.ru/Watson/resources/

Forth Dimensions, V19N2, pg 7-11
"A Platform-Independent Token System for Payment Terminals" by Peter
Johannes, Stephen Pelc, and Elizabeth Rather
http://www.forth.org/fd/FD-V19N2.pdf

Forth Dimensions, V19N2, pg 11
"Background: Payment Systems in Europe" by P. Johannes, Europay
International http://www.forth.org/fd/FD-V19N2.pdf

Just a five page reprint of both FD V19N2 articles from www.forth.com
http://dl.forth.com/sitedocs/OTA_FD.pdf

"Smart Cards and the Open Terminal Architecture" by Edward K. Conklin,
Dec 01, 1998, Dr. Dobb's Journal
http://www.drdobbs.com/open-source/smart-cards-and-the-open-terminal-archit/184410748

Forth Dimensions
http://www.forth.org/fd/contents.html

Rod Pemberton

unread,

May 14, 2016, 12:27:58 AM5/14/16

to

On Fri, 13 May 2016 14:33:51 -0700 (PDT)
hughag...@gmail.com wrote:

> On Friday, May 13, 2016 at 1:05:57 PM UTC-7, Stephen Pelc wrote:
> > On Fri, 6 May 2016 17:36:24 -0400, Walter Banks
> > <wal...@bytecraft.com> wrote:

> > >We were looking at using forth as an intermediate compiled step as
> > >a possible way to create an easily ported C compiler to a new ISA.
> > >Kind of like the old stage2 approach.
> > >w..
> >
> > The Europay OTA project used a two-stack virtual machine for which
> > there were both Forth and C compilers. The VM was designed to be
> > kind to C as well as to Forth. Europay became a part of Mastercard
> > and the OTA documents may be hard to find. If you do not already
> > have them and need/want them, send me an email.
>
> None of this is ANS-Forth!

So? ...

The fact that there is a VM design that can support both Forth and C,
even if it is limited in certain aspects, is likely valuable to someone.
I've provided links in my other post for anyone interested.

> This seems highly hypocritical, that your
> job as a Forth-200x committee member is to force ANS-Forth down
> everybody's throat by damning anybody who refuses to brown-nose as
> being non-standard --- yet your own efforts at making money
> invariably abandon ANS-Forth on the first day of the project.

Hugh, people need money to live, including you. Get over it. Get a
job. Stop wasting your time here. It's clear that you're not in need
of the help of anyone here. You've got it all figured out, correct
or not, and you can already code Forth. Also, they don't seem to be
in need your help either. How long has it been since someone asked
about your novice package? I think it was, like what, one guy in
the past five years. So, why do you keep on ranting about stuff you
cannot change? What's the point? ...

> I get the impression that ANS-Forth and Forth-200x are purposely
> crippled to prevent anybody from using them in competition with MPE

Standards are frequently used to protect or enrich incumbents. That
doesn't mean that it is the case here though, although it could be.

> --- the whole idea is that anybody who wants to learn Forth gets
> stuck in gForth hell, and they can never write any commercial-grade
> programs ---

Hey, you know that I'm "not a Forth guy," but even I don't understand
how you can argue that gForth can't be used for commercial-grade
programs. If a business wants to use Forth, without initially paying
for a commercial version of Forth, that gForth is very likely the
program they'll start with. They may decide to modify it over a long
time period to fit their needs, or they may decide that upgrading to a
commercial program is a better choice. Of course, such a business is
likely to be running code on commercial, high-speed, fault-tolerant
servers or using cloud servers. So, the fact that gForth may not be as
fast as commercial Forth programs is not an issue.

> ANS-Forth is a cult --- it has no practical value whatsoever ---

As I told you before, most of my Forth was ANS compliant even though it
was based on fig-Forth and bits and pieces from Forth-79 and Forth-83
and ANS Forth. That's even with a C backend. So, saying ANS Forth has
no practical value whatsoever is like saying the earlier Forths have no
value either.

> ANS-Forth is just a collection of brown-nosers who want to be big
> internet experts on Forth without ever writing any Forth code

I won't argue with you on that one. That might true, in general.

Rod Pemberton

Paul Rubin

unread,

May 14, 2016, 12:55:49 AM5/14/16

to

Rod Pemberton <NoHave...@bcczxcfre.cmm> writes:
> Archive of MLG directory (possibly CLF regular M.L. Gassanenko? ...)
> http://web.archive.org/web/20041021061206/http://www.forth.org.ru/~mlg/std/OTA/

Oh thanks, this looks like what what I wanted.

> Forth Dimensions, V19N2, pg 7-11
> "A Platform-Independent Token System for Payment Terminals" by Peter
> Johannes, Stephen Pelc, and Elizabeth Rather
> http://www.forth.org/fd/FD-V19N2.pdf

I do remember seeing this and related articles, but they were missing
most of the details.

Elizabeth D. Rather

unread,

May 14, 2016, 3:02:50 AM5/14/16

to

On 5/13/16 6:28 PM, Rod Pemberton wrote:
> On Fri, 13 May 2016 14:33:51 -0700 (PDT)
> hughag...@gmail.com wrote:

...

>> ANS-Forth is just a collection of brown-nosers who want to be big
>> internet experts on Forth without ever writing any Forth code
>
> I won't argue with you on that one. That might true, in general.

I can only speak authoritatively for the Forth94 committee, but it
included some of the finest and most experienced Forth programmers
around at the time. Take a look at the list of contributing members in
the free published draft. I don't know all of the members of Forth 20xx,
but the ones I do know have outstanding programming backgrounds.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

hughag...@gmail.com

unread,

May 14, 2016, 6:15:14 PM5/14/16

to

On Saturday, May 14, 2016 at 12:02:50 AM UTC-7, Elizabeth D. Rather wrote:
> On 5/13/16 6:28 PM, Rod Pemberton wrote:
> > On Fri, 13 May 2016 14:33:51 -0700 (PDT)
> > hughag...@gmail.com wrote:
> ...
> >> ANS-Forth is just a collection of brown-nosers who want to be big
> >> internet experts on Forth without ever writing any Forth code
> >
> > I won't argue with you on that one. That might true, in general.
>
> I can only speak authoritatively for the Forth94 committee, but it
> included some of the finest and most experienced Forth programmers
> around at the time. Take a look at the list of contributing members in
> the free published draft. I don't know all of the members of Forth 20xx,
> but the ones I do know have outstanding programming backgrounds.
>
> Cheers,
> Elizabeth

You list Ray Duncan as a contributing member. In 1993, one year before ANS-Forth came out, he was describing aspects of ANS-Forth as "brain damaged" on c.l.f.. When ANS-Forth came out he gave up on Forth altogether.

You also list Charles Moore as a contributing member. He doesn't support you either. In all likelihood, none of the people that you list as supporters actually support you. You just make this stuff up!

I wrote MFX in 1994/1995 using UR/Forth (from Ray Duncan's LMI). Realistically, this would not have been possible in ANS-Forth --- ANS-Forth was crippled to make cross-compilation difficult. In UR/Forth I was able to take an xt an determine whether it was immediate or not, and which vocabulary it was defined in --- this was needed for error-checking --- you disallowed this in ANS-Forth.

If the ANS-Forth committee included the "finest and most experienced Forth programmers around at the time," then why were they unable to write a compiler for ANS-Forth? You pushed ANS-Forth through ANSI without any compiler having ever been written for it. You were in a hurry to get the ANSI stamp because doing so makes you the "leading expert" on Forth and puts you in a position to denounce everybody else (me, for example) as being non-standard. ANS-Forth was just a marketing gimmick from Forth Inc. to make Forth Inc. appear more important than they are. You didn't have a compiler for ANS-Forth --- ANS-Forth became the standard without being tested --- if ANS-Forth had been tested, people would have noticed the myriad bugs and ambiguities.

ANS-Forth is a cult --- ANS-Forth has no practical value whatsoever.

Cecil Bayona

unread,

May 14, 2016, 6:40:03 PM5/14/16

to

If ANS-Forth is seriously flawed then what existing Forth is not so
flawed? I'm curious to see if any current or older Forth version does
not share some of the ANS-Forth issues.

I'm not personally hung up on Standards but appreciate a Forth that is
consistent and logical even if it doesn't meet the Standards. I'm no
Forth expert but have always looked at Forth as a programmable tool that
one tweaks to accomplish ones goals, so one persons Forth is not
necessarily someone else's Forth.

--
Cecil - k5nwa

hughag...@gmail.com

unread,

May 14, 2016, 7:56:49 PM5/14/16

to

Prior to ANS-Forth, Forth was pretty consistent and logical. For example, we always knew which words were immediate or non-immediate. With ANS-Forth we can have systems such as VFX in which words like IF are non-immediate but get special-cased by COMPILE, so they actually execute at compile-time like immediate words. That is just bizarre! We also have systems such as gForth in which FIND returns different xt values depending upon what STATE is at the time that FIND is executed. That is beyond bizarre! My disambiguifiers fix these bizarre differences between ANS-Forth systems, but Pelc refuses to put the disambiguifiers in VFX --- apparently he only does what Leon Wagner tells him to do, and Leon Wagner likes ambiguity (presumably because having a broken FIND makes writing a cross-compiler difficult, and both Forth Inc. and MPE make their money selling cross-compilers so they are trying to prevent competition).

Forth-83 had some problems, but the problems were minor and easily solved.
1.) Forth-83 specified a cell size of 2 bytes. This was trivial to solve. I defined the constant W to be the cell size and used it throughout the programs. I could port programs between 16-bit and 32-bit and all I had to do was change the value in W between 2 and 4.
2.) Forth-83 specified ITC. This was trivial to solve. Lots of Forth systems used DTC or STC, and programs could be ported between them without difficulty. The only programs that couldn't be ported were those that accessed the ITC threaded code, but that is a very bad idea that was rarely done, so this never became an issue in my experience (none of my programs did this).
3.) Forth-83 lacked some features needed for cross-compilation. Before I could begin MFX, I had to write all of these myself in assembly-language for UR/Forth relying on carnal knowledge of UR/Forth. I put all of this code in a single file so that, if MFX ever got ported to another Forth-83 system, only that file would have to be rewritten for the new system. It was a pretty short file --- there were only a handful of needed words.

You said: "I'm curious to see if any current or older Forth version does not share some of the ANS-Forth issues."
I'm not aware of any of the older Forth systems prior to ANS-Forth that shared any of the ANS-Forth issues. All of the problems in ANS-Forth were introduced by ANS-Forth. Forth was logical and consistent prior to ANS-Forth. Elizabeth Rather introduced all of this ambiguity in ANS-Forth because she is just not a programmer and knows nothing about Forth --- there was never any call for ambiguity!

Forth is an inherently simple language. This is actually why a lot of people, including myself, got interested in Forth originally. ANS-Forth was just full of ambiguity and gratuitous complication, and Forth-200x is worse. It just blows my mind that something consistent and logical could be turned into such a mess --- this is the work of idiots who don't know what they are doing! --- it should be an easy job to write a standard that is consistent and logical, and which supports cross-compilation (cross-compilation is the primary use of a desktop-computer Forth system).

Cecil Bayona

unread,

May 14, 2016, 9:25:21 PM5/14/16

to

On 5/14/2016 6:56 PM, hughag...@gmail.com wrote:

> Prior to ANS-Forth, Forth was pretty consistent and logical. For example, we always knew which words were immediate or non-immediate. With ANS-Forth we can have systems such as VFX in which words like IF are non-immediate but get special-cased by COMPILE, so they actually execute at compile-time like immediate words. That is just bizarre! We also have systems such as gForth in which FIND returns different xt values depending upon what STATE is at the time that FIND is executed. That is beyond bizarre! My disambiguifiers fix these bizarre differences between ANS-Forth systems, but Pelc refuses to put the disambiguifiers in VFX --- apparently he only does what Leon Wagner tells him to do, and Leon Wagner likes ambiguity (presumably because having a broken FIND makes writing a cross-compiler difficult, and both Forth Inc. and MPE make their money selling cross-compilers so they are trying to prevent competition).
>
> Forth-83 had some problems, but the problems were minor and easily solved.
>

> You said: "I'm curious to see if any current or older Forth version does not share some of the ANS-Forth issues."
> I'm not aware of any of the older Forth systems prior to ANS-Forth that shared any of the ANS-Forth issues. All of the problems in ANS-Forth were introduced by ANS-Forth. Forth was logical and consistent prior to ANS-Forth. Elizabeth Rather introduced all of this ambiguity in ANS-Forth because she is just not a programmer and knows nothing about Forth --- there was never any call for ambiguity!
>
> Forth is an inherently simple language. This is actually why a lot of people, including myself, got interested in Forth originally. ANS-Forth was just full of ambiguity and gratuitous complication, and Forth-200x is worse. It just blows my mind that something consistent and logical could be turned into such a mess --- this is the work of idiots who don't know what they are doing! --- it should be an easy job to write a standard that is consistent and logical, and which supports cross-compilation (cross-compilation is the primary use of a desktop-computer Forth system).
>

Indeed that is one of the best things about Forth, it being simple yet
expandable to the point that you can make it anything you want.

One of the older versions I like was Pygmy Forth which did not follow
the F83 standards but was it' own thing, unfortunately it was made for
DOS which is no longer compatible with Windows 10, my current OS. I
looked at many of those versions of Forth such as eForth, Fig Forth and
its variants but they also suffer from being DOS compatible and not
Windows 10 compatible.

--
Cecil - k5nwa

rickman

unread,

May 15, 2016, 12:16:14 AM5/15/16

to

Nearly all of the issues Hugh complains about only exist in Hugh's head.
His idea of a truly worthy Forth is only the one that he writes.

--

Rick C

hughag...@gmail.com

unread,

May 15, 2016, 3:19:51 AM5/15/16

to

Rickman is a sycophant of Elizabeth Rather. He continuously defends her like this. First we had John Passaniti, then Alex McDonald, and now Rickman --- a parade of disgusting little sycophants!

Anyway, here is an example of ANS-Forth. We have section 4.1.2 with the ominous heading: "Ambiguous Conditions." One of the ambiguous conditions is:
"attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics;"

There are 50 some words in the standard that have "undefined interpretation semantics." These include everything that was traditionally immediate, such as IF etc.. So, we can't tick or FIND most of the words in the standard! Also, these words may or may not be immediate (if they are non-immediate, this means that COMPILE, special-cases them, as done in VFX). There is no way to determine if they are immediate or non-immediate however, because FIND doesn't work anymore.

For a good laugh, read section 3.4.4.:
-------------------------------------------------------------------------
When an ambiguous condition exists, a system may take one or more of the following actions:
– ignore and continue;
– display a message;
– execute a particular word;
– set interpretation state and begin text interpretation;
– take other implementation-defined actions;
– take implementation-dependent actions.
The response to a particular ambiguous condition need not be the same under all circumstances.
-------------------------------------------------------------------------
So, pretty much anything can happen, including reformatting your hard-disk.

I have actually fixed this problem though. My disambiguifiers make all of these "undefined interpretation semantics" words immediate so they work the way they traditionally worked in Forth --- tick and FIND will work on them correctly.

Here is one of my disambiguifiers:

: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate

There are 50 some of these disambiguifiers. This fixes the problem! Nobody on the Forth-200x committee, including Stephen Pelc, will accept the disambiguifiers however --- they want to have ambiguity!

There is more weirdness. See section 6.1.1550 (this describes FIND):
"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."

This is Anton Ertl's justification in gForth for making FIND return different xt values depending upon what STATE is at the time that FIND is executed. He gets to claim that gForth is ANS-Forth standard, despite the fact that no other ANS-Forth system does this, and it is utter nonsense.

Most likely what happened here is that the ANS-Forth committee were aware that FIND in cmForth returned different values inside of a colon word compared to outside of a colon word. What they didn't understand is that this was due to there being a different vocabulary in CONTEXT inside of colon words as compared to outside of colon words. Nobody on the ANS-Forth committee knew how a cross-compiler worked, so they didn't understand that CONTEXT is changed by colon and then changed back again by semi-colon. They didn't understand how vocabularies work, so they believed that FIND was STATE-smart and returned different values depending upon what STATE is, but that isn't true. The ANS-Forth committee really seemed to lack an understanding of how Forth works --- they didn't know how CONTEXT and CURRENT work --- Anton Ertl apparently doesn't understand how vocabularies work either, which is why he made FIND in gForth return different values depending upon STATE despite the fact that the vocabulary search order has not been changed. WTF???

Now we have little Rickman the sycophant who says that the issues of ANS-Forth are in my head --- no they're not --- they are in the ANS-Forth document sections that I listed above.

I can list many other ANS-Forth document sections that are equal idiocy to these --- it is almost impossible to find any section in the ANS-Forth document that isn't rife with idiocy.

Anton Ertl

unread,

May 15, 2016, 6:44:05 AM5/15/16

to

rickman <gnu...@gmail.com> writes:
>Nearly all of the issues Hugh complains about only exist in Hugh's head.
> His idea of a truly worthy Forth is only the one that he writes.

Does he write one? Or is it the Forth that he claims he will be
writing?

- 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 2016: http://www.euroforth.org/ef16/

rickman

unread,

May 15, 2016, 8:58:34 AM5/15/16

to

> This is Anton Ertl's justification in gForth for making FIND return different xt values depending upon what STATE is at the time that FIND is executed.. He gets to claim that gForth is ANS-Forth standard, despite the fact that no other ANS-Forth system does this, and it is utter nonsense.

>
> Most likely what happened here is that the ANS-Forth committee were aware that FIND in cmForth returned different values inside of a colon word compared to outside of a colon word. What they didn't understand is that this was due to there being a different vocabulary in CONTEXT inside of colon words as compared to outside of colon words. Nobody on the ANS-Forth committee knew how a cross-compiler worked, so they didn't understand that CONTEXT is changed by colon and then changed back again by semi-colon. They didn't understand how vocabularies work, so they believed that FIND was STATE-smart and returned different values depending upon what STATE is, but that isn't true. The ANS-Forth committee really seemed to lack an understanding of how Forth works --- they didn't know how CONTEXT and CURRENT work --- Anton Ertl apparently doesn't understand how vocabularies work either, which is why he made FIND in gForth return different values depending upon STATE despite the fact that the v
ocabulary search order has not been changed. WTF???
>
> Now we have little Rickman the sycophant who says that the issues of ANS-Forth are in my head --- no they're not --- they are in the ANS-Forth document sections that I listed above.
>
> I can list many other ANS-Forth document sections that are equal idiocy to these --- it is almost impossible to find any section in the ANS-Forth document that isn't rife with idiocy.

As anyone can see, Hugh is not a well balanced person. He may have some
useful things to say about Forth, but the question is whether it is
worth reading through all his paranoid rantings to find them.
Personally, I thing this group would be better off without him, not
unlike the Forth standard committee found their work better without him.
At risk of setting him off on another rant, I will point out that Hugh
was once part of the Forth standards process, but he was unable to
refrain from his rantings long enough to do any useful work and ended up
in such conflict with nearly everyone else on the committee that he
could not remain.

It's a shame as Hugh could make useful contributions. The Forth
community is full of eccentrics and eclectics, but even there Hugh
stands out as too extreme to be compatible.

Oh yeah, if anyone reading this does not already know Hugh well enough,
ask him what he does for a living and how long it has been since he was
paid to write Forth code... and why. Also, ask him where *his* Forth
system is and when it will be released.

--

Rick C

Tessa Bonting

unread,

May 15, 2016, 11:32:48 AM5/15/16

to

Op zondag 15 mei 2016 00:15:14 UTC+2 schreef hughag...@gmail.com:

> On Saturday, May 14, 2016 at 12:02:50 AM UTC-7, Elizabeth D. Rather wrote:
> > On 5/13/16 6:28 PM, Rod Pemberton wrote:
> > > On Fri, 13 May 2016 14:33:51 -0700 (PDT)
> > > hughag...@gmail.com wrote:
> > ...
> > >> ANS-Forth is just a collection of brown-nosers who want to be big
> > >> internet experts on Forth without ever writing any Forth code
> > >
> > > I won't argue with you on that one. That might true, in general.
> >
> > I can only speak authoritatively for the Forth94 committee, but it
> > included some of the finest and most experienced Forth programmers
> > around at the time. Take a look at the list of contributing members in
> > the free published draft. I don't know all of the members of Forth 20xx,
> > but the ones I do know have outstanding programming backgrounds.
> >
> > Cheers,
> > Elizabeth
>
> You list Ray Duncan as a contributing member. In 1993, one year before ANS-Forth came out, he was describing aspects of ANS-Forth as "brain damaged" on c.l.f.. When ANS-Forth came out he gave up on Forth altogether.
>
> You also list Charles Moore as a contributing member. He doesn't support you either. In all likelihood, none of the people that you list as supporters actually support you. You just make this stuff up!
>
> I wrote MFX in 1994/1995 using UR/Forth (from Ray Duncan's LMI). Realistically, this would not have been possible in ANS-Forth --- ANS-Forth was crippled to make cross-compilation difficult. In UR/Forth I was able to take an xt an determine whether it was immediate or not, and which vocabulary it was defined in --- this was needed for error-checking --- you disallowed this in ANS-Forth.

unread,

May 15, 2016, 8:24:59 PM5/15/16

to

Tessa Bonting <tessa....@gmail.com> writes:
> Anybody, that is at grade C in ANS-Forth can write a cross-compiler
> and you say that you are a professial writer of Forth.

I'm probably below grade C but I don't quite see how to write a
cross-compiler in pure ANS. There was an extension proposal that seems
to be offline now:

http://www.forth.com/downloads/ANS/XCpaper.pdf

I didn't check Wayback so it might be there. I think I have an offline
copy someplace.

hughag...@gmail.com

unread,

May 15, 2016, 10:30:46 PM5/15/16

to

My experience is that everybody says cross-compilation in Forth is "easy" or "well-established," etc.. As soon as the person begins to describe it however, it becomes obvious that the person doesn't know how it works.

In private correspondence, Jeff Fox said this:
---------------------------------------------------------------------------
You are right that a target compiler can be simpler than when one has
to include an interpreter and a compiler inside an application. There
are times when one does want an interpreter and/or a compiler in an
application but not always.

It is also true that the proposed ANS target compiler standard is
way overly complicated. Have you seen it? It doesn't sound like
that is your style.

I am about to post two new pages, One is Factoring and one is
Smarter than a First Grader? I expect that many people
will think that I am overstating my opinions. Like many of
the essays and tutorials I have posted they are both
related to people asking the same dumb questions and saying
the same dumb things in c.l.f but never learning the answers
or why some things are dumb.
---------------------------------------------------------------------------
He may have been referring to the same document that you are referring to (I have not read it; I have never actually read anything about Forth cross-compilation whether ANS-Forth or otherwise). As to those pages that he intended to post, I don't think he ever did. This email was dated 4/27/2011 and he died 5/4/2011.

On the subject of people making statements about Forth cross-compilation that indicate that they don't know what they are talking about, this thread contains some doozies:
https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ
I recommend that everybody read this thread --- there is a lot of good stuff in there!

On Friday, December 4, 2009 at 1:19:24 PM UTC-7, Anton Ertl wrote:
> Jerry Avins <j...@ieee.org> writes:
> >What's this about? Are host/Ttarget systems covered by ANS Forth?
>
> No. Cross compilers are not supported by Forth-94, nor in the current
> draft of Forth200x. There is a cross-compiler proposal, and there are
> people working on getting it ready for Forth 200x (or 201x).
>
> - anton

According to Tessa Bonting, writing a cross-compiler in ANS-Forth is something that a C-student can accomplish, but yet nobody knew how to do it in 2009 --- apparently the Forth-200x committee were all D students!

On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote:
> On Tue, 8 Dec 2009 14:32:02 -0500, Jonah Thomas <jeth...@gmail.com>
> wrote:
>
> >Suppose you extended the cross-compiler so that the TARGET could be the
> >HOST . Then you'd have a clear distinction between COMPILER words and
> >regular words, but the distinction between HOST and TARGET would have
> >disappeared.
>
> There are three types of compilation involved
> 1) Host compilation
> 2) Clone compilation (target CPU same as host and memory matches)
> 3) Cross compilation (target CPU is not host CPU)
>
> In the third case you have to simulate *everything* when dealing
> with both the definition and execution of defining words. It's not
> easy. You also have to extend the normal Forth compiler by at least
> two time frames. Forth cross compilers are much more complicated
> and much more subtle than they appear to be.
>
> That's one reason why the cross compiler proposal is the way it is.
> The big downside of the proposal is that the original was written in
> a hurry to satisfy EuroPay. It also reflects the state of Forth cross
> compiler design of about 15 years ago. I have prototyped a design
> for which the current proposal is inappropriate.
>
> Stephen

This is totally not true! There is no need to simulate the target processor on the host machine at compile-time. I think Stephen is referring to a technique that was used way back in the early 1980s. At that time people had a 6502 Forth system running, but compilation took too long. Their solution was to simulate the 6502 on a PDP-11 and run their Forth system in the simulator for improved speed. In a way this was cross-compilation, because the compiler was running on a PDP-11, but it wasn't really cross-compilation because it was just the traditional Forth system running the same way that it would have run on a 6502, just somewhat faster.

On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote:
> Hugh Aguilar <hugoa...@rosycrew.com> writes:
> >On Nov 25, 4:14=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> >On Nov 25, 8:57=3DA0am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> >> >> I don't use gforth. What does that error message mean? What is a
> >> >> "compile-only word?"
> >>
> >> A word without interpretation semantics.
> >>
> >> >It doesn't like you taking the address of ";" , though I don't
> >> >understand why.
> >>
> >> Because ";" has no execution or interpretation semantics. =A0The
> >> execution token returned by ['] represents the execution semantics,
> >> but since ";" does not have that ...
> >
> >I don't understand how a word can not have execution semantics.
>
> That's quite simple: By not defining execution semantics in the
> definition of the word in the standard document. Look up the
> definition of ";" in the standard, and you will see that there is no
> "Execution:" section there; and there are other labeled sections
> there, so the "omitted label" sentence of 3.4.3.1 does not apply.
>
> >For immediate words (IF, ;, etc.)
>
> IF and ";" are not immediate words in the standard. A system can
> implement them as immediate words, but a program cannot rely on their
> immediacy.
>
> >I looked up ['] in the ANS-Forth document and it says:
> >
> >"Place name's execution token xt on the stack."
>
> What's the execution token of a word that has no execution semantics.
>
> Hmm, since you think that ";" is immediate, I guess you want an
> execution token that, when executed, performs the compilation
> semantics. You can get that as follows. Before the rest of the
> program, define:
>
> : ; postpone ; ; immediate
>
> Now you have an immediate ";" with an execution semantics that's the
> same as the compilation semantics, and you can tick it.
>
> >What I am saying is that I didn't have any warning that what I was
> >doing in MACRO: was going to be a problem.
>
> A system that would tell us all non-standard usages would be nice, but
> we don't have that. For now the solution is to test on as many
> systems as possible.
>
> - anton

This last one is a super-doozy! Here Anton Ertl invents disambiguifiers. I forgot about this, and it was years later when I invented disambiguifiers myself. Now, the irony is that everybody (including Anton Ertl) refuses to accept my disambiguifiers --- this is despite (actually because of) the fact that disambiguifiers are the key to allowing the ANS-Forth programmer to write his own outer-interpreter, which is the key to writing a cross-compiler --- nobody at Forth Inc. or MPE wants this to happen, because they make most of their money on selling cross-compilers and they don't want any competition.

Also, btw, is it pretty humorous the way that Anton Ertl says that we have to just test our programs on as many ANS-Forth systems as possible to find out if the programs are ANS-Forth compatible?

ANS-Forth is just too much fun! More fun than a barrel of monkeys!

Elizabeth D. Rather

unread,

May 16, 2016, 12:52:22 AM5/16/16

to

I do not believe he ever actually participated. He certainly did not
when I was involved (through the 90's), and the Forth200x process has
met entirely in Europe as far as I know. One has to attend a certain
minimum number of meetings to be a voting participant.

Anton Ertl

unread,

May 16, 2016, 2:37:37 AM5/16/16

to

"Elizabeth D. Rather" <era...@forth.com> writes:
>On 5/15/16 2:58 AM, rickman wrote:
>> At risk of setting him off on another rant, I will point out that Hugh
>> was once part of the Forth standards process, but he was unable to
>> refrain from his rantings long enough to do any useful work and ended up
>> in such conflict with nearly everyone else on the committee that he
>> could not remain.
>
>When and in what capacity was Hugh ever involved in the Forth standards
>process? He is not listed in any of the contributors either to Forth94
>(ANS Forth) or Forth 2012.

He made an RfD
<https://groups.yahoo.com/neo/groups/forth200x/conversations/topics/448>.
This was discussed quite a bit, but then it turned out that most Forth
systems implement ALLOCATE etc. based on C's malloc() etc., and any
variant of SIZE would therefore be expensive to implement on most
Forth systems, or require that we use carnal knowledge of the
malloc()'s implementation; the latter is particularly problematic for
the significant number of systems that run on multiple platforms.
That pretty much doomed that proposal, and Hugh Aguilar did not take
that gracefully.

From that point on, his participation on the mailing list was not
constructive, and at some point, his behaviour became so abusive that
several people unsubscribed, so we removed him from the mailing list
(he actually had asked for that in one of his postings, so one can say
we followed his wishes).

Anton Ertl

unread,

May 16, 2016, 9:40:39 AM5/16/16

to

Paul Rubin <no.e...@nospam.invalid> writes:
>I'm probably below grade C but I don't quite see how to write a
>cross-compiler in pure ANS.

What problem do you see? Gforth's cross-compiler was originally
intended and claimed to be in pure ANS Forth; I did not check this,
and I guess that if it did have this property at one point, it has
probably lost it by now.

> There was an extension proposal that seems
>to be offline now:
>
> http://www.forth.com/downloads/ANS/XCpaper.pdf

Maybe these ones:

http://www.mpeforth.com/arena/XCtext5.PDF
http://www.mpeforth.com/arena/XCapp5.PDF

hughag...@gmail.com

unread,

May 16, 2016, 10:25:58 AM5/16/16

to

On Monday, May 16, 2016 at 6:40:39 AM UTC-7, Anton Ertl wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> >I'm probably below grade C but I don't quite see how to write a
> >cross-compiler in pure ANS.
>
> What problem do you see? Gforth's cross-compiler was originally
> intended and claimed to be in pure ANS Forth; I did not check this,
> and I guess that if it did have this property at one point, it has
> probably lost it by now.

ANS-Forth is totally crippled. I've already pointed out how both of the techniques used for writing a cross-compiler don't work under ANS-Forth.
1.) Use the built-in outer-interpreter --- you don't get literal numbers because LITERAL is not vectored so you can't change it to compile into the target system, but it always compiles into the host system.
2.) Write your own outer-interpreter --- you can't do this because FIND has been crippled to have ambiguous behavior on most of the words in ANS-Forth (everything that was traditionally immediate) --- but my disambiguifiers now fix this problem so this technique will now work.

So, #2 above can be used, if you have the disambiguifiers.

There are still problems though. ANS-Forth does not provide a way to smudge a word given its xt. This is necessary for local variables.

I think that the ANS-Forth committee purposely sabotaged ANS-Forth to make it unusable for writing a cross-compiler --- Forth Inc. makes most of its money by selling cross-compilers, and Elizabeth Rather was the chair-person of the ANS-Forth committee --- coincidence, or not?

Most of the people who claim that a cross-compiler can be written in ANS-Forth, are actually customers of either Forth Inc. or MPE. They don't have the source-code to their cross-compiler; they don't realize that the source-code is not ANS-Forth at all. They may also have a cross-compiler written using technique #1 above, and they just put up with the lack of literal numbers, vaguely assuming that this limitation is inherent in cross-compilers and wasn't purposeful sabotage of ANS-Forth.

WJ

unread,

May 16, 2016, 11:15:09 AM5/16/16

to

Tessa Bonting wrote:

> Live the Forth.

It seems that this person thinks that there is something
magical and mystical about ANS Forth.

The language is like a religion to him.

--
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

Albert van der Horst

unread,

May 16, 2016, 1:58:42 PM5/16/16

to

On 2016-05-16, Paul Rubin <no.e...@nospam.invalid> wrote:
> Tessa Bonting <tessa....@gmail.com> writes:
>> Anybody, that is at grade C in ANS-Forth can write a cross-compiler
>> and you say that you are a professial writer of Forth.
>
> I'm probably below grade C but I don't quite see how to write a
> cross-compiler in pure ANS. There was an extension proposal that seems
> to be offline now:
>
> http://www.forth.com/downloads/ANS/XCpaper.pdf

Goebbels wants to discuss the "Judenfrage". If you do, you implicitly
admit there is a "Judenfrage".

The problems with a cross compiler lay squarely on other terrains than
the interpreter. E.g the noforth cross-compiler starts with defining
BL-WORD which is ' BL WORD ' but with automatic REFILL. Then it goes
on with WINTERPRET interpreting a single word.
The remainder is portable accross Win32Forth, Gforth and 32 and 64 bit
ciforth. We have discussed a problem with line endings portability
issue between Win32Forth and Gforth, remember?

The real problems are the format of executable files (on OS-es) or the
booting (for stand alone) and mastering the target instruction set.

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

Bernd Paysan

unread,

May 16, 2016, 5:54:22 PM5/16/16

to

Am Mon, 16 May 2016 13:37:14 +0000 schrieb Anton Ertl:

> Paul Rubin <no.e...@nospam.invalid> writes:
>>I'm probably below grade C but I don't quite see how to write a
>>cross-compiler in pure ANS.
>
> What problem do you see? Gforth's cross-compiler was originally
> intended and claimed to be in pure ANS Forth; I did not check this,
> and I guess that if it did have this property at one point, it has
> probably lost it by now.

Jens Wilke managed to run the cross compiler on iForth before Gforth was
self-hosted, removing all bigForth-specific parts (bigForth was the
original host for Gforth's cross compiler). Things necessary to do back
then were handling of number-prefixes (like $CAFEBABE for hex), so part
of the cross compiler contain copies of Gforth's sources.

Hugh apparently has written his cross compiler using carnal knowledge of
the Forth he was using, and can't think outside that box - he used hooks
in his system to implement some functions like putting literals into the
dictionary.

A typical thing about a cross compiler is that you have to rewrite the
entire outer interpreter. With recognizers, you could skip that, and
just replace the number recognizer with a cross-compiling one. This
could even resolve some remaining issues with our cross compiler for 32-
>64 bit cross compilations, because it can't deal with 64 bit constants
(we work around that problem were we need these constants). A cross
compiler recognizer could handle 64 bit constants even when it runs on a
32 bit system.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

hughag...@gmail.com

unread,

May 16, 2016, 6:12:29 PM5/16/16

to

It is pathetic that you are so dependent upon GCC that you can't allow Forth-200x to have any feature, such as ALLOCATION, that isn't already provided by GCC. The standard is supposed to standardize behavior not implementation, but you are standardizing a GCC implementation. Most likely, you don't actually know assembly-language --- that is just pathetic! --- I think that Elizabeth Rather appointed you to be the chair-person of the Forth-200x committee because you agreed to make gForth generate slower code than SwiftForth so as to not undermine SwiftForth sales (I found gForth code to be about half the speed of SwiftForth, which is pretty pathetic considering that SwiftForth does almost no optimization and the code is too slow for commercial use).

At the same time, Elizabeth Rather began telling a lot of lies about my novice package. Specifically, she said this:
-----------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------
I was seriously offended by this statement. I put a lot of work into implementing general-purpose data-structures in the novice-package, and she is just straight-out lying about how they work. She is trying to drag myself, and the entire Forth community, down to her own level of incompetence. And why is she so opposed to general-purpose data-structures? Supposedly, Charles Moore was opposed to general-purpose code, and there are some quotes from Charles Moore indicating this --- I doubt that Charles Moore is actually so opposed to general-purpose code though, or he would be here on c.l.f. saying so himself --- more likely is that his thoughts on the subject are more nuanced than people believe, and that saying he is totally opposed to general-purpose code is just Elizabeth Rather's simple-minded interpretation.

Now she claims to have never heard of my involvement in Forth-200x. At the time however, she was demanding that I be kicked out. This is what she said:
-----------------------------------------------------------------------------
Hugh has been hanging around c.l.f for several years, now. He originally
got mad at FORTH, Inc. because we insisted on charging for an upgrade to
SwiftForth 3.0 for people who had bought 2.x > a year earlier. He has
had one programming job, paying $10/hr, on which he wrote a
cross-compiler for a microcontroller for a project. He was fired at the
end of the project, and has since been working as a taxicab driver. He
is actively homophobic, and developed his hatred for me when I called
him on a particularly vitriolic attack on a c.l.f poster who dared to
mention his partner. Pretty much everyone on c.l.f has his number.

Hope you are doing well. Ned and i are enjoying life in Hawaii, and hope
you are, too!

Aloha,
Elizabeth
-----------------------------------------------------------------------------
She is totally lying! I wasn't fired from Testra (where I wrote MFX for the MiniForth processor). Her lie isn't even realistic --- how would she know anything about Testra business? --- nobody at Testra can stand her either, and they aren't talking to her. After I left Testra after finishing MFX, I worked worked as an IBM370 assembly-language programmer for about 18 months, and after that company went out of business I went back to Testra and did another project for them.

And, BTW, how is that Hawaii thing working out for you, Elizabeth? There was an assassination attempt made against you in the parking lot of the condo where you lived. After this you had to leave Hawaii. That assassination attempt was bad publicity for Hawaii because Hawaii represents itself as being crime-free, so you were told to leave Hawaii because the police didn't want to protect you from future assassination attempts. Aloha! (means both "hello" and "goodbye," and in your case it meant: "goodbye and don't come back!"). Just prior to the assassination attempt you were on comp.lang.forth bragging about how Forth Inc. was suing Apple Computer for using the name "Swift" for their new programming language (Swift is Apple's answer to Google's Go; it has most of the same features as Go). So, how is that lawsuit working out for you? After the assassination attempt against you, you stopped bragging about the lawsuit and apparently dropped it. It seems likely to me that Apple Computer paid for the assassination (they can have this done for $10,000, and they would pay a lot more than that in legal fees to stop your frivolous lawsuit, so it is less expensive for them to just kill you rather than go to court). Of course, Forth Inc. scams all of its customers, so Apple Computer isn't the only company around that might want you dead --- you have left a long trail of victims, so there is no way to even begin to figure out who tried to kill you --- as far as the police in Hawaii were concerned, however, just telling you to leave was the best way to solve the problem.

Anton says that I did ask to get kicked out of Forth-200x, and this is true:
-----------------------------------------------------------------------------
Elizabeth says:
"Hope you are doing well. Ned and i are enjoying life in Hawaii, and hope
you are, too!"

I don't live in Hawaii, so kick me off the Forth-200x mailing list!

Ultimately, one or the other of us have to get kicked out --- we can't both be part of Forth-200x --- it is up to Anton to decide which one of will get kicked off, and I had expected him to make his decision already. It seems like a pretty easy decision, so I don't know why he is delaying.
-----------------------------------------------------------------------------

Elizabeth Rather has a long history of lying about people who refuse to brown-nose her. Jeff Fox, in private communication, said this:
-----------------------------------------------------------------------------
For many years Rather posted tons of garbage about Chuck and
would argue with me about simple facts over and over, always
claiming to have forgotten the facts every couple of years. She
never heard of Chuck after he left Forth Inc. She never heard
about things like cmForth and continued to make claims that
she never heard of optimzing native code Forth compilers that
were published a decade before ANS. She preferred to pretend
to be ingnorant and have a bad memory.

For years I did not think that there was any way to prevent Elizabeth
from posting garbage about Chuck and his work. All I could do was
correct her year after year and put up the abuse. It almost seemed
like she was trying to blackmail Chuck.

Then IntellaSys paid her some obscene amount of money to write
a little (poorly written) documenation on SEAforth. Then she had
no excuse to claim complete ignorance. That's when I realized
that it had been blackmail. The way to get her to stop posting
lies was simply to pay her off.

Once IntellaSys quit paying her she began posting garbage
again.
-----------------------------------------------------------------------------
This email was sent to me on 5/3/2011 and Jeff Fox died on 5/4/2011, so calling Elizabeth Rather a liar was the last thing he did in life.

John Passaniti, the flaming homosexual, used to torment Jeff Fox continually on comp.lang.forth. He would endlessly tell lies about Jeff Fox and Charles Moore, and when Jeff Fox would tell the truth Passaniti would purposely misunderstand what he said and twist his words to mean something completely untrue. Of course, Elizabeth Rather and Bernd Paysan would praise Passaniti continually, and they would pretend that Passaniti was a great Forth programmer despite the fact that Passaniti had never posted any Forth code on c.l.f. (all the code that Passaniti posted on c.l.f. was in Perl, and it seemed that Perl was the only language he knew; his claim to fame regarding Forth was to have once written a Forth-like interpreter in Perl).

After Jeff Fox died, Passaniti just disappeared. How strange, that he was supposedly a great Forth programmer, and he was so dedicated to c.l.f. that he posted messages here every day, and yet he completely lost interest in the subject and disappeared. Most likely, Elizabeth Rather was paying him to torment Jeff Fox --- after Jeff Fox died there was no further need for him, so she stopped paying him --- he left because he wasn't getting paid anymore.

hughag...@gmail.com

unread,

May 16, 2016, 7:07:00 PM5/16/16

to

On Monday, May 16, 2016 at 2:54:22 PM UTC-7, Bernd Paysan wrote:
> A typical thing about a cross compiler is that you have to rewrite the
> entire outer interpreter. With recognizers, you could skip that, and
> just replace the number recognizer with a cross-compiling one. This
> could even resolve some remaining issues with our cross compiler for 32-
> >64 bit cross compilations, because it can't deal with 64 bit constants
> (we work around that problem were we need these constants). A cross
> compiler recognizer could handle 64 bit constants even when it runs on a
> 32 bit system.

You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter.

Recognizers are a terrible idea. I won't have them in my Straight Forth that is designed primarily to be a platform for cross-compilers.

Recognizers give Forth a syntax, which Forth has traditionally not had. The problem with recognizers in Forth-200x is that there are likely to be a lot of them, and they are going to clash with each other. Every Forth-200x program is going to require a mish-mash of recognizers, and so every Forth-200x program will have syntax that is unique to itself. This is very similar to the problem in ANS-Forth in which there is a lot of ambiguity --- we have different ANS-Forth compilers (SwiftForth, gForth, VFX and Win32Forth) that are incompatible with each other regarding fundamental aspects of the language, and yet are all considered to be ANS-Forth (and they can all make a claim that they conform to the ANS-Forth document given their interpretation of the ambiguous aspects because multiple interpretations are valid). Similarly, different Forth-200x compilers will have incompatible syntax and programs written for one won't compile on another, but every Forth-200x compiler will claim to conform to Forth-200x.

Normally, if a person is looking at Forth source-code and sees a word that he doesn't recognize, he can look up the word to find out what it does. This is done with WHEREIS in VFX and with LOCATE in most Forth systems. This gives him the source-code for the word, which is hopefully commented. Also, there may be documentation for a code-library that he is using and it will explain each word provided. But what does the person look up when he sees $CAFEBABE or some such thing? LOCATE is not going to work! He is left not knowing what the word does, and not having any way to find out.

Actually, I think that it is a good idea to add some syntax to Forth. In Straight Forth, I will allow hexadecimal numbers to be represented by a $ in front --- so $CAFEBABE is effectively the same as: 3405691582. This is part of the language though which will be well-documented, and it isn't going to change. Nobody can install his own recognizer in which the $ in front indicates something else.

Recognizers don't have any practical value. They are just provided to allow every Forth-200x user to exercise his creativity and have is own cute syntax. This doesn't help people to write programs though. At best, (such as allowing a $ in front to indicate hexadecimal), it may improve readability. There are few cases in which readability will be improved though --- for the most part, recognizers in Forth-200x are going to be written by people who have too much free time on their hands and who want to cutify Forth --- I predict that Forth-200x will have dozens of incompatible recognizers and all of them will be written late at night by alcoholic failed-artists trying to be cute.

Recognizers are not the way to implement a cross-compiler --- anybody who believes this, does not know how to implement a cross-compiler.

Ilya Tarasov

unread,

May 17, 2016, 4:04:10 AM5/17/16

to

> You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter.

Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course.

This is a snippet of cross-compiler for my Forth-CPU

: KF532-LIT // N --
CAN-DISPATCH OFF
// placing literal from stack to memory
CAN-DISPATCH ON
;
: MAIN:
['] KF532-LIT TO DISPATCH-NUMBER
CAN-DISPATCH ON
...

> Recognizers don't have any practical value.

+1

First time I've heard of this new toy :) This is intresting exercise, but in practice it is useless for anybody skilled enough to write cross-compiler (and understood how both PC and target CPU works).

hughag...@gmail.com

unread,

May 17, 2016, 4:12:36 AM5/17/16

to

On Monday, May 16, 2016 at 4:07:00 PM UTC-7, hughag...@gmail.com wrote:
> Actually, I think that it is a good idea to add some syntax to Forth. In Straight Forth, I will allow hexadecimal numbers to be represented by a $ in front --- so $CAFEBABE is effectively the same as: 3405691582. This is part of the language though which will be well-documented, and it isn't going to change. Nobody can install his own recognizer in which the $ in front indicates something else.

I've already written STR>NUM that could be used in an outer-interpreter to recognize numbers and convert them into numbers. This code is discussed here:
https://groups.google.com/forum/#!topic/comp.lang.forth/CYR7FhjYMkg

This is the comment in the file describing STR>NUM and related code:

\ STR>INT converts strings to integers, either singles and doubles.
\ An integer is a string of digits. There may be commas throughout.
\ An integer may have a $ # or % at the front, signifying that it is hexadecimal, decimal or binary. If none of these are present, then BASE is used.
\ An integer may have a + or - at the front (after the base signifier if there is one), signifying non-negative or negative, but otherwise it is non-negative.
\ A comma at the beginning (after the sign signifier if there is one) signifies that the integer is a double, but otherwise it is a single.

\ These are valid integers:
\ $-,123,456 double: -123456 hexadecimal
\ -,123,456 double: -123456
\ ,123,456 double: 123456
\ 123,456 single: 123456

\ STR>FLT converts strings to floats.
\ A float is a string of digits. There may be commas throughout. All floats are in decimal.
\ A comma in the front is legal but should not be used as STR>NUM will interpret this as an invalid double.
\ There must be either a decimal-point or an exponent-signifier (either 'E' or 'e') or both.
\ If there is a decimal-point, there must be digits either before or after or both.
\ The first digits are the integer part. The digits after the decimal-point, if there is a decimal-point, are the fraction part.
\ The digits after the exponent-signifier, if there is an exponent-signifier, are the exponent part (scientific notation).
\ If there is an exponent-signifier, there must be digits after it.
\ An exponent may have a + or - at the front, signifying non-negative or negative, but otherwise it is non-negative.

\ STR>NUM converts strings to either integers or floats.

\ These are valid floats:
\ -123,456.78 float: -123456.78
\ -123,456.78E4 float: -1234567800
\ -123,456.78E-4 float: -12.345678
\ 123E4 float: 1230000

hughag...@gmail.com

unread,

May 17, 2016, 4:43:53 AM5/17/16

to

On Tuesday, May 17, 2016 at 1:04:10 AM UTC-7, Ilya Tarasov wrote:
> > You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter.
>
> Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course.

ANS-Forth could have easily been made to support cross-compilers. All that was needed was to make LITERAL vectored.

A lot of the low-level code in ANS-Forth could have been defined as being vectored. Weirdly enough, nothing in ANS-Forth was defined as being vectored. The book "Starting Forth" discusses vectored execution, so Elizabeth Rather should have been aware of the concept when she wrote ANS-Forth --- the book does describe the subject as being "hairy" (for our Russian readers, that means "difficult") --- so maybe that was a part of the book that she didn't understand.

All in all, ANS-Forth is the work of a non-programmer --- it was just a marketing gimmick from Forth Inc. --- ANS-Forth has to be abandoned if Forth is ever going to succeed.

> > Recognizers don't have any practical value.
>
> +1

Well, my STR>NUM allows either a + or a - in front of the number to indicate positive or negative, with positive being the default if neither is there.

try string-stack.4th
UPPER isn't unique.
OCTAL isn't unique.
2 definitions were hidden
ok
s" +123" str>num ok
.s
123 1 <-Top ok

The 1 is a code telling what kind of number it is. The codes are:

0 \ these are the kinds of numbers
enum #invalid
enum #single
enum #double
enum #float
drop

> First time I've heard of this new toy :) This is intresting exercise, but in practice it is useless for anybody skilled enough to write cross-compiler (and understood how both PC and target CPU works).

Forth-200x is overly concerned with toy programming --- they are not focusing their minds on making the language practical.

I get the impression that very few people are writing programs in Forth. There is no interest in my string-stack.4th apparently because nobody is writing any programs that involve text --- it is not that there is a better way to work with strings, because there is no other string package available, neither better nor worse --- the many Forth experts on Forth-200x just aren't writing programs involving text or any other kind of data.

Forth-200x is full of hobbyists who just want to be experts because being an expert seems pretty fun, and Forth-200x has little or no qualification to be an expert, so it is an opportunity to be an expert programmer without actually programming.

Anyway Ilya --- I'm happy to see that you have built a Forth processor and that you are using Forth for practical work --- I translated that webpage of yours from Russian to English and I'm reading up on your work.

There seems to be more interest in Forth in Russia these days than in America or Europe, and there seems to be little or no interest in ANS-Forth or Forth-200x in Russia --- eventually Forth may become a purely Russian language and people will forget that it actually originated in America during the 20th century --- the Americans dropped the ball, and the Russians picked it up.

Gerry Jackson

unread,

May 17, 2016, 5:05:36 AM5/17/16

to

On 17/05/2016 09:43, hughag...@gmail.com wrote:
> On Tuesday, May 17, 2016 at 1:04:10 AM UTC-7, Ilya Tarasov wrote:
>>> You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter.
>>
>> Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course.
>
> ANS-Forth could have easily been made to support cross-compilers. All that was needed was to make LITERAL vectored.
>

I'm puzzled about why you persist in making that claim when instead of
writing in the target code, say
... 1234 ...
instead write
... [ 1234 ] LITERAL ...
and the host redefines LITERAL to stick the number in target code, just
like IF etc have to be redefined.

I admit this is ugly but it *is* ANS Forth whether you like it or not.

Elsewhere you claim smudge is needed for locals, this is also not true
as wordlists can be created and used for locals.

--
Gerry

Ilya Tarasov

unread,

May 17, 2016, 5:14:23 AM5/17/16

to

> Forth-200x is full of hobbyists who just want to be experts because being an expert seems pretty fun, and Forth-200x has little or no qualification to be an expert, so it is an opportunity to be an expert programmer without actually programming.

Nearly the same situation in Russia FIG. A lot of hobbyists who triyng to 'determine Forth roadmap', but don't use Forth for real projects. Almost the same situation with standards - SP-Forth by Andrey Cherezov claimed as 'Standard de-facto for Russia'. This product is not bad, but it targeting server application primarly and not suited well for desktop and embedded. Information noise around it is worse, because 'everyone should know we have SP-Forth and you should improve it instead of implement your own'. Nothing new here :)

> Anyway Ilya --- I'm happy to see that you have built a Forth processor and that you are using Forth for practical work --- I translated that webpage of yours from Russian to English and I'm reading up on your work.

This is more placeholder than real website for partners involving. I don't plan to sell my ForthCPUs via Internet, and all our partners knows we can implement a complete FPGA system. Forth is only a very effective tool, and we need no other standards or self-claimed experts.

> There seems to be more interest in Forth in Russia these days than in America or Europe, and there seems to be little or no interest in ANS-Forth or Forth-200x in Russia --- eventually Forth may become a purely Russian language and people will forget that it actually originated in America during the 20th century --- the Americans dropped the ball, and the Russians picked it up.

Look at www.fforum.winglion.ru We create it in 2006 with my friend Ivan Makarchenko. Unfortunately, he is died several years ago. Now I'm supporting this forum, and it is a place for RuFIG. English is allowed and has a separate folder for non-russian users. Now we have about 300 users, but 10-20 are active. Having an electronic design center, I'm not expecting any serious results... because I KNOW how to use Forth and sell devices driven by it.

All forthers are welcomed, note registration must be approved manually because of hundreds of bots. Write you nick to hishnik7@rambler (dot) ru after completing registration.

Cecil Bayona

unread,

May 17, 2016, 5:34:50 AM5/17/16

to

Can you point me to where there is a copy of your novice package and
tools? I've seen several mentions of it on CLF but I have not see a
copy. I assume that the string handling routines are in there too.

Thanks

--
Cecil - k5nwa

unread,

May 17, 2016, 10:12:12 AM5/17/16

to

"HAA" <som...@microsoft.com> writes:
>If ANS was so great, what need was there for 200x?

There is only so much a standard can do at a time. Time moves on,
Forth systems get additional features, Forth programs use additional
features, and there is additional common practice. Some of that was
documented in Forth-2012. But for the same reason we are continuing.

hughag...@gmail.com

unread,

May 17, 2016, 1:46:56 PM5/17/16

to

Here it is: http://www.forth.org/novice.html

The forth.org website is no longer active so it is not possible for me to send them an updated version of my novice-package.

Email me so I get your email address and I will email you the string-stack.4th file as well as upgraded versions of novice.4th and list.4th.

Now that the forth.org website is kaput I will have to find another website to put my novice-package on, but I haven't gotten around to doing that yet.

hughag...@gmail.com

unread,

May 17, 2016, 2:08:31 PM5/17/16

to

On Tuesday, May 17, 2016 at 2:05:36 AM UTC-7, Gerry wrote:
> On 17/05/2016 09:43, hughag...@gmail.com wrote:
> > On Tuesday, May 17, 2016 at 1:04:10 AM UTC-7, Ilya Tarasov wrote:
> >>> You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter.
> >>
> >> Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course.
> >
> > ANS-Forth could have easily been made to support cross-compilers. All that was needed was to make LITERAL vectored.
> >
>
> I'm puzzled about why you persist in making that claim when instead of
> writing in the target code, say
> ... 1234 ...
> instead write
> ... [ 1234 ] LITERAL ...
> and the host redefines LITERAL to stick the number in target code, just
> like IF etc have to be redefined.
>
> I admit this is ugly but it *is* ANS Forth whether you like it or not.

It is ugly and the cross-compiler is ANS-Forth --- I never said otherwise --- ANS-Forth is not able to cross-compile Forth (Forth is supposed to have literal numbers, so what is being cross-compiled here is at best Forth-like code).

I actually have this supported:
... [ 1234 ]L ...
This is somewhat shorter and less ugly, but it is still not Forth (still not supporting literal numbers).

Really, LITERAL needs to be vectored! This need was obvious in 1994, and it continues to be obvious in 2016, and after Forth-200x gets released (if it ever gets released), this need will still be obvious.

> Elsewhere you claim smudge is needed for locals, this is also not true
> as wordlists can be created and used for locals.

Word-lists are created with WORDLIST (see section 16.6.1.2460):
"A system shall allow the creation of at least 8 new word lists in addition to any provided as part of the system."

You can't call WORDLIST in every function to create a word-list for the locals of that function, and then just forget about that wid --- if you have more than 8 functions with locals then your cross-compiler is not ANS-Forth compliant anymore (your cross-compiler may work on some or all of the major ANS-Forth systems though; as Anton says: "A system that would tell us all non-standard usages would be nice, but we don't have that. For now the solution is to test on as many systems as possible.")

If you did use VFX or SwiftForth to write a cross-compiler using this technique of calling WORDLIST for every function with locals (I don't know if this will actually work) and it did work, then Stephen Pelc or Leon Wagner or both would likely modify their compiler so that it would only allow 8 calls to WORDLIST --- they can do this, and still be ANS-Forth compliant --- they would be motivated to do this to prevent you from writing a cross-compiler in competition with them. They are not your friends! They will do everything in their power to prevent you from competing with them! This is the whole purpose of the committee!

hughag...@gmail.com

unread,

May 17, 2016, 2:50:07 PM5/17/16

to

On Tuesday, May 17, 2016 at 2:14:23 AM UTC-7, Ilya Tarasov wrote:
> > Forth-200x is full of hobbyists who just want to be experts because being an expert seems pretty fun, and Forth-200x has little or no qualification to be an expert, so it is an opportunity to be an expert programmer without actually programming.
>
> Nearly the same situation in Russia FIG. A lot of hobbyists who triyng to 'determine Forth roadmap', but don't use Forth for real projects. Almost the same situation with standards - SP-Forth by Andrey Cherezov claimed as 'Standard de-facto for Russia'. This product is not bad, but it targeting server application primarly and not suited well for desktop and embedded. Information noise around it is worse, because 'everyone should know we have SP-Forth and you should improve it instead of implement your own'. Nothing new here :)

It is natural to want to be the Standard with a capital 'S'.

If we ever make contact with the Sasquatch (I hope we don't), there is going to be trouble! The Sasquatch will refuse to become Christians because of the Christian doctrine that God created us (humans) in his own image. The truth is exactly the opposite, that we created God in our image --- presumably the Sasquatch have their own vision of God, big and hairy --- the inevitable result will be the Christians waging a war of genocide against the Sasquatch (this is why the Sasquatch are hiding from us!).

Getting back to the subject of SPforth, I downloaded it. There was no source-code however. I got on the forum and asked how to obtain the source-code, but I was told that the source-code was provided with the download. It is not! I just forgot about SPforth after that. Also, SPforth has quotations, but they are just fake quotations --- they don't have access to the parent function's local variables --- so it wasn't really doing what I wanted anyway.

I have my Stundurd design --- I gave it that name as a joke, to mock everybody who wants to be Standard.

Elizabeth D. Rather

unread,

May 17, 2016, 5:40:25 PM5/17/16

to

On 5/17/16 4:06 AM, Anton Ertl wrote:
> "HAA" <som...@microsoft.com> writes:
>> If ANS was so great, what need was there for 200x?
>
> There is only so much a standard can do at a time. Time moves on,
> Forth systems get additional features, Forth programs use additional
> features, and there is additional common practice. Some of that was
> documented in Forth-2012. But for the same reason we are continuing.

All true. In recognition of this fact, all major standards organizations
(ANSI, IEEE, ISO, etc.) *require* standards to be updated every 5 years.
If a standard is not updated, it loses official recognition.

unread,

May 18, 2016, 5:10:10 AM5/18/16

to

On 2016-05-17, hughag...@gmail.com <hughag...@gmail.com> wrote:
<SNIP>

> Now that the forth.org website is kaput I will have to find another
website to put my novice-package on, but I haven't gotten around to
doing that yet.

Please wrap your lines. Thanks.

The worst thing to happen is that suddenly it falls in the hands of those
sharks that make money from internet addresses.
Such frozen sites should be archived in a single file and then
mirrored somewhere.
The Dutch Forth chapter is part of a largish organisation (HCC)
with tens of thousands of members.
Should we propose to mirror such site?
Even better is if the site is transferred to a reliable organisation.

In the meantime. Could you manage to capture the site?

The wayback machine is fantastic, but you can't rely on it.
Governments will try to make it reflect their vision of history.
If it doesn't, they will close down.

Groetjes Albert.

Andrew Haley

unread,

May 18, 2016, 5:58:10 AM5/18/16

to

Paul Rubin <no.e...@nospam.invalid> wrote:
> Tessa Bonting <tessa....@gmail.com> writes:
>> Anybody, that is at grade C in ANS-Forth can write a cross-compiler
>> and you say that you are a professial writer of Forth.
>

> I'm probably below grade C but I don't quite see how to write a
> cross-compiler in pure ANS.

There is one thing which seems to keep coming up: there is some
question about whether it is possible to write an interpreter loop in
portable Forth. It is arguable, but I have tried the following code
on every Forth that I care about and it works just fine. (In practice
a full-featured loop would be more elaborate, but this is a proof of
concept.)

So, if there is a problem it is an entirely theoretical one. As far
as I'm aware this is the only problem which might prevent anyone
writing a cross- compiler in Standard Forth.

In an ideal world the following code or something like it would be in
an appendix to the standard along with the strong suggestion that if
it doesn't work your Forth is broken.

Andrew.

: number ( a n1 - n2)
2>r 0 0 2r> dup >r >number r> = abort" ?" 2drop ;

: compiling ( i*x a - j*x)
find ?dup 0= if
count number postpone literal
else 0< if compile,
else execute
then then ;

: interpreting ( i*x a - j*x)
find ?dup 0= if count number
else drop execute then ;

: interp-loop ( i*x - j*x)
begin
bl word dup c@ while
state @ if compiling else interpreting then
repeat drop ;

Albert van der Horst

unread,

May 18, 2016, 7:26:01 AM5/18/16

to

With prefixes this problem just goes away.
The prefixes that compile/interpret target numbers (or string)
are present in the target vocabulary.
So if target is the first in the search order,
the DROP will be from the target.
Likewise if the prefix 1 --that recognizes numbers that
start with 1 -- is found in the target vocabulary, it will
result in a target number.

This doesn't really works with the so called recognizers.
Although you could add recognizers to work for target numbers
probably (by redefining to look what the search order is,
it would be orders of magnitute more complicated than your
solution.

The real problems remain.

Groetjes Albert

P.S.
I hate the recognizer proposal. Instead of trying to make
Forth itself simpler, it seems intended to accomodate all silly,
cumbersome and conflicting notations invented in all other
languages for no good reason. "Not because it must, but because
it can"

rickman

unread,

May 18, 2016, 9:35:57 AM5/18/16

to

On 5/18/2016 5:10 AM, Albert van der Horst wrote:
>
> The wayback machine is fantastic, but you can't rely on it.
> Governments will try to make it reflect their vision of history.
> If it doesn't, they will close down.

There is enough crazy talk here already. Do we really need paranoid
conspiracy theory type talk as well?

--

Rick C

rickman

unread,

May 18, 2016, 9:41:00 AM5/18/16

to

I read some of what Hugh talked about for his processor and my
impression was that it would be a fairly impractical processor because
of being overly complex. Like the highly pipelined and parallelized
CISC and RISC designs of today, his processor would be difficult to get
running at a decent speed. It is usually better to let the software
manage the various details of the software design and keep the
underlying hardware as simple as practical. That is why a stack machine
can run very fast. Simple hardware.

I'm not saying it won't run, I'm just saying it would not be small or
fast. Usually you can get one of the two easily. It's a poor design
that can't get either.

--

Rick C

Andrew Haley

unread,

May 18, 2016, 11:28:42 AM5/18/16

to

Albert van der Horst <alb...@cherry.spenarnc.xs4all.nl> wrote:
> On 2016-05-18, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:

>> So, if there is a problem it is an entirely theoretical one. As far
>> as I'm aware this is the only problem which might prevent anyone
>> writing a cross- compiler in Standard Forth.
>

> With prefixes this problem just goes away.

Well, maybe, but it's not a real problem anyway.

> I hate the recognizer proposal. Instead of trying to make
> Forth itself simpler, it seems intended to accomodate all silly,
> cumbersome and conflicting notations invented in all other
> languages for no good reason. "Not because it must, but because
> it can"

True! :-)

Andrew.

Anton Ertl

unread,

May 18, 2016, 1:08:45 PM5/18/16

to

Albert van der Horst <alb...@cherry.spenarnc.xs4all.nl> writes:
>On 2016-05-18, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>: number ( a n1 - n2)
>> 2>r 0 0 2r> dup >r >number r> = abort" ?" 2drop ;
>>
>>: compiling ( i*x a - j*x)
>> find ?dup 0= if
>> count number postpone literal
>> else 0< if compile,
>> else execute
>> then then ;
>>
>>: interpreting ( i*x a - j*x)
>> find ?dup 0= if count number
>> else drop execute then ;
>>
>>: interp-loop ( i*x - j*x)
>> begin
>> bl word dup c@ while
>> state @ if compiling else interpreting then
>> repeat drop ;

...

>This doesn't really works with the so called recognizers.
>Although you could add recognizers to work for target numbers
>probably (by redefining to look what the search order is,
>it would be orders of magnitute more complicated than your
>solution.

Why would a recognizer look at what the search order is?

You have words like HOST and TARGET that change the search order, and
with recognizers, they would also change the recognizer stack. Orders
of magnitude more complicated?

>I hate the recognizer proposal. Instead of trying to make
>Forth itself simpler, it seems intended to accomodate all silly,
>cumbersome and conflicting notations invented in all other
>languages for no good reason. "Not because it must, but because
>it can"

Right. Let's make Forth simpler by eliminating recognizers, instead
of having silly, cumbersome, and conflicting notations for literal
numbers, invented in other languages for no good reason.

Instead of the built-in recognizer for various kinds of numbers, let's
make it simpler, and go for a simple Forth solution like CHAR/[CHAR].
Let's have BASE# 123 and [BASE#] 123 for single integers (converted
using BASE), DBASE# 123 and [DBASE#] 123 for doubles (also eliminates
the problem of what "." in a number means), and F# 123 and [F#] 123
for FP numbers.

Then you can simplify the code above by just ABORTing when FIND was
unsuccessful, without that silly and cumbersome NUMBER complication
that is there for no good reason. And as a benefit, the simplified
approach also works for doubles and FP numbers, unlike the code above.

Of course, then you get the usual problems with parsing words, but at
least it's different from other languages; and isn't that the most
important thing for a real Forther?

hughag...@gmail.com

unread,

May 18, 2016, 1:49:52 PM5/18/16

to

On Tuesday, May 17, 2016 at 11:08:31 AM UTC-7, hughag...@gmail.com wrote:
> On Tuesday, May 17, 2016 at 2:05:36 AM UTC-7, Gerry wrote:
> > I'm puzzled about why you persist in making that claim when instead of
> > writing in the target code, say
> > ... 1234 ...
> > instead write
> > ... [ 1234 ] LITERAL ...
> > and the host redefines LITERAL to stick the number in target code, just
> > like IF etc have to be redefined.
> >
> > I admit this is ugly but it *is* ANS Forth whether you like it or not.
>
> It is ugly and the cross-compiler is ANS-Forth --- I never said otherwise --- ANS-Forth is not able to cross-compile Forth (Forth is supposed to have literal numbers, so what is being cross-compiled here is at best Forth-like code).
>
> I actually have this supported:
> ... [ 1234 ]L ...
> This is somewhat shorter and less ugly, but it is still not Forth (still not supporting literal numbers).
>
> Really, LITERAL needs to be vectored! This need was obvious in 1994, and it continues to be obvious in 2016, and after Forth-200x gets released (if it ever gets released), this need will still be obvious.

This is what I had in MFX for literal numbers:
: 8+ [ 8 ]L + ;

This is just a shorthand for this:
: 8+ [ 8 ] literal + ;

I did this because UR/Forth (and Forth-83) also failed to make LITERAL vectored. Now ANS-Forth fails to make LITERAL vectored, so there has been no improvement. Presumably Forth-200x will maintain the tradition of failing to make LITERAL vectored...

MFX used the built-in outer-interpreter. This problem can be avoided by writing your own outer-interpreter with its own LITERAL etc.. There are problems here too though! QUIT is not vectored either, so there is no way to make it call your new-and-improved outer-interpreter. If you have an abort on an error, QUIT will be called internally by the word that aborted and it will return to the old outer-interpreter. You will have to manually restart your new outer-interpreter. If you don't do this, and you try to cross-compile the program when you're in the wrong outer-interpreter, chaos will result!

All in all, the solution is to make LITERAL vectored --- this was obvious in 1994 and continues to be obvious in 2016. There are some other features that are also needed, such as a way to examine an xt and determine its attributes (what vocabulary it is in, immediate or not immediate, smudged or not smudged, etc.), and to modify all of these attributes. Moving a word from one vocabulary to another is important!

In MFX I had modules. This means that I could mark words as being smudge-ready . I had a word END-MODULE that would search the entire dictionary and smudge all of of the smudge-ready words (and also turn off the smudge-ready flag). This allowed me to have only certain words in the module visible outside of the module --- all the words that were used only within the module were marked as smudge-ready and got smudged by END-MODULE that was at the end of the module (each file was a module). This really reduces name-space pollution in a large program. I had only one level of module --- it would be possible to have multiple levels of modules. This would be a good way to implement locals. The locals are marked as smudge-ready-level1 and the semi-colon smudges all the smudge-ready-level1 words, so it smudges the locals in that function (IIRC that is how I did it in MFX, although my memory is somewhat fuzzy after 22 years). We could also have a way to mark words as smudge-ready-level2 and END-MODULE would smudge all the smudge-ready-level2 words. There could also be smudge-ready-level3 words and we would have END-LIBRARY that would smudge all of the smudge-ready-level3 words, with a library containing multiple modules.

All in all, making a Forth system friendly toward cross-compilers is easy --- all of these suggestions of mine are trivial to implement --- I think most of the self-proclaimed experts on cross-compilation have not actually written a cross-compiler, because if they had then they would consider all of this stuff that I'm saying to be obvious.

Jan Coombs

unread,

May 19, 2016, 3:58:36 AM5/19/16

to

On Sat, 14 May 2016 00:27:56 -0400
Rod Pemberton <NoHave...@bcczxcfre.cmm> wrote:

> Why is it that no one ever asks me? ...

Do you have electronic copy of the Harris/Intersil? RTX20xx
Hardware or Programmers' Guides?

I'm curious about just how complex this part is, and how it
differs from Novix, J1 and similar.

Jan Coombs.

Gerry Jackson

unread,

May 19, 2016, 8:27:45 AM5/19/16

to

On 18/05/2016 18:49, hughag...@gmail.com wrote:
> On Tuesday, May 17, 2016 at 11:08:31 AM UTC-7, hughag...@gmail.com wrote:
>> On Tuesday, May 17, 2016 at 2:05:36 AM UTC-7, Gerry wrote:
>>> I'm puzzled about why you persist in making that claim when instead of
>>> writing in the target code, say
>>> ... 1234 ...
>>> instead write
>>> ... [ 1234 ] LITERAL ...
>>> and the host redefines LITERAL to stick the number in target code, just
>>> like IF etc have to be redefined.
>>>
>>> I admit this is ugly but it *is* ANS Forth whether you like it or not.
>>
>> It is ugly and the cross-compiler is ANS-Forth --- I never said otherwise --- ANS-Forth is not able to cross-compile Forth (Forth is supposed to have literal numbers, so what is being cross-compiled here is at best Forth-like code).
>>
>> I actually have this supported:
>> ... [ 1234 ]L ...
>> This is somewhat shorter and less ugly, but it is still not Forth (still not supporting literal numbers).
>>
>> Really, LITERAL needs to be vectored! This need was obvious in 1994, and it continues to be obvious in 2016, and after Forth-200x gets released (if it ever gets released), this need will still be obvious.
>
> This is what I had in MFX for literal numbers:
> : 8+ [ 8 ]L + ;
>
> This is just a shorthand for this:
> : 8+ [ 8 ] literal + ;
>

I was only pointing out that, despite your claim, you could get literals
into a target system and you agree. Just because I did that doesn't mean
that I disagree with your points that things, such as your suggestions,
could things could make the writing of cross compilers easier, of course
they can. Incidentally I was wrong about stating that wordlists could be
used for locals - I'd overlooked the fact that the number of wordlists
caould be limited.

> I did this because UR/Forth (and Forth-83) also failed to make LITERAL vectored. Now ANS-Forth fails to make LITERAL vectored, so there has been no improvement. Presumably Forth-200x will maintain the tradition of failing to make LITERAL vectored...

Well the proposed recognisers could do the job instead.

>
> MFX used the built-in outer-interpreter. This problem can be avoided by writing your own outer-interpreter with its own LITERAL etc.. There are problems here too though! QUIT is not vectored either, so there is no way to make it call your new-and-improved outer-interpreter. If you have an abort on an error, QUIT will be called internally by the word that aborted and it will return to the old outer-interpreter. You will have to manually restart your new outer-interpreter. If you don't do this, and you try to cross-compile the program when you're in the wrong outer-interpreter, chaos will result!

A well-written outer interpreter would use CATCH to intercept errors,
including executions of ABORT and QUIT. What errors would you want to
recover from to continue cross compilation? Most would be fatal.

--
Gerry

Ilya Tarasov

unread,

May 19, 2016, 9:01:28 AM5/19/16

to

> A well-written outer interpreter would use CATCH to intercept errors,
> including executions of ABORT and QUIT. What errors would you want to
> recover from to continue cross compilation? Most would be fatal.

Why do we need to rewrite an entire interpreter, when cross-compilation requires well-defined and limited features? 'Recognizers' means 'you are about to write all you need and stop annoying us'. There are several point in interpreter, there vectorized words may be helpful. Now programmers must rewrite everything... so what surprising in rewriting all Forth system as needed for qualified programmer? Why do you expect ANS-compatibility will remains, if nobody in committee wants to hear real requirements? How they really can prevent writing more usable Forth systems?

Andrew Haley

unread,

May 19, 2016, 11:32:32 AM5/19/16

to

Ilya Tarasov <ilya74....@gmail.com> wrote:
>> A well-written outer interpreter would use CATCH to intercept errors,
>> including executions of ABORT and QUIT. What errors would you want to
>> recover from to continue cross compilation? Most would be fatal.
>
> Why do we need to rewrite an entire interpreter, when
> cross-compilation requires well-defined and limited features?

Because it's the best way to do it. The "entire interpreter" is a
small piece of code, and it makes sense to write one which is extended
to include cross compilation. You're pretending to choke on a gnat.

> 'Recognizers' means 'you are about to write all you need and stop
> annoying us'. There are several point in interpreter, there
> vectorized words may be helpful. Now programmers must rewrite
> everything... so what surprising in rewriting all Forth system as
> needed for qualified programmer? Why do you expect ANS-compatibility
> will remains, if nobody in committee wants to hear real
> requirements? How they really can prevent writing more usable Forth
> systems?

This is Forth! We have the choice of putting a bunch of hooks in the
base system so that it fits some people's idea of how a cross-compiler
can be written, or keeping the base system simple. We will choose the
wrong hooks for some people.

There's no-one better than Chuck Moore on this: "Do not leave hooks on
which you can hang extensions. The things you might want to do are
infinite; that means that each has 0 probability of realization. If
you need an extension later, you can code it later -- and probably do
a better job than if you did it now. And if someone else adds the
extension, will he notice the hooks you left?"

Andrew.

hughag...@gmail.com

unread,

May 19, 2016, 1:11:22 PM5/19/16

to

On Thursday, May 19, 2016 at 8:32:32 AM UTC-7, Andrew Haley wrote:
> Ilya Tarasov <ilya74....@gmail.com> wrote:
> >> A well-written outer interpreter would use CATCH to intercept errors,
> >> including executions of ABORT and QUIT. What errors would you want to
> >> recover from to continue cross compilation? Most would be fatal.
> >
> > Why do we need to rewrite an entire interpreter, when
> > cross-compilation requires well-defined and limited features?
>
> Because it's the best way to do it. The "entire interpreter" is a
> small piece of code, and it makes sense to write one which is extended
> to include cross compilation. You're pretending to choke on a gnat.

If you do write your own outer-interpreter, you will need my disambiguifiers because otherwise FIND will have ambiguous behavior on over 50 of the words in ANS-Forth (everything, such as IF etc., that was immediate in traditional Forths).

If you do write your own outer-interpreter, you will need need my STR>NUM to convert strings into numbers so you can have literal strings. This is in my string-stack.4th (I wrote STR>NUM specifically to support an outer interpreter).

So, it is not a "small piece of code" --- you need my novice-package. This would be the latest version which I can email --- the old version on www.forth.org doesn't support cross-compilation. This is an unofficial release --- I have some more code and documentation that I want to put in before I officially release it, plus I have to test it all on multiple versions of ANS-Forth compilers as usual because they all have their incompatible quirks.

I may put a cross-compiler for a simple processor in the next official release of the novice-package, but most likely not. I got paid for this stuff in the past --- I'm not enthusiastic about giving it away for free --- especially because all of Elizabeth Rather's sycophants will just say that it "sucks" and is "crap" etc., because that is what they do.

> > 'Recognizers' means 'you are about to write all you need and stop
> > annoying us'. There are several point in interpreter, there
> > vectorized words may be helpful. Now programmers must rewrite
> > everything... so what surprising in rewriting all Forth system as
> > needed for qualified programmer? Why do you expect ANS-compatibility
> > will remains, if nobody in committee wants to hear real
> > requirements? How they really can prevent writing more usable Forth
> > systems?

To answer Ilya --- the whole purpose of the committee is to prevent programmers from using ANS-Forth to compete against the commercial closed-source (not actually written in ANS-Forth internally) cross-compilers.

But no, they can't succeed. The ANS-Forth committee sabotaged tick and FIND with section (4.1.2): "Ambiguous Conditions. ... attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." But they left a loophole! POSTPONE wasn't sabotaged and it did work correctly, so it was possible to write disambiguifiers that used POSTPONE internally:

: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate

The POSTPONE of the old IF works because POSTPONE wasn't sabotaged the way that FIND was sabotaged. The new IF is no longer special-cased as a word that FIND won't work on, so FIND works on the new IF perfectly (meet the new IF, same as the old IF). Also, we no longer have the bizarre circumstance (VFX) of IF being non-immediate --- IF and all the special-case words were traditionally immediate, and thanks to the disambiguifiers, they are immediate again!

In gForth FIND will return a different xt value depending upon what STATE is at the time that FIND is called. This is beyond bizarre! But now, thanks to the disambiguifiers, gForth's FIND doesn't recognize the new IF as being a special-case word that it is supposed to act bizarrely on, and so it acts on the new IF in a normal manner just like it would on any other Forth word.

The disambiguifiers are really the key to writing your own outer-interpreter, and this is a valid way to write a cross-compiler. As I said before, there are two ways to write a cross-compiler. The other way, in which the built-in outer-interpreter is used, is also valid. If you do this however, then you can't have literal numbers because LITERAL is not vectored.

The simplest solution, would be to make LITERAL vectored. Then the built-in outer-interpreter can be used --- why have two outer-interpreters, except that the built-in outer-interpreter is sabotaged (it doesn't support literal numbers because LITERAL is not vectored)? --- obviously, it would be better to have one outer-interpreter than worked, rather than a built-in outer-interpreter that doesn't work, and another one that does work and is used instead.

Elizabeth Rather is a truly evil person! She has devoted her entire life to preventing Forth programmers from writing Forth programs in competition with Forth Inc.. The whole purpose of the ANS-Forth standard was to trap the Forth community in a pit of incompetence that they can't get out of without becoming non-standard. Fortunately, Elizabeth Rather is also dumber than a box of rocks --- she should have sabotaged POSTPONE as well as FIND to prevent cross-compilers from being written --- she left a loophole in ANS-Forth, and my disambiguifiers drive right through the loophole to make FIND work correctly again.

> This is Forth! We have the choice of putting a bunch of hooks in the
> base system so that it fits some people's idea of how a cross-compiler
> can be written, or keeping the base system simple. We will choose the
> wrong hooks for some people.
>
> There's no-one better than Chuck Moore on this: "Do not leave hooks on
> which you can hang extensions. The things you might want to do are
> infinite; that means that each has 0 probability of realization. If
> you need an extension later, you can code it later -- and probably do
> a better job than if you did it now. And if someone else adds the
> extension, will he notice the hooks you left?"
>
> Andrew.

ANS-Forth is a cult. Whenever the cult members get pushed into a corner, they respond by claiming to have a monopoly on "the Forth Way" and they say, "This is Forth!," as if only they know what Forth is. Most humorously, they always act like they can channel Charles Moore and speak for him. This is what Elizabeth Rather does routinely with her shtick about being the "second Forth programmer" and being taught personally by Charles Moore. Typically they trot out some quote from Charles Moore, similar to the way that wanna-be leaders often trot out quotes from the Bible to make it seem as if they have God's support for their agenda. This is all a great steaming pile of horse-shit! If Charles Moore wants to tell us what to believe, then he will show up on c.l.f. and do so himself --- the fact that he doesn't, seems to imply that he doesn't give a damn what we believe --- people who claim to speak for Charles Moore are just flinging the horse-shit in a mad attempt to fertilize their own poisonous weeds that they planted.

This business of channeling a great hero, and putting your own words in the hero's mouth, works a lot better if the hero is dead --- Elizabeth Rather would be more believable if she channeled some Egyptian Pharaoh from 4000 years ago --- channeling Charles Moore is stupid because it should be obvious to anybody that if he actually believed in all this horse-shit then he would shovel it himself.

Anyway, I just do whatever the hell I want to do, and I don't get permission from any hero first. In 1994 I wanted to write a Forth cross-compiler, because that was what I was getting paid to do --- this is why I now know how to write a Forth cross-compiler.

rickman

unread,

May 19, 2016, 4:29:10 PM5/19/16

to

On 5/19/2016 1:11 PM, hughag...@gmail.com wrote:
>
> ANS-Forth is a cult.

It won't be much longer before Hugh has a manifesto.

--

Rick C

Paul Rubin

unread,

May 19, 2016, 5:07:41 PM5/19/16

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> Why do we need to rewrite an entire interpreter

> The "entire interpreter" is a small piece of code,

The dictionary/wordlist mechanism is part of the interpreter, so the
code isn't THAT small. It would be great if the cross-compiler could
re-use the host Forth's existing dictionary implementation. Maybe
that's doable using just the ANS definitions, but it doesn't seem that
easy. ANS could have defined a different wordlist interface that
wouldn't have complicated implementations significantly yet would have
made cross-compilation easier, I think.

> There's no-one better than Chuck Moore on this: "Do not leave hooks on
> which you can hang extensions. The things you might want to do are
> infinite; that means that each has 0 probability of realization.

A lot of the ANS spec, and the vocabularies of historical Forths
pre-ANS, seems constructed for the specific purpose of providing enough
stuff to write a self-hosted interpreter. Cross-compilation doesn't
seem like an unpredictable or unlikely an extension. There is a
proposed ANS spec for it, after all. Also, while it's reasonable to
avoid expending extra effort implementing generality that you don't
immediately need, if you can get the generality with no extra effort you
might as well take it. In fact a lot of the time it makes the code
simpler.

hughag...@gmail.com

unread,

May 19, 2016, 5:16:41 PM5/19/16

to

Elizabeth Rather has a manifesto called ANS-Forth --- that is just her special way of informing the world that she is the "leading expert" on Forth who sets the standard that all Forth programmers rely on --- you seem to like her manifesto just fine.

"You hypocrite, first cast out the beam out of your own eye; and then shall you see clearly to cast out the speck out of your brother's eye."

This seems to be a constant theme with you. This is from the 2010:

On Nov 11, 5:31 am, rickman <gnu...@gmail.com> wrote:
> I estimate it is just a matter of time... and not much of it... before
> Hugh has a manifesto...
>
> Anyone disagree?
>
> Rick

hughag...@gmail.com

unread,

May 19, 2016, 5:42:16 PM5/19/16

to

On Thursday, May 19, 2016 at 2:07:41 PM UTC-7, Paul Rubin wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >> Why do we need to rewrite an entire interpreter
> > The "entire interpreter" is a small piece of code,
>
> The dictionary/wordlist mechanism is part of the interpreter, so the
> code isn't THAT small. It would be great if the cross-compiler could
> re-use the host Forth's existing dictionary implementation. Maybe
> that's doable using just the ANS definitions, but it doesn't seem that
> easy. ANS could have defined a different wordlist interface that
> wouldn't have complicated implementations significantly yet would have
> made cross-compilation easier, I think.

If FIND works then you can use it in your outer-interpreter, and you get the whole dictionary implementation with word-lists and all that.

My disambiguifiers make FIND work, so you are good to go!

I have not actually written an outer-interpreter however. MFX used the built-in outer-interpreter and we just put up with the lack of literal numbers (it looks unprofessional, but it is not really a major setback because constants are used for most constant numbers anyway). I think that, given STR>NUM and given a FIND that is uncrippled, the outer-interpreter should be easy to write. You still have the problem of QUIT going to the wrong outer-interpreter, but it may be possible to fix that with CATCH and THROW. Until I actually do this however, I can't say if it is easy or even possible --- past experience ANS-Forth indicates that there may be unexpected pit-falls...

> > There's no-one better than Chuck Moore on this: "Do not leave hooks on
> > which you can hang extensions. The things you might want to do are
> > infinite; that means that each has 0 probability of realization.
>
> A lot of the ANS spec, and the vocabularies of historical Forths
> pre-ANS, seems constructed for the specific purpose of providing enough
> stuff to write a self-hosted interpreter. Cross-compilation doesn't
> seem like an unpredictable or unlikely an extension. There is a
> proposed ANS spec for it, after all. Also, while it's reasonable to
> avoid expending extra effort implementing generality that you don't
> immediately need, if you can get the generality with no extra effort you
> might as well take it. In fact a lot of the time it makes the code
> simpler.

UR/Forth just had CONTEXT and CURRENT --- I was able to write MFX just fine. MFX itself didn't have vocabularies, but I didn't consider this to be a problem --- it did imply, however, that Forth-83 can't be used to write a cross-compiler for Forth-83 --- it may be possible to write an ANS-Forth cross-compiler for ANS-Forth, complete with word-lists, but I don't know as I haven't tried to do so yet. I don't know of any use for word-lists or vocabularies other than to write a cross-compiler, so getting the cross-compiler itself to support word-lists or vocabularies isn't a priority (I can't think of anything they would be used for).

In 1993, Ray Duncan was on c.l.f. describing the ONLY ALSO word-list scheme as being "brain-damaged." It really is! I fixed this in the novice-package two years ago. See the section in NOVICE.4TH with the heading: "Some word-list stuff." It is too big and complicated for me to describe here. I already did describe some or all of this on c.l.f. at the time that I wrote it --- this was when I discovered the bug in VFX in which a word-list called LOCAL-VARS was pushed on the word-list stack by colon words that had locals, and this got in the way of word-list manipulations done by immediate words in the colon word --- Stephen Pelc supposedly fixed this bug in version 4.71.3523 of Oct.8,2014 (I didn't actually check that the bug was fixed, because I had already written code that worked around the bug).

All of this was discussed here:
https://groups.google.com/forum/#!topic/comp.lang.forth/olO-VHXJa1Q%5B1-25%5D

Ilya Tarasov

unread,

May 19, 2016, 6:05:30 PM5/19/16

to

> > Why do we need to rewrite an entire interpreter, when
> > cross-compilation requires well-defined and limited features?
>
> Because it's the best way to do it. The "entire interpreter" is a
> small piece of code, and it makes sense to write one which is extended
> to include cross compilation. You're pretending to choke on a gnat.

The best way is to replace only one word, or add a word to execute before or after existing. I don't plan to do exercises every time I want to write a practical code. What if my new interpreter will broke a code added by previous loaded libraries? This is annoying and I don't want to waste my time writing 'pure Forth-style code'.

> This is Forth! We have the choice of putting a bunch of hooks in the

Does this mean you possesses the 'Spirit of Forth'? :)

> There's no-one better than Chuck Moore on this: "Do not leave hooks on
> which you can hang extensions. The things you might want to do are
> infinite; that means that each has 0 probability of realization. If
> you need an extension later, you can code it later -- and probably do
> a better job than if you did it now. And if someone else adds the
> extension, will he notice the hooks you left?"

Ok, I need this extension. What now? I also need a pack of vectored words, analyzing functional keys, mouse events and timers while user entering text in Forth console. This is another example of non-ANS behavior, caused many flames in RuFIG. Several peoples tried to 'explain' me this way is wrong and new version of message dispatcher can be easily written if needed. But why I must keep only basic version, if I need these features for almost every program? I can assign a word to K_F1 and simple press F1 to run this word. Just several critical points must be vectorized to greatly improves usability of Forth engine. If you think Moore will come to blame me... 1) I'm not sure he will 2) why do you think my interest to Forth made me depended on any kind of guru? Peoples make mistakes, and followers may interpret right thesises by wrong way. So let's call Moore and ask if you want to point to him ;)

hughag...@gmail.com

unread,

May 20, 2016, 12:25:59 AM5/20/16

to

On Thursday, May 19, 2016 at 3:05:30 PM UTC-7, Ilya Tarasov wrote:
> Peoples make mistakes, and followers may interpret right thesises by wrong way. So let's call Moore and ask if you want to point to him ;)

If we assume that Charles Moore was a genius (a good argument can be made that he was), then we have to also assume that his thinking was complex and nuanced --- this implies that simple-minded platitudes representing him are certainly incorrect.

Elizabeth Rather has spent her entire career doing everything in her power to prevent general-purpose data-structures from being written in Forth, all on the basis that this is what Charles Moore desired. Here are some typical quotes:

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

"...in applications where you *do* want to do range checking [of array indices], you may not always want to do the same thing. In some cases, you want to give an error message, in others you want to clip or substitute for the errant value or take some completely different action. The programmer should have full control."

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

This is making the whole subject overly complicated. A general-purpose array is fine --- there is no need to customize the array for each application program --- also, all of her quotes are about arrays because that is the only data-structure that she knows about (arrays were the only data-structure discussed in "Starting Forth"); she doesn't actually know that there are other data-structures, such as lists and trees etc..

It seems very unlikely that Charles Moore spent a lot of time customizing the perfect array for each application program that he wrote. Who has time for that? More likely, he was okay with general-purpose code --- he just didn't have time to write any code libraries before he got kicked out of Forth Inc. (he got kicked out in 1982, which was only 3 years after the Forth-79 standard was written, which was the first attempt at standardization).

I don't think Elizabeth Rather has the authority to declare that I'm not a Forth programmer because I write general-purpose data-structures in Forth. It seems very unlikely that Charles Moore would support her in this. It also seems very unlikely that Charles Moore cares one way or the other --- if he did, he would come to c.l.f. and say so --- but he doesn't.

Elizabeth Rather is not channeling Charles Moore --- general-purpose data-structures are just her own bugaboo --- Charles Moore doesn't actually care.

P.S. Why do all the ANS-Forth cult members refer to Charles Moore as "Chuck"? They are pretending that he is their buddy that they are on a first-name basis with. Bullshit! He doesn't even know who you are, nor does he care, same as with myself.

Andrew Haley

unread,

May 20, 2016, 4:46:40 AM5/20/16

to

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> Why do we need to rewrite an entire interpreter
>> The "entire interpreter" is a small piece of code,
>
> The dictionary/wordlist mechanism is part of the interpreter, so the
> code isn't THAT small.

You say potato, I say potahtoe. I say it's not part of the
interpeter, and historically it's never been thought of as such.

> It would be great if the cross-compiler could re-use the host
> Forth's existing dictionary implementation. Maybe that's doable
> using just the ANS definitions, but it doesn't seem that easy.

Sure, you use the host Forth's existing dictionary to hold the
name-address mapping for target words while cross-compiling. It's not
difficult at all. I can't imagine what problem you're thinking of.

>> There's no-one better than Chuck Moore on this: "Do not leave hooks
>> on which you can hang extensions. The things you might want to do
>> are infinite; that means that each has 0 probability of
>> realization.
>
> A lot of the ANS spec, and the vocabularies of historical Forths
> pre-ANS, seems constructed for the specific purpose of providing
> enough stuff to write a self-hosted interpreter. Cross-compilation
> doesn't seem like an unpredictable or unlikely an extension. There
> is a proposed ANS spec for it, after all. Also, while it's
> reasonable to avoid expending extra effort implementing generality
> that you don't immediately need, if you can get the generality with
> no extra effort you might as well take it. In fact a lot of the
> time it makes the code simpler.

Not in this case, AFAIK. But as I said, I don't know what problem
you're thinking of. And indeed, it's quite likely that whatever hooks
you think might be needed will be the wrong hooks for me.

Andrew.

Rod Pemberton

unread,

May 20, 2016, 4:52:49 AM5/20/16

to

On Fri, 20 May 2016 03:46:38 -0500
Andrew Haley <andr...@littlepinkcloud.invalid> wrote:

<OT>

> You say potato, I say potahtoe.

WHO says potahtoe? ...

It's tomato and tomahtoe. The fact that no one says potahtoe is the
clue tomahtoe is a wrong pronunciation.

RP

Andrew Haley

unread,

May 20, 2016, 4:57:58 AM5/20/16

to

Ilya Tarasov <ilya74....@gmail.com> wrote:
>> > Why do we need to rewrite an entire interpreter, when
>> > cross-compilation requires well-defined and limited features?
>>
>> Because it's the best way to do it. The "entire interpreter" is a
>> small piece of code, and it makes sense to write one which is extended
>> to include cross compilation. You're pretending to choke on a gnat.
>
> The best way is to replace only one word, or add a word to execute
> before or after existing. I don't plan to do exercises every time I
> want to write a practical code. What if my new interpreter will
> broke a code added by previous loaded libraries? This is annoying
> and I don't want to waste my time writing 'pure Forth-style code'.

So what? It's no big deal; it's not difficult; and it's an absolutely
minuscule part of the effort required to write a cross-compiler.

IMO: words in the standard should be those needed to write
applications because it's impractical, impossible, or inefficient to
provide them as libraries. That's the only way to keep the standard
reasonably small.

>> This is Forth! We have the choice of putting a bunch of hooks in the
>
> Does this mean you possesses the 'Spirit of Forth'? :)

I hope so!

>> There's no-one better than Chuck Moore on this: "Do not leave hooks on
>> which you can hang extensions. The things you might want to do are
>> infinite; that means that each has 0 probability of realization. If
>> you need an extension later, you can code it later -- and probably do
>> a better job than if you did it now. And if someone else adds the
>> extension, will he notice the hooks you left?"
>

> OK, I need this extension. What now? I also need a pack of vectored

> words, analyzing functional keys, mouse events and timers while user
> entering text in Forth console.

Gosh. Each to their own, I guess.

> This is another example of non-ANS behavior, caused many flames in
> RuFIG.

I don't understand how this is non-ANS. There doesn't seem to be any
conflict.

> Several peoples tried to 'explain' me this way is wrong and new
> version of message dispatcher can be easily written if needed. But
> why I must keep only basic version, if I need these features for
> almost every program? I can assign a word to K_F1 and simple press
> F1 to run this word. Just several critical points must be vectorized
> to greatly improves usability of Forth engine. If you think Moore
> will come to blame me... 1) I'm not sure he will 2) why do you think
> my interest to Forth made me depended on any kind of guru?

I didn't quote Chuck because he was some kind of guru, but because he
expressed this idea very well. I could have paraphrased it in my own
words, but what would be the point? And once you use someone else's
words, you must give credit, so I did.

> Peoples make mistakes, and followers may interpret right thesises by
> wrong way. So let's call Moore and ask if you want to point to him
> ;)

About what? Whatever your Forth will do, enjoy it.

People like Chuck can only advise. When that advice is given it falls
on the ear of the recipient, and then it's gone.

Andrew.

Ilya Tarasov

unread,

May 20, 2016, 9:48:32 AM5/20/16

to

> > The best way is to replace only one word, or add a word to execute
> > before or after existing. I don't plan to do exercises every time I
> > want to write a practical code. What if my new interpreter will
> > broke a code added by previous loaded libraries? This is annoying
> > and I don't want to waste my time writing 'pure Forth-style code'.
>
> So what? It's no big deal; it's not difficult; and it's an absolutely
> minuscule part of the effort required to write a cross-compiler.

Can't you see in this case you simple use Forth interpreter once to run another interpreter? Also I don't understand why I must so care about limiting my Forth by someone's opinion, if I use the same mechanism ten times and want to see it built-in?

> IMO: words in the standard should be those needed to write
> applications because it's impractical, impossible, or inefficient to
> provide them as libraries. That's the only way to keep the standard
> reasonably small.

One of big problem is concentrated around vectorized words. There are many reasons to have some words inside interpreter vectorized, but over 20 years ANS apologets don't want to listen anything about it :) Making LITERAL vectorized is very easy. I see no reasons for me to return back to ANS version of interpreter, because it breaks almost all my programs.

> >> This is Forth! We have the choice of putting a bunch of hooks in the
> >
> > Does this mean you possesses the 'Spirit of Forth'? :)
>
> I hope so!

So do you think you are right because you possesses this 'Spirit' while I'm not? :)

> > OK, I need this extension. What now? I also need a pack of vectored
> > words, analyzing functional keys, mouse events and timers while user
> > entering text in Forth console.
>
> Gosh. Each to their own, I guess.

Ok, I have it (let me remember) since 1995 or 1996. A large list of vectorized words inside Forth engine and many effective ways to use it. Also many questions 'why do you write is this way?', 'when do you plan to implement it accordingly to ANS?' and even 'when you will accept the Spirit of Forth?' :)

> > This is another example of non-ANS behavior, caused many flames in
> > RuFIG.
>
> I don't understand how this is non-ANS. There doesn't seem to be any
> conflict.

Ok, explain it to those, who triyng to prevent any extensions.

> > Peoples make mistakes, and followers may interpret right thesises by
> > wrong way. So let's call Moore and ask if you want to point to him
> > ;)
>
> About what? Whatever your Forth will do, enjoy it.

Of course, Im very happy with my Forths and Forth-CPUs. I just can see there is another iteration of wasting time for peoples who don't want to take a look on their activity from the distance. Ok, another little club for chosen persons, 'who possesses the Spirit of Forth' and interpreting this by their own style. When I ask some peoples, how they use Forth now and what projects they complete last year, they name me a troll! :) So I clearly see they can't achieve any valuable result with their ANS-compatible products, but pretends to teach everyone around.

> People like Chuck can only advise. When that advice is given it falls
> on the ear of the recipient, and then it's gone.

Any advices are welcome. But nobody should accept advice 'as is'. I told you I need some of these hooks for practical purposes, but are you think I'm still wrong?

Andrew Haley

unread,

May 20, 2016, 10:40:22 AM5/20/16

to

Ilya Tarasov <ilya74....@gmail.com> wrote:
>> > The best way is to replace only one word, or add a word to execute
>> > before or after existing. I don't plan to do exercises every time I
>> > want to write a practical code. What if my new interpreter will
>> > broke a code added by previous loaded libraries? This is annoying
>> > and I don't want to waste my time writing 'pure Forth-style code'.
>>
>> So what? It's no big deal; it's not difficult; and it's an absolutely
>> minuscule part of the effort required to write a cross-compiler.
>
> Can't you see in this case you simple use Forth interpreter once to
> run another interpreter?

Yes.

> Also I don't understand why I must so care about limiting my Forth
> by someone's opinion, if I use the same mechanism ten times and want
> to see it built-in?

It's your Forth, so do what you like. The only interesting question
for me is what should be standard.

>> IMO: words in the standard should be those needed to write
>> applications because it's impractical, impossible, or inefficient to
>> provide them as libraries. That's the only way to keep the standard
>> reasonably small.
>
> One of big problem is concentrated around vectorized words. There
> are many reasons to have some words inside interpreter vectorized,
> but over 20 years ANS apologets don't want to listen anything about
> it :) Making LITERAL vectorized is very easy. I see no reasons for
> me to return back to ANS version of interpreter, because it breaks
> almost all my programs.

I've always liked vectorized NUMBER. As far as I can remember every
Forth I've ever used supports it. Recognizers are one way to do
achieve the same thing, but I don't like the latest proposal because
it seems to me to go too far.

>> >> This is Forth! We have the choice of putting a bunch of hooks
>> >> in the
>> >
>> > Does this mean you possesses the 'Spirit of Forth'? :)
>>
>> I hope so!
>
> So do you think you are right because you possesses this 'Spirit'
> while I'm not? :)

I don't know about you, but I certainly hope I do.

Every language has an ethos, especially unusual languages like, say,
Forth, Haskell, and LISP. In any of these languages one can program
in a "conventional" way, but the results won't be great. (As the old
saying, goes "The determined Real Programmer can write FORTRAN
programs in any language.")

Without using Forth design (as described in e.g. Thinking FORTH and
Programming a Problem-Oriented Language) FORTH can be an just annoying
nuisance. All this SWAP DROP ROT blah. But use Forth in the way that
it was intended and the results can be elagant and sparkling. Of
course there are no guarantees, and in the end no substitute for good
taste.

>> > This is another example of non-ANS behavior, caused many flames in
>> > RuFIG.
>>
>> I don't understand how this is non-ANS. There doesn't seem to be any
>> conflict.
>
> Ok, explain it to those, who triyng to prevent any extensions.

That's not my job! Everything you describe sounds fine and
ANS-compatible to me.

>> People like Chuck can only advise. When that advice is given it falls
>> on the ear of the recipient, and then it's gone.
>
> Any advices are welcome. But nobody should accept advice 'as is'. I
> told you I need some of these hooks for practical purposes, but are
> you think I'm still wrong?

No. I think you're misunderstanding what Chuck wrote. If you
actually *use* a hook, then the probability of it being used is 1, not
0. Chuck was talking about *speculative* hooks, and there is a huge
difference.

Andrew.

[1] www.forth.org/POL.pdf

hughag...@gmail.com

unread,

May 20, 2016, 12:31:28 PM5/20/16

to

On Friday, May 20, 2016 at 7:40:22 AM UTC-7, Andrew Haley wrote:
> Ilya Tarasov <ilya74....@gmail.com> wrote:

> > Also I don't understand why I must so care about limiting my Forth
> > by someone's opinion, if I use the same mechanism ten times and want
> > to see it built-in?
>
> It's your Forth, so do what you like. The only interesting question
> for me is what should be standard.

This really summarizes everything that Andrew Haley has to say, or ever will have to say.

So long as Andrew Haley brown-noses Elizabeth Rather then he is Standard with a capital 'S' and he can dismiss everything that programmers such as Ilya do simply by saying that it is non-standard and hence meaningless --- he doesn't even have to understand the subject being discussed (he doesn't actually understand how cross-compilers work) --- he can use the mighty Standard club to squash everybody left and right, to win every debate with ease, until nobody dares to write a line of Forth code without his permission. What will actually happen is that Ilya will give up comp.lang.forth as a waste of time and his FPGA Forth processor will be unknown, but Bernd Paysan's B16 will be the only FPGA Forth processor that anybody ever hears about. Of course, the B16 isn't ANS-Forth compatible either, but Bernd brown-noses Elizabeth Rather faithfully, and Elizabeth Rather appointed Bernd to the Forth-200x committee, so this doesn't matter --- ANS-Forth is a cult so being ANS-Forth is all about loyalty but has nothing to do with compatibility.

All of these threads end up being deja-vu all over again. Previously Andrew Haley used the term "Forth Way" and now he uses the term "Forth Spirit," but other than that it is the same argument every time:
https://groups.google.com/forum/#!searchin/comp.lang.forth/uart%7Csort:date/comp.lang.forth/pqhqqvWg9zk/vpBKfGHsDwAJ

On Friday, April 29, 2016 at 12:11:42 AM UTC-7, hughag...@gmail.com wrote:
> On Tuesday, April 26, 2016 at 2:04:29 AM UTC-7, Andrew Haley wrote:
> > Paul Rubin <no.e...@nospam.invalid> wrote:
> > > Maybe if I know the application only uses half-duplex, I can
> > > implement some hacky thing that relies on that fact. But if I'm
> > > supplying a library facility it wouldn't occur to me to limit it
> > > like that.
> >
> > I'm sure it wouldn't, because you don't really think in the Forth way.
> > Don't speculate!
>
> ANS-Forth is a cult --- this is why we have Andrew Haley's emphasis on the "Forth Way." Andrew Haley is supporting Elizabeth Rather by arguing against full-duplex asynchronous communication, despite the fact that the UART has been in use since the 1970s and is generally considered to be one of the big breakthroughs of computer science --- no matter how stupid Elizabeth Rather's pronouncements are, the cult members will argue in favor of those pronouncements using twisted logic and blatant lies.
>
> Elizabeth Rather says: "I can't think offhand of a case in which a
> full-duplex port literally has concurrent streams of data flowing in and
> out." She is opposed to general-purpose code and instead wants hacky code that relies on the fact that a particular application only needs half-duplex code --- but this code won't work on other applications that need full-duplex, so it is not general-purpose.
>
> Why is general-purpose code considered to be in contradiction to the "Forth Way"? I've seen a handful of quotes from Charles Moore indicating that he is opposed to general-purpose code. I don't think this proves that he is opposed to general-purpose code though; this reminds me of how people find a handful of quotes in the Bible that support their agenda, and they ignore the huge number of quotes that are in contradiction to their agenda. If Charles Moore really was opposed to general-purpose code he would be on comp.lang.forth denouncing general-purpose code, and he would also be on comp.lang.forth agreeing with Elizabeth Rather than I'm not a Forth programmer --- but he isn't.
>
> Most likely, what happened is that sometime in the 1970s Charles Moore made a comment to Elizabeth Rather such as: "I don't have time to write a general-purpose code-library because I told the customer that I would have the program ready on Monday, so I'm just going to hack together some code over the weekend." This little bit of wisdom stuck in Elizabeth Rather's mind forever, and so she spent the rest of her life denouncing general-purpose code-libraries in favor of hacky application-specific code that can't be reused.
>
> Another problem here is that Elizabeth Rather just doesn't understand how general-purpose code is possible. This is what she said about my general-purpose data-structures in my novice package:
> --------------------------------------------------------------------------
> 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.
> --------------------------------------------------------------------------
> That's stupid! But ANS-Forth is a cult, so all the cult members totally support Elizabeth Rather on this.
>
> I would like to meet Charles Moore someday, just to ask him if he is really opposed to general-purpose code-libraries, and if he agrees with Elizabeth Rather that I'm not a Forth programmer. I suspect that he doesn't support ANS-Forth and he is okay with me writing code in Forth --- but you never know --- maybe he totally supports ANS-Forth and he damns me to Hell for having written MFX for the MiniForth.

rickman

unread,

May 20, 2016, 1:53:36 PM5/20/16

to

Hugh doesn't seem to be winding down this time. I guess there is
something upsetting him in his personal life and he is venting here.

--

Rick C

Ilya Tarasov

unread,

May 20, 2016, 5:16:08 PM5/20/16

to

> > Can't you see in this case you simple use Forth interpreter once to
> > run another interpreter?
>
> Yes.

On this way you can simple run MS Visual Studio from your Forth.

> It's your Forth, so do what you like. The only interesting question
> for me is what should be standard.

I know this is my Forth. Interesing question from me - what is standard goals? With no goal declared this is no chance to decide use it ir not. I don't know where ANS-Forth going and can't be sure it is going in right direction.

> > So do you think you are right because you possesses this 'Spirit'
> > while I'm not? :)
>
> I don't know about you, but I certainly hope I do.
> Every language has an ethos, especially unusual languages like, say,
> Forth, Haskell, and LISP. In any of these languages one can program
> in a "conventional" way, but the results won't be great. (As the old
> saying, goes "The determined Real Programmer can write FORTRAN
> programs in any language.")

Unfortunately, small and uncommon community often leads to 'white crow syndrome'. An idiomaic-precise translation is close to 'divergent', but has more deep meaning un Russian. Crows are black, so white crow is uncommon. Moreover, white crow constantly trying to focus others on its difference and use it as a feature. 'Forth-way' or, translated from Russian FIG, 'Spirit of Forth' is an easy way to stop any discussion and claim yourself as a winner.

> Without using Forth design (as described in e.g. Thinking FORTH and
> Programming a Problem-Oriented Language) FORTH can be an just annoying
> nuisance. All this SWAP DROP ROT blah. But use Forth in the way that
> it was intended and the results can be elagant and sparkling. Of
> course there are no guarantees, and in the end no substitute for good
> taste.

I have a lot of examples where Forth was used properly, not by me only. I prefer to listen colleagues and add features they want, whenever it ANS-compatible or not. ANS is far from me and I have no projects or contract proposals based on ANS compatibility. My company is... my company :) I need some features to implement and don't want wait until someone comes to agrees me. So someone just lost me as a customer.

unread,

May 21, 2016, 4:08:36 AM5/21/16

to

On Sat, 14 May 2016 00:27:56 -0400
Rod Pemberton <NoHave...@bcczxcfre.cmm> wrote:

> On Fri, 13 May 2016 14:06:28 -0700
> Paul Rubin <no.e...@nospam.invalid> wrote:
> > ste...@mpeforth.com (Stephen Pelc) writes:

> > > Europay became a part of Mastercard and the OTA documents may be
> > [...]
> FYI, I'm not sure what is on page 4 of Overview.pdf. Both of the pdf
> viewers (ePDFviewer and Zathura) that I have for Linux can't seem to
> handle that page, or they're taking an excessively long time. They
> will go to the other pages.

I was still having problems viewing page 4 of Overview.pdf. I
thought I was going to have to load it up on Windows 10 with Adobe
Acrobat Reader, but I managed to fix it on Linux.

Using pdfseparate on Linux separated the file into page, but page 4
still wasn't viewable. Executing pdf2ps and viewing with gs the page
rendered well.

So, the solution for Linux is to execute pdf2ps on Overview.pdf, rm
delete Overview.pdf, then execute ps2pdf on Overview.ps. The page
appears to be complete, but I don't know if something was edited out or
modified.

Rod Pemberton

Elizabeth D. Rather

unread,

May 21, 2016, 4:11:56 AM5/21/16

to

On 5/20/16 9:52 PM, Andrew Haley wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:

...

>> Well, the ANS cross-compiler extension proposal linked earlier seems
>> like it has been useful in practice.
>
> Shrug. That proposal was incomplete and unsuccessful IIRC.

It has been technically very successful, with a large number of major
current applications in the field. The drafts are outdated now, and need
work, but a cross-compiler standard could be the basis of major market
openings for Forth. I think the major reason it hasn't progressed is
that the major users (FORTH, Inc. and MPE) are so busy using these
techniques in significant projects they haven't had time to refine the
proposal.

Andrew Haley

unread,

May 21, 2016, 4:13:31 AM5/21/16

to

Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:
>>

>> Well, the ANS cross-compiler extension proposal linked earlier seems
>> like it has been useful in practice.
>
> Shrug. That proposal was incomplete and unsuccessful IIRC.

I just read Elizabeth's reply, and it seems like this proposal has
turned out to be useful; mea culpa.

Andrew.

Elizabeth D. Rather

unread,

May 21, 2016, 4:50:42 AM5/21/16

to

On 5/20/16 11:16 AM, Ilya Tarasov wrote:
>>> Can't you see in this case you simple use Forth interpreter once to
>>> run another interpreter?
>>
>> Yes.
>
> On this way you can simple run MS Visual Studio from your Forth.
>
>> It's your Forth, so do what you like. The only interesting question
>> for me is what should be standard.
>
> I know this is my Forth. Interesing question from me - what is standard goals? With no goal declared this is no chance to decide use it ir not. I don't know where ANS-Forth going and can't be sure it is going in right direction.

The goals of any programming language standard are to promote portable
code (applications that can run on multiple systems) and portable
programmers (people who understand the principles and can move easily
from one implementation to another). If you do not share those goals,
there is no need for you to worry about standards.

>>> So do you think you are right because you possesses this 'Spirit'
>>> while I'm not? :)
>>
>> I don't know about you, but I certainly hope I do.
>> Every language has an ethos, especially unusual languages like, say,
>> Forth, Haskell, and LISP. In any of these languages one can program
>> in a "conventional" way, but the results won't be great. (As the old
>> saying, goes "The determined Real Programmer can write FORTRAN
>> programs in any language.")
>
> Unfortunately, small and uncommon community often leads to 'white crow syndrome'. An idiomaic-precise translation is close to 'divergent', but has more deep meaning un Russian. Crows are black, so white crow is uncommon. Moreover, white crow constantly trying to focus others on its difference and use it as a feature. 'Forth-way' or, translated from Russian FIG, 'Spirit of Forth' is an easy way to stop any discussion and claim yourself as a winner.

Standards encourage communities with shared understanding and tools.

>> Without using Forth design (as described in e.g. Thinking FORTH and
>> Programming a Problem-Oriented Language) FORTH can be an just annoying
>> nuisance. All this SWAP DROP ROT blah. But use Forth in the way that
>> it was intended and the results can be elagant and sparkling. Of
>> course there are no guarantees, and in the end no substitute for good
>> taste.
>
> I have a lot of examples where Forth was used properly, not by me only. I prefer to listen colleagues and add features they want, whenever it ANS-compatible or not. ANS is far from me and I have no projects or contract proposals based on ANS compatibility. My company is... my company :) I need some features to implement and don't want wait until someone comes to agrees me. So someone just lost me as a customer.

Your primary loyalty is appropriately to your users. If you're a solo
programmer, none of this matters. If you have colleagues and other
users, it is beneficial to them to have shared documentation as to how
things work.

>> That's not my job! Everything you describe sounds fine and
>> ANS-compatible to me.
>
> I don't see any serious troubles too. Why main loop in Forth must be untouchable? You told it sound fine, but other peoples may tell this is non-standard behavior and I must write another interpreter to add words or features. For example, having floating point was absolutely critical for me 20 years ago. This was easily done with vecorized NUMBER and LITERAL in SP-Forth. When I ask Andrey Cherezov for some changes to his SP-Forth (LITERAL was non-vectorized) he answer... right! 'This is non-standard, everyone may be happy with integer numbers or fixed point'. How do you think, is it prevents me from rewriting Forth according to my design?

Nothing in Forth is untouchable. One does what the application and
customer demand.

>> No. I think you're misunderstanding what Chuck wrote. If you
>> actually *use* a hook, then the probability of it being used is 1, not
>> 0. Chuck was talking about *speculative* hooks, and there is a huge
>> difference.
>
> But I point you to real used things, not to hooks for future use by someone. LITERAL is required. EMIT is very useful. DISPATCH-NUMBER was used by me yesterday to convert several files with numbers in text format. Reaction of ANS committee is more intresting thing. Why don't add useful things, if programmers want to see it? Oh, I see, this is dangerous because will lead to real projects and paid job ;)

Real used things are good. Real projects and paid jobs are also good. A
standards committee should be (and, in my experience is) made up of
people accustomed to using the technology in real projects and paid
jobs, as well as personal enrichment. But proposed hooks get evaluated
by the perceived need of the whole group, not a subset. One person's
hook is another's useless complication. A standards committee searches
for widespread acceptance and understanding before adding a hook. That
needn't inhibit anyone who needs that hook from implementing and using
it; nothing is forbidden that gets the job done. If a hook or feature is
publicized and becomes popular, it may be standardized.

Albert van der Horst

unread,

May 21, 2016, 6:23:25 AM5/21/16

to

And if you really fear that about every word may be in need of
revectoring use an indirect threaded Forth.
E.g. if NAME is the word CREATE get's it name from, you can revector
it for one invocation to a word that ... restores the former behaviour.
Revectoring is a matter of filling in the data field addres.
Remember for docol the executed code is data.
The way is to prepend the creating word ( : CONSTANT VARIABLE VALUE
create-does-constructs ) by POSTFIX:

The following is working code, but you should read only the comment.
7 \ Have the original behaviour of DEA restored.
8 : RESTORED DUP >PHA SWAP >DFA ! ;
9 \ Do nothing for one call of ``NAME''
10 : NAME-NEW 'NAME RESTORED ;
11 \ Make the following defining word postfix for one execution.
12 \ The name must be a string constant on the stack
13 \ Use only while compiling, or you crash the system
14 : POSTFIX ( ?COMP ) 'NAME-NEW >DFA @ 'NAME >DFA ! ;

Like so.
"2DROP" POSTFIX : DROP DROP ;

It is unwise to try to think up these things before hand.

> Andrew.

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

hughag...@gmail.com

unread,

May 21, 2016, 6:43:23 PM5/21/16

to

On Saturday, May 21, 2016 at 12:52:06 AM UTC-7, Andrew Haley wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:

> > You want the host's version of DUP to be different than the target's
> > version. Maybe there's a way to do this with word lists, but it would
> > have been a lot cleaner to supply a generalized dictionary interface.
>
> Eh? This is exactly the sort of thing for which wordlists have been
> used for more than thirty years. They're exactly what is needed for
> cross-compiling.

I did this in MFX with the Forth-83 vocabularies using CONTEXT and CURRENT.

Cross-compilation is not "exactly the sort of thing for which wordlists have been used for more than thirty years." Ray Duncan described the ONLY ALSO scheme as being "brain-damaged" in 1993, and he was right. When I tried to use wordlists in my ANS-Forth cross-compiler in 2010 I found it unusable. I fixed all of these problems, getting ANS-Forth up to the level of Forth-83. These fixes are now in the latest version of the novice-package (see the "some word-list stuff" section) --- I can email this to anybody who wants it.

Andrew Haley doesn't know how to write a cross-compiler --- he is just brown-nosing Elizabeth Rather when he says that ANS-Forth is "exactly" correct --- he has no personal experience with this stuff.

Also, saying that ANS-Forth is 30 years old is an exaggeration. That ONLY ALSO scheme does predate ANS-Forth (I remember it being discussed in "Forth Dimensions"), but I'm not aware of anybody using it for anything --- it really is ill-conceived --- a screw-ball idea that has never been tried out in practice.

hughag...@gmail.com

unread,

May 21, 2016, 6:56:44 PM5/21/16

to

On Saturday, May 21, 2016 at 12:43:42 AM UTC-7, Elizabeth D. Rather wrote:
> On 5/20/16 7:16 PM, Paul Rubin wrote:
> Strictly speaking, the Forth interpreter is a single, modest, definition
> a few lines long. An only slightly simplified version is:
>
> : INTERPRET BEGIN -' IF NUMBER ELSE DROP
> EXECUTE DEPTH 0< ABORT" Stack empty"
> THEN AGAIN ;
>
> ( -' searches the dictionary and returns TRUE if the word is not found;
> everything else here is pretty standard)

NUMBER is not in the ANS-Forth standard --- so no, it is not "pretty standard."

NUMBER has to be vectored so the cross-compiler can have the number compiled into the target system rather than the host system --- either that or vector LITERAL which NUMBER calls internally to do the compiling.

> > Well, the ANS cross-compiler extension proposal linked earlier seems
> > like it has been useful in practice.
>
> Indeed, it is now nearly 20 years old, and has been used in many, many
> challenging applications by FORTH, Inc., MPE, and our many various
> customers. No surprise, the technology has matured some, but the
> principles are still there.

That is bullshit --- I don't think that either the Forth Inc. or MPE cross-compilers are written in ANS-Forth.

What I have seen of VFX from MPE is that very little of the code is ANS-Forth. Pelc claims that it is ANS-Forth, but that is just a hand-waving argument based on the idea that because he is on the Forth-200x committee everything he writes is automatically Standard. The code is not ANS-Forth however --- he routinely breaks with ANS-Forth compatibility --- all of that code is VFX-specific, and anybody who uses it is trapped in vendor lock-in.

Elizabeth Rather is presenting the argument that only Forth Inc. and MPE "customers" can have a cross-compiler --- ANS-Forth was crippled to prevent ordinary programmers from writing cross-compilers in competition with Forth INc. and MPE --- anybody who does write a cross-compiler will necessarily break with ANS-Forth compatibility and they will get denounced by the committee for being non-standard.

hughag...@gmail.com

unread,

May 21, 2016, 7:22:19 PM5/21/16

to

On Saturday, May 21, 2016 at 1:50:42 AM UTC-7, Elizabeth D. Rather wrote:
> On 5/20/16 11:16 AM, Ilya Tarasov wrote:
> >> It's your Forth, so do what you like. The only interesting question
> >> for me is what should be standard.
> >
> > I know this is my Forth. Interesing question from me - what is standard goals? With no goal declared this is no chance to decide use it ir not. I don't know where ANS-Forth going and can't be sure it is going in right direction.
>
> The goals of any programming language standard are to promote portable
> code (applications that can run on multiple systems) and portable
> programmers (people who understand the principles and can move easily
> from one implementation to another). If you do not share those goals,
> there is no need for you to worry about standards.

If you share this goal --- "promote portable code (applications that can run on multiple systems)" --- don't use ANS-Forth.

ANS-Forth is full of ambiguity. The major ANS-Forth compilers represent multiple incompatible interpretations of what ANS-Forth is, but all of them are ANS-Forth because pretty much any interpretation is valid, but application code can't be ported between them.

The reason why ANS-Forth is full of ambiguity, is that it was all about political concessions. Everybody wanted their compiler to be ANS-Forth compliant, so Elizabeth Rather said okay, they are standard, but they were incompatible with each other --- Elizabeth Rather did this just because she wanted them to sign on to ANS-Forth (ANSI primarily wants to see a list of people supporting the proposal in order for the proposal to get the ANSI stamp, but ANSI doesn't actually care about technical details such as whether the proposal is self-consistent or not).

As an example, we have 6.1.1550 (the definition of FIND):
"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."

This was put in there in an effort to make cmForth ANS-Forth compliant too. What is pathetic about this, is that in cmForth FIND returned different values while compiling or not compiling because cmForth was a cross-compiler and hence colon changed CONTEXT while compiling the colon word, and semicolon changed CONTEXT back again afterward. The ANS-Forth committee didn't understand how FIND could return different values inside or outside of a colon definition because they didn't understand how cross-compilation works (didn't know that colon changes CONTEXT) and possibly didn't understand how vocabularies work either (didn't know that CONTEXT can be changed).

What is also pathetic about this is that Charles Moore didn't ask to have cmForth be ANS-Forth, and Charles Moore has ignored ANS-Forth entirely --- this goofy sentence was inserted into the ANS-Forth document in the hopes that it would induce Charles Moore to care about ANS-Forth, but there was no evidence to indicate that he was going to start caring any time soon, or that he would ever care --- then Elizabeth Rather listed Charles Moore's name in the ANS-Forth document anyway! Most likely, she thought that ANSI would not give her the stamp of approval without Charles Moore's name listed, because he is the inventor of Forth, and she just hoped that Charles Moore wouldn't sue her for libel for claiming that he is a supporter when he isn't.

Now Anton Ertl has seized upon this goofy sentence and has made it the basis for gForth --- FIND in gForth actually does return different values for certain words (not all words) depending upon what STATE is at the time that FIND is executed --- this is just bizarre!

Ilya Tarasov

unread,

May 22, 2016, 4:37:35 PM5/22/16

to

> >> > Can't you see in this case you simple use Forth interpreter once to
> >> > run another interpreter?
> >>
> >> Yes.
> >
> > On this way you can simple run MS Visual Studio from your Forth.
>
> Probably, but what for?

If you have INTERPRET, but use it only once to run your INTERPRET2, you will switch to another version of Forth right after launching. So why do you need to standartize INTERPRET? On this way, you can run INTERPRET2, INTERPRET3, or even MS Visual Studio. All of these programs are not original INTERPRET, and rewrited INTERPRET2 is not covered by standars as well as MSVS.

> There are two goals: common libraries and a common language. Without
> some common understaning about what Forth is, we can't even talk about
> Forth programs.

Look at my answer to Elizabeth Rather.

> No, because a small Forth is better than a big one, and the number of
> potentially useful hooks is very large. In order to justify its
> inclusion in a standard, a feature has to be needed by many people.
> C++ and Java are over there. -->

So committee should explain how this features may be added. Otherwise it is chaotic and depended on committee members particular decisions. Indeed this is a real question how to add hooks to make extensions easy-to-add and still not huge. Right now I see only restrictions and remarks about 'non-standard
solutions'.

Ilya Tarasov

unread,

May 22, 2016, 5:05:00 PM5/22/16

to

> The goals of any programming language standard are to promote portable
> code (applications that can run on multiple systems) and portable
> programmers (people who understand the principles and can move easily
> from one implementation to another). If you do not share those goals,
> there is no need for you to worry about standards.

'One man drives a car and his car has broken on the road. He quits and start to repair his car. A small boy told him:
- Hey man, I know what you need to repair.
- Really?! Tell me please!
- You need to repair the car.'
:)

Ok, now I have you trivial explanation what is the standard. This is not so useful, because does not explain criterias of accepting or declining changes. Now it is up to committee and nobody can check the quality of their work without knowing what they want to achieve. There are many sets of portable code and libraries, but basic principes should be listed and accepted before moving forward. Portability or performance are just empty words without measurable criterias.

> Standards encourage communities with shared understanding and tools.

How many peoples or companies were encouraged last year? Where I can found hundreds of active Forth programmers and thousands of compatible libraries? This is rhetorical question. I know answer: nowhere. I know 'Forth Inc is on the market since the dinosaurs era', but this is not covering my demands.

> Your primary loyalty is appropriately to your users. If you're a solo
> programmer, none of this matters. If you have colleagues and other
> users, it is beneficial to them to have shared documentation as to how
> things work.

Of course, we did.

> Nothing in Forth is untouchable. One does what the application and
> customer demand.

However, I've heard many arguments, why it must not be used. First of all, 'you can always write a library ofr another word'. Thank you, I did. I also rewrite all code and receive my own version of Forth engine. I'm afraid, now you will switch to 'you should write compatible code and share it with others'. THIS is a problem to solve, not how to choose a name for another stack-playing word.

> hook is another's useless complication. A standards committee searches
> for widespread acceptance and understanding before adding a hook. That
> needn't inhibit anyone who needs that hook from implementing and using
> it; nothing is forbidden that gets the job done. If a hook or feature is
> publicized and becomes popular, it may be standardized.

Then you should explain your pocket boys they behavior is unacceptable. If they cannot discuss serious questions, they must not claim themselves as experts.

hughag...@gmail.com

unread,

May 22, 2016, 6:33:08 PM5/22/16

to

On Sunday, May 22, 2016 at 2:05:00 PM UTC-7, Ilya Tarasov wrote:
> > Standards encourage communities with shared understanding and tools.
>
> How many peoples or companies were encouraged last year? Where I can found hundreds of active Forth programmers and thousands of compatible libraries? This is rhetorical question. I know answer: nowhere. I know 'Forth Inc is on the market since the dinosaurs era', but this is not covering my demands.

Within the last year? Ask instead how many within the last 22 years. The answer is the same --- none! --- ANS-Forth failed to provide portability, and portability is the purpose of having a standard, so ANS-Forth failed as a standard.

> > Nothing in Forth is untouchable. One does what the application and
> > customer demand.
>
> However, I've heard many arguments, why it must not be used. First of all, 'you can always write a library ofr another word'. Thank you, I did. I also rewrite all code and receive my own version of Forth engine. I'm afraid, now you will switch to 'you should write compatible code and share it with others'. THIS is a problem to solve, not how to choose a name for another stack-playing word.

Nothing in Forth is untouchable for MPE --- MPE breaks with ANS-Forth compatibility on the first day of every project --- but if anybody else breaks with ANS-Forth compatibility, all of the ANS-Forth cult members howl that his code is non-standard and shouldn't be considered to be Forth at all, and that he is not a Forth programmer at all.

> > hook is another's useless complication. A standards committee searches
> > for widespread acceptance and understanding before adding a hook. That
> > needn't inhibit anyone who needs that hook from implementing and using
> > it; nothing is forbidden that gets the job done. If a hook or feature is
> > publicized and becomes popular, it may be standardized.
>
> Then you should explain your pocket boys they behavior is unacceptable. If they cannot discuss serious questions, they must not claim themselves as experts.

I think "pocket boys" is a great term --- Ilya has improved the English language by giving us this term! --- so much easier to spell than "sycophants."

Elizabeth Rather says: "If a hook or feature is publicized and becomes popular, it may be standardized." This is a trick! My experience with Forth-200x is that the committee would tell me that my RfD has to be "vetted" on comp.lang.forth --- then on comp.lang.forth John Passaniti and/or Alex McDonald says that it "sucks" and is "crap" (plus Rickman and/or Ron Aaron suggest that I be given psychiatric treatment involving restraints and powerful drugs) --- then the Forth-200x committee says that my RfD didn't prove to be popular, so it is killed, but they are only following the demands of the "Forth community" and not acting like dictators.

How about we only ask the opinion of computer programmers? Ignore the opinion of a sales-person and her pocket-boys.

rickman

unread,

May 22, 2016, 7:14:07 PM5/22/16

to

On 5/22/2016 5:04 PM, Ilya Tarasov wrote:
>> The goals of any programming language standard are to promote
>> portable code (applications that can run on multiple systems) and
>> portable programmers (people who understand the principles and can
>> move easily from one implementation to another). If you do not
>> share those goals, there is no need for you to worry about
>> standards.
>
> 'One man drives a car and his car has broken on the road. He quits
> and start to repair his car. A small boy told him: - Hey man, I know
> what you need to repair. - Really?! Tell me please! - You need to
> repair the car.' :)

I wish I understood what your point was.

> Ok, now I have you trivial explanation what is the standard. This is
> not so useful, because does not explain criterias of accepting or
> declining changes. Now it is up to committee and nobody can check the
> quality of their work without knowing what they want to achieve.
> There are many sets of portable code and libraries, but basic
> principes should be listed and accepted before moving forward.
> Portability or performance are just empty words without measurable
> criterias.

This is very simple. The standard is what the standard is. The purpose
is to lay out a language with defined features so that compliant
compilers can be written that people know how to use and that compliant
programs may be written that will run on these compliant compilers.

It is nothing more and hopefully, nothing less. If that doesn't suit
you, then you can ignore the standard and do you own thing.

You talk of "goals" and "criterias[sic] of accepting or declining
changes" is not what standards are about. They may well have those
features, but that is not essential to a user. I don't know why you are
even talking about it.

>> Standards encourage communities with shared understanding and
>> tools.
>
> How many peoples or companies were encouraged last year? Where I can
> found hundreds of active Forth programmers and thousands of
> compatible libraries? This is rhetorical question. I know answer:
> nowhere. I know 'Forth Inc is on the market since the dinosaurs era',

> but this is not covering my demands..

Do you have "demands"? Why don't you share those with us? What about
your "demands" do you not find in the available Forths? If you can't
find your "demands" in any Forth, then obviously Forth is not for you
unless you want to roll your own.

>> Your primary loyalty is appropriately to your users. If you're a
>> solo programmer, none of this matters. If you have colleagues and
>> other users, it is beneficial to them to have shared documentation
>> as to how things work.
>
> Of course, we did.
>
>> Nothing in Forth is untouchable. One does what the application and
>> customer demand.
>
> However, I've heard many arguments, why it must not be used. First of
> all, 'you can always write a library ofr another word'. Thank you, I
> did. I also rewrite all code and receive my own version of Forth
> engine. I'm afraid, now you will switch to 'you should write
> compatible code and share it with others'. THIS is a problem to
> solve, not how to choose a name for another stack-playing word.

I don't think anyone cares how you write your code or if you share it.
That is up to you. I don't know why you say that. Maybe I don't
understand what you are saying.

>> hook is another's useless complication. A standards committee
>> searches for widespread acceptance and understanding before adding
>> a hook. That needn't inhibit anyone who needs that hook from
>> implementing and using it; nothing is forbidden that gets the job
>> done. If a hook or feature is publicized and becomes popular, it
>> may be standardized.
>
> Then you should explain your pocket boys they behavior is
> unacceptable. If they cannot discuss serious questions, they must not
> claim themselves as experts.

Who are you exactly? Who are the "pocket boys"? If you find the
behavior of the Forth community unacceptable, why are you here?

--

Rick C

hughag...@gmail.com

unread,

May 22, 2016, 8:11:47 PM5/22/16

to

On Sunday, May 22, 2016 at 4:14:07 PM UTC-7, rickman wrote:
> On 5/22/2016 5:04 PM, Ilya Tarasov wrote:
> This is very simple. The standard is what the standard is. The purpose
> is to lay out a language with defined features so that compliant
> compilers can be written that people know how to use and that compliant
> programs may be written that will run on these compliant compilers.
>
> It is nothing more and hopefully, nothing less. If that doesn't suit
> you, then you can ignore the standard and do you own thing.

This presumes that ANS-Forth is the only possible way to write a standard --- ANS-Forth is actually the worst possible way to write a standard --- I think Ilya wants a standard (so do I), but he wants it to make sense, which precludes ANS-Forth.

> >> Standards encourage communities with shared understanding and
> >> tools.
> >
> > How many peoples or companies were encouraged last year? Where I can
> > found hundreds of active Forth programmers and thousands of
> > compatible libraries? This is rhetorical question. I know answer:
> > nowhere. I know 'Forth Inc is on the market since the dinosaurs era',
> > but this is not covering my demands..
>
> Do you have "demands"? Why don't you share those with us? What about
> your "demands" do you not find in the available Forths? If you can't
> find your "demands" in any Forth, then obviously Forth is not for you
> unless you want to roll your own.

He did roll his own Forth --- and built a Forth processor in an FPGA.

By comparison, Rickman has not written a Forth compiler, nor has he ever written any Forth code at all, and he seems to know almost nothing about Forth (I think he read Koopman's book on stack-machines, but that is all).

> >> hook is another's useless complication. A standards committee
> >> searches for widespread acceptance and understanding before adding
> >> a hook. That needn't inhibit anyone who needs that hook from
> >> implementing and using it; nothing is forbidden that gets the job
> >> done. If a hook or feature is publicized and becomes popular, it
> >> may be standardized.
> >
> > Then you should explain your pocket boys they behavior is
> > unacceptable. If they cannot discuss serious questions, they must not
> > claim themselves as experts.
>
> Who are you exactly? Who are the "pocket boys"? If you find the
> behavior of the Forth community unacceptable, why are you here?

Rickman assumes that he speaks for and represents the "Forth community" --- that is not true; he speaks for and represents Elizabeth Rather (she speaks for and represents Forth Inc., where she works as a sales-person) --- Rickman is her latest "pocket boy" (first we had John Passaniti, then Alex McDonald, and now Rickman).

People who claim to speak for and represent the Forth community annoy me --- same with people who claim to speak for and represent the Hispanic community, the Christian community, etc. --- they aren't elected; they are self-appointed blowhards (pathological liars with delusions of grandeur).

rickman

unread,

May 22, 2016, 8:58:41 PM5/22/16

to

On 5/22/2016 8:11 PM, hughag...@gmail.com wrote:
>
> Rickman assumes that he speaks for and represents the "Forth
> community" --- that is not true; he speaks for and represents
> Elizabeth Rather

I don't normally reply to Hugh's rantings, but I want to set this
straight. I speak only for myself. I replied to Ilya because I don't
understand the nature or the basis of the complaint. Ilya seems to be
complaining that the Forth ANS standard is not good enough or does not
specify enough, but I don't really get it. So I am asking for a more
complete, or maybe a more basic statement of the complaint. I have no
idea if it is valid or not since I don't follow what Ilya is saying.

As to Hugh, I mostly ignore him and his ravings. So far he has not
shown that he is anything other than a minor lunatic who is "highly
functioning" enough to stay out of a mental ward. I do have some
concern for the safety of others he assails though. I don't think he
has the means to reach any of the people he expresses such hatred for,
but clearly he gives all appearances of being capable of causing harm.

--

Rick C

Paul Rubin

unread,

May 23, 2016, 1:22:18 AM5/23/16

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> The more featureful text interpreters can also get somewhat
>> complicated: think of gforth locals, for example.
> Sure, but it's quite possible that a target's way of handling locals
> will be different from that of the host. I can't see much advantage
> to sharing just the text interpreter part of that.

The idea is the cross-compiler should be able to compile itself. It
should also be expected to be written in itself; i.e., if it supports
gforth locals it should be allowed to use them in its own
implementation. So the secondary text interpreter has to deal with them
somehow.

I have to admit that the idea of a second text interpreter didn't occur
to me when I thought about this problem a year or so ago, after reading
Jay Melvin's article about the CMForth metacompiler. I liked the idea
of a compiler that could completely compile itself starting from a
minimal shim. eForth does something like it, but iirc, it used some
some non-ANS machinery, that might or might not have been essential.

> Eh? This is exactly the sort of thing for which wordlists have been
> used for more than thirty years. They're exactly what is needed for
> cross-compiling.

The ANS wordlist extension appears to be a complete mess. It was
designed to implement things like CODE, but a cross compiler seems much
more painful, and unnecessarily so. Anton posted some ugly code to
implement gforth's EXECUTE-PARSING with word lists, and that might help
implement a cleaner dictionary. Again, I confess not having realized
that was even possible, before examining Anton's implementation.

Lars Brinkhoff

unread,

May 23, 2016, 2:30:54 AM5/23/16

to

Paul Rubin <no.e...@nospam.invalid> writes:
> The ANS wordlist extension appears to be a complete mess. It was
> designed to implement things like CODE, but a cross compiler seems
> much more painful, and unnecessarily so.

It's not that painful. Why do you this so? If you do it the usual way
(which is explained in several Forth Dimensions articles), it's actually
quite easy.

hughag...@gmail.com

unread,

May 23, 2016, 2:36:16 AM5/23/16

to

On Sunday, May 22, 2016 at 10:22:18 PM UTC-7, Paul Rubin wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:

> > Eh? This is exactly the sort of thing for which wordlists have been
> > used for more than thirty years. They're exactly what is needed for
> > cross-compiling.
>
> The ANS wordlist extension appears to be a complete mess. It was
> designed to implement things like CODE, but a cross compiler seems much
> more painful, and unnecessarily so. Anton posted some ugly code to
> implement gforth's EXECUTE-PARSING with word lists, and that might help
> implement a cleaner dictionary. Again, I confess not having realized
> that was even possible, before examining Anton's implementation.

Actually, the original vocabulary scheme with CONTEXT and CURRENT (as standardized in Forth-83, and afaik also the same in Forth-79) was designed for assemblers. This was pretty simple. A code word would change CONTEXT to ASSEMBLER so it could use the assembler, but CURRENT continued to be whatever vocabulary the programmer was putting the word in (usually FORTH). This allowed the assembler to have words such as OR and AND etc. that are also in Forth. The vocabulary scheme was also used when working with the line-editor. The user could use editor words such as I that are also in Forth. All in all, pretty simple, and it worked quite well for these kinds of uses.

My MFX used the Forth-83 vocabulary scheme with CONTEXT and CURRENT and it worked fine. I did have to resort to carnal knowledge of UR/Forth for a few things. I needed to be able to take an xt and determine its attributes (what vocabulary it was defined in, immediate or non-immediate, smudge flag set or not set, smudge-ready flag set or not set), and I needed to change these attributes as needed. This is actually trivial to implement, and it is essential to a cross-compiler. The fact that ANS-Forth didn't provide such essential features, and Forth-200x continues to refuse to do so, implies that the ANS-Forth and Forth-200x committees are purposely crippling the Standard to prevent the common programmers from writing cross-compilers in competition with Forth Inc. and MPE (they presumably have these features for use in their own cross-compilers which are closed-source and are not ANS-Forth).

As for the ONLY ALSO scheme that was put in ANS-Forth, this is a screwball system that was not thought out very well. My novice-package fixes this though! I fixed this while maintaining ANS-Forth compatibility. This was two years ago. I can email you the new novice-package that has this fix --- I think that you will be amazed at how much better it works than the ONLY ALSO scheme.

hughag...@gmail.com

unread,

May 23, 2016, 2:39:22 AM5/23/16

to

There are no Forth Dimensions articles that explain cross-compilers --- cross-compilers are not "quite easy" --- you're making this stuff up!

I remember Forth Dimensions articles that described the ONLY ALSO scheme. I don't recall that the offered any suggestion to what it could be used for --- I'm not aware of there being any use for the ONLY ALSO scheme.