Dictionary separated from code ... PROS and CONs

[Chris Curl]

As you folks may remember, I am implementing my own little Forth.

I have implemented two flavors of the memory organization, one where
the code and dictionary start at opposite ends of the memory space and
grow towards each other, and one where the dictionary entries are interspersed
with the code.

At this point, I don't have a clear favorite or preference between the two.

From your perspective, what are the PROs and CONs of the two different
approaches, and which would you tend to gravitate to?

https://github.com/CCurl/Forth_C

Thanks, Chris

[Pablo Hugo Reda]

In Intel, asm guys tell diferent places for code and data are better for speed, but I don't test this.

[Anton Ertl]

Pablo Hugo Reda <pabl...@gmail.com> writes:
>In Intel, asm guys tell diferent places for code and data are better for sp=

>eed, but I don't test this.

Look at slide 12 of
<http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-slides.pdf>.
You can see that bigForth is slower than Gforth for cd16sim (by more
than a factor of 4), brew, and lexex. The reason is that bigForth
mixes native code and data, and Gforth keeps them separate.

If your system generates native code, keep the native code separated
from the data. However, AFAIK Chris Curl's system uses some
interpreted virtual machine code. Mixing that with the data does not
hurt, on the first order, and the system becomes simpler.

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

[Chris Curl]

Yes, mine is not native code. However, I do hope to get to the point where
I am able to generate native code.

[hughag...@gmail.com]

Even with a threaded system, it is best to keep the threaded-code separate from the headers --- this way the data-cache contains threaded-code and not headers which are rarely accessed (certainly not at run-time).

Note that ITC should be faster than DTC on a cached system. In DTC you have DOCOLON machine-code in front of every colon words, and none of those share a cache-line with the others. In ITC there is only one DOCOLON that all of the colon words use, and it stays in the code-cache continuously.

This last point is surprising to many Forthers with experience on the 16-bit x86. In the old days of MS-DOS, DTC was significantly faster than ITC because it was shorter code and had one less memory-access (this is one of the many reasons for why UR/Forth was significantly faster than PolyForth). This is not true on modern processors with a code-cache however --- as I said above, ITC should generally be faster --- Straight Forth is ITC.

[Elizabeth D. Rather]

On 7/21/16 4:09 AM, Chris Curl wrote:
> As you folks may remember, I am implementing my own little Forth.
>
> I have implemented two flavors of the memory organization, one where
> the code and dictionary start at opposite ends of the memory space and
> grow towards each other, and one where the dictionary entries are interspersed
> with the code.

I'm not sure what you mean by this. Do you mean segregating code and
data space, or machine code separate from compiled definitions? The
former makes a lot of sense in certain cases (dating back to some early
8086 implementations using segmented registers, an approach that was
abandoned when people went to 32-bit implementations). The latter is
pretty unusual, and I can't offhand think of a rationale for it.

The most common mapping for integrated data space is to have the
dictionary in low memory growing towards high memory and the stacks in
high memory growing down, with the data stack lower so that it and the
dictionary basically share unused memory. If there is a segregated data
space, it would be elsewhere, with the dictionary (containing code and
high-level definitions) still growing towards high memory. This would
include the name space for variables and other data structures that
reside in data space.

> At this point, I don't have a clear favorite or preference between the two.
>
> From your perspective, what are the PROs and CONs of the two different
> approaches, and which would you tend to gravitate to?
>
> https://github.com/CCurl/Forth_C

An integrated code/data space dictionary is simpler to create and
maintain, and results in less implementation code and modestly better
compilation performance. The segregated dictionary is necessary when you
need to run from ROM/flash, or on segregated code space microcontrollers.

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

[miss...@gmail.com]

Elizabeth, here is what I am talking about ... this is the 2 words
HERE and LAST in the integrated version. Note that the dictionary headers
at 005e and 0073 are interspersed with the code:

005e 49 00 73 00 ; Prev=0049, Next=0073, HERE
0062 6b 00 00 ; XT=006b, flags=00
0065 04 48 45 52 45 00

006b 18 5e 00 ; DICTP 005e - HERE
006e 0b 43 00 ; CALL 0043 - (HERE)
0071 02 ; FETCH
0072 0c ; RET

0073 5e 00 88 00 ; Prev=005e, Next=0088, LAST
0077 80 00 00 ; XT=0080, flags=00
007a 04 4c 41 53 54 00

0080 18 73 00 ; DICTP 0073 - LAST
0083 0b 58 00 ; CALL 0058 - (LAST)
0086 02 ; FETCH
0087 0c ; RET

In the separated version, the code for HERE and LAST are at
0033 and 003b, while the dictionary headers are at 1ec1 and 1ecc:

0033 18 cc 1e ; DICTP 1ecc - HERE
0036 0b 27 00 ; CALL 0027 - (HERE)
0039 02 ; FETCH
003a 0c ; RET

003b 18 c1 1e ; DICTP 1ec1 - LAST
003e 0b 2d 00 ; CALL 002d - (LAST)
0041 02 ; FETCH
0042 0c ; RET

...

1ec1 cc 1e ; Next=1ecc, LAST
1ec3 3b 00 00 ; XT=003b, flags=00
1ec6 04 4c 41 53 54 00

1ecc d7 1e ; Next=1ed7, HERE
1ece 33 00 00 ; XT=0033, flags=00
1ed1 04 48 45 52 45 00

[Brad Eckert]

On Thursday, July 21, 2016 at 7:09:46 AM UTC-7, Chris Curl wrote:
> As you folks may remember, I am implementing my own little Forth.
>
> I have implemented two flavors of the memory organization, one where
> the code and dictionary start at opposite ends of the memory space and
> grow towards each other, and one where the dictionary entries are interspersed
> with the code.
>

If header space is separate from code space, you can possibly do things like:

: place ( a u dest -) 0 over c! [
: +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ;

Also, the code is smaller so you have fewer cache misses. As processors get faster, it seems cache misses get more expensive. That's why small virtual machines sometimes beat native code implementations. The VM fits in cache.

You also have the option of discarding the header space, such as when creating a ROM image for an embedded system.

[hughag...@gmail.com]

ANS-Forth failed because it was written by an idiot salesperson who doesn't know even the most rudimentary concepts of assembly-language that any first-year assembly-language programmer would be expected to know. Caches! Ask somebody what they are!

ANS-Forth should have specified that code and data are separate. HERE would only be affected by ALLOT and comma (there are several variations on comma, for different data types). The ANS-Forth document would define exactly which words cause the HERE value to change. What we have now is ambiguity, because the programmer doesn't know if the HERE value changes or not (for example, when CONSTANT is executed) and his programs work on some ANS-Forth systems but not on other ANS-Forth systems. Also, the advantage of separating code and data is faster speed. You never have data in a code-cache line or code in a data cache-line, which is obviously going to slow down the system considerably.

What most likely happened is that some compiler-writers had code and data separated, because they knew that this results in significantly faster execution speed. SwiftForth had code and data intermixed. Everybody wanted to be ANS-Forth compliant, so Elizabeth Rather said either method was fine --- data may or may not be intermixed with code --- nothing was standardized.

[hughag...@gmail.com]

What I learned over on comp.lang.asm.x86 is that cache-thrashing is primarily what kills speed. There are a lot of different optimization techniques, all of which have some effect --- by far however, the most important is to reduce cache-thrashing --- this has more effect than all of the others combined.

[Cecil Bayona]

Besides the speed advantage, as time progresses more of the OSes and CPU
chips are implementing protection of the code area from data writes,
it's an option now but its easy to see that in the future writing to
the code area will be prohibited so having separate data headers and
code headers can prevent future issues.

This will be done as a safety issue because so many system hijacking
malware/viruses is done by buffer overflows which ends up changing the
software code. That can' happen if code and data are separate, and the
code area is protected.

--
Cecil - k5nwa

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> its easy to see that in the future writing to the code area will be
> prohibited

No I don't think it will be prohibited in the forseeable future. Too
much code depends on JIT compilers.

[hughag...@gmail.com]

What happens when you write to memory that has already been loaded into the code-cache? I've never been clear on this and it seems like an ambiguous aspect of the processor --- I couldn't find an answer in the Intel books; maybe I didn't look hard enough though --- I wouldn't try a stunt like that and expect it to work on every processor.

[Cecil Bayona]

The cache area written to is updated or flushed depending on the CPU
hardware.

--
Cecil - k5nwa

[Elizabeth D. Rather]

On 7/21/16 2:06 PM, Brad Eckert wrote:
> On Thursday, July 21, 2016 at 7:09:46 AM UTC-7, Chris Curl wrote:
>> As you folks may remember, I am implementing my own little Forth.
>>
>> I have implemented two flavors of the memory organization, one where
>> the code and dictionary start at opposite ends of the memory space and
>> grow towards each other, and one where the dictionary entries are interspersed
>> with the code.
>>
> If header space is separate from code space, you can possibly do things like:
>
> : place ( a u dest -) 0 over c! [
> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ;
>
> Also, the code is smaller so you have fewer cache misses. As processors get faster, it seems cache misses get more expensive. That's why small virtual machines sometimes beat native code implementations. The VM fits in cache.

Yes, but cache sizes have grown much bigger. The system I'm typing on
has 6M cache. With integrated code/data your entire system should fit in
a small corner of that space.

> You also have the option of discarding the header space, such as when creating a ROM image for an embedded system.
>

Yes, that's the main argument for segregating them.

But the OP is talking about segregating the dictionary heads from the
code, which is another issue altogether. In a cross-compiler, the heads
are in the host, and only the actual code and an image of initialized
RAM go in the ROMable image. In a resident system, the advantage of
segregating the headers from the code is unclear to me.

[Brad Eckert]

On Thursday, July 21, 2016 at 5:07:46 PM UTC-7, hughag...@gmail.com wrote:
>
> What most likely happened is that some compiler-writers had code and data separated, because they knew that this results in significantly faster execution speed. SwiftForth had code and data intermixed. Everybody wanted to be ANS-Forth compliant, so Elizabeth Rather said either method was fine --- data may or may not be intermixed with code --- nothing was standardized.

AFAIK, Rick Van Norman was the primary author of SwiftForth, not Elizabeth. Does this interleaving make much difference on a PC? Caches keep getting bigger to accommodate monster bloatware. SwiftForth is not VFX and will never be VFX. Horses for courses, as Wil Baden liked to say.

The ANS Standard is 22 years old. In the intervening 22 years, has anyone proposed an alternative standard? Perhaps a cleaner subset that ANS can ride on top of, something to bridge the embedded and desktop worlds.

You are aware that Elizabeth is 75 and still programming in Forth. My mom is 72 and still banging out website code in MS Access. Because they like it. I hope I'm still programming decent code when I'm that age.

-Brad

[HAA]

Elizabeth D. Rather wrote:
> On 7/21/16 2:06 PM, Brad Eckert wrote:

> ...

> > You also have the option of discarding the header space, such as when creating a ROM
> > image for an embedded system.
> >
>
> Yes, that's the main argument for segregating them.
>
> But the OP is talking about segregating the dictionary heads from the
> code, which is another issue altogether. In a cross-compiler, the heads
> are in the host, and only the actual code and an image of initialized
> RAM go in the ROMable image. In a resident system, the advantage of
> segregating the headers from the code is unclear to me.

The advantage is that on more than a few occasions potential Forthers and
purchasers of commercial systems have asked whether applications can be
saved without compiler overhead. That is after all what compilers in other
languages traditionally do. In Forth the choices to date have been to live with
the bloat, or use a meta-compiler that limits the very interactivity Forth claims
is behind its productivity.

[Brad Eckert]

On Thursday, July 21, 2016 at 6:57:41 PM UTC-7, Elizabeth D. Rather wrote:
> But the OP is talking about segregating the dictionary heads from the
> code, which is another issue altogether. In a cross-compiler, the heads
> are in the host, and only the actual code and an image of initialized
> RAM go in the ROMable image. In a resident system, the advantage of
> segregating the headers from the code is unclear to me.
>

I think what you're saying is that headers might as well be in code space because caches are huge anyway. Separating data and code spaces is a separate issue. The hardware has to support interleaved code and data because too many apps use it, so it's really a non-issue to everyone but Intel design teams.

However, on the evolution front I think Forth is getting a bit stale. Chris has the chance to implement his Forth without any baggage or customers who are locked into certain ways of doing things. I'm in favor of removing the dependency that headers may or may not be interleaved with code, and saying that they are not. Like in my cute PLACE/+PLACE example. In other words, embedded tricks work on the desktop.

Even the normative embedded standard that MPE and FORTH Inc. came up with could use some work. Last I heard, Leon wasn't completely satisfied with it. I think a Forth that fits both desktop and embedded environments would be a good goal. Perhaps it's time to run the code in a tight VM expressed in C, so as to leverage today's C-based IDEs and middleware. You're back down to 16K or 32K caches for $5-$10 chips, enough for the VM to run in cache at an ARM9's 400 MHz speed.

-Brad

[hughag...@gmail.com]

On Thursday, July 21, 2016 at 7:41:28 PM UTC-7, Brad Eckert wrote:
> On Thursday, July 21, 2016 at 5:07:46 PM UTC-7, hughag...@gmail.com wrote:
> >
> > What most likely happened is that some compiler-writers had code and data separated, because they knew that this results in significantly faster execution speed. SwiftForth had code and data intermixed. Everybody wanted to be ANS-Forth compliant, so Elizabeth Rather said either method was fine --- data may or may not be intermixed with code --- nothing was standardized.
>
> AFAIK, Rick Van Norman was the primary author of SwiftForth, not Elizabeth.

I'm well aware that Elizabeth Rather has never written a Forth program in her life. I wasn't aware of which employee of Forth Inc. did write SwiftForth. This Rick Van Norman apparently is a crappy programmer --- he did a terrible job --- I hope he got paid well.

> Does this interleaving make much difference on a PC? Caches keep getting bigger to accommodate monster bloatware.

The code-cache and data-cache on the 64-bit x86 is 32KB each --- same as on the 32-bit x86 --- each cache-line is 16 bytes.

> The ANS Standard is 22 years old. In the intervening 22 years, has anyone proposed an alternative standard? Perhaps a cleaner subset that ANS can ride on top of, something to bridge the embedded and desktop worlds.

You can't have ANS-Forth with its ambiguity being part of any Standard that doesn't have ambiguity!

Also, I have said many times that it is a mistake for ANS-Forth to be a Standard for both desktop-computers and micro-controllers. This made some sense in 1984 when the same processors (the 6502 and Z80) were used for both, but it did not make sense in 1994, and it becomes a worse idea with every year. Straight Forth is only for desktop-computers. The "killer app" for Straight Forth is a cross-compiler to LFTforth which is for micro-controllers. Straight Forth and LFTforth aren't compatible at all. LFTforth is really Raimond Dragomir's thing, not mine, as he has a lot more experience with micro-controllers than I do.

> You are aware that Elizabeth is 75 and still programming in Forth.

Elizabeth Rather was stupid in 1994 when she wrote ANS-Forth, and she was stupid in 1974 when she was a COBOL programmer --- she has been stupid her entire life --- age has nothing to do with it.

Also, Elizabeth Rather is not "still programming in Forth" --- she has never written a Forth program in her life --- the only code she ever posts on comp.lang.forth (for as long as comp.lang.forth has existed) are code snippets copied directly out of the "Starting Forth" book.

[Ron Aaron]

Doubtful it will be prohibited since it is necessary for loading code
from external sources, JIT, etc.

However, it is good practice to separate data and code on modern
processors (not just Intel ones), particularly writable data -- since
writing to data which shares cache with code will cause a delay while
the CPU make sure the cached data are consistent. You avoid that
penalty simply by not putting data in with code (yes, you must do it
sometimes).

[hughag...@gmail.com]

On Thursday, July 21, 2016 at 6:57:41 PM UTC-7, Elizabeth D. Rather wrote:

> In a resident system, the advantage of
> segregating the headers from the code is unclear to me.

If both code and data are in the same cache-line, then you are wasting cache space --- also, there is the awkward problem of what happens if your code writes into data that is in the code-cache.

Stupid! Why do you even get involved in these technical discussions? You really know nothing about programming! You should just stick to braying about how you are the "leading expert" who writes the Standard for all Forth programmers, and avoid getting involved in technical discussions because you invariably make fool out of yourself with your ignorance.

[Ron Aaron]

On 22/07/2016 03:50, hughag...@gmail.com wrote:

>
> What happens when you write to memory that has already been loaded into the code-cache?

You generally need to inform the CPU that it needs to refresh its caches.

[Brad Eckert]

On Thursday, July 21, 2016 at 8:58:15 PM UTC-7, hughag...@gmail.com wrote:
>
> If both code and data are in the same cache-line, then you are wasting cache space --- also, there is the awkward problem of what happens if your code writes into data that is in the code-cache.
>

Yes, that is awkward. How do you propose handling two different behaviors of comma (compile to code space or compile to data space)?

> Stupid! Why do you even get involved in these technical discussions? You really know nothing about programming! You should just stick to braying about how you are the "leading expert" who writes the Standard for all Forth programmers, and avoid getting involved in technical discussions because you invariably make fool out of yourself with your ignorance.

Did I mention the ANS TC was a quarter century ago? She and Ned wrote a nice book on ANS, which is an information-dense reference. Regardless, there's a book. How about you write a book as you write your cool new Forth. If you develop the book and Forth together, you will have a good reference book so people can actually use it.

I've never met Elizabeth Rather (now Conklin), so I can't really say much about her apart from what I read on c.l.f. However, I've never seen her call anyone stupid.

[hughag...@gmail.com]

On Thursday, July 21, 2016 at 9:56:11 PM UTC-7, Brad Eckert wrote:
> On Thursday, July 21, 2016 at 8:58:15 PM UTC-7, hughag...@gmail.com wrote:
> >
> > If both code and data are in the same cache-line, then you are wasting cache space --- also, there is the awkward problem of what happens if your code writes into data that is in the code-cache.
> >
> Yes, that is awkward. How do you propose handling two different behaviors of comma (compile to code space or compile to data space)?

Comma goes into data space.

There is COMPILE, and LITERAL that go into code space.

The important thing is that everything that goes into data space is documented so the programmer knows what affects the HERE value. Also, it is important that the HERE value is affected in the same way in every system --- not like in ANS-Forth where ALIGN may or may not modify the HERE value (in SwiftForth-v2 ALIGN and ALIGNED were noops, whereas in SwiftForth-v3 they did what they were expected to do; ALIGN could change HERE in the expected way).

I can't think of any reason why the application programmer needs to know what is going into code space. This is going to be different from one compiler to the next, so he can't write a program that depends upon him knowing how code is compiled. Also, there is likely to be a time delay --- COMPILE, etc. will compile code into an intermediate data-structure, then semicolon will call the optimizer to compile that intermediate code into actual code in the code space. I don't think it is a good idea for any of this to be exposed in the Standard --- the Standard should standardize behavior not implementation.

> > Stupid! Why do you even get involved in these technical discussions? You really know nothing about programming! You should just stick to braying about how you are the "leading expert" who writes the Standard for all Forth programmers, and avoid getting involved in technical discussions because you invariably make fool out of yourself with your ignorance.
>
> Did I mention the ANS TC was a quarter century ago? She and Ned wrote a nice book on ANS, which is an information-dense reference. Regardless, there's a book.

What book was this? I haven't seen anything from Forth Inc. that I would describe as being an "information-dense reference" --- are you referring to the ANS-Forth document?

> How about you write a book as you write your cool new Forth. If you develop the book and Forth together, you will have a good reference book so people can actually use it.

Yea, I'll do that.

> I've never met Elizabeth Rather (now Conklin), so I can't really say much about her apart from what I read on c.l.f. However, I've never seen her call anyone stupid.

When she appoints herself to be the chair-person of the ANS-Forth committee, and declares that ANS-Forth is the Standard for the entire Forth community, that is effectively the same as saying that every Forth programmer is stupid.

I think her tactic is to pay a troll such as John Passaniti to attack people such as Jeff Fox and myself. Then she praises the troll lavishly and calls him "brilliant" --- this makes her seem to be saying only positive things, but she doesn't get dirty by directly saying negative things --- if she associates with a troll like Passaniti though, then she is profoundly dirty, and she'll never be able to hide this dirtiness.

She also just lies routinely. She used to drive Jeff Fox crazy by continually lying about his and Charles Moore's work. Programmers take pride in their accomplishments, and it bothers them to have lies told about this saying that they actually failed. When she was demanding that I be kicked off the Forth-200x mailing list, she said that I had been fired from Testra after writing MFX. All of the ANS-Forth cult members cheerfully accept everything that she says, even when it is implausible (How would she know anything about Testra? They won't have anything to do with her either.) She tries to act like a sweet old lady, but she is a "deeply dishonest person" (Jeff Fox's words) --- pretty much everything that she says is a lie --- she hates anybody who has accomplished anything with Forth, and she tells gross lies about the person, but she praises those who have never accomplished anything (so long as they praise her as the "leading expert" of Forth). She also lies routinely about Forth Inc. "accomplishments" --- I've never heard any Forth Inc. customer verify any of this --- I think she is lying about all of this. Forth Inc. screws up everything that they get involved in --- OpenForth, for example, failed due to Forth Inc. screwing it all up --- it is the Forth community who gets a black-eye though, as everybody in the world says that Forth is no good.

She is mad at me because she made a sales-pitch at Testra to write the cross-compiler for the MiniForth, but I got the job instead (I was told at Testra that her price was "exorbitant" and that they felt insulted that Forth Inc. sent a glib salesperson rather than a programmer to talk to them). She hates anybody who steals a job from Forth Inc.. She said one company declined to use Forth Inc. and hired some C programmers instead, then she says that the C program ended up costing more than the Forth program was going to cost and took several times as long to complete --- how would she know any of this? --- did that potential customer keep her informed on the progress of his project after he rejected her offer? All the ANS-Forth cult members just accept these stories without question though.

If Elizabeth Rather just stuck to selling SwiftForth and Forth Inc. programming services, she wouldn't bother me --- declaring herself to be my leader and saying that I (and all other Forth programmers) depend entirely on her for guidance does bother me --- I am amazed that you guys accept such a gross insult without complaint.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>I'm not sure what you mean by this. Do you mean segregating code and
>data space, or machine code separate from compiled definitions? The
>former makes a lot of sense in certain cases (dating back to some early
>8086 implementations using segmented registers, an approach that was
>abandoned when people went to 32-bit implementations). The latter is
>pretty unusual, and I can't offhand think of a rationale for it.

Gforth generates both something like threaded code, and native
(machine) code, and the native code is separated from the rest, to
avoid cache consistency problems, but also because the native code is
optional and mostly transparent to the rest of the system: if the
conditions for dynamic native code generations are not met, the
threaded code just points to the original code for the primitives
(like classical threaded code), and no native code is generated.

[Anton Ertl]

Ron Aaron <ramb...@gmail.com> writes:
>However, it is good practice to separate data and code on modern
>processors (not just Intel ones)

Yes, AMD ones, too; and IBM 360 successors. I think that's pretty
much all. The others require software intervention to ensure cache
consistency; the upside is that the same memory can be in both the
I-cache and the D-cache, and storing into the D-cache will not throw
the line out of the I-cache; it will not be up-to-date, but for the
false sharing that is under discussion here that does not hurt.

[hughag...@gmail.com]

On Thursday, July 21, 2016 at 11:42:33 PM UTC-7, Anton Ertl wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
> >I'm not sure what you mean by this. Do you mean segregating code and
> >data space, or machine code separate from compiled definitions? The
> >former makes a lot of sense in certain cases (dating back to some early
> >8086 implementations using segmented registers, an approach that was
> >abandoned when people went to 32-bit implementations). The latter is
> >pretty unusual, and I can't offhand think of a rationale for it.

It is ridiculous that Elizabeth Rather now claims to understand how 8086 segment registers work. That wasn't the reality at the time. PolyForth for the 8086 had everything (machine-code, threaded-code code, application data, the compiler, the dictionary headers) all in a single 64K segment. It was obvious that the 8086 version of PolyForth was ported from an old version of PolyForth written for a processor (most likely the PDP-11) that only addressed 64K of memory --- the Forth Inc. "programmers" just ported it line-by-line without any modification to take advantage of the 8086's segment registers --- presumably the original version of PolyForth was written by Charles Moore, but after he got kicked out Forth Inc. had to just maintain his old software but were unable to write any software themselves.

Weirdly enough, what Elizabeth Rather is describing above sounds like UR/Forth from Laboratory MicroSystems Inc.. UR/Forth was a DTC system with the machine-code in the CS segment, the threaded-code and application data in the DS segment, and the dictionary headers in the ES segment. I wrote some benchmarks in both UR/Forth and Borland Turbo-C (small memory model) and found that the programs ran at pretty close to the same speed. By comparison, PolyForth compared badly to QBASIC.

> Gforth generates both something like threaded code, and native
> (machine) code, and the native code is separated from the rest, to
> avoid cache consistency problems, but also because the native code is
> optional and mostly transparent to the rest of the system: if the
> conditions for dynamic native code generations are not met, the
> threaded code just points to the original code for the primitives
> (like classical threaded code), and no native code is generated.

The last time I checked, Gforth code ran at about half the speed of SwiftForth code. I assumed that you had made an agreement with Elizabeth Rather that you would make sure that Gforth code was always slower than SwiftForth code so as to not undermine Forth Inc. sales, and in return she would appoint you to be the Forth-200x chair-person.

When you describe Gforth however, as you did above, it sounds like it should be pretty fast. Have you improved Gforth now so that it does surpass SwiftForth?

The quality of the code generated by SwiftForth is truly awful --- I find it difficult to believe that any Forth system could be slower than SwiftForth, unless the compiler-writers were purposely trying to make it slower.

[hughag...@gmail.com]

On Thursday, July 21, 2016 at 11:58:44 PM UTC-7, Anton Ertl wrote:
> Ron Aaron <ramb...@gmail.com> writes:
> >However, it is good practice to separate data and code on modern
> >processors (not just Intel ones)
>
> Yes, AMD ones, too; and IBM 360 successors. I think that's pretty
> much all. The others require software intervention to ensure cache
> consistency; the upside is that the same memory can be in both the
> I-cache and the D-cache, and storing into the D-cache will not throw
> the line out of the I-cache; it will not be up-to-date, but for the
> false sharing that is under discussion here that does not hurt.

All modern assemblers separate data and code --- this has been true going back to the late 1980s --- in those days, the leading-edge processors (i8086, MC68000) separated data and code, whereas the trailing-edge processors (6502, Z80, 6809) intermixed data and code. Actually, the IBM360 separated data and code, and that goes back to the 1960s --- it was quite expensive though --- it wasn't until the 1980s that this kind of technology reached the personal-computer world.

It is depressing to me that a basic topic such as this has to be debated on comp.lang.forth --- this was well-known when I was a teenager --- nobody has an excuse to not know this in the year 2016.

[Cecil Bayona]

Actually the Z80 assemblers had facilities to separate code and data,
some didn't use it and lumped everything together but that was the
programmers choice.

--
Cecil - k5nwa

[Ron Aaron]

On 22/07/2016 10:19, hughag...@gmail.com wrote:

> All modern assemblers separate data and code --- this has been true going back to the late 1980s

Wrong. You can easily insert data into the code (text) section in
modern assemblers. Similarly you can define code in the data section.

What is correct is that assemblers make it easy to separate data and
code. They do not, generally, enforce any such separation.

[Lars Brinkhoff]

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

> Yes, but cache sizes have grown much bigger. The system I'm typing on
> has 6M cache.

Two problems with that statement:

- There may be a cache hierarchy. On a desktop computer, 6M is
typically at level 3. If you stay inside the much smaller L1, or the L2
cache, your code will be much faster.

- Embedded targets usually have smaller caches.

[Stephen Pelc]

On Thu, 21 Jul 2016 20:24:15 -0700 (PDT), Brad Eckert
<hwf...@gmail.com> wrote:

>Even the normative embedded standard that MPE and FORTH Inc. came up with c=
>ould use some work. Last I heard, Leon wasn't completely satisfied with it.=

The embedded draft standard was designed on a whiteboard in Waterloo
(Belgium) during the OTA project. It reflects the design of the FI
and MPE cross-compilers of the time, especially in terms of their
use of wordlists/vocabularies. A lot of detail is missing from
the specification of the COMPILER scope.

I have also designed a cross-compiler in which the ideas of the
cross-compiler scopes do not work well. Every year, Leon and I
discuss overhauling the document, but it really needs input from
other people who use cross-compilers every day.

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

[Chris Curl]

So if I am understanding the discussion here, in many Forth implementations,
the actual machine code is static (the system's primitives), and essentially
everything else is data. The dictionary headers are obviously data, but the
words' definitions are also really just data, in that they are just a list of
identifiers for the primitives that are to be executed in order, along with
whatever other data the primitives are to work on.

Do I have that right? If so, why would an additional layer of separation
be necessary or desired? And exactly what is split apart?

In my little world, I am generating executable machine code (albeit for
my VM's CPU). It currently uses the same "code" area for the ALLOTed data
as well as VARIABLEs.

I suppose separating code and data in my little world would mean having a 3rd,
non-dictionary header area where VARIABLEs and ALLOTed memory would go. Then
the "code" area would truly be all code, and for an embedded implementation,
I could include the code and data areas, but not the dictionary headers.

But in either case, keeping the dictionary headers out of the code area
sounds like the right way to go.

I guess for a more "traditional" Forth, separation would also have two data
areas, one for the dictionary headers, the other for the data the primitives
work on.

[Anton Ertl]

Chris Curl <ccur...@gmail.com> writes:
>So if I am understanding the discussion here, in many Forth implementations,
>the actual machine code is static (the system's primitives), and essentially
>everything else is data.

That would be a classic threaded-code implementation. The current
mainstream is to have a native-code implementation, though, e.g.,
SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with
--no-dynamic your description fits, but in the default configuration
it generates native code at run-time (unless there is some red flag
that turns this off).

[Chris Curl]

On Friday, July 22, 2016 at 9:12:14 AM UTC-4, Anton Ertl wrote:

> Chris Curl <ccurl...@gmail.com> writes:
> >So if I am understanding the discussion here, in many Forth implementations,
> >the actual machine code is static (the system's primitives), and essentially
> >everything else is data.
>
> That would be a classic threaded-code implementation. The current
> mainstream is to have a native-code implementation, though, e.g.,
> SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with
> --no-dynamic your description fits, but in the default configuration
> it generates native code at run-time (unless there is some red flag
> that turns this off).
>
> - anton

Thanks for the clarification ... one last clarification please ...

Since I am not doing something totally new and different, I might as
use words that other implementations have used for the same sorts of
operations.

In a native code implementation, what do "," and "C," operate on ...
the data or the code area?

Hugh referred to a "COMPILE," word for adding to the code area, which
implies that "," and "C," are used for the data/dictionary area ... is
that pretty common, and if so, does it take 8, 16, 32, or 64 bit value?

It almost feels like it would be clearer to have words like "CODE,",
"CODE-C,", "DICT,", "DICT-C,", "DATA,", and "DATA-C,". With a setup
like that, "," and "C," would be shortcuts for one of the 3 different
more specific words.

Thanks

[rickman]

On 7/21/2016 8:07 PM, hughag...@gmail.com wrote:
> On Thursday, July 21, 2016 at 3:40:35 PM UTC-7, Elizabeth D. Rather
> wrote:

>> On 7/21/16 4:09 AM, Chris Curl wrote:
>>> As you folks may remember, I am implementing my own little
>>> Forth.
>>>
>>> I have implemented two flavors of the memory organization, one
>>> where the code and dictionary start at opposite ends of the
>>> memory space and grow towards each other, and one where the
>>> dictionary entries are interspersed with the code.
>>

>> I'm not sure what you mean by this. Do you mean segregating code
>> and data space, or machine code separate from compiled definitions?
>> The former makes a lot of sense in certain cases (dating back to
>> some early 8086 implementations using segmented registers, an
>> approach that was abandoned when people went to 32-bit
>> implementations). The latter is pretty unusual, and I can't offhand
>> think of a rationale for it.
>>

Someone once said, "there is no correct way to do this stuff --- so, get
off your high horse and stop criticizing people for doing things
differently than you do them."

--

Rick C

[rickman]

On 7/21/2016 11:52 PM, hughag...@gmail.com wrote:
> On Thursday, July 21, 2016 at 7:41:28 PM UTC-7, Brad Eckert wrote:
>> On Thursday, July 21, 2016 at 5:07:46 PM UTC-7, hughag...@gmail.com
>> wrote:
>>>
>>> What most likely happened is that some compiler-writers had code
>>> and data separated, because they knew that this results in
>>> significantly faster execution speed. SwiftForth had code and
>>> data intermixed. Everybody wanted to be ANS-Forth compliant, so
>>> Elizabeth Rather said either method was fine --- data may or may
>>> not be intermixed with code --- nothing was standardized.
>>
>> AFAIK, Rick Van Norman was the primary author of SwiftForth, not
>> Elizabeth.
>

> I'm well aware...

of precious little for the most part. Your rantings are getting the
better of you here so I snipped the pointless maniacal ravings. I will
point out that computers come in many sizes, shapes and architectures.
Not all of them require or even support the separation of data and code
space. The bottom line is Forth allows you to design a compiler that is
appropriate for your computer system no matter what it is. Well, maybe
not on an abacus.

--

Rick C

[rickman]

Really? Is there any reason to believe anything you say will have even
the tiniest impact on Hugh's behavior? The one thing I do know is that
in replying to him you give him an opportunity to continue ranting and
raving. He is clearly not completely balanced. Would you try to talk
sense to someone on the street who ranted about secret conspiracies?
No, you would just walk away and most likely very quickly.

--

Rick C

[rickman]

If any at all.

--

Rick C

[Cecil Bayona]

I do believe he was referring about desktop machines since his Forth
project is only for desktops and that seems to be his area of interest,
in that case the chips do have mechanisms to enforce the separation of
the code and the data, although use of those features is optional.
Windows has that feature although it can be turned off for compatibility
with old software. Linus also has that capability also.

In the embedded field that forced separation is all over the place with
many devices offering no protection and separation of data versus code.
The assemblers for those embedded devices do provide with commands to
separate the two as that feature is vital in creating code that can be
placed in ROM or FLASH memories.

These two classes of computers have drifted apart over the years, it
used to be that desktops used the same processors that embedded
computers used, but that has changed although some ARM machines are
beginning to blend the two classes again. Raspberry Pi 3 ,or their
brethren anyone?

The only thing one can count on is that Forth is great, specially for
embedded computer devices.

--
Cecil - k5nwa

[Brad Eckert]

On Thursday, July 21, 2016 at 11:38:36 PM UTC-7, hughag...@gmail.com wrote:
> >
> > Did I mention the ANS TC was a quarter century ago? She and Ned wrote a nice book on ANS, which is an information-dense reference. Regardless, there's a book.
>
> What book was this? I haven't seen anything from Forth Inc. that I would describe as being an "information-dense reference" --- are you referring to the ANS-Forth document?
>

The Forth Programmer's Handbook, 3rd Edition. You can get it:
Free PDF either in the wild or in SwiftForth eval version.
$20 used: https://www.amazon.com/Forth-Programmers-Handbook-Elizabeth-Rather/dp/1419675494

>
> If Elizabeth Rather just stuck to selling SwiftForth and Forth Inc. programming services, she wouldn't bother me --- declaring herself to be my leader and saying that I (and all other Forth programmers) depend entirely on her for guidance does bother me --- I am amazed that you guys accept such a gross insult without complaint.

Well, okay. Elizabeth's role in life has evolved into "Mama Forth" and you disagree with the way she fills the role. She does like to pontificate, but I suppose it goes with being a nice Catholic girl. The pontiff of Forth. Maybe in a previous life you had a run-in with the Grand Inquisitor Torquemada.

What I get from all this is that you can't design Forth by committee. You have to do it like Chuck. One committed guy does the whole thing his way. When Chuck left Forth Inc, the basic philosophy was frozen in amber. When the ANS TC came along, Chuck found this amber too hard to chisel through.

So, you have you and Chris and others implementing their own Forths. It's a big job to work your way up to Chuck level. Many Forths to write. But, Forth will never be finished. It's a way of life, this pursuit of elegant minimalism. We live in age in which the costs of complexity are almost universally underestimated.

[Chris Curl]

On Friday, July 22, 2016 at 1:43:55 PM UTC-4, Brad Eckert wrote:
> We live in age in which the costs of complexity are almost universally underestimated.

Very well put. I agree completely.

One of my primary gauges for code is that it should be "intuitively obvious
upon casual inspection". If it isn't, then there better be a damn good reason
why not.

[rickman]

Sometimes the problem is just that complex. I wrote some VHDL code to
search for a sync to an external signal and then keep the internal
signal in step. I tried more than once to simplify the code, but the
functional elements were all required with lots of interaction between
them.

If it were written in Forth, I don't think it could have been factored
any better with the possibility of a bit more reuse. Factoring and
reuse is not as easy in VHDL, but it isn't limited, just verbose.

--

Rick C

[Elizabeth D. Rather]

On 7/22/16 7:43 AM, Brad Eckert wrote:
> What I get from all this is that you can't design Forth by
> committee. You have to do it like Chuck. One committed guy
> does the whole thing his way. When Chuck left Forth Inc, the
> basic philosophy was frozen in amber. When the ANS TC came
> along, Chuck found this amber too hard to chisel through.
>

The level of implementation creativity inspired by ANS Forth's emphasis
on semantics (behavior) rather than implementation (as in Forth83) has
led to major improvements in performance, by various optimizing compiler
techniques and other things. No amber there.

However, the existence of a large and growing number of significant
existing applications, as well as the need to encourage organizations
and professional programmers to use Forth, meant that a level of
stability had to be provided. This is true of all programming languages
that aspire to be more than a personal toy.

During the Forth94 development the TC members received from ANSI all the
official correspondence of other language TCs. During that period both
Fortran and Cobol standards were undergoing development. The level of
outrage against some of the changes being discussed was impressive,
including multi-million $$ lawsuits. I gather that the C standards have
strayed somewhat from the original K&R, but I'll bet it's still pretty
recognizable.

> So, you have you and Chris and others implementing their
> own Forths. It's a big job to work your way up to Chuck level.
> Many Forths to write. But, Forth will never be finished.
> It's a way of life, this pursuit of elegant minimalism.
> We live in age in which the costs of complexity are almost
> universally underestimated.

If you really want Forth to flourish, you need to be writing
applications and publishing application-oriented code, rather than
re-designing the elegantly simple wheel itself.

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

[Elizabeth D. Rather]

...or no cache at all. But embedded Forths and applications generally
*do* segregate code and data spaces.

[Elizabeth D. Rather]

On 7/22/16 5:13 AM, Chris Curl wrote:
> On Friday, July 22, 2016 at 9:12:14 AM UTC-4, Anton Ertl wrote:
>> Chris Curl <ccurl...@gmail.com> writes:
>>> So if I am understanding the discussion here, in many Forth implementations,
>>> the actual machine code is static (the system's primitives), and essentially
>>> everything else is data.
>>
>> That would be a classic threaded-code implementation. The current
>> mainstream is to have a native-code implementation, though, e.g.,
>> SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with
>> --no-dynamic your description fits, but in the default configuration
>> it generates native code at run-time (unless there is some red flag
>> that turns this off).
>>
>> - anton
> Thanks for the clarification ... one last clarification please ...
>
> Since I am not doing something totally new and different, I might as
> use words that other implementations have used for the same sorts of
> operations.
>
> In a native code implementation, what do "," and "C," operate on ...
> the data or the code area?
>
> Hugh referred to a "COMPILE," word for adding to the code area, which
> implies that "," and "C," are used for the data/dictionary area ... is
> that pretty common, and if so, does it take 8, 16, 32, or 64 bit value?

COMPILE, is in ANS Forth and its successors. It's used to compile
contents of colon definitions. Exactly what they compile depends on the
implementation strategy: pointers, JSRs, tokens, or actual machine code
(potentially optimized), but whatever it is will go in code space. ","
and "C," compile one-cell and one-char items in data space.

> It almost feels like it would be clearer to have words like "CODE,",
> "CODE-C,", "DICT,", "DICT-C,", "DATA,", and "DATA-C,". With a setup
> like that, "," and "C," would be shortcuts for one of the 3 different
> more specific words.

ANS Forth and successors try to be very clear what spaces words work in,
as I describe above. HERE is specified to return the next address in
data space. Implementations that segregate code and data space commonly
use THERE for the equivalent next code space location. In
implementations with mixed code and data space, compilation may affect
HERE; this exception is clearly spelled out in the standard. Application
writers are cautioned not to assume any particular implementation or to
attempt to modify either definition heads or contents, only data.

[Brad Eckert]

On Friday, July 22, 2016 at 4:32:11 AM UTC-7, Stephen Pelc wrote:
> Every year, Leon and I
> discuss overhauling the document, but it really needs input from
> other people who use cross-compilers every day.
>

One thing that just occurred to me is that the TARGET scope can be implemented with a group of WORDLISTs, not just one. You could have VOCABULARY, MODULE, etc. work on this group. TARGET would plop the group into the search order. Maybe TARGET FORTH would start you off with the basic target visibility and then you could dig down from there.

Search order scoping is one of the things I miss in embedded Forths. There might be other things you can think of.

I haven't looked at the document in a while. Do you have a link to it?

[Chris Curl]

So ... "HERE" "THERE", and "COMPILE,"

Do "," and "C," increment HERE, while "COMPILE," increments THERE?

[hughag...@gmail.com]

COMPILE, compiles an xt. In the old days of Forth-83, there was just comma and it was also used for compiling a cfa --- this worked given the assumption that the system was ITC --- with STC and/or an optimizing compiler however, comma doesn't work.

In a simple ITC system, COMPILE, is just like comma except for code-space rather than data-space. In a simple STC system, COMPILE, will compile a CALL instruction and the cfa as the operand. In an optimizing system, COMPILE, isn't necessarily going to compile into the code-space at all --- it may compile into an intermediate data-structure, then semicolon will call the optimizer that will compile that intermediate code into machine-code for the entire function. As I said before, you don't want the user to have any expectation of what COMPILE, does, or to mess with code-space himself --- this is definitely unlawful carnal knowledge --- if you're going to have portability of programs, then COMPILE, has to be a black-box and you define it with terms such as "compile the xt" that are purposely left undefined.

One of the lies that Elizabeth Rather likes to tell, is that there were no optimizing compilers prior to ANS-Forth and that ANS-Forth made optimizing compilers possible. That lie used to drive Jeff Fox up the wall! Elizabeth Rather really knew how to push his buttons, and that lie made him mad every time! There were optimizing compilers before ANS-Forth (some written by Jeff Fox) but they weren't Forth-83 compliant because they had something other than comma for compiling an xt, so Forth-83 program that used comma wouldn't work. What is really dumb about Elizabeth Rather bragging that ANS-Forth was such an improvement over Forth-83, is that it was Forth Inc. that screwed up both the Forth-83 and ANS-Forth Standards. In Forth-83 days, all the Forth programmers had to work around the bugs in the Forth-83 design --- then, in ANS-Forth days, all the Forth programmers had to work around the bugs in the ANS-Forth design --- when Forth-200x comes out, etc...

The Forth Standards over the decades have documented Elizabeth Rather's glacial progress through programming-101 concepts that most programmers learn in one year --- now Elizabeth Rather's appointed Forth-200x committee are writing a new Standard, but as usual it looks like the work of a programming-101 'D' student, just like every other time.

There is never going to be a meaningful Forth Standard until Forth Inc. gets kicked out --- they have screwed up every standard so far --- Forth Inc. is a boat-anchor chained to the ankle of the Forth community.

[Elizabeth D. Rather]

Yes, although THERE isn't standardized. Generally the standards have
avoided any requirements that might impinge on internal kernel
development (involving "kernal knowledge"). Note also that ALLOT
specifically allocates data space.

[Brad Eckert]

On Friday, July 22, 2016 at 2:08:55 PM UTC-7, Chris Curl wrote:

> So ... "HERE" "THERE", and "COMPILE,"
>
> Do "," and "C," increment HERE, while "COMPILE," increments THERE?

HERE is not a variable. A simple system might define it as:

VARIABLE DP \ data pointer
VARIABLE CP \ code pointer
: HERE ( -- a ) DP @ ;
: ORG ( a -- ) DP ! ;
: ALLOT ( n --) DP +! ;
: , ( n -- ) HERE ! CELL ALLOT ;
: THERE ( a -- ) CP ! ;

Or, DP could be a pointer to a pointer to support as many spaces as you want:

VARIABLE DPTR \ data pointer
VARIABLE CPTR \ code pointer
: DATA ( -- ) DPTR DP ! ;
: CODE ( -- ) CPTR DP ! ;
: HERE ( -- a ) DP @ @ ;
: ORG ( a -- ) DP @ ! ;
: ALLOT ( n --) DP @ +! ;
: , ( n -- ) HERE ! CELL ALLOT ;

[Brad Eckert]

On Friday, July 22, 2016 at 3:24:11 PM UTC-7, hughag...@gmail.com wrote:
> One of the lies that Elizabeth Rather likes to tell, is that there were no optimizing compilers prior to ANS-Forth and that ANS-Forth made optimizing compilers possible.

"It's not a lie if you believe it" -- George Castanza

The "Dr Dobbs Toolbook of Forth" (1987) described a subroutine threaded Forth for the 68000 with peephole optimization and native code generation. MacForth was one of the first programming SDKs for the Mac (1984). It switched to subroutine threading in 1987. MacForth (Carbon and Cocoa) is alive and well 30 years later at MPE, running under VFX.

[Elizabeth D. Rather]

Indeed, MacForth was an outstanding, and in some ways groundbreaking,
Forth. But it was not Forth83 compatible, and suffered some in the
marketplace for that reason. Don Colburn was an enthusiastic participant
in the development of ANS Forth, and delighted to be able to offer a
*Standard* version of MacForth with all its nice features. The version
of locals adopted for Forth94 came from MacForth.

[hughag...@gmail.com]

On Friday, July 22, 2016 at 8:36:40 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/22/16 5:12 PM, Brad Eckert wrote:
> > On Friday, July 22, 2016 at 3:24:11 PM UTC-7, hughag...@gmail.com wrote:
> >> One of the lies that Elizabeth Rather likes to tell, is that there were no optimizing compilers prior to ANS-Forth and that ANS-Forth made optimizing compilers possible.
> >
> > "It's not a lie if you believe it" -- George Castanza
> >
> > The "Dr Dobbs Toolbook of Forth" (1987) described a subroutine threaded Forth for the 68000 with peephole optimization and native code generation. MacForth was one of the first programming SDKs for the Mac (1984). It switched to subroutine threading in 1987. MacForth (Carbon and Cocoa) is alive and well 30 years later at MPE, running under VFX.
>
> Indeed, MacForth was an outstanding, and in some ways groundbreaking,
> Forth. But it was not Forth83 compatible, and suffered some in the
> marketplace for that reason. Don Colburn was an enthusiastic participant
> in the development of ANS Forth, and delighted to be able to offer a
> *Standard* version of MacForth with all its nice features. The version
> of locals adopted for Forth94 came from MacForth.

So, it was Don Colburn's fault that the parameters for LOCALS| were backwards --- you always blame somebody else for the myriad screw-ups in ANS-Forth! --- to a large extent, the purpose of having a Forth-200x committee, and appointing people to be on the committee, is so you will have somebody to blame when the bad design of Forth-200x becomes obvious.

There was no ANS-Forth compiler until 3 years after ANS-Forth became the Standard. This was SwiftForth, and up through version-2 of SwiftForth (LOCAL) would crash the system when it was used (SwiftForth had so many bugs as to be unusable for professional programming). It seems more likely that the locals design for ANS-Forth is completely screwed up because nobody ever tested it --- if you want to blame Don Colburn for this, then go ahead --- it was, however, your job as the chairperson of the ANS-Forth committee to test the design and make sure it made sense.

You were in a hurry to get ANS-Forth ratified by ANSI --- this is why you didn't take the time to test any of this stuff --- all you cared about was declaring yourself to be the person who writes the Standard for the entire Forth community, and actually having a Standard that made sense was unimportant to you.

Earlier it was said that Rick Van Norman was to blame for all the bugs in SwiftForth, and that you were not to blame --- this is how your little cult works --- they always blame somebody other than you for your failures.

[Brad Eckert]

On Friday, July 22, 2016 at 8:36:40 PM UTC-7, Elizabeth D. Rather wrote:
>

> Indeed, MacForth was an outstanding, and in some ways groundbreaking,
> Forth. But it was not Forth83 compatible, and suffered some in the
> marketplace for that reason. Don Colburn was an enthusiastic participant
> in the development of ANS Forth, and delighted to be able to offer a
> *Standard* version of MacForth with all its nice features. The version
> of locals adopted for Forth94 came from MacForth.
>

It's interesting that the biggest ANS opponents were the Forth hardware guys. It's as if ANS was geared to use all four flags in CPUs designed to run C code: Overflow, Carry, Minus and Zero. Of course all architectures going forward have to support C, so that was the main target of ANS. So, : < - 0< ; is nonstandard in one case that will probably never happen in practice.

For all the arm waving, I never saw a compelling example of what's so wrong with ANS. I think the biggest objection is the limited access to the compiler internals, which forces you to write your own QUIT loop to do much customization of the interpreter. But the facilities are there to do that. The TC had the job of parsing out religious issues from technical issues. The 2012 standard revisited locals and other things that couldn't reach a consensus in 1994.

But now that the dust has settled, what are the most popular objections to the ANS way of doing things?

[Brad Eckert]

On Friday, July 22, 2016 at 9:54:49 PM UTC-7, hughag...@gmail.com wrote:
> -- this is how your little cult works --- they always blame somebody other than you for your failures.

The hooded brown robes are actually quite comfy.

[hughag...@gmail.com]

Elizabeth Rather declares her way to be the Standard (with a capital 'S') and declares that anybody who does anything different is non-standard, and hence not a Forth programmer at all --- she alone decides what Forth is!

When I made that statement about people criticizing others for doing things differently, I was referring to the debate between infix and postfix arithmetic. Both ways are valid, so neither is "correct." People can go with whichever they want --- obviously infix for that Gareth fellow --- postfix for Forthers. If you are going to implement infix arithmetic however, then it must be done correctly --- if you give addition a higher precedence than multiplication, then that is incorrect --- similarly, if you are compiling for any processor bigger than the 6502 and you intermix code and data, then that is incorrect.

It is okay to prefer infix to postfix or vice-versa --- it is okay to prefer chicken salad to chicken soup or vice-versa --- it is not okay to declare chicken shit to be chicken salad, or to declare that this is the Standard and anybody who does anything else with the chicken is non-standard.

[hughag...@gmail.com]

On Friday, July 22, 2016 at 10:00:53 PM UTC-7, Brad Eckert wrote:
> It's interesting that the biggest ANS opponents were the Forth hardware guys. It's as if ANS was geared to use all four flags in CPUs designed to run C code: Overflow, Carry, Minus and Zero. Of course all architectures going forward have to support C, so that was the main target of ANS. So, : < - 0< ; is nonstandard in one case that will probably never happen in practice.

The MiniForth processor, developed in 1994/1995 did not have an overflow flag. The only flag that it had was Carry --- it was possible to test for minus and zero and obtain a flag on the data-stack for use by 0BRANCH --- there was no easy way to test for overflow (the only time this became an issue for me was when I wrote the DO loops).

> For all the arm waving, I never saw a compelling example of what's so wrong with ANS. I think the biggest objection is the limited access to the compiler internals, which forces you to write your own QUIT loop to do much customization of the interpreter. But the facilities are there to do that. The TC had the job of parsing out religious issues from technical issues. The 2012 standard revisited locals and other things that couldn't reach a consensus in 1994.
>
> But now that the dust has settled, what are the most popular objections to the ANS way of doing things?

ambiguity

[hughag...@gmail.com]

On Friday, July 22, 2016 at 4:32:11 AM UTC-7, Stephen Pelc wrote:

> On Thu, 21 Jul 2016 20:24:15 -0700 (PDT), Brad Eckert
> <hwf...@gmail.com> wrote:
>
> >Even the normative embedded standard that MPE and FORTH Inc. came up with c=
> >ould use some work. Last I heard, Leon wasn't completely satisfied with it.=
>
> The embedded draft standard was designed on a whiteboard in Waterloo
> (Belgium) during the OTA project. It reflects the design of the FI
> and MPE cross-compilers of the time, especially in terms of their
> use of wordlists/vocabularies. A lot of detail is missing from
> the specification of the COMPILER scope.
>
> I have also designed a cross-compiler in which the ideas of the
> cross-compiler scopes do not work well. Every year, Leon and I

> discuss overhauling the document, but it really needs input from
> other people who use cross-compilers every day.

I don't think you need input from people who use cross-compilers every day --- I think you need input from somebody who has written a cross-compiler.

I find it quite arrogant that you believe that you and Leon Wagner are qualified to write the Standard for cross-compilers, and that people like me have to just RTFM. I wrote MFX in 1994/1995 and it was used to cross-compile the motion-control program. I know how cross-compilers work.

I am very dubious that you know how a cross-compiler works. Consider this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ

You said this:
On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote:
> 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.

This is totally not true --- you do not have to simulate the target processor on the host processor at compile-time --- wtf???

Forth cross-compilers are not "much more complicated and much more subtle than they appear to be" --- they seem this way to you because you don't know how they work --- they are pretty simple after you have grasped the concept.

[hughag...@gmail.com]

On Friday, July 22, 2016 at 12:49:53 PM UTC-7, Brad Eckert wrote:
> One thing that just occurred to me is that the TARGET scope can be implemented with a group of WORDLISTs, not just one. You could have VOCABULARY, MODULE, etc. work on this group. TARGET would plop the group into the search order. Maybe TARGET FORTH would start you off with the basic target visibility and then you could dig down from there.
>
> Search order scoping is one of the things I miss in embedded Forths. There might be other things you can think of.

I don't know what you are talking about here. None of this stuff makes sense to me. I think you are over-complicating cross-compilation because you don't know how it works.

MFX was written in UR/Forth that was Forth-83 and had the traditional vocabulary system with CONTEXT and CURRENT --- that worked fine --- there was no need for the wordlist stack that ANS-Forth has.

The only limitation is that in MFX the TARG application code could not have vocabularies. This seemed unimportant to me --- the only program I've ever written that used vocabularies was MFX --- I've never needed vocabularies in application code.

As for modules, I did upgrade UR/Forth to do that. I could mark a word as being local to a module with LOCAL that was executed after the word definition (it set a smudge-ready flag in the word's header). I also had END-MODULE that searched through the entire dictionary and if it found a word with the smudge-ready flag set, it would set the smudge flag and unset the smudge-ready flag. So, in a file I would mark all of the words that wanted available only within the file with LOCAL and I would put END-MODULE at the end of the file to smudge them all. This reduced namespace pollution a lot. This also made the source-code more readable because the reader would know which words were intended to be used outside of the module (these are the API for the module) and which words were used internally within the module (these he could ignore).

Modules don't have anything to do with cross-compiling. I only implemented modules because MFX was a big program with many files, and making files into modules helps to simplify big programs --- I would have implemented modules for any big program that I was writing.

[Elizabeth D. Rather]

The major conflicts in developing Forth94 were between the
small/simple/classical system purists (predominantly the Boston FIG
group) and the big systen "Forth ought to do everything every other
language can do" contingent. There was also a "Forth83 was perfect"
contingent. The middle ground was occupied by folks such as FORTH, Inc.
and MPE who were (and are) are less interested in theoretical issues
than in getting applications written for our clients and improving their
confidence that these applications will be maintainable and not trashed
by a totally re-written standard.

It's important to understand that standards exist for application
writers, not system developers. An individual system developer is always
free to do whatever; what remains to be seen is whether others adopt
that technology. Companies whose lives depend upon developed
applications that they are dependent upon require that these
applications are written in standardized languages, so that there will
be a market of programmers to help maintain them over the years. They
are far more interested in stability than in innovation and cute
features. These are the markets that MPE and FORTH, Inc. are dependent
upon. As we are continually involved in writing and maintaining
applications for these clients, we identify what application needs there
and develop solutions. We are less interested in theoretical things
(*this language* has *this* feature, how can we do this in Forth?) than
"*this feature* was necessary in the last <n> projects we worked on, so
we should standardize it."

Chuck and the GreenArrays folks have a completely different set of
desiderata from any of the above.

[Anton Ertl]

Brad Eckert <hwf...@gmail.com> writes:
>It's interesting that the biggest ANS opponents were the Forth hardware guy=
>s. It's as if ANS was geared to use all four flags in CPUs designed to run =
>C code: Overflow, Carry, Minus and Zero. Of course all architectures going =
>forward have to support C, so that was the main target of ANS. So, : < - 0<=

> ; is nonstandard in one case that will probably never happen in practice.

C code does not need these flags, and indeed, architectures like Alpha
have been designed for C that do not have these flags. They seem to
be a pretty useful result of common ALU designs, although apparently
not compelling enough to design them into every architecture. Apart
from Alpha, MIPS does not have them, and in particular, at best you
can trap on overflow in Alpha and the original MIPS (recently MIPS has
acquired a way to test for overflow without incurring a trap or
long-winded computations). There is no carry flag at all in these
architectures, but you can work around that relatively cheaply.

Anyway, programming languages, including C and Forth normally don't
make flags explicit, so architectures have quite a lot of freedom in
their design in this area. And given that standard Forth runs on
Alpha, MIPS, PowerPC (which also deviates from the NZCV scheme), and
IA-64 (another deviation), it is obviously not limited to
architectures with these flags. Sure, someone designed +LOOP too
cleverly to make use of the oVerflow flag, and you need a few extra
instructions on Alpha and classical MIPS for that, but that's small
change.

As for the circular comparison

: < - 0< ;

that's not any more efficient than the standard Forth (since Forth-79,
although with 0/1 instead of 0/-1 in Forth-83...2012) pair of < and
U<, on either Alpha, MIPS, PowerPC, or IA-64 (I think it takes an
additional instruction on IA-64). What circular comparison gives us
is having just one less-than instead of two.

As for the difference not happening in practice, I am pretty sure that
it does happen, especially with smaller cell sizes, or they would not
have standardized on two less-than words rather than one in Forth-79
when memory was at a premium. But you can check it yourself, by
defining < and u< to do both the standard and the circular comparison,
and reporting the cases when the results differ.

>But now that the dust has settled, what are the most popular objections to =

>the ANS way of doing things?

1) It's too big for the smallest systems, and includes features that
are not needed for these systems.

2) It does not contain certain features the objector considers important.

3) It's too loosely defined.

4) It's too tightly defined (e.g., : < - 0< ; is not a standard
implementation of < :-)

5) Chuck Moore stopped participating in Forth-94 and does not see much
value in any standard.

The cool thing is that 1 and 2 often come from the same person, as
well as 3 and 4. Moreover, between the objectors, the perceived sets
of missing and superfluous features usually don't have that much
overlap, as well as the areas where the standard is too tightly or too
loosely specified in their opinion. In those cases where many people
agree on such issues, one can standardize them (however,
de-standardizing is something that is not done lightly, and takes a
lot of time).

Concerning reason 5, that's a good reason to do your own thing, just
like Chuck Moore, and the implementors of a number of non-standard
systems. Note that these system implementors generally don't waste
any time objecting to the standard; they don't need it, so they also
don't object to it.

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

[Andrew Haley]

Brad Eckert <hwf...@gmail.com> wrote:

> But now that the dust has settled, what are the most popular
> objections to the ANS way of doing things?

I don't know about "popular", but from what I can remember:

The semantics of DO ... +LOOP are bewildering. This was inherited from
Forth-83.

The distinction between "immediacy" and "special compilation
semantics" still causes confusion, and from time to time there is an
effort to sort it out.

It seems that words such as S" (in the FILE wordset) and TO can't be
implemented in a strictly-correct way as STATE-smart IMMEDIATE words.
TO can't be POSTPONEd or COMPILEd, so can't easily be used as a
factor. All of this is something of a mess. In hindsight it would
have been better if there were no state-smart (more formally, "words
with interpretation semantics and non-default compilation semantics")
words in the standard system. But I am of the [unpopular] opinion
that STATE should not exist at all, or perhaps that if it exists it
should be an internal detail of the system. So it's probably just me.

It's not entirely clear that a text interpreter can be written in
Standard Forth, for reasons discussed at length here. In practice
this isn't a problem, so it's perhaps not worth mentioning.

The floating-point wordset is lacking some conveniences which many
systems supply: there's no floating-point PICK, or LOCAL, or >R.

But all of these things are fairly minor.

Andrew.

[HAA]

Elizabeth D. Rather wrote:
> ...

> The middle ground was occupied by folks such as FORTH, Inc.
> and MPE who were (and are) are less interested in theoretical issues
> than in getting applications written for our clients and improving their
> confidence that these applications will be maintainable and not trashed
> by a totally re-written standard.
>
> It's important to understand that standards exist for application
> writers, not system developers. An individual system developer is always
> free to do whatever; what remains to be seen is whether others adopt
> that technology. Companies whose lives depend upon developed
> applications that they are dependent upon require that these
> applications are written in standardized languages, so that there will
> be a market of programmers to help maintain them over the years. They
> are far more interested in stability than in innovation and cute
> features. These are the markets that MPE and FORTH, Inc. are dependent
> upon. As we are continually involved in writing and maintaining
> applications for these clients, we identify what application needs there
> and develop solutions. We are less interested in theoretical things
> (*this language* has *this* feature, how can we do this in Forth?) than
> "*this feature* was necessary in the last <n> projects we worked on, so
> we should standardize it."

Compare the above with that below from a couple weeks ago. It's amazing
what a bit of emphasis can do.

Elizabeth D. Rather wrote:
>
> The "Forth Community" has always been a strong consideration, including
> not only professional vendors like FORTH, Inc. and MPE (who have
> collaborated on projects and have never been hostile competitors) but
> also implementer of systems in widespread use such as GForth and
> Win32Forth and FIG back in the day, not to mention Open Firmware, which
> contributed several great concepts to ANS Forth. Experience and a user
> base count for a lot. Individual bright ideas are a good thing, but as
> candidates for standardization they become more valuable when they have
> been shared and picked up by others and developed a body of users.

[Roelf Toxopeus]

MacForth was the first resident Mac development system which didn't need
the Lisa to program the Mac.

AFAIK MacForth was indirect threaded using tokens and not using
subroutines/etc. till the mpve from 68000 to PPC. Ward McFarland and
Doug Hoffman might elaborate on this.

Native/subroutine/peephole/etc/ commercial Forth systems for the 68000
platforms Mac, Amiga and Atari were Mach2 and jForth. An article in
Dr.Dobb's Journal, October 1987: "A Fast Forth for the 68000" by Lori
Chavez (Palo Alto Shipping Co.) describes Mach2 code generation.

Jack Woehr and Phil Burk among others can tell you everything about
Amiga's jForth.

And yes non of these Forth systems were 79 or 83 compliant of course.
ANS Forth was/is very nice to these systems.

A lot of subroutine/native Forth systems were developed and explored on
the 68000 during the 1980ies. Some can be found in Dr.Dobb's Toolbook of
Forth and Forth Dimensions. And don't forget Bernd Paysan !!

I should know, I was there and still am ...

[Brad Eckert]

On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote:
> Brad Eckert <hwf...@gmail.com> wrote:
>
> > But now that the dust has settled, what are the most popular
> > objections to the ANS way of doing things?
>
> I don't know about "popular", but from what I can remember:
>
> The semantics of DO ... +LOOP are bewildering. This was inherited from
> Forth-83.

That's why I rarely use +LOOP. Inefficiency, and it creates more work the next time I implement it.

I use a FOR NEXT structure for simple loops that do something 0 or more times. A quick SEE of my current Forth:

: dt_typec ( $a --) countc for countc emit next drop ;
see dt_typec
31D COUNTC 1- MBRAN 7
321 >R COUNTC EMIT R> BRAN -A
328 DROP DROP EXIT

FOR compiles the "1- MBRAN 7 >R"
NEXT compiles the "R> BRAN -A DROP"
It's done this way so R@ can get the loop count.
All of these are 8-bit tokens for a VM, although they are sometimes Forth CPU instructions. MBRAN is a non-swallowing "branch if <0" instruction.

>
> But I am of the [unpopular] opinion
> that STATE should not exist at all, or perhaps that if it exists it
> should be an internal detail of the system. So it's probably just me.

Are there any papers on STATEless Forths? I think search order manipulation could handle the different semantics, but has it been tried?

I'm not sure colorForth is stateless. The state is specified in each word. Unfortunately, the idea is dependent on having an editor that people like as much as the impressive array of text editors already existing.

> It's not entirely clear that a text interpreter can be written in
> Standard Forth, for reasons discussed at length here. In practice
> this isn't a problem, so it's perhaps not worth mentioning.

Come to think of it, modifying the interpreter in a nonstandard way is mostly a cut-n-paste job. Much easier than trying to do it in a standard way.

[Paul Rubin]

Brad Eckert <hwf...@gmail.com> writes:
> Are there any papers on STATEless Forths? I think search order
> manipulation could handle the different semantics, but has it been
> tried?

I thought that's what cmForth was.

[humptydumpty]

On Saturday, July 23, 2016 at 8:43:26 PM UTC+3, Brad Eckert wrote:
> On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote:

Hi!

> Are there any papers on STATEless Forths? I think search order manipulation could handle the different semantics, but has it been tried?

Maybe FreeForth? http://christophe.lavarenne.free.fr/ff/

Have nice day,
humptydumpty

[Pablo Hugo Reda]

> I'm not sure colorForth is stateless. The state is specified in each word. Unfortunately, the idea is dependent on having an editor that people like as much as the impressive array of text editors already existing.

My forth not have state, not compiling or execution diference, ColorForth have macro word but only for optimization i guess, really not have state too.

[HAA]

Brad Eckert wrote:
> On Thursday, July 21, 2016 at 7:09:46 AM UTC-7, Chris Curl wrote:
> > As you folks may remember, I am implementing my own little Forth.
> >
> > I have implemented two flavors of the memory organization, one where
> > the code and dictionary start at opposite ends of the memory space and
> > grow towards each other, and one where the dictionary entries are interspersed
> > with the code.
> >
> If header space is separate from code space, you can possibly do things like:
>
> : place ( a u dest -) 0 over c! [
> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ;

I have but the benefit is questionable. When primitives are involved you
may be saving space at the cost of efficiency e.g. PLACE needs overlap
checking whereas +PLACE does not.

> Also, the code is smaller so you have fewer cache misses. As processors get faster, it
> seems cache misses get more expensive. That's why small virtual machines sometimes beat
> native code implementations. The VM fits in cache.
>
> You also have the option of discarding the header space, such as when creating a ROM
> image for an embedded system.

Unless you can discard the compiler, separated heads don't offer much IMO.
An exception is segmented architectures like the 8086 where putting heads
in their own segment meant more room for code.

[Andrew Haley]

Brad Eckert <hwf...@gmail.com> wrote:
> On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote:
>> Brad Eckert <hwf...@gmail.com> wrote:
>>
>> > But now that the dust has settled, what are the most popular
>> > objections to the ANS way of doing things?
>>

>> But I am of the [unpopular] opinion that STATE should not exist at
>> all, or perhaps that if it exists it should be an internal detail
>> of the system. So it's probably just me.
>
> Are there any papers on STATEless Forths? I think search order
> manipulation could handle the different semantics, but has it been
> tried?

There's no need to change the search order: the compiler and
interpreter are different programs rather than interleaved, so there's
no need to maintain any STATE because it's implicit in whichever word
is running. IMMEDIATE still exists.

Andrew.

[miss...@gmail.com]

On Sunday, July 24, 2016 at 4:33:48 AM UTC-4, Andrew Haley wrote:

I don't follow this statement. In my system, "DUP" is an immediate word. It
looks to see if a word is being compile, and if so, it generates the appropriate
code into the definition. If not, it actually performs the DUP right then.
I suppose this is just how I implemented that optimization, and there are
certainly other ways to skin that cat ...

: DUP
?COMPILING
IF
<asm> CPUSH opDUP </asm> C, <asm> RET </asm>
ELSE
<asm> opDUP </asm>
THEN ; IMMEDIATE

[Brad Eckert]

On Saturday, July 23, 2016 at 8:14:11 PM UTC-7, HAA wrote:

> Brad Eckert wrote:
>> If header space is separate from code space, you can possibly do
>> things like:
>>
>> : place ( a u dest -) 0 over c! [
>> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ;
>
> I have but the benefit is questionable. When primitives are involved you
> may be saving space at the cost of efficiency e.g. PLACE needs overlap
> checking whereas +PLACE does not.
>

I just thought of ;: for multiple entry points. In a mixed dictionary, ;: can compile a branch over the header data. Or in my example above,
: ;: postpone [ : ;

[Brad Eckert]

On Sunday, July 24, 2016 at 1:33:48 AM UTC-7, Andrew Haley wrote:
> There's no need to change the search order: the compiler and
> interpreter are different programs rather than interleaved, so there's
> no need to maintain any STATE because it's implicit in whichever word
> is running. IMMEDIATE still exists.
>

That's interesting. So, [ calls the interpreter and ] exits it. The compiler checks each word's IMMEDIATE flag as usual.

My main concern would be for code written in this dialect of Forth to run on an ANS system with the addition of possibly a small harness.

[hughag...@gmail.com]

It doesn't matter which way is done internally. You can have the compiler and interpreter be distinct, or combine them together and have them use STATE --- either way is a reasonable implementation --- they are about equally complex, so it doesn't really matter which you use.

The problem is not that STATE exists --- the problem is that STATE is exposed to the user, which allows the user to write STATE-smart words --- you can have the combined compiler/interpreter that uses STATE and this is not a problem so long as the user doesn't have access to STATE and doesn't write STATE-smart words.

Even if you have the distinct compiler and interpreter, a STATE-smart could still be written --- it would be immediate and it would look at the return-address on the return-stack with R@ to find out if it was called by the compiler or the interpreter, effectively determining what STATE is, although STATE doesn't actually exist and this is supposedly a STATEless system --- the only way to prevent this, is by making the return-address inaccessible with R@, but then you can't have rquotations.

There is no such thing as a fool-proof system!

[Elizabeth D. Rather]

Works fine. polyFORTH operated this way. STATE only returned to FORTH,
Inc. systems in order to comply with ANS Forth. The rationale for STATE
is mainly to enable STATE-smart user words, which many people are fond of.

[hughag...@gmail.com]

On Friday, July 22, 2016 at 11:40:25 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/22/16 7:00 PM, Brad Eckert wrote:
> > On Friday, July 22, 2016 at 8:36:40 PM UTC-7, Elizabeth D. Rather wrote:
> >>
> >> Indeed, MacForth was an outstanding, and in some ways groundbreaking,
> >> Forth. But it was not Forth83 compatible, and suffered some in the
> >> marketplace for that reason. Don Colburn was an enthusiastic participant
> >> in the development of ANS Forth, and delighted to be able to offer a
> >> *Standard* version of MacForth with all its nice features. The version
> >> of locals adopted for Forth94 came from MacForth.
> >>
> > It's interesting that the biggest ANS opponents were the Forth hardware guys. It's as if ANS was geared to use all four flags in CPUs designed to run C code: Overflow, Carry, Minus and Zero. Of course all architectures going forward have to support C, so that was the main target of ANS. So, : < - 0< ; is nonstandard in one case that will probably never happen in practice.
> >
> > For all the arm waving, I never saw a compelling example of what's so wrong with ANS. I think the biggest objection is the limited access to the compiler internals, which forces you to write your own QUIT loop to do much customization of the interpreter. But the facilities are there to do that. The TC had the job of parsing out religious issues from technical issues. The 2012 standard revisited locals and other things that couldn't reach a consensus in 1994.
> >
> > But now that the dust has settled, what are the most popular objections to the ANS way of doing things?
>
> The major conflicts in developing Forth94 were between the
> small/simple/classical system purists (predominantly the Boston FIG
> group) and the big systen "Forth ought to do everything every other
> language can do" contingent. There was also a "Forth83 was perfect"
> contingent.

The debate is not between whether we should have fewer features or more features, the debate is between whether we should design the features in an intelligent way or whether we should design the features in a stupid way.

You screwed up the design of *all* the features in ANS-Forth! The locals were completely screwed up. Your ANS-Forth is also rife with ambiguity --- you routinely standardized two features that were incompatible with each other.

You are a sales-person --- all sales-people are stupid --- you are stupid!

> The middle ground was occupied by folks such as FORTH, Inc.
> and MPE who were (and are) are less interested in theoretical issues
> than in getting applications written for our clients and improving their
> confidence that these applications will be maintainable and not trashed
> by a totally re-written standard.

This isn't true either. If writing applications is important, then you need to have a compiler to compile those applications. ANS-Forth was sent to ANSI in 1994 without any ANS-Forth compiler being written. It would not be until 1997 that the first ANS-Forth compiler, SwiftForth, came out. SwiftForth was a bug-ridden mess and was not suitable for professional programming due to the bugs.

It is laughable that you say that your goal was to improve the confidence of your clients --- nobody has any confidence that Forth Inc. can succeed at writing any program --- that was true in 1994 and continues to be true today.

[hughag...@gmail.com]

On Sunday, July 24, 2016 at 3:43:14 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/24/16 10:06 AM, Brad Eckert wrote:
> > On Sunday, July 24, 2016 at 1:33:48 AM UTC-7, Andrew Haley wrote:
> >> There's no need to change the search order: the compiler and
> >> interpreter are different programs rather than interleaved, so there's
> >> no need to maintain any STATE because it's implicit in whichever word
> >> is running. IMMEDIATE still exists.
> >>
> > That's interesting. So, [ calls the interpreter and ] exits it. The compiler checks each word's IMMEDIATE flag as usual.
> >
> > My main concern would be for code written in this dialect of Forth to run on an ANS system with the addition of possibly a small harness.
>
> Works fine. polyFORTH operated this way. STATE only returned to FORTH,
> Inc. systems in order to comply with ANS Forth. The rationale for STATE
> is mainly to enable STATE-smart user words, which many people are fond of.

Encouraging people to write STATE-smart user words was one of the many screw-ups of ANS-Forth.

ANS-Forth was built on compromises. Everybody wanted to be Standard, so you just said okay, everybody is standard --- this includes the people who do stupid things such as write STATE-smart words.

All you cared about was getting ANS-Forth ratified by ANSI so you could declare yourself to be the person who defines what Forth is for the entire Forth community. ANS-Forth was never anything other than a marketing gimmick from Forth Inc. --- ANS-Forth makes no sense from a technical standpoint --- ANS-Forth was written by an idiot sales-person who has never written a Forth program in her life.

[miss...@gmail.com]

On Sunday, July 24, 2016 at 6:48:37 PM UTC-4, hughag...@gmail.com wrote:
> The debate is not between whether we should have fewer features or more features, the debate is between whether we should design the features in an intelligent way or whether we should design the features in a stupid way.
>
> You screwed up the design of *all* the features in ANS-Forth! The locals were completely screwed up. Your ANS-Forth is also rife with ambiguity --- you routinely standardized two features that were incompatible with each other.
>
> You are a sales-person --- all sales-people are stupid --- you are stupid!
>

> This isn't true either. If writing applications is important, then you need to have a compiler to compile those applications. ANS-Forth was sent to ANSI in 1994 without any ANS-Forth compiler being written. It would not be until 1997 that the first ANS-Forth compiler, SwiftForth, came out. SwiftForth was a bug-ridden mess and was not suitable for professional programming due to the bugs.
>
> It is laughable that you say that your goal was to improve the confidence of your clients --- nobody has any confidence that Forth Inc. can succeed at writing any program --- that was true in 1994 and continues to be true today.

Hugh, do you realize that the only thing your rants do is tuen off people
like me? Your constant bashing of Elizabeth does not help anything, and it
certainly is off topic for this thread.

We all get it that you have a big problem with the positions taken by the ANS Forth committee, and you blame Elizabeth for much of it. How many years have
to go by before you put it behind you?

[rickman]

I guess I'm as guilty as anyone as I don't always resist the impulse to
respond to Hugh. But I can assure you it is pointless. He genuinely
has no idea of how crazy he sounds. He doesn't understand his actions
are absurd. He is powerless to control his compulsion to rant and rave.

Nothing any of us can do will help Hugh. We can help ourselves by not
responding to him. However, that isn't going to happen.

--

Rick C

[Brad Eckert]

On Sunday, July 24, 2016 at 4:31:40 PM UTC-7, rickman wrote:
>
> Nothing any of us can do will help Hugh. We can help ourselves by not
> responding to him. However, that isn't going to happen.
>

It seems most readers are pretty tolerant of Hugh's unique way of processing reality.

[hughag...@gmail.com]

On Sunday, July 24, 2016 at 4:04:52 PM UTC-7, miss...@gmail.com wrote:
> Hugh, do you realize that the only thing your rants do is tuen off people
> like me? Your constant bashing of Elizabeth does not help anything, and it
> certainly is off topic for this thread.
>
> We all get it that you have a big problem with the positions taken by the ANS Forth committee, and you blame Elizabeth for much of it. How many years have
> to go by before you put it behind you?

When you say, "put it behind you," you mean that I should just give up and become one of Elizabeth Rather's sycophants --- start sucking and learn to like it --- I'm never going to do that!

I know you will say that you aren't a sycophant, but that isn't really true. You complain that I'm off topic, but you don't complain that Elizabeth Rather is off topic. Look at what Elizabeth Rather said that your were okay with:

On Friday, July 22, 2016 at 11:40:25 PM UTC-7, Elizabeth D. Rather wrote:
> The middle ground was occupied by folks such as FORTH, Inc.
> and MPE who were (and are) are less interested in theoretical issues
> than in getting applications written for our clients and improving their
> confidence that these applications will be maintainable and not trashed
> by a totally re-written standard.
>

> It's important to understand that standards exist for application
> writers, not system developers. An individual system developer is always
> free to do whatever; what remains to be seen is whether others adopt
> that technology. Companies whose lives depend upon developed
> applications that they are dependent upon require that these
> applications are written in standardized languages, so that there will
> be a market of programmers to help maintain them over the years. They
> are far more interested in stability than in innovation and cute
> features. These are the markets that MPE and FORTH, Inc. are dependent
> upon. As we are continually involved in writing and maintaining
> applications for these clients, we identify what application needs there
> and develop solutions. We are less interested in theoretical things
> (*this language* has *this* feature, how can we do this in Forth?) than
> "*this feature* was necessary in the last <n> projects we worked on, so
> we should standardize it."

This is just meaningless sales blather --- she is saying that only Forth Inc. and MPE were interested in writing application programs --- really???

This isn't true anyway. ANS-Forth wasn't designed for writing application programs. ANS-Forth was purposely crippled to prevent application programs from being written --- all of the Forth community would be relegated to programming in ANS-Forth in gForth which has never been used for professional programming and never will --- to become professional programmers, they have to abandon ANS-Forth and go non-standard (that is what MPE does in every professional program that MPE writes).

I know that you think you can work within Forth-200x to improve ANS-Forth. This is not true either. I have said many times that a cross-compiler needs to be able to examine an xt and determine the word's attributes (which vocabulary is it in?, is it immediate or not?, is it smudged or not?, is it smudge-ready or not?), and also to change these attributes --- this is actually trivial to implement --- Forth-200x refuses to do this because they want to prevent the Forth community from writing cross-compilers in competition with Forth Inc. and MPE.

Elizabeth Rather said that her goal was to have: "a market of programmers to help maintain [legacy programs at Forth Inc. and MPE] over the years." ANS-Forth was purposely crippled to so that it would only support toy programs (what Anton Ertl's students write) and would not support professional programming. If you become an ANS-Forth programmer though, then you learn ultra-basic concepts (what is taught in "Starting Forth") and you become qualified to maybe work as a maintenance programmer at Forth Inc. or MPE --- those legacy programs aren't actually ANS-Forth though, so you will have to learn a lot of vendor-specific features that were used in the programs --- as an ANS-Forth programmer however you will never write professional programs (not Forth Inc. or MPE or anybody else has ever written a professional program in ANS-Forth).

The topic of this thread is code and data separation. Since you seem to want to be stay on-topic, lets go with that. Here is what Stephen Pelc says on the subject (section 21.9.1 of the VFX manual):
"CPUs from the Pentium 3 onwards have serious performance problems when data is close to code, leading to a wide variation in performance depending on data location."

Later on we have section 21.9.3 with the ominous heading: "Gotchas." This says:
-------------------------------------------------------------------------
When +IDATA is in use, standard defining words such as VARIABLE and VALUE will reserve space
in the IDATA areas, but ALLOT still reserves space in the dictionary. Consequently code such as:
VARIABLE <name> <size> ALLOT
will break when +IDATA is active. Use:
<size> BUFFER: <name>
for all such allocations.
Words such as >BODY and BODY> will not work correctly on words whose data area is in an
IDATA region.
-------------------------------------------------------------------------

Essentially what this means is that ANS-Forth can't work in a system that separates code and data, because it typically won't work. So, ANS-Forth screwed up by allowing code and data to be intermixed --- there is no way to smooth this over --- it is just a screw-up typical of what you get when you put somebody in charge who doesn't know assembly-language.

ANS-Forth was built on compromises. Back in 1994 Stephen Pelc knew that code and data needed to be separated (this is basic assembly-language programming that everybody knows). He wanted to be ANS-Forth compliant, so Elizabeth Rather said fine, separating code and data is ANS-Forth. Forth Inc. however had code and data intermixed (and continues to do so today), so she said that this is is also ANS-Forth compliant. Everybody gets to be ANS-Forth compliant! The only problem is that (as Stephen Pelc admits in the VFX manual as quoted above) ANS-Forth code won't run on a Forth system that has code and data separated --- a lot of code that runs on SwiftForth will fail on VFX unless this feature is turned off with the -IDATA switch --- so, anybody who wants to write portable code has to assume the worst-case scenario (invariable, this means assuming SwiftForth, because SwiftForth is always the worst-case).

Stephen Pelc is fine with this situation. He wants people to just buy VFX and write code that is VFX-specific (the +IDATA switch is the default in VFX) and forget about porting their programs to other ANS-Forth compilers. So, how is this different from not having a standard at all? What exactly was accomplished by Elizabeth Rather in 1994?

[rickman]

I think this serves as installment 2 of Hugh's manifesto.

--

Rick C

[hughag...@gmail.com]

On Sunday, July 24, 2016 at 6:27:29 PM UTC-7, rickman wrote:
> On 7/24/2016 8:54 PM, hughag...@gmail.com wrote:
> > On Sunday, July 24, 2016 at 4:04:52 PM UTC-7, miss...@gmail.com wrote:
> >> Your constant bashing of Elizabeth does not help anything, and it
> >> certainly is off topic for this thread.
>

> I think this serves as installment 2 of Hugh's manifesto.

Why do you complain that my constant bashing of Elizabeth does not help anything and is off topic --- but you don't complain that Rickman's constant talk about a "manifesto" does not help anything and is off topic?

Somewhat of a double-standard there, don't you think?

[rickman]

No, a single standard applied to all, but one that you are not capable
of understanding.

I really and truly feel sorry for you. I'm sorry that you live the life
you do and will never get help. I can't imagine what it's like to feel
so persecuted as you.

There are *lots* of off topic posts in this group. But most are sane.
The complaint was that your post was obnoxious. The mention of it being
off topic was secondary. But you are not capable of understanding any
of that, are you?

--

Rick C

[Chris Curl]

Hugh,

Yes, perhaps other posts are not perfectly on topic, but at least they are
not personal attacks. That is where I draw the line.

Your rants against Elizabeth seem to be in every thread where Elizabeth posts,
and they are very personal and hateful. They inject an element of toxicity
into the thread, and I will call it out when it happens in my threads.

And if you think I'm a sycophant, then you clearly don't know what a
sycophant is. One can be polite and courteous without being a sycophant.

[Elizabeth D. Rather]

On 7/24/16 3:27 PM, rickman wrote:
> I think this serves as installment 2 of Hugh's manifesto.

It really would be a service to the community to avoid quoting all this
trash. Many of us have Hugh in the kill file to avoid the unpleasantness.

[hughag...@gmail.com]

On Sunday, July 24, 2016 at 8:48:43 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/24/16 3:27 PM, rickman wrote:
> > I think this serves as installment 2 of Hugh's manifesto.
>
> It really would be a service to the community to avoid quoting all this
> trash. Many of us have Hugh in the kill file to avoid the unpleasantness.

What you snipped was a quote from Stephen Pelc in his VFX manual. Are you saying that Stephen Pelc's words are trash? This is what Stephen Pelc said:
"CPUs from the Pentium 3 onwards have serious performance problems when data is close to code, leading to a wide variation in performance depending on data location."

By comparison, this is what you said on the subject:

On Thursday, July 21, 2016 at 3:40:35 PM UTC-7, Elizabeth D. Rather wrote:
> An integrated code/data space dictionary is simpler to create and
> maintain, and results in less implementation code and modestly better
> compilation performance.

On Thursday, July 21, 2016 at 6:57:41 PM UTC-7, Elizabeth D. Rather wrote:
> In a resident system, the advantage of
> segregating the headers from the code is unclear to me.

I think that SwiftForth has combined code and data because SwiftForth is really just a port of an old Forth system that Charles Moore wrote in the 1970s for the PDP-11 for which separating code and data wasn't an issue. Forth Inc. doesn't employ programmers who are capable of writing new software --- your "programmers" just maintain software written by Charles Moore --- you have been keeping this old code going for about 40 years now.

If it was just a matter of SwiftForth being low-quality, I wouldn't care. The problem however is that you want to impose your ignorance on the entire Forth community by declaring that the bugs in SwiftForth are the Standard for Forth and that every Forth system must have the same bugs as SwiftForth or they will be non-standard.

ANS-Forth is full of bad design decisions. All of these bad design decisions originated in Forth Inc. systems, but you were the chair-person of the ANS-Forth committee so you required Forth Inc. systems to be ANS-Forth compliant without any modification whatsoever, so all of these bugs got written in stone and imposed on the entire Forth community. Most of these bugs are grossly obvious --- Stephen Pelc is hardly the only assembly-language programmer who knows that code and data need to be separated to avoid cache conflicts --- you are the only person who doesn't know this.

People make themselves look foolish by using ANS-Forth because they are required to embrace bugs as their standard --- they come off appearing to be ignorant of even first-year programming concepts --- ANS-Forth is ignored by essentially everybody (including Stephen Pelc) because nobody wants to look dumb.

[hughag...@gmail.com]

If Elizabeth Rather just stuck to selling SwiftForth, then I would be polite and courteous to her. The world is full of sales-people selling low-quality products which they claim is high-quality --- I don't argue with them or point out the flaws in their product --- I just ignore them.

When Elizabeth Rather declares that she alone decides what Forth is, I consider that to be a personal attack on me --- why should I be polite and courteous when insulted in such a way? --- I'm going to continue to point out the problems with SwiftForth and ANS-Forth (which are essentially the same thing).

If you allow Elizabeth Rather to declare herself to be your "leading expert" and tell you that she alone (not you) has a right to define what Forth is, then you are being a sycophant.

I guarantee you that if you come out with a Forth system that does not have all of SwiftForth's bugs, Elizabeth Rather will dismiss your Forth system as being non-standard --- you hope that by being "polite and courteous" to her, you can induce her to be nice to you and say that your Forth system is Forth --- you are deluding yourself; she will say that it is non-standard, and hence not Forth at all (then you'll be the victim of a "personal attack" but it will be too late to complain because you have already supported her in saying that I'm not a Forth programmer).

From Elizabeth Rather's point of view, the whole point of having a Standard is so she can tell the competition that they are non-standard. You and your Forth are the competition. What part of this is not obvious???

[Julian Fondren]

On Monday, July 25, 2016 at 1:32:33 AM UTC-5, hughag...@gmail.com wrote:
> When Elizabeth Rather declares that she alone decides what Forth is, I consider that to be a personal attack on me

The standard is ignored by everybody.
... but the standard's faults are a big problem for Forth
... and it would be devastating for a system to be determined to
not be standard.

#JustHughThings

Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth
(would "be polite and courteous" to her) if only she hadn't
declared, in some feverish delusion of Hugh's, to be the sole
arbiter of Forth.

Well, that's water under the bridge. Even if she apologized,
somehow, for what the delusion said, probably the delusion would
just go on to say more things to justify renewed attacks on her.


BTW, Hugh, I don't particularly dislike you. A solid 15% of what
you say is worth reading. When I said that you were insane, I only
meant that you were insane. I don't use labels only to communicate
"bad dog!" or "good dog!", the way leftists use them. These days
I'm only annoyed when someone takes your rantings seriously -- and
mostly at that person. Like, read the air of the room better. The
worst is when such people ask Elizabeth to engage you to resolve the
'dispute'. I say this because you seemed to have been a bit
confused by my last on post on this matter.


-- Julian

[Elizabeth D. Rather]

On 7/24/16 9:30 PM, Julian Fondren wrote:

> Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth
> (would "be polite and courteous" to her) if only she hadn't
> declared, in some feverish delusion of Hugh's, to be the sole
> arbiter of Forth.

Which, exactly, feverish delusion of Hugh's was that, Julian? There have
been so many.

[Julian Fondren]

On Monday, July 25, 2016 at 2:36:38 AM UTC-5, Elizabeth D. Rather wrote:
> On 7/24/16 9:30 PM, Julian Fondren wrote:
>
> > Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth
> > (would "be polite and courteous" to her) if only she hadn't
> > declared, in some feverish delusion of Hugh's, to be the sole
> > arbiter of Forth.
>
> Which, exactly, feverish delusion of Hugh's was that, Julian? There have
> been so many.

According to pattern, Hugh will link to a thread, or even directly
quote from the thread, and then declare victory. There's no actual
need for the thread or his quote to support his claims. He'll just
say that it does :p

[HAA]

It's a good name. While the resulting coding style takes getting used to,
a reader can't but help notice PLACE is dependent upon +PLACE.

OTOH I have the same problem with multiple entry points as quotations.
It's hard to find enough compelling cases to justify their use ... unlike say
+string which has everyday uses e.g. : +place count +string swap 1- c! ;

[Elizabeth D. Rather]

Historical note: ;: was Chuck's original name for the structure which
for many years now has been CREATE DOES> (by separating the creation
from the instance behaviors you get more flexibility).

[Andrew Haley]

miss...@gmail.com wrote:
> On Sunday, July 24, 2016 at 4:33:48 AM UTC-4, Andrew Haley wrote:
>> Brad Eckert <hwf..@gmail.com> wrote:
>> > On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote:
>> >> Brad Eckert <hwf...@gmail.com> wrote:
>> >>
>> >> > But now that the dust has settled, what are the most popular
>> >> > objections to the ANS way of doing things?
>> >>
>> >> But I am of the [unpopular] opinion that STATE should not exist at
>> >> all, or perhaps that if it exists it should be an internal detail
>> >> of the system. So it's probably just me.
>> >
>> > Are there any papers on STATEless Forths? I think search order
>> > manipulation could handle the different semantics, but has it been
>> > tried?
>>
>> There's no need to change the search order: the compiler and
>> interpreter are different programs rather than interleaved, so there's
>> no need to maintain any STATE because it's implicit in whichever word
>> is running. IMMEDIATE still exists.
>

> I don't follow this statement. In my system, "DUP" is an immediate word.

So, DUP has to be STATE-smart in your system.

Let me be absolutely clear what I mean by STATEless Forth: there is no
word which has non-default compilation semantics and interpretation
semantics.

> It looks to see if a word is being compile, and if so, it generates
> the appropriate code into the definition. If not, it actually
> performs the DUP right then. I suppose this is just how I
> implemented that optimization, and there are certainly other ways to
> skin that cat ...

There are many. You don't have to do it that way: you could have a
smart COMPILE, which performs the appropriate optimizations on
primitives without needing STATE-smartness. Or you could tokenize the
whole word, processing IMMEDIATE words etc along the way, and then
make a pass over it to do any optimization. Or arrange the compiler
as a pipeline which passes tokens to an optimizer. Or use dual-cfa
words, but that has its own problems.

Andrew.

[Andrew Haley]

Brad Eckert <hwf...@gmail.com> wrote:
> On Sunday, July 24, 2016 at 1:33:48 AM UTC-7, Andrew Haley wrote:
>> There's no need to change the search order: the compiler and
>> interpreter are different programs rather than interleaved, so there's
>> no need to maintain any STATE because it's implicit in whichever word
>> is running. IMMEDIATE still exists.
>>
> That's interesting. So, [ calls the interpreter and ] exits it. The
> compiler checks each word's IMMEDIATE flag as usual.

Right.

> My main concern would be for code written in this dialect of Forth
> to run on an ANS system with the addition of possibly a small
> harness.

It's not compatible with Standard Forth. It might be possible to make
it work with a small harness, but it'd bae ticky to figure that out.
In any case, it's not really necessary to do that: almost all of the
evils of a STATEful Forth can be avoided simply by not using STATE.
But even STATE-smartness, if you *must* use it, isn't a huge problem
as long as both behaviours of a STATE-smart word are provided as
factors.

Andrew.

[WJ]

> she hates anybody who has accomplished
> anything with Forth, and she tells
> gross lies about the person, but she
> praises those who have never
> accomplished anything (so long as they
> praise her as the "leading expert" of
> Forth).

From Ambrose Bierce's "Devil's Dictionary":

commendation, n. The tribute that we pay to achievements that
resemble, but do not equal, our own.

--
[W]e had enough employees who made more than 85 to fill all the openings. The
highest score that any of the blacks scored on the test was 11. The lowest
score that any black made on the test was 4. All four of those blacks went
into skilled-trades training.
https://archive.org/download/TheOldmanArchives/oldman29-081003.mp3

[hughag...@gmail.com]

On Monday, July 25, 2016 at 12:46:18 AM UTC-7, Julian Fondren wrote:
> On Monday, July 25, 2016 at 2:36:38 AM UTC-5, Elizabeth D. Rather wrote:
> > On 7/24/16 9:30 PM, Julian Fondren wrote:
> >
> > > Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth
> > > (would "be polite and courteous" to her) if only she hadn't
> > > declared, in some feverish delusion of Hugh's, to be the sole
> > > arbiter of Forth.
> >
> > Which, exactly, feverish delusion of Hugh's was that, Julian? There have
> > been so many.
>
> According to pattern, Hugh will link to a thread, or even directly
> quote from the thread, and then declare victory. There's no actual
> need for the thread or his quote to support his claims. He'll just
> say that it does :p

Consider this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B76-100%5D

I'll quote directly from the thread:

On Sunday, July 10, 2016 at 9:23:44 PM UTC-7, hughag...@gmail.com wrote:
> As usual, SwiftForth code is grossly over-complicated. I figured it out though. Just as a joke, here is code for both VFX (slightly upgraded to be more efficient) and SwiftForth (not totally trivial, but reasonably easy to write):
>
> \ in the stack-picture comments, R is a continuation (a vector to a quotation)
>
> VFX? SwiftForth? or [if]
>
> \ My code ( VFX or SwiftForth only) requires that the HOF does have local variables.
>
> : rexit ( -- ) rdrop ;
> : (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
> : r[ ( -- r ) postpone (r:) postpone ahead ; immediate
> : ]r ( -- ) postpone rexit postpone then ; immediate
>
> VFX? [if]
>
> code rex ( r -- ) \ HumptyDumpty called this RCALL
> push edi \ this is the HOF's LF which won't be used by the quotation
> mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
> mov eax, ebx
> mov ebx, 0 [ebp] lea ebp, w [ebp]
> call eax
> pop edi \ restore HOF's LF
> next, end-code
>
> [then]
>
> SwiftForth? [if]
>
> 156 constant lf-offset \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)
>
> code rex ( r -- ) \ HumptyDumpty called this RCALL
> lf-offset [esi] edx mov
> edx push \ this is the HOF's LF which won't be used by the quotation
> -4 [edx] eax mov \ this is the old ESP
> 0 [eax] eax mov \ this is the parent's LF which will be used by the quotation
> eax lf-offset [esi] mov
> ebx eax mov [drop]
> eax call
> lf-offset [esi] pop \ restore HOF's LF
> ret end-code
>
> [then]
>
> [else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX
>
> : rexit ( -- ) RDROP ;
> : (r:) ( -- r ) R@ 0 ;
> : r[ ( -- r ) postpone (r:) postpone IF ; immediate
> : ]r ( -- ) postpone REXIT postpone THEN ; immediate
> : rex ( r -- ) >R -1 ; \ HumptyDumpty called this RCALL
>
> \ HumptyDumpty's code requires that the HOF does not have local variables.
>
> [then]
>
> \ char & comment \ this only works for my code (VFX or SwiftForth)
>
> : test-hof { r | y -- }
> 9 to y
> cr ." enter TEST-HOF " y . \ should be 9
> 3 0 do r rex loop
> cr ." leave TEST-HOF " y . \ should be 9
> ;
>
> : test { | x -- }
> 10 to x
> cr ." before: " x . \ should be 10
> r[ 1 +to x ]r test-hof
> cr ." after: " x . \ should be 13
> ;
>
> &

I declare victory in this thread!

The quotations RfD was supposed to be a slam-dunk from a ladder. The code for the Paysan-faked quotations was written by Bernd Paysan (Forth-200x committee member). The RfD was taken word-for-word from an article written by Stephen Pelc (Forth-200x committee member) and endorsed by Anton Ertl (Forth-200x committee chair-person). The RfD was pre-approved by Leon Wagner (boss of the Forth-200x committee). Alex McDonald put his name on the RfD to fake-up a grass-roots aspect to the RfD so it wouldn't appear to have come straight from the Forth-200x committee, but would instead appear to have come from the Forth community. All in all, a slam-dunk from a ladder!

Now the RfD has pretty much died. Over on the Forth-200x mailing list, nobody wants to discuss the RfD anymore. The last post in the mailing-list thread is dated July 7, which is quite some time ago. This is the last post (from Jennifer Brien):
----------------------------------------------------------------------------
On Thu, Jul 7, 2016 at 3:48 PM, Hans Bezemer han...@xs4all.nl [forth200x] <fort...@yahoogroups.com> wrote:

I don't like to write dirty stuff just to please quiche eaters, so IMHO this
one is far more controversial that the "keep access to outer variables". For
what? It has already executed. The thing is dead!


I think we are all agreed on that. I asked because I didn't see any great need for what Hugh was demanding, I still don't, and I can see trying to provide it might result in a lot of gotchas. I'm quite content with what he is pleased to call "Paysan faked quotations."

As far as locals and quotations are concerned, I think it is much more important that they can be passed as parameters to structure-walking words like map-array and traverse-wordlist.
----------------------------------------------------------------------------

The reason why nobody wants to respond, is that what she says is clearly untrue. She is saying that my rquotations can't be passed as parameters to "structure-walking words" (her term for higher-order-functions, commonly called HOFs). This is a pretty disingenuous argument --- roughly comparable to Alex McDonald saying that I have a "serious misunderstanding of how pointers work" or that I "really don't know how CREATE DOES> works" --- just typical Forth-200x insults (Forth-200x is a house founded upon sand, and for mortar they use bullshit).

So, I feel comfortable in declaring victory against the Forth-200x committee in regard to quotations. If anybody disagrees, then they need to get on the Forth-200x mailing list and go back to praising the RfD for the Paysan-faked quotations that Jennifer Brien is "quite content" with. Do it Forth-200x supporters! This is the only way you can declare victory for yourselves! The Forth-200x mailing-list is a "Hugh-free zone" (Jennifer Brien's term) so there is no way for me to stop you from declaring victory --- all that is needed is for you to is to get off your fat asses and declare victory --- but you haven't done so yet, and instead you have let the RfD wither and die (that RfD is almost a year old now, and it has yet to be turned into a CfV and ratified unanimously despite being pre-approved by Leon Wagner).

P.S. I actually do like to eat quiche. I remember way back in Santa Barbara going to parties and the women would bring quiche for the pot-luck. Awesome! Who doesn't like quiche?

[rickman]

On 7/25/2016 3:30 AM, Julian Fondren wrote:
>
> When I said that you were insane, I only
> meant that you were insane.

When I read this I *literally* laughed out loud!

I couldn't have said it better myself.

--

Rick C

[rickman]

Not sure, but this might qualify as installment 3 in Hugh's manifesto.
How many installments did the Unibomber make? Or was his manifesto
published all in one edition?

--

Rick C