Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #49737 > unrolled thread

The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

Back to article view | Back to comp.lang.forth

Contents

  The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 09:33 -0700
    Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-02 10:35 -0700
      Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 11:46 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 00:04 -0700
          Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-04 00:41 -0700
            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-04 09:35 -0400
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-04 10:08 -0500
    Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc Brad Eckert <hwfwguy@gmail.com> - 2016-08-02 15:45 -0700
      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-02 19:56 -0500
        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 22:43 -0700
        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 00:12 -0700
          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 02:42 -0500
            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 10:41 -0700
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 12:56 -0500
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 13:09 -0500
                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-03 14:15 -0400
                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Richard Owlett <rowlett@cloud85.net> - 2016-08-03 18:00 -0500
                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-05 20:35 -0700
                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 00:16 -0500
                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 16:58 -0700
                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 18:01 -0700
                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 21:28 -0500
                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 19:46 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 22:54 -0500
                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-06 21:39 -0700
                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-06 22:28 -0700
                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 23:49 -0700
                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 02:32 -0500
                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-07 01:06 -0700
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 07:05 -0500
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 13:01 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:02 -0500
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 14:20 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc franck.bensusan@gmail.com - 2016-08-08 03:13 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-08 11:25 -0500
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-07 13:55 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:22 -0500
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 15:03 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 23:02 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc "Elizabeth D. Rather" <erather@forth.com> - 2016-08-07 21:10 -1000
                                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-09 00:36 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 09:06 +0000
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 09:33 -0700
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 11:31 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 12:35 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:11 -0500
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 22:43 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 22:48 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 08:34 +0000
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-08 23:59 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 13:53 +0000
                                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-10 19:56 -0700
                                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 00:33 -0700
                                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-11 11:58 +0000
                                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-11 13:16 -0700
                                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc stephen@mpeforth.com (Stephen Pelc) - 2016-08-11 23:36 +0000
                                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-11 20:49 -0700
                                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 11:20 -0700
                                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 17:33 -0700
                                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-28 21:10 -0500
                                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 22:49 -0700
                                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-12 23:10 -0700
                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-06 20:20 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 09:58 -0700
                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-07 11:08 -0700
                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 09:10 +0000
                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 10:47 +0000
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JennyB <jennybrien@googlemail.com> - 2016-08-08 13:44 -0700
                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc mhx@iae.nl - 2016-08-08 11:32 -0700
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 06:13 +0000
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 06:19 +0000
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc mhx@iae.nl - 2016-08-09 02:54 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 10:22 +0000
                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc lawrencedo99@gmail.com - 2016-08-15 20:33 -0700
                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-16 10:40 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc lawrencedo99@gmail.com - 2016-08-17 02:21 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-17 11:14 -0700
          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Roberto Waltman <usenet@rwaltman.com> - 2016-08-03 18:21 -0400
      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-03 02:46 -0400
    Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-13 09:51 -0700
      Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-13 12:18 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-14 19:13 -0700
          Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-15 07:43 -0700
            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-15 12:34 -0500
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Brad Eckert <hwfwguy@gmail.com> - 2016-08-17 22:08 -0700
                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-18 15:26 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-14 19:18 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-15 08:24 -0700
          Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-15 08:31 -0700
            Re: The Fourth Forth eBook in our little series - Programming Forth- Stephen Pelc "WJ" <w_a_x_man@yahoo.com> - 2016-08-19 23:54 +0000
              Re: The Fourth Forth eBook in our little series - Programming Forth- Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-20 01:43 -0700

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#49895 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Monday, August 8, 2016 at 12:10:22 AM UTC-7, Elizabeth D. Rather wrote:
> There are a number of Forth cross-compilers that represent extensions of 
> ANS/ISO Forth, and have been for over 20 years. 

Saying that Forth cross-compilers are "extensions of ANS/ISO Forth" is the same as saying that Forth cross-compilers are necessarily non-standard --- it is not possible to write a cross-compiler in ANS-Forth --- ANS-Forth was crippled to prevent common Forth programmers from writing cross-compilers in competition with Forth Inc. and MPE who rely heavily on undocumented non-standard features in their compilers to write their cross-compilers.

[toc] | [prev] | [next] | [standalone]

#49870 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

=?UTF-8?B?SMOla2FuIFRow7ZybmdyZW4=?= <hth313@gmail.com> writes:
>By ANS-Forth, do you mean Forth-94?

In the reality where Hugh Aguilar lives, Forth-2012 has not been
released, so in that reality, the current standard is Forth-94 and is
still referred to as ANS Forth.

> What about EuroForth?

EuroForth is a yearly conference on Forth, not a standard.

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

[toc] | [prev] | [next] | [standalone]

#49846 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 1:06:29 AM UTC-7, Paul Rubin wrote:
> Mostly I don't understand quite what you're trying to do.  Gforth is
> reasonably fast and well documented, and it has plenty of creature
> comforts (at least in the language implementation).  So I'd probably use
> it if the target machine is powerful enough for it.

I have rquotations working under VFX and SwiftForth. I might be able to get them to work under Gforth, but I'm not enthusiastic about figuring out the internal workings of a C-based compiled. Getting rquotations to work under VFX was trivial because VFX is super-simple --- getting rquotations to work under SwiftForth was much more difficult because SwiftForth is grossly and pointlessly over-complicated  --- getting rquotations to work under Gforth might be even worse. All in all, I'm not enthusiastic about disassembling other people's compilers, figuring out their over-complicated messy code, and fixing it so that it does something useful --- eForth doesn't have any documentation either --- at least eForth was designed to be small and simple though.

Everything I've seen of Anton Ertl's work indicates that he is not very good at Forth. For example:
1.) In Gforth he has FIND return different xt values for a given word depending upon what STATE is when FIND is called. If fixed this problem with my disambiguifiers, but he pretends that they don't exist.
2.) He wrote { (but called it {: to appease Leon Wagner) and he made the locals to the right of the | get initialized to an arbitrary value --- they should be initialized to zero.
3.) He is obsessed with making the Paysan-faked quotations standard in Forth-200x --- he has seen my rquotations, but he pretends that they don't exist --- he is obviously just a tool of Forth Inc. and he does what Leon Wagner tells him to do, even as it becomes increasingly stupid.

The last I checked, Gforth code was 1/2 the speed of SwiftForth code, and SwiftForth code was 1/4 the speed of VFX code, and VFX code was adequate for commercial programming but was limited to 32-bit (all desktop computers made this century are 64-bit). Anyway, Gforth is not "reasonably fast" --- I think Anton Ertl crippled Gforth so that it would not undermine the sales of SwiftForth --- he did this in exchange for Elizabeth Rather appointing him to be the chair-person of the Forth-200x committee.

[toc] | [prev] | [next] | [standalone]

#49850 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 9:33:51 AM UTC-7, hughag...@gmail.com wrote:

> 1.) In Gforth he has FIND return different xt values for a given word depending upon what STATE is when FIND is called. If fixed this problem with my disambiguifiers, but he pretends that they don't exist.

I am interested in the best way to handle this case. If you refer to,
say IF, outside compilation, it does not have a a defined semantics in
that case. What should happen if you try to FIND it?

I can on the top of my head think of three ways to deal with it:

1. You FIND it, but realize you are in the wrong mode and give an
   error. This is what I believe Gforth does.

2. You arrange your search order and word lists in such a way that if
   you try to FIND such word in a state where it has no defined
   semantics, it will not find it.

3. You find it anyway and let the word decide what to do, you
   essentially put the responsibility on the word.

I would like to understand the pros and cons of these approaches, or
even if there are further ways. For the moment I feel most appealed by
(2), it makes seems quite clean and simple.
(I have not reflected on the actual complexities of arranging the
search order, word lists and relation to STATE to uphold it).
I like to understand this better.

> 2.) He wrote { (but called it {: to appease Leon Wagner) and he made the locals to the right of the | get initialized to an arbitrary value --- they should be initialized to zero.

I really like to see { being uses rather than {:, the whole community
should not suffer because one vendor at some point did what looks to
be the wrong choice.

> 3.) He is obsessed with making the Paysan-faked quotations standard in Forth-200x --- he has seen my rquotations, but he pretends that they don't exist --- he is obviously just a tool of Forth Inc. and he does what Leon Wagner tells him to do, even as it becomes increasingly stupid.

Regarding quotations I would very much like to see that we go for
allowing quotations to access variables of their parents, provided we
can do it using a generic mechanism.
I do not want a special case implementation like you promote, it is
too fragile.

As I understand it, what you propose is that a HOF need a environment,
the quotation cannot have it, but are given its parent
environment. What happens if the programmer uses a word that creates
an environment? It will trash the environment of the HOF (unless you
are maintaining double environment pointers). 
Also consider that words invoked from the quotation may not create an
environment today, but someone may come along later and change it and
suddenly it does. It is trap waiting to go off. 

You can always argue that quotations are simple so it won't be a
problem. I say that if you put a useful mechanism in hands of people,
they are bound to find good creative uses of it that you did not
foresee. You are basically preventing this and making the system 
fragile.

Double environment pointers would solve it, but I would rather go for
allowing inner words to access environments of their parent and
grand-parents, as well as having an environment of their own.

In such case we need some kind of closure (or semi-closure) xt. It
would need to carry the xt together with the environment pointer of its
immediate parent. Once this is in place, it is actually easy to access any
local in any surrounding environment.

At compile time you find the word to be a local in a surrounding
parent environment. For example, you find that it is two steps away
and have index 8. Then you compile that information in as a
environment lookup. (All environments used in such context need an
extra slot to carry a pointer to its immediate parent.)
At run-time, you just follow the pointers to previous environments
back 2 times and offset into that record.

[toc] | [prev] | [next] | [standalone]

#49851 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 11:31:18 AM UTC-7, Håkan Thörngren wrote:
> On Sunday, August 7, 2016 at 9:33:51 AM UTC-7, hughag...@gmail.com wrote:
> 
> > 1.) In Gforth he has FIND return different xt values for a given word depending upon what STATE is when FIND is called. If fixed this problem with my disambiguifiers, but he pretends that they don't exist.
> 
> I am interested in the best way to handle this case. If you refer to,
> say IF, outside compilation, it does not have a a defined semantics in
> that case. What should happen if you try to FIND it?
> 
> I can on the top of my head think of three ways to deal with it:
> 
> 1. You FIND it, but realize you are in the wrong mode and give an
>    error. This is what I believe Gforth does.
> 
> 2. You arrange your search order and word lists in such a way that if
>    you try to FIND such word in a state where it has no defined
>    semantics, it will not find it.
> 
> 3. You find it anyway and let the word decide what to do, you
>    essentially put the responsibility on the word.
> 
> I would like to understand the pros and cons of these approaches, or
> even if there are further ways. For the moment I feel most appealed by
> (2), it makes seems quite clean and simple.
> (I have not reflected on the actual complexities of arranging the
> search order, word lists and relation to STATE to uphold it).
> I like to understand this better.

Look at my novice-package (I can email the latest version to you). I have disambiguifiers. These cause words such as IF to become immediate (in ANS-Forth they can be immediate or non-immediate, and in VFX they weirdly are non-immedate) --- the words work fine when executed in compilation mode --- the words abort with an error message when executed in interpretation mode.

> Regarding quotations I would very much like to see that we go for
> allowing quotations to access variables of their parents, provided we
> can do it using a generic mechanism.
> I do not want a special case implementation like you promote, it is
> too fragile.

I agree that my rquotations are fragile, but this was the best I could do given VFX and SwiftForth.

I don't think the fragility is as bad as you believe. Just remember the four rules:
1.) The rquotation must be called with REX rather than EXECUTE.
2.) Only a HOF can use REX.
3.) A HOF can not call another HOF.
4.) A HOF must have local variables.

> In such case we need some kind of closure (or semi-closure) xt. It
> would need to carry the xt together with the environment pointer of its
> immediate parent. Once this is in place, it is actually easy to access any
> local in any surrounding environment.

This is how Straight Forth works. It has a "fat xt." In Straight Forth the cells are 64-bit, but the addresses are all 32-bit. A fat-xt is a 64-bit struct that contains the 32-bit cfa and the 32-bit pointer to the parent function's local-frame.

The fat-xt can be passed around and used without following the four rules mentioned above for rquotations --- the only limitation is that the parent function still has to be in scope when the quotation is executed --- I have a method for checking this and aborting with a helpful error message if the parent function is not in scope, rather than just blindly access a local-frame that no longer exists.

[toc] | [prev] | [next] | [standalone]

#49856 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/7/2016 2:35 PM, hughaguilar96@gmail.com wrote:

> This is how Straight Forth works. It has a "fat xt." In Straight Forth the cells are 64-bit, but the addresses are all 32-bit. A fat-xt is a 64-bit struct that contains the 32-bit cfa and the 32-bit pointer to the parent function's local-frame.
>
> The fat-xt can be passed around and used without following the four rules mentioned above for rquotations --- the only limitation is that the parent function still has to be in scope when the quotation is executed --- I have a method for checking this and aborting with a helpful error message if the parent function is not in scope, rather than just blindly access a local-frame that no longer exists.
>
In Delphi when you define a function inside a function, it passes a 
pointer to the parents environment, so the function has access to the 
parents variables, and that environment contains a pointer to it's 
parents environment, so you could access the grand-parents variables 
also or further back the chain. I have never tried it other than 
accessing the parents variables but the possibility is there. In couple 
of cases that proved rather handy, I didn't know they were closures but 
I did used them in a couple of cases when manipulating complex data 
structures in the BT+ Library, it cut down on the number of parameters 
being passed since I could access the parents data and change it.
-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#49864 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 2:11:36 PM UTC-7, Cecil - k5nwa wrote:

> In Delphi when you define a function inside a function, it passes a 
> pointer to the parents environment, so the function has access to the 
> parents variables, and that environment contains a pointer to it's 
> parents environment, so you could access the grand-parents variables 
> also or further back the chain. I have never tried it other than 
> accessing the parents variables but the possibility is there. In couple 
> of cases that proved rather handy, I didn't know they were closures but 
> I did used them in a couple of cases when manipulating complex data 
> structures in the BT+ Library, it cut down on the number of parameters 
> being passed since I could access the parents data and change it.
> -- 
> Cecil - k5nwa

They are not real closures. To implement a real closure you need to
allocate environments on a heap so that they can survive when the
parent function goes out of scope. You may also have a pointer from
the top-most parent environment to the global environment.
This implies some kind of mechanism that can reclaim memory for
environments when they finally go out of scope, which usually means of
a garbage collector, probably not a feature you want in Forth.

In any case, just having fake-closures can be useful, as you
apparently found out from using Delphi.

[toc] | [prev] | [next] | [standalone]

#49865 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 12:35:36 PM UTC-7, hughag...@gmail.com wrote:

> Look at my novice-package (I can email the latest version to you). I have disambiguifiers. These cause words such as IF to become immediate (in ANS-Forth they can be immediate or non-immediate, and in VFX they weirdly are non-immedate) --- the words work fine when executed in compilation mode --- the words abort with an error message when executed in interpretation mode.

Yes, feel free to send it to me. I downloaded it a couple of days ago,
but it was probably an older version. Also tell me where the
disambiguifiers are, there are many files in that package.

Maybe you want to put it on some code hosting site?

[toc] | [prev] | [next] | [standalone]

#49869 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

=?UTF-8?B?SMOla2FuIFRow7ZybmdyZW4=?= <hth313@gmail.com> writes:
>On Sunday, August 7, 2016 at 9:33:51 AM UTC-7, hughag...@gmail.com wrote:
>
>> 1.) In Gforth he has FIND return different xt values for a given word dep=
>ending upon what STATE is when FIND is called. If fixed this problem with m=
>y disambiguifiers, but he pretends that they don't exist.
>
>I am interested in the best way to handle this case. If you refer to,
>say IF, outside compilation, it does not have a a defined semantics in
>that case. What should happen if you try to FIND it?
>
>I can on the top of my head think of three ways to deal with it:
>
>1. You FIND it, but realize you are in the wrong mode and give an
>   error. This is what I believe Gforth does.

Just check it out yourself.

There is no provision in the standard for FIND giving an error on
valid input.

Here is what Gforth 0.7 does:

: c-if c" if" ;  ok
c-if find   ok
.s <2> 139790204771072 1  ok
drop  ok
xt-see 
: compile-only-error  
  -14 throw ; ok

So when you FIND IF in interpretation state, you get the xt of a word,
that, when executed, produces an error ("Interpreting a compile-only
word").

In the meantime, we have changed compile-only words to produce a
warning instead of an error, so in the development version of Gforth
interpreted IF just behaves like compiled IF (i.e., it's just an
immediate word), but also gives a warning, and when you FIND IF, you
get the same xt in both STATEs; when you EXECUTE that, it behaves just
like compiled IF (no warning):

: c-if c" if" ;  ok
c-if find   ok    
.s <2> 140215597006432 1  ok
drop xt-see 
: IF  ['] 
  ?branch compile, >mark ; ok

However, the bigger problem is words like (FILE wordset) S" that have
valid interpretation semantics and valid compilation semantics, that
are neither default compilation semantics nor immediate compilation
semantics.  There Gforth's FIND produces different xts in compilation
state and interpretation state:

create c-s" 2 c, 's' c, '"' c,  ok           
c-s" find .s <2> 140215597015472 1  ok
drop xt-see 
noname : 
  34 parse save-mem ; ok
: ]find[ ] find postpone [ ;  ok
c-s" ]find[ .s <2> 140215597015568 1  ok
drop xt-see 
noname : 
  34 parse  POSTPONE SLiteral ; ok

>2. You arrange your search order and word lists in such a way that if
>   you try to FIND such word in a state where it has no defined
>   semantics, it will not find it.

That's the cmForth way, and is probably what the ANS Forth TC had in
mind when they wrote that FIND can return different results in
different STATEs.

>3. You find it anyway and let the word decide what to do, you
>   essentially put the responsibility on the word.

If the word decides, that is STATE-smartness.  The problem with that
is that the word decides based on the STATE at run-time, and if the
STATE at run-time differs from the STATE where the word appeared, the
result is often not what the programmer had in mind.  See
<https://www.complang.tuwien.ac.at/papers/ertl98.ps.gz> for a longer
discussion on that topic.

>I would like to understand the pros and cons of these approaches, or
>even if there are further ways. For the moment I feel most appealed by
>(2), it makes seems quite clean and simple.

As long as you don't implement the search order, yes, it probably is.
But this approach has not been picked up by many Forth
implementations, and I think the reason is that it stops being simple
once you also want to implement a search order.

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

[toc] | [prev] | [next] | [standalone]

#49893 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Monday, August 8, 2016 at 2:05:38 AM UTC-7, Anton Ertl wrote:
> There is no provision in the standard for FIND giving an error on
> valid input.

According to the ANS-Forth document in the entry for IF (section 6.1.1700): "Interpretation semantics for this word are undefined." The ANS-Forth document has a section (4.1.2) with the ominous heading: "Ambiguous Conditions." One of the many ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."

What this means is that giving the string  C" IF"  to FIND is an ambiguous condition. IF is a Forth word however and it has an xt --- C" IF" is valid input --- so, it is obvious that Anton Ertl is lying.

Section 3.4.4. explains what will happen:
----------------------------------------------------------------------------
Possible actions on an ambiguous condition
When an ambiguous condition exists, a system may take one or more of the following actions:
– ignore and continue;
– display a message;
– execute a particular word;
– set interpretation state and begin text interpretation;
– take other implementation-defined actions;
– take implementation-dependent actions.
The response to a particular ambiguous condition need not be the same under all circumstances.
----------------------------------------------------------------------------

There are two ways to write a cross-compiler. One (the easy way) is to use the built-in outer-interpreter. This won't work in ANS-Forth however because LITERAL is not vectored and so when you encounter a literal number the outer-interpreter will compile it into host memory --- you want LITERAL to be vectored so you can change it for TARG words to compile the literal number into target memory, then change it back for HOST words to do what it usually does.

The second way (the somewhat more complicated way) is to write your own outer-interpreter. This won't work in ANS-Forth however because FIND considers looking up most of the words in the system (such as IF etc.) to be an ambiguous condition. I have actually fixed FIND however with my disambiguifiers --- ironically, Anton Ertl invented the disambiguifiers himself way back in 2009 --- now however, Anton Ertl refuses to acknowledge the existence of the disambiguifiers.

This second way, btw, is still problematic because QUIT isn't vectored in ANS-Forth. This means that if you abort with an error then you get dumped back into the built-in outer-interpreter rather than back to your custom outer-interpreter.

[toc] | [prev] | [next] | [standalone]

#49904 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

hughaguilar96@gmail.com writes:
>On Monday, August 8, 2016 at 2:05:38 AM UTC-7, Anton Ertl wrote:
>> There is no provision in the standard for FIND giving an error on
>> valid input.
>
>According to the ANS-Forth document in the entry for IF (section 6.1.1700):=
> "Interpretation semantics for this word are undefined." The ANS-Forth docu=
>ment has a section (4.1.2) with the ominous heading: "Ambiguous Conditions.=
>" One of the many ambiguous conditions is: "attempting to obtain the execut=
>ion token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition wit=
>h undefined interpretation semantics."

Good catch.  Interestingly, the definition of FIND does not mention
that, and given the return values that FIND can produce, and the way
that FIND is used, I don't think it makes sense.  I don't think there
are any Forth systems that produce an error when performing

: c-if c" if" ;
c-if find

Of course, some people find it surprising that

c-if find drop execute

produces an error in Gforth 0.7, but errors produced during execution
of xts returned by FIND are no rarity.

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

[toc] | [prev] | [next] | [standalone]

#49938 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Tuesday, August 9, 2016 at 7:08:55 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >On Monday, August 8, 2016 at 2:05:38 AM UTC-7, Anton Ertl wrote:
> >> There is no provision in the standard for FIND giving an error on
> >> valid input.
> >
> >According to the ANS-Forth document in the entry for IF (section 6.1.1700):=
> > "Interpretation semantics for this word are undefined." The ANS-Forth docu=
> >ment has a section (4.1.2) with the ominous heading: "Ambiguous Conditions.=
> >" One of the many ambiguous conditions is: "attempting to obtain the execut=
> >ion token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition wit=
> >h undefined interpretation semantics."
> 
> Good catch.  Interestingly, the definition of FIND does not mention
> that, and given the return values that FIND can produce, and the way
> that FIND is used, I don't think it makes sense.  

Well, I'm glad that you are admitting that FIND in ANS-Forth is broken. I would use the term "sabotaged" because there is no point to making FIND not work except to prevent the programmer from writing an outer-interpreter.

It is disingenious to describe this as a "good catch" in the year 2016. You yourself pointed this problem out to me in 2009, and you provided the way to fix it. This was in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D

On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote:
> Hugh Aguilar <hugoaguilar@rosycrew.com> writes:
> >I don't understand how a word can not have execution semantics.
> 
> That's quite simple: By not defining execution semantics in the
> definition of the word in the standard document.  Look up the
> definition of ";" in the standard, and you will see that there is no
> "Execution:" section there; and there are other labeled sections
> there, so the "omitted label" sentence of 3.4.3.1 does not apply.
> 
> >For immediate words (IF, ;, etc.)
> 
> IF and ";" are not immediate words in the standard.  A system can
> implement them as immediate words, but a program cannot rely on their
> immediacy.
> 
> >I looked up ['] in the ANS-Forth document and it says:
> >
> >"Place name's execution token xt on the stack."
> 
> What's the execution token of a word that has no execution semantics.
> 
> Hmm, since you think that ";" is immediate, I guess you want an
> execution token that, when executed, performs the compilation
> semantics.  You can get that as follows.  Before the rest of the
> program, define:
> 
> : ; postpone ; ; immediate
> 
> Now you have an immediate ";" with an execution semantics that's the
> same as the compilation semantics, and you can tick it.
> 
> >What I am saying is that I didn't have any warning that what I was
> >doing in MACRO: was going to be a problem.
> 
> A system that would tell us all non-standard usages would be nice, but
> we don't have that.  For now the solution is to test on as many
> systems as possible.

What you have above above are what I now have in the novice-package and call "disambiguifiers." Here is one disambiguifier copied out of the novice-package:
: if  state @ 0= abort" *** no interpretation semantics for: IF ***"         
    postpone if  ; immediate

This is just a bug-fix for ANS-Forth. Straight Forth doesn't need disambiguifiers because it is just straight Forth without ambiguity.

Earlier, I provided a list of what is needed for a cross-compiler. Let me slightly upgrade that list:
1.) LITERAL is vectored so the built-in outer-interpreter can be used and when it encounters a number in a TARG colon word it compiles that number into the target memory rather than the host memory. 
2.) QUIT is vectored so the user can write his own outer-interpreter if he wants, and if it aborts on an error then control will go back to his outer-interpreter rather than to the built-in outer-interpreter (because ABORT and ABORT" call QUIT internally).
3.) The ability to take an xt and determine the following attributes: 
    what vocabulary it is in 
    immediate or non-immediate 
    smudged or not smudged 
    smudge-ready or not smudge-ready 
4.) The ability to take an xt and modify those attributes. 
5.) CONTEXT and CURRENT have to work like they did in Forth-83. 
6.) FIND has to work correctly. The words in the standard have to be defined as being immediate or non-immediate. Words that have traditionally been immediate (everything requiring a disambiguifier in ANS-Forth) will be defined as immediate.

My primary goal with Straight Forth is to allow Forth programmers to write cross-compilers using a standard Forth system. As it currently stands, ANS-Forth has been sabotaged to prevent cross-compilers from being written (because this would be competition against Forth Inc. and MPE). It is possible to write a cross-compiler in various Forth systems, but each system has to be disassembled and the cross-compiler writer will need to rely on carnal knowledge. I did this with UR/Forth when I wrote MFX, but not a lot of carnal knowledge was necessary as UR/Forth was already pretty good out of the box. Modern Forth systems, such as VFX are a lot bigger than UR/Forth and hence disassembling them to obtain the needed carnal knowledge is more time-consuming and difficult. We shouldn't have to disassemble Forth systems though, because this is a waste of time. Also, the cross-compilers are not portable but obviously become vendor-specific due to relying on carnal knowledge. The goal with Straight Forth is just that we have a Standard that supports cross-compilers and does so in a straightforward manner that is well documented. People can write cross-compilers and they can be ported to any Straight Forth system. The cross-compiler itself will not be standardized in Straight Forth because there are many valid ways to write a cross-compiler (the most important choice is to either use the built-in outer-interpreter or write your own outer-interpreter, but there are other choices as well). There is room for creativity in writing a cross-compiler and it is not my business to tell people how to write their cross-compilers. Straight Forth only serves as a common host for these cross-compilers, making them possible. 

I don't understand why Straight Forth is controversial. Other than Leon Wagner and Stephen Pelc, who is opposed to common Forth programmers writing cross-compilers? I wrote MFX for the MiniForth processor in 1994/1995 --- everybody on comp.lang.forth treats me like a criminal for doing this --- they howl: "That is not the Forth Way!!!" WTF???

Straight Forth can be a pretty simple Forth Standard --- about 1/2 the size of ANS-Forth and 1/8 the size of Forth-200x --- I'm adding a few features, such as quotations, that aren't related to cross-compilation, but Straight Forth is still pretty simple and straightforward --- a super-simple Forth Standard seems like a good thing to me, because Forth was traditionally super-simple (only with ANS-Forth did Forth become complicated, ambiguous and difficult or impossible to understand).

Most Forth programmers, including myself, originally got interested in Forth (rather than C) because of these reasons:
1.) Forth is simple and easy to understand. There is no syntax. The outer-interpreter is a short and straightforward function. Forth is to C as Go is to Chess.
2.) Forth is extensible. For example, in Forth structs can start with any offset, whereas in C they have to start with zero. As another example, a Forth system can be extended to generate code for a different processor (cross-compilation) using the built-in outer-interpreter, whereas in C a new compiler has to be written from scratch with its own super-complicated outer-interpreter.
3.) Forth is interactive. We can debug individual functions from the command-line (a REPL to use the Lisp term), whereas in C an entire program has to be compiled into an executable and then single-stepped through with a debugger.

I see no reason why Forth-200x and Straight Forth can't coexist as incompatible Standards --- their goals are completely different so they can't be combined into one Standard --- the Forth community can just diverge into two groups each with their own Standard and each with their own take on what Forth is:
1.) Forth-200x --- mind-numbingly complicated and utterly useless and opposed to general-purpose data-structures
2.) Straight Forth --- super-simple and useful as the host for a cross-compiler and supportive of general-purpose data-structures

[toc] | [prev] | [next] | [standalone]

#49943 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Wednesday, August 10, 2016 at 9:56:36 PM UTC-5, hughag...@gmail.com wrote:
> I don't understand why Straight Forth is controversial.

It isn't.  You argue for it; nobody argues against it.  You develop your
definition of it; nobody disputes your definitions.  An example of a
controversial thing would be ANS Forth: people don't understand it (or the the
role of a 'standard' even) or regard it as malign or unnecessary or degenerate;
others defend it against all of those charges, and try to explain what
standards are for.  Not as much anymore now that you've settled on it just
being malign, but more interesting attacks and defences are clf history.

Go ahead and do your Straight Forth.  But nobody cares.  Nobody is 'howling'
anything.  If you desire opposition so much, well, maybe you'll get some when
you actually produce it.  One can hope.


-- Julian

[toc] | [prev] | [next] | [standalone]

#49951 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

hughaguilar96@gmail.com writes:
>On Tuesday, August 9, 2016 at 7:08:55 AM UTC-7, Anton Ertl wrote:
>> hughaguilar96@gmail.com writes:
>> >On Monday, August 8, 2016 at 2:05:38 AM UTC-7, Anton Ertl wrote:
>> >> There is no provision in the standard for FIND giving an error on
>> >> valid input.
>> >
>> >According to the ANS-Forth document in the entry for IF (section 6.1.170=
>0):=3D
>> > "Interpretation semantics for this word are undefined." The ANS-Forth d=
>ocu=3D
>> >ment has a section (4.1.2) with the ominous heading: "Ambiguous Conditio=
>ns.=3D
>> >" One of the many ambiguous conditions is: "attempting to obtain the exe=
>cut=3D
>> >ion token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition =
>wit=3D
>> >h undefined interpretation semantics."
>>=20
>> Good catch.  Interestingly, the definition of FIND does not mention
>> that, and given the return values that FIND can produce, and the way
>> that FIND is used, I don't think it makes sense. =20
>
>Well, I'm glad that you are admitting that FIND in ANS-Forth is broken. I w=
>ould use the term "sabotaged" because there is no point to making FIND not =
>work except to prevent the programmer from writing an outer-interpreter.
>
>It is disingenious to describe this as a "good catch" in the year 2016. You=
> yourself pointed this problem out to me in 2009, and you provided the way =
>to fix it. This was in this thread:
>https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%=
>5D

FIND does not occur in that posting.

I dimly remember you pointing out that ambiguous condition at another
occasion, though, but obviously that has not stuck in my memory
enough, or I would not have written the sentence above.

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

[toc] | [prev] | [next] | [standalone]

#49958 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Thursday, August 11, 2016 at 5:04:27 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >On Tuesday, August 9, 2016 at 7:08:55 AM UTC-7, Anton Ertl wrote:
> >> hughaguilar96@gmail.com writes:
> >> >On Monday, August 8, 2016 at 2:05:38 AM UTC-7, Anton Ertl wrote:
> >> >> There is no provision in the standard for FIND giving an error on
> >> >> valid input.
> >> >
> >> >According to the ANS-Forth document in the entry for IF (section 6.1.170=
> >0):=3D
> >> > "Interpretation semantics for this word are undefined." The ANS-Forth d=
> >ocu=3D
> >> >ment has a section (4.1.2) with the ominous heading: "Ambiguous Conditio=
> >ns.=3D
> >> >" One of the many ambiguous conditions is: "attempting to obtain the exe=
> >cut=3D
> >> >ion token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition =
> >wit=3D
> >> >h undefined interpretation semantics."
> >>=20
> >> Good catch.  Interestingly, the definition of FIND does not mention
> >> that, and given the return values that FIND can produce, and the way
> >> that FIND is used, I don't think it makes sense. =20
> >
> >Well, I'm glad that you are admitting that FIND in ANS-Forth is broken. I w=
> >ould use the term "sabotaged" because there is no point to making FIND not =
> >work except to prevent the programmer from writing an outer-interpreter.
> >
> >It is disingenious to describe this as a "good catch" in the year 2016. You=
> > yourself pointed this problem out to me in 2009, and you provided the way =
> >to fix it. This was in this thread:
> >https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%=
> >5D
> 
> FIND does not occur in that posting.
> 
> I dimly remember you pointing out that ambiguous condition at another
> occasion, though, but obviously that has not stuck in my memory
> enough, or I would not have written the sentence above.
> 
> - anton

ANS-Forth is terrible as a standard because it is rife with ambiguity. I have said this 100 times --- I'm pretty sure that you can dimly remember me saying this!

One ambiguity is that words in the ANS-Forth Standard aren't defined to be immediate or non-immediate, so in some ANS-Forth systems IF and semicolon etc. are immediate and in other ANS-Forth systems (VFX) they are non-immediate. I said this is "one ambiguity" but it is actually over 50 ambiguities because that is how many words in ANS-Forth have this problem --- that is how many disambiguifiers are needed to fix the problem --- I have these disambiguifiers in the novice-package.

Another ambiguity is that the definition of FIND (section 6.1.1550) includes this sentence: 
"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."
In general, whenever you are reading the ANS-Forth document and you encounter the word "may," then you are in trouble!

In Gforth, FIND returns different values for a given string depending upon what STATE is when FIND is executed. This was mind-blowing for me in 2009 (when I wrote my LC53 encryption-cracking program in ANS-Forth) --- I had never expected such an abomination given my years of programming in Forth-83 --- this abomination is ANS-Forth standard though! Also, in Gforth, tick aborts when it encounters these words --- this was very unexpected to me, because I would have assumed that tick and FIND worked comparably (normally tick calls FIND internally) --- in Gforth they behave completely differently given the same string.

In VFX all of these words (such as IF and semicolon etc.) that were immediate traditionally, are now non-immediate (in Gforth they are still immediate). This was mind-blowing for me in 2009 --- I had never expected such an abomination given my years of programming in Forth-83 --- this abomination is ANS-Forth standard though! In VFX all of these non-immediate words are special-cased internally within COMPILE, so they execute at compile-time like immediate words and generate code for run-time. In VFX tick and FIND return an xt for these words, but when the xt is given to EXECUTE (whether STATE is compiling or interpreting), the system aborts. So, the xt is an unexecutable execution-token. Mind-blowing!!!

For many years (from 2009 until 2015) I believed that FIND was completely broken in ANS-Forth and that there was no way to write a cross-compiler in which I write my own outer-interpreter. Then, I figured out the solution during the course of this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/oXXQAGDKP7w%5B1-25%5D
This was when I wrote the disambiguifiers. Now FIND in ANS-Forth is fixed! All of the ambiguity is gone! All of those words are now immediate (including in VFX where they were non-immediate). For all of those words FIND returns one xt value (including in Gforth where FIND returned different xt values depending upon what STATE was when FIND executed). For all of those words the xt value can be executed during the compilation of a colon word and it will work properly just like any immediate word should (including in VFX where all of these xt values would abort the system when executed during the compilation of a colon word).

This is why they are called "disambiguifiers" --- all of that mind-blowing ambiguity is removed and all of these 50-some words work correctly and consistently --- what is not to love about disambiguifiers???

The reason why the Forth-200x committee hates disambiguifiers is because the disambiguifiers allow the common Forth programmer to write his own outer-interpreter, which was effectively illegal in ANS-Forth --- a custom outer-interpreter can be used as the basis for a cross-compiler --- the Forth-200x committee is dedicated to preventing common Forth programmers from writing cross-compilers in competition against Forth Inc. and MPE, hence they hate the disambiguifiers.

My first-ever ANS-Forth program was LowDraw.4th which is now in the novice-package. This program worked out pretty well and I felt confident that I could learn ANS-Forth easily given my experience with Forth-83. My second-ever ANS-Forth program was the LC53 encryption-cracking program which used MACRO: (I wrote MACRO: in MFX originally when I was employed at Testra, and MFX was pretty-much Forth-83). This worked under SwiftForth so I made the code public, but it did not work under Gforth and so I was heavily criticized in that thread mentioned above for being a bad ANS-Forth programmer. This was when I doubted that I would ever become an ANS-Forth programmer. Now in 2016 nobody on comp.lang.forth has changed their mind on this subject --- they continue to criticize me for being a bad ANS-Forth programmer --- it has become obvious that I will always be a bad ANS-Forth programmer, which is why I'm now working on the Straight Forth standard to replace ANS-Forth.

The whole point of Straight Forth is that there is no ambiguity, and everything makes sense, and the language definition is short and simple --- this is what is needed for a standard that supports cross-compilers --- you have to have a solid foundation to write a cross-compiler!

[toc] | [prev] | [next] | [standalone]

#49963 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughaguilar96@gmail.com
wrote:

>In VFX tick and FIND return=
> an xt for these words, but when the xt is given to EXECUTE (whether STATE =
>is compiling or interpreting), the system aborts.

Bollocks!

 VFX Forth for Windows IA32
 © MicroProcessor Engineering Ltd, 1998-2015 

 Version: 4.72 [build 3552]
 Build date: 24 July 2016

 Free dictionary = 7545678 bytes [7368kb]


' ' execute words  ok-1 
. 4282148  ok
' words . 4282148  ok

>The whole point of Straight Forth is that there is no ambiguity, and everyt=
>hing makes sense, and the language definition is short and simple

Ah, but Straight Forth doesn't exist ...

Stephen

-- 
Stephen Pelc, stephenXXX@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

[toc] | [prev] | [next] | [standalone]

#49968 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Thursday, August 11, 2016 at 4:36:05 PM UTC-7, Stephen Pelc wrote:
> On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughaguilar96@gmail.com
> wrote:
> 
> >In VFX tick and FIND return=
> > an xt for these words, but when the xt is given to EXECUTE (whether STATE =
> >is compiling or interpreting), the system aborts.
> 
> Bollocks!
> 
>  VFX Forth for Windows IA32
>  © MicroProcessor Engineering Ltd, 1998-2015 
> 
>  Version: 4.72 [build 3552]
>  Build date: 24 July 2016
> 
>  Free dictionary = 7545678 bytes [7368kb]
> 
> 
> ' ' execute words  ok-1 
> . 4282148  ok
> ' words . 4282148  ok

Your example code above is just a big steaming pile of bollocks. This is meaningless.

The bug in VFX has already been covered in this thread that I mentioned above as being where I figured out the disambiguifiers:

https://groups.google.com/forum/#!topic/comp.lang.forth/oXXQAGDKP7w%5B1-25%5D

: my-if [ ' if ] literal execute ; immediate   ok
: ttt ( flag -- ) my-if ." true" else ." false" then ; 
Err# -14 ERR: Attempt to interpret a compile only definition.
 -> : ttt ( flag -- ) my-if ." true" else ." false" then ;

The xt (execution token) of IF can't be executed in VFX --- just like I said! IF is actually non-immediate in VFX, which is an abomination --- just like I said! 

Now, here is the disambiguifier to fix the bug in VFX:

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

Now we try again:

: my-if [ ' if ] literal execute ; immediate 
MY-IF is redefined  ok

: ttt ( flag -- ) my-if ." true" else ." false" then ;  ok

TTT now compiles correctly! Yay! Lets test it:

1 ttt true ok
0 ttt false ok

The bug in VFX has been fixed with the disambiguifier! In the novice-package I now have disambiguifiers that fix all the broken words in VFX --- these are the same words that are broken in Gforth (except broken in a different way) --- the disambiguifiers fix all of the ANS-Forth systems and makes them consistent.

It is obvious to me that you are just straight out lying when you claim that FIND in ANS-Forth is not broken. You want FIND in ANS-Forth to be broken in order to prevent common ANS-Forth programmers from writing their own outer-interpreter, because you don't want common ANS-Forth programmers to write cross-compilers in competition with MPE.

[toc] | [prev] | [next] | [standalone]

#50516 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Thursday, August 11, 2016 at 8:49:47 PM UTC-7, hughag...@gmail.com wrote:
> On Thursday, August 11, 2016 at 4:36:05 PM UTC-7, Stephen Pelc wrote:
> > On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughaguilar96@gmail.com
> > wrote:
> > 
> > >In VFX tick and FIND return=
> > > an xt for these words, but when the xt is given to EXECUTE (whether STATE =
> > >is compiling or interpreting), the system aborts.
> > 
> > Bollocks!
> > 
> >  VFX Forth for Windows IA32
> >  © MicroProcessor Engineering Ltd, 1998-2015 
> > 
> >  Version: 4.72 [build 3552]
> >  Build date: 24 July 2016
> > 
> >  Free dictionary = 7545678 bytes [7368kb]
> > 
> > 
> > ' ' execute words  ok-1 
> > . 4282148  ok
> > ' words . 4282148  ok
> 
> Your example code above is just a big steaming pile of bollocks. This is meaningless.
> 
> The bug in VFX has already been covered in this thread that I mentioned above as being where I figured out the disambiguifiers:
> 
> https://groups.google.com/forum/#!topic/comp.lang.forth/oXXQAGDKP7w%5B1-25%5D
> 
> : my-if [ ' if ] literal execute ; immediate   ok
> : ttt ( flag -- ) my-if ." true" else ." false" then ; 
> Err# -14 ERR: Attempt to interpret a compile only definition.
>  -> : ttt ( flag -- ) my-if ." true" else ." false" then ;
> 
> The xt (execution token) of IF can't be executed in VFX --- just like I said! IF is actually non-immediate in VFX, which is an abomination --- just like I said! 
> 
> Now, here is the disambiguifier to fix the bug in VFX:
> 
> : if  state @ 0= abort" *** no interpretation semantics for: IF ***"  postpone if  ;  immediate 
> IF is redefined  ok
> 
> Now we try again:
> 
> : my-if [ ' if ] literal execute ; immediate 
> MY-IF is redefined  ok
> 
> : ttt ( flag -- ) my-if ." true" else ." false" then ;  ok
> 
> TTT now compiles correctly! Yay! Lets test it:
> 
> 1 ttt true ok
> 0 ttt false ok
> 
> The bug in VFX has been fixed with the disambiguifier! In the novice-package I now have disambiguifiers that fix all the broken words in VFX --- these are the same words that are broken in Gforth (except broken in a different way) --- the disambiguifiers fix all of the ANS-Forth systems and makes them consistent.
> 
> It is obvious to me that you are just straight out lying when you claim that FIND in ANS-Forth is not broken. You want FIND in ANS-Forth to be broken in order to prevent common ANS-Forth programmers from writing their own outer-interpreter, because you don't want common ANS-Forth programmers to write cross-compilers in competition with MPE.

Well, I read Bernd Paysan's article on Mini-OOF:
https://bernd-paysan.de/mini-oof.html

In there, he says:
-----------------------------------------------------------------------------
Note: this early binding means that the xt you have assigned to the method may not have non-default compilation semamtics applied with SET-COMPILER (e.g. in VFX Forth). Example: You want to perform the execution semantics of IF in a method

:noname ( -- if-sys ) postpone IF ; some-class defines if-method
is the only portable way to achive this. If you have a mix of interpretation and compilation semantics, like with S", achieving a deliberate selection portable may even be more difficult:

:noname state @ >r postpone [ ['] s" execute r> IF ] THEN ; class defines xxx
will most likely work on all systems.
-----------------------------------------------------------------------------

Well, that looks familiar! Bernd Paysan (Forth-200x committee member) is on the verge of figuring out how to write a disambiguifier. As I said before, disambiguifiers were originally invented by Anton Ertl (Forth-200x committee chair-person) in 2009. Later on, in the "Bug in VFX" thread mentioned above, I figured out that disambiguifiers could solve the problem with FIND --- and so I now have all the disambiguifiers in the novice-package.

Stephen Pelc says "Bollocks!" to me, implying that I'm lying about FIND is broken in ANS-Forth. Yet, it is obvious that both Anton Ertl and Bernd Paysan are aware of the fact that FIND is broken in ANS-Forth --- they are working around the problem with disambiguifiers --- they are working around the problem in the same way that I am!

So, why doesn't Stephen Pelc say "Bollocks!" to Anton Ertl and Bernd Paysan? He doesn't do this because he doesn't want to undermine the credibility of the Forth-200x committee. Instead he says "Bollocks!" to me --- he feels confident in doing this because he knows that all of the Forth-200x sycophants will support him in this --- the Forth-200x sycophants love to fling vulgar insults at anybody who criticizes ANS-Forth or Forth-200x; that is what Forth-200x is all about.

I said above: 
----------------------------------------------------------------------------
It is obvious to me that you are just straight out lying when you claim that FIND in ANS-Forth is not broken. You want FIND in ANS-Forth to be broken in order to prevent common ANS-Forth programmers from writing their own outer-interpreter, because you don't want common ANS-Forth programmers to write cross-compilers in competition with MPE.
----------------------------------------------------------------------------

This is the truth! 

ANS-Forth is a cult. Forth Inc. and MPE purposely crippled ANS-Forth so that it would not be useful for writing a cross-compiler in competition with Forth Inc. and MPE. They are doing the same with Forth-200x now. They rely entirely on sycophants to support them --- the sycophants just do this because it is fun to be a big expert in programming --- with ANS-Forth and Forth-200x they don't have to learn how to program, but all that is required of them is loyalty to the Forth-200x committee.

[toc] | [prev] | [next] | [standalone]

#50533 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Thursday, August 11, 2016 at 8:49:47 PM UTC-7, hughag...@gmail.com wrote:
> On Thursday, August 11, 2016 at 4:36:05 PM UTC-7, Stephen Pelc wrote:
> > On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughaguilar96@gmail.com
> > wrote:
> > 
> > >In VFX tick and FIND return=
> > > an xt for these words, but when the xt is given to EXECUTE (whether STATE =
> > >is compiling or interpreting), the system aborts.
> > 
> > Bollocks!
> ...
> It is obvious to me that you are just straight out lying when you claim that FIND in ANS-Forth is not broken. You want FIND in ANS-Forth to be broken in order to prevent common ANS-Forth programmers from writing their own outer-interpreter, because you don't want common ANS-Forth programmers to write cross-compilers in competition with MPE.

I was looking through some old Jeff Fox emails and I found this:
------------------------------------------------------------------
It is nearly impossible to get Elizabeth to say anything
that isn't marketing language.  But eventually I got [her] to
say simply, "FORTH Inc. supports the standard and the
standard supports FORTH Inc."
------------------------------------------------------------------

This is what I have been saying --- ANS-Forth was always just a marketing gimmick from Forth Inc. to make it appear that Forth Inc. sets the standard for the entire Forth community --- and ANS-Forth was purposely crippled to trap the Forth community in a pitfall of incompetence, but if anybody writes Forth code competently then they get denounced for being non-standard. This is primarily why my MFX was ignored in the late 1990s --- the ANS-Forth crowd could denounce it because it was non-standard --- and the C crowd could denounce it because it was "Forth" which was considered to be a synonym for "stupid" due to ANS-Forth having made stupidity the standard or Forth in 1994.

[toc] | [prev] | [next] | [standalone]

#50536 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/28/2016 7:33 PM, hughaguilar96@gmail.com wrote:

> I was looking through some old Jeff Fox emails and I found this:
> ------------------------------------------------------------------
> It is nearly impossible to get Elizabeth to say anything
> that isn't marketing language.  But eventually I got [her] to
> say simply, "FORTH Inc. supports the standard and the
> standard supports FORTH Inc."
> ------------------------------------------------------------------
  "ANS Forth a guide to alternate realities" is a book that could deal 
with all these possibilities and alternate realities. Soon to be 
available at a store near you, in Hardback and eBook versions available 
soon.

Buy a dozen with a 20% discount,  and give it as a gift to your enemies, 
and relatives!
-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web