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

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

FORTH - How Does It Work?

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

Contents

  FORTH - How Does It Work? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-04 09:44 -0700
    FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-04 10:21 -0700
      Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-04 11:00 -0700
        Re: FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-05 03:03 -0700
        Re: FORTH - How Does It Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-05 11:31 +0000
      Re: FORTH - How Does It Work? lehs <skydda.barnen@gmail.com> - 2015-05-05 01:31 -0700
        Re: FORTH - How Does It Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-05 08:49 +0000
        Re: FORTH - How Does It Work? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-05-05 11:16 +0200
        Re: FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-05 02:33 -0700
    Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-04 08:49 -1000
      Re: FORTH - How Does It Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-04 19:13 +0000
        Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-04 20:35 +0100
          Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-04 10:43 -1000
          Re: FORTH - How Does It Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-05 08:52 +0000
            Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 10:54 +0100
              Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 10:56 +0100
        Re: FORTH - How Does It Work? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-05-04 20:01 -0400
          Re: FORTH - How Does It Work? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-04 17:23 -0700
          Re: FORTH - How Does It Work? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-04 17:34 -0700
            Re: FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-05 00:25 -0700
              Re: FORTH - How Does It Work? Coos Haak <chforth@hccnet.nl> - 2015-05-05 12:41 +0200
            Re: FORTH - How Does It Work? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-05-05 03:31 -0400
              Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 08:41 +0100
          Re: FORTH - How Does It Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-05 11:36 +0000
      Re: FORTH - How Does It Work? "HAA" <someone@microsoft.com> - 2015-05-07 11:26 +1000
        Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-06 16:46 -1000
          Re: FORTH - How Does It Work? lehs <skydda.barnen@gmail.com> - 2015-05-07 00:06 -0700
          Re: FORTH - How Does It Work? "HAA" <someone@microsoft.com> - 2015-05-10 12:57 +1000
            Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-09 21:36 -0700
            Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-09 18:36 -1000
              Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-09 22:09 -0700
                Re: FORTH - How Does It Work? Walter Banks <walter@bytecraft.com> - 2015-05-10 13:38 -0400
                  Re: FORTH - How Does It Work? Richard Owlett <rowlett@cloud85.net> - 2015-05-10 14:23 -0500
                    Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-10 20:51 +0100
                      Re: FORTH - How Does It Work? Coos Haak <chforth@hccnet.nl> - 2015-05-11 01:18 +0200
                      Apology to Walter Banks - was [Re: FORTH - How Does It Work?] Richard Owlett <rowlett@cloud85.net> - 2015-05-10 23:09 -0500
                        Re: Apology to Walter Banks - was [Re: FORTH - How Does It Work?] Walter Banks <walter@bytecraft.com> - 2015-05-11 07:24 -0400
                        Re: Apology to Walter Banks - was [Re: FORTH - How Does It Work?] rickman <gnuarm@gmail.com> - 2015-05-11 11:34 -0400
                  Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-10 19:18 -0700
                    Re: FORTH - How Does It Work? Walter Banks <walter@bytecraft.com> - 2015-05-11 07:50 -0400
                    Re: FORTH - How Does It Work? beeflo <beeflobill@gmail.com> - 2015-05-11 09:37 -0700
                      Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 11:32 -0700
                        Re: FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-12 05:21 -0700
                          Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 14:08 +0100
                            Re: FORTH - How Does It Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-12 14:52 +0000
                              Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 17:18 +0100
                                Re: FORTH - How Does It Work? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-05-13 08:41 +0200
                                  Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-13 08:07 +0100
                                  Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-13 19:29 -0700
                            Re: FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-12 08:10 -0700
                              Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 17:13 +0100
                              Re: FORTH - How Does It Work? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-12 09:33 -0700
                          Re: FORTH - How Does It Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-12 15:38 +0000
                          Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-12 21:51 -0700
                        Re: FORTH - How Does It Work? "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 16:05 +0000
                      Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-14 17:26 -0700
                        Re: FORTH - How Does It Work? bettilyona@gmail.com - 2015-06-02 10:21 -0700
                          Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-06-02 20:39 -0700
                            Re: FORTH - How Does It Work? bettilyona@gmail.com - 2015-06-08 13:14 -0700
                            Re: FORTH - How Does It Work? Hans Bezemer <the.beez.speaks@gmail.com> - 2015-06-20 13:15 +0200
                              Re: FORTH - How Does It Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 14:37 +0000
                              Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-06-20 08:23 -1000
                                Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-06-20 19:24 -0700
                                  Re: FORTH - How Does It Work? Hans Bezemer <the.beez.speaks@gmail.com> - 2015-06-21 12:30 +0200
                                  Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-06-21 20:58 +0100
                                    Re: FORTH - How Does It Work? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 00:13 +0200
              Re: FORTH - How Does It Work? "HAA" <someone@microsoft.com> - 2015-05-11 12:10 +1000
                Re: FORTH - How Does It Work? rickman <gnuarm@gmail.com> - 2015-05-11 11:35 -0400
                  Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 16:52 +0100
                    Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-11 08:12 -1000
                      Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 12:37 -0700
                        Re: FORTH - How Does It Work? Walter Banks <walter@bytecraft.com> - 2015-05-11 15:59 -0400
                          Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 21:34 +0100
                          Re: FORTH - How Does It Work? rickman <gnuarm@gmail.com> - 2015-05-11 16:42 -0400
                            Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 21:52 +0100
                              Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 14:55 -0700
                                Re: FORTH - How Does It Work? "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 16:22 +0000
                                  Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-12 22:42 -0700
                                    Re: FORTH - How Does It Work? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-13 11:18 -0700
                                  Re: FORTH - How Does It Work? "WJ" <w_a_x_man@yahoo.com> - 2015-05-25 15:04 +0000
                              Re: FORTH - How Does It Work? rickman <gnuarm@gmail.com> - 2015-05-11 20:38 -0400
                          Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 14:31 -0700
                            Re: FORTH - How Does It Work? Walter Banks <walter@bytecraft.com> - 2015-05-12 07:06 -0400
                        Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 21:30 +0100
                          Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 14:52 -0700
                            Re: FORTH - How Does It Work? rickman <gnuarm@gmail.com> - 2015-05-11 20:40 -0400
                              Re: FORTH - How Does It Work? Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-12 03:38 +0200
                                Re: FORTH - How Does It Work? rickman <gnuarm@gmail.com> - 2015-05-11 22:10 -0400
                                  Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 20:25 -0700
                                    Re: FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-12 01:13 -0700
                                      Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 11:03 +0100
                                        Re: FORTH - How Does It Work? Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-12 16:08 +0200
                                  Re: FORTH - How Does It Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-12 14:04 +0000
                              Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 19:08 -0700
                                Re: FORTH - How Does It Work? rickman <gnuarm@gmail.com> - 2015-05-11 22:46 -0400
                  Re: FORTH - How Does It Work? "HAA" <someone@microsoft.com> - 2015-05-14 18:30 +1000
                    Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-13 22:55 -1000
                      Re: FORTH - How Does It Work? "HAA" <someone@microsoft.com> - 2015-05-16 05:08 +1000
                        Re: FORTH - How Does It Work? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-15 09:54 -1000
                          Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-20 13:59 -0700
                    Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 10:40 +0100
                      Re: FORTH - How Does It Work? Mark Wills <markwills1970@gmail.com> - 2015-05-14 03:12 -0700
                        Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 12:03 +0100
              Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-10 22:09 -0700
                Re: FORTH - How Does It Work? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-11 10:12 -0700
                  Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 18:57 +0100
                    Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-11 11:48 -0700
                      Re: FORTH - How Does It Work? "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 20:28 +0100
                        Re: FORTH - How Does It Work? hughaguilar96@gmail.com - 2015-05-12 21:28 -0700
          Re: FORTH - How Does It Work? rickman <gnuarm@gmail.com> - 2015-05-11 11:29 -0400
    Re: FORTH - How Does It Work? Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-05-04 19:40 -0700
    Re: FORTH - How Does It Work? tthomas@duelcraft2.com - 2015-05-08 16:22 -0700

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

#38978

On Sunday, May 10, 2015 at 8:18:08 PM UTC-6, hughag...@gmail.com wrote:
> On Sunday, May 10, 2015 at 10:38:35 AM UTC-7, Walter Banks wrote:
> > On 10/05/2015 1:09 AM, hughaguilar96wrote:
> > > Anton Ertl is just a puppet. He is currently making the ridiculous claim
> > > that it is ANS-Forth compliant for FIND to abort when given certain words
> > > (IF, semicolon, etc.).
> > > https://groups.google.com/forum/#!topic/comp.lang.forth/oXXQAGDKP7w%5B1-25%5D
> > > He is just making a fool out of himself in public --- this is obviously
> > > being done to prevent people from writing a outer-interpreter in gForth, 
> > > meaning that they can't write a cross-compiler in gForth in competition
> > > with Forth Inc. and MPE. I defeated him with my disambiguifiers though ---
> > > now FIND works correctly for all words in the dictionary in both VFX 
> > > and gForth.
> 
> > You clearly don't know how standards groups work.
> 
> A standards group is supposed to represent the programming community. 
> 
> The ANS-Forth standard gives us section 4.1.2. ("Ambiguous Conditions"). It says this is an ambiguous condition: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."
> 
> So, what part of the Forth community asked for this? Apparently, when the ANS-Forth committee was in meeting, there were Forth programmers marching in the street outside with signs that said: "Give us ambiguity or give us undefined behavior!"
> 
> Forth programmers from around the world were sending in emails daily that said: "We hate it when FIND returns an xt for every word in the dictionary and also tells us if it is immediate or non-immediate. We demand that FIND should either abort on some of the words, or should return an xt that aborts when executed. We also demand that words like IF should sometimes be immediate and sometimes be non-immediate, in the event that they have an xt --- of course, if FIND just aborts on them, then nobody knows if they are immediate or non-immediate, which is ever better."
> 
> Forth programmers were crying: "It is wrong for us to write cross-compilers! We shouldn't be allowed! This is unfair competition for Forth Inc. and MPE. But we can't stop ourselves from doing it, so we demand that ANS-Forth be crippled with a FIND that fails about half the time, giving us a baffling error-message. This is the only way that we can squelch our urge to write Forth programs that could be sold for money."
> 
> All of this is total baloney! Every Forth programmer wants FIND to work correctly. Anton Ertl's wild claims about how Forth is ambiguous and undefined are just whitewash for sabotage. ANS-Forth is cripple-ware --- it was sabotaged with a FIND that doesn't work correctly about half the time --- this was done to prevent people from writing cross-compilers in competition with the corporate big-dollar cross-compilers.

The standards also are helpful in helping people learn forth.  It would be nice to have 25 years of forth hacking experience, having seen umpteen variations of forth, many of them derivatives of earlier ones. But to someone who doesn't have that benefit, a standard is a great place to start.  

That's true even if forth experts think the standard isn't perfect (or worse) because they have abstruse ideas about what for is, is not, or should be.

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

#38983

On Monday, May 11, 2015 at 9:37:40 AM UTC-7, beeflo wrote:
> On Sunday, May 10, 2015 at 8:18:08 PM UTC-6, hughag...@gmail.com wrote:
> > On Sunday, May 10, 2015 at 10:38:35 AM UTC-7, Walter Banks wrote:
> > > On 10/05/2015 1:09 AM, hughaguilar96wrote:
> > > > Anton Ertl is just a puppet. He is currently making the ridiculous claim
> > > > that it is ANS-Forth compliant for FIND to abort when given certain words
> > > > (IF, semicolon, etc.).
> > > > https://groups.google.com/forum/#!topic/comp.lang.forth/oXXQAGDKP7w%5B1-25%5D
> > > > He is just making a fool out of himself in public --- this is obviously
> > > > being done to prevent people from writing a outer-interpreter in gForth, 
> > > > meaning that they can't write a cross-compiler in gForth in competition
> > > > with Forth Inc. and MPE. I defeated him with my disambiguifiers though ---
> > > > now FIND works correctly for all words in the dictionary in both VFX 
> > > > and gForth.
> > 
> > > You clearly don't know how standards groups work.
> > 
> > A standards group is supposed to represent the programming community. 
> > 
> > The ANS-Forth standard gives us section 4.1.2. ("Ambiguous Conditions"). It says this is an ambiguous condition: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."
> > 
> > So, what part of the Forth community asked for this? Apparently, when the ANS-Forth committee was in meeting, there were Forth programmers marching in the street outside with signs that said: "Give us ambiguity or give us undefined behavior!"
> > 
> > Forth programmers from around the world were sending in emails daily that said: "We hate it when FIND returns an xt for every word in the dictionary and also tells us if it is immediate or non-immediate. We demand that FIND should either abort on some of the words, or should return an xt that aborts when executed. We also demand that words like IF should sometimes be immediate and sometimes be non-immediate, in the event that they have an xt --- of course, if FIND just aborts on them, then nobody knows if they are immediate or non-immediate, which is ever better."
> > 
> > Forth programmers were crying: "It is wrong for us to write cross-compilers! We shouldn't be allowed! This is unfair competition for Forth Inc. and MPE. But we can't stop ourselves from doing it, so we demand that ANS-Forth be crippled with a FIND that fails about half the time, giving us a baffling error-message. This is the only way that we can squelch our urge to write Forth programs that could be sold for money."
> > 
> > All of this is total baloney! Every Forth programmer wants FIND to work correctly. Anton Ertl's wild claims about how Forth is ambiguous and undefined are just whitewash for sabotage. ANS-Forth is cripple-ware --- it was sabotaged with a FIND that doesn't work correctly about half the time --- this was done to prevent people from writing cross-compilers in competition with the corporate big-dollar cross-compilers.
> 
> The standards also are helpful in helping people learn forth.  It would be nice to have 25 years of forth hacking experience, having seen umpteen variations of forth, many of them derivatives of earlier ones. But to someone who doesn't have that benefit, a standard is a great place to start.  

Since the standard is such a great place to start, lets start here:

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

We have already learned a lot! But, what is an "ambiguous condition?" We can read about that here:

4.1.2 Ambiguous conditions
- attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics;
...
- interpretating (sic) a word with undefined interpretation semantics;
...

All of this is nonsense! We shouldn't have any "ambiguous conditions or undefined semantics." It should just be an error to execute words like IF and ; etc. in interpretation mode (STATE is zero). This is not ambiguous in the sense that pretty much anything could happen and not the same thing every time --- this is an error in the sense that the system aborts with an error message. Also, there is no reason to cripple FIND and ' so that it is an ambiguous condition if they are applied to a word that can't execute in interpretation mode. FIND should just return the xt and a flag of 1 to indicate that it is immediate (all of these words such as IF etc. that currently are defined as "interpretation semantics for this word are undefined" should just be defined as immediate and should just abort with an error message if they are used in interpretation mode). If the xt is given to EXECUTE and executed, it checks STATE and aborts if it is in interpretation mode but executes if it is in compilation mode. I have explained the situation as it should be in one paragraph using plain English so that any novice should be able to understand. The ANS-Forth standard is not a good place to learn Forth however, because everything is "ambiguous" and "undefined" and the novice (expert too) is left feeling baffled, bewildered and bamboozled.

Since reading the standard is a great way to learn Forth, lets learn what we can about the control-flow stack:

3.2.3.2 
...
The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed.

So, what exactly have we learned? The ANS-Forth standards says, "If [the control-flow stack] does exist, it may be, but need not be, implemented using the data stack." A more careful reading indicates however, that the programmer has to assume that it is the data-stack: "Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed." So why not just define it as being the data-stack? What was the point of saying that it may be a distinct stack, if the programmer has to assume that it isn't? 

Obviously, somebody on the ANS-Forth standards committee understood that the control-flow stack should be a distinct stack. That person didn't have enough authority to make ANS-Forth define it as being a distinct stack, so we get this wishy-washy nonsense that ultimately means that it has to be treated as if it were the data-stack --- the worst-case scenario becomes the standard!

So, for 20 years, all ANS-Forth programmers have been required to work-around the problem of the control-flow data being on top of the user's data on the data-stack (although the data-stack is supposed to be for, you know: data). For example, we have this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/THP64AeGuS0
In here, the ever self-satisfied Bernd Payson can be seen writing an awkward work-around for the problem:

On Sunday, March 22, 2015 at 2:11:03 PM UTC-7, Bernd Paysan wrote:
> Paul Rubin wrote:
> 
> > Bernd Paysan <bernd.paysan@gmx.de> writes:
> >> Of course Forth has first-class functions.  We call them "xt", execution
> >> tokens.  You can pass them as parameters to other words, you can return
> >> an xt as result of a word, you can use xts to define higher order
> >> functions.
> > 
> > Hmm, ok, I hadn't thought of xt's as first-class functions but maybe
> > they are.  Is it possible to create them at runtime?  I.e. is there an
> > ANS portable way to do something like:
> > 
> >     \ given functions f and g, make a new function that composes them
> >     : compose ( xt1 xt2 -- xt3 ) .... ;
> > 
> > So this should work:
> > 
> >    ['] sin ['] sqrt compose constant sin-sqrt      => ok
> > 
> >    2e sin-sqrt execute f.       => 0.9877659459927356 ok
> > 
> > That number is sin(sqrt(2)).  "Compose" has made a new xt that combines
> > the actions of the previous two.  It's like adding two numbers in order
> > to create a new number.  I'd say that to call xt's first class
> > functions, you have to be able to do this.
> 
> Sure, no doubts about that.  So let's do it:
> 
> : compose ( xt1 xt2 -- xt3 ) swap >r >r
>   :noname r> compile, r> compile, postpone ; ;
> 
> Fixing the bugs in your code, to test it:
> 
> ' fsin ' fsqrt compose constant sin-sqrt  ok
> 2e sin-sqrt execute f. 0.987765945992736  ok
> 
> Are you happy with that?
> 
> -- 
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> http://bernd-paysan.de/
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

No, actually, I'm not happy with that. The use of the return-stack is just a crude work-around for the problem that the data-stack can't be used for data. Bernd Payson is obviously aware of the problem in ANS-Forth because he works around it in his code, but he refuses to fix the problem in Forth-200x. Bernd Payson, like all of the Forth-200x committee members, only does what Leon Wagner tells him to do --- until Leon Wagner says that this problem should be fixed, it won't be fixed --- and this will never happen because nobody at Forth Inc. knows what meta-compiling is.

> That's true even if forth experts think the standard isn't perfect (or worse) because they have abstruse ideas about what for is, is not, or should be.

Well, I had to look up "abstruse" (my English is not as refined as yours). I found this definition: "difficult to understand; obscure." --- I don't think this describes my ideas about Forth, which are pretty straight-forward --- I think this describes the ANS-Forth document ("occult" is another good word, which is more in keeping with my statement that ANS-Forth is a cult).

I'm actually a very blue-collar type of guy --- I originally got into Forth (in 1984) because it was simple and easy to understand (compared to C or Pascal), and when I programmed in Forth professionally (in 1994) I was able to write a cross-compiler primarily because Forth was simple and easy to understand (which continued to be untrue of C or Pascal, even more so 10 years later) --- when ANS-Forth came out however, Forth suddenly became abstruse and just plain bizarre, making C look simple by comparison (and, Forth simultaneously became extremely unpopular, so there was no longer any economic reason to learn it).

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

#39017

On Monday, 11 May 2015 19:32:56 UTC+1, hughag...@gmail.com  wrote:
> 
> All of this is nonsense! We shouldn't have any "ambiguous conditions or undefined semantics." It should just be an error to execute words like IF and ; etc. in interpretation mode (STATE is zero). This is not ambiguous in the sense that pretty much anything could happen and not the same thing every time --- this is an error in the sense that the system aborts with an error message. Also, there is no reason to cripple FIND and ' so that it is an ambiguous condition if they are applied to a word that can't execute in interpretation mode. FIND should just return the xt and a flag of 1 to indicate that it is immediate (all of these words such as IF etc. that currently are defined as "interpretation semantics for this word are undefined" should just be defined as immediate and should just abort with an error message if they are used in interpretation mode). If the xt is given to EXECUTE and executed, it checks STATE and aborts if it is in interpretation mode but executes if it is in compilation mode. I have explained the situation as it should be in one paragraph using plain English so that any novice should be able to understand. 

Agree. It should be the business of the word itself to abort if invoked
in the wrong the state. It is not the business of subordinate words such
as ' and FIND.

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

#39018

on 12/05/2015 13:20:55, Mark Wills wrote:
> On Monday, 11 May 2015 19:32:56 UTC+1, hughag...@gmail.com  wrote:
>>
>> All of this is nonsense! We shouldn't have any "ambiguous conditions or u
> ndefined semantics." It should just be an error to execute words like
> IF an d ; etc. in interpretation mode (STATE is zero). This is not
> ambiguous in t he sense that pretty much anything could happen and not
> the same thing ever y time --- this is an error in the sense that the
> system aborts with an err or message. Also, there is no reason to
> cripple FIND and ' so that it is an ambiguous condition if they are
> applied to a word that can't execute in in terpretation mode. FIND
> should just return the xt and a flag of 1 to indica te that it is
> immediate (all of these words such as IF etc. that currently are
> defined as "interpretation semantics for this word are undefined"
> shoul d just be defined as immediate and should just abort with an
> error message if they are used in interpretation mode). If the xt is
> given to EXECUTE and executed, it checks STATE and aborts if it is in
> interpretation mode but e xecutes if it is in compilation mode. I have
> explained the situation as it should be in one paragraph using plain
> English so that any novice should be able to understand.
> 
> Agree. It should be the business of the word itself to abort if
> invoked in the wrong the state. It is not the business of subordinate
> words such as ' and FIND.
> 

Have you read the spec for ' and FIND? I don't know where you are getting
this from, but neither ' nor FIND in any ANS Forth (in fact, in any Forth
I've heard of) do an ABORT if the word is found but has undefined
interpretation semantics. FIND returns at XT and a flag, or the original
string and a flag if not found; and ' returns the XT and only aborts if
the word is not found.

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

#39024

"Alex McDonald" <blog@rivadpm.com> writes:
>Have you read the spec for ' and FIND? I don't know where you are getting
>this from, but neither ' nor FIND in any ANS Forth (in fact, in any Forth
>I've heard of) do an ABORT if the word is found but has undefined
>interpretation semantics.

In Gforth ticking compile-only words produces an error.

In Gforth 0.7.0:
' if 
:1: Cannot tick compile-only word (try COMP' ... DROP)
' >>>if<<<

(The current development version gives a less refined error message).

The error message resulted in several complaints; the complainers probably
expected an xt of a word representing the compilation semantics, same
as if the word had just been defined IMMEDIATE without COMPILE-ONLY.
Maybe that would have been the better option.

FINDing a compile-only word in interpret state does not produce an
error in Gforth (and should not in any Forth IMO, if FIND is to be
useful for a text interpreter), but gives the xt of a word that
produces an error when executed:

:noname c" if" ; execute find cr . execute
1 
:3: Interpreting a compile-only word
:noname c" if" ; execute find cr . >>>execute<<<

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39029

on 12/05/2015 15:52:07,  wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>Have you read the spec for ' and FIND? I don't know where you are getting
>>this from, but neither ' nor FIND in any ANS Forth (in fact, in any Forth
>>I've heard of) do an ABORT if the word is found but has undefined
>>interpretation semantics.
> 
> In Gforth ticking compile-only words produces an error.
> 
> In Gforth 0.7.0:
> ' if
>:1: Cannot tick compile-only word (try COMP' ... DROP)
> ' >>>if<<<
> 
> (The current development version gives a less refined error message).
> 
> The error message resulted in several complaints; the complainers
> probably expected an xt of a word representing the compilation
> semantics, same as if the word had just been defined IMMEDIATE without
> COMPILE-ONLY. Maybe that would have been the better option.

The behaviour of ' IF in gforth does seem to fly in the face of the
standard, since it states

<quote>
Skip leading space delimiters. Parse name delimited by a space. Find name
and return xt, the execution token for name. An ambiguous condition
exists if name is not found. When interpreting, ’ xyz EXECUTE is
equivalent to xyz. </quote>

I expect ' <word> not to surprise me and having ' IF fail and not return
an xt is one surprise too many. OK, there are no execution semantics for
IF (in the strict sense of no interpretation semantics) but there is a
name and it is found, and the result should be an XT, even if executing
it does cause stuff to fly out of your nose.

I can't see any other reading.

> 
> FINDing a compile-only word in interpret state does not produce an
> error in Gforth (and should not in any Forth IMO, if FIND is to be
> useful for a text interpreter), but gives the xt of a word that
> produces an error when executed:
> 
>:noname c" if" ; execute find cr . execute
> 1
>:3: Interpreting a compile-only word
>:noname c" if" ; execute find cr . >>>execute<<<
> 
> - anton

That's what I expected.

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

#39066

Alex McDonald wrote:
>> In Gforth 0.7.0:
>> ' if
>>:1: Cannot tick compile-only word (try COMP' ... DROP)
>> ' >>>if<<<
>
> The behaviour of ' IF in gforth does seem to fly in the face of the
> standard, since it states
>
> <quote>
> Skip leading space delimiters. Parse name delimited by a space. Find name
> and return xt, the execution token for name. An ambiguous condition
> exists if name is not found. When interpreting, ’ xyz EXECUTE is
> equivalent to xyz. </quote>

It also states:

  4.1.2 Ambiguous conditions

  [...]
  * attempting to obtain the execution token, (e.g., with 6.1.0070 ',
  6.1.1550 FIND, etc.) of a definition with undefined interpretation
  semantics

And:

  6.1.1700 IF

  Interpretation: Interpretation semantics for this word are undefined.

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

#39067

on 13/05/2015 07:41:48, Lars Brinkhoff wrote:
> Alex McDonald wrote:
>>> In Gforth 0.7.0:
>>> ' if
>>>:1: Cannot tick compile-only word (try COMP' ... DROP)
>>> ' >>>if<<<
>>
>> The behaviour of ' IF in gforth does seem to fly in the face of the
>> standard, since it states
>>
>> <quote>
>> Skip leading space delimiters. Parse name delimited by a space. Find name
>> and return xt, the execution token for name. An ambiguous condition
>> exists if name is not found. When interpreting, ’ xyz EXECUTE is
>> equivalent to xyz. </quote>
> 
> It also states:
> 
> 4.1.2 Ambiguous conditions
> 
> [...]
> * attempting to obtain the execution token, (e.g., with 6.1.0070 ',
> 6.1.1550 FIND, etc.) of a definition with undefined interpretation
> semantics
> 
> And:
> 
> 6.1.1700 IF
> 
> Interpretation: Interpretation semantics for this word are undefined.
> 

Thanks, I missed that. It's not the first time.

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

#39098

On Tuesday, May 12, 2015 at 11:57:19 PM UTC-7, Lars Brinkhoff wrote:
> Alex McDonald wrote:
> >> In Gforth 0.7.0:
> >> ' if
> >>:1: Cannot tick compile-only word (try COMP' ... DROP)
> >> ' >>>if<<<
> >
> > The behaviour of ' IF in gforth does seem to fly in the face of the
> > standard, since it states
> >
> > <quote>
> > Skip leading space delimiters. Parse name delimited by a space. Find name
> > and return xt, the execution token for name. An ambiguous condition
> > exists if name is not found. When interpreting, ' xyz EXECUTE is
> > equivalent to xyz. </quote>
> 
> It also states:
> 
>   4.1.2 Ambiguous conditions
> 
>   [...]
>   * attempting to obtain the execution token, (e.g., with 6.1.0070 ',
>   6.1.1550 FIND, etc.) of a definition with undefined interpretation
>   semantics
> 
> And:
> 
>   6.1.1700 IF
> 
>   Interpretation: Interpretation semantics for this word are undefined.

My disambiguifiers defeat the ANS-Forth committee:

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

Now you can FIND or tick IF --- this works on all 56 of the words in the ANS-Forth document that say: "Interpretation semantics for this word are undefined."

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

#39025

On Tuesday, 12 May 2015 14:08:42 UTC+1, Alex McDonald  wrote:
> > Agree. It should be the business of the word itself to abort if
> > invoked in the wrong the state. It is not the business of subordinate
> > words such as ' and FIND.
> > 
> 
> Have you read the spec for ' and FIND? I don't know where you are getting
> this from, but neither ' nor FIND in any ANS Forth (in fact, in any Forth
> I've heard of) do an ABORT if the word is found but has undefined
> interpretation semantics. FIND returns at XT and a flag, or the original
> string and a flag if not found; and ' returns the XT and only aborts if
> the word is not found.

See Bernd's post.

From Bernd's post:

"Looks similar, but is not the same. ' IF already fails, the EXECUTE part is 
not even reached.  You could interpret that statement of the standard that 
EXECUTE should do the actual action (here: throwing an error), in Gforth, 
it's ' which throws the error. "

Bernd himself says that when given:

' IF EXECUTE

EXECUTE is not even reached. ' does the abort. Therefore, in the case
of GForth, ' <word> execute is not (always) equivalent. Even when
interpreting.

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

#39028

on 12/05/2015 16:10:07, Mark Wills wrote:
> On Tuesday, 12 May 2015 14:08:42 UTC+1, Alex McDonald  wrote:
>> > Agree. It should be the business of the word itself to abort if
>> > invoked in the wrong the state. It is not the business of subordinate
>> > words such as ' and FIND.
>> >
>>
>> Have you read the spec for ' and FIND? I don't know where you are getting
>> this from, but neither ' nor FIND in any ANS Forth (in fact, in any Forth
>> I've heard of) do an ABORT if the word is found but has undefined
>> interpretation semantics. FIND returns at XT and a flag, or the original
>> string and a flag if not found; and ' returns the XT and only aborts if
>> the word is not found.
> 
> See Bernd's post.
> 
> From Bernd's post:
> 
> "Looks similar, but is not the same. ' IF already fails, the EXECUTE
> part is not even reached. You could interpret that statement of the
> standard that EXECUTE should do the actual action (here: throwing an
> error), in Gforth, it's ' which throws the error. "
> 
> Bernd himself says that when given:
> 
> ' IF EXECUTE
> 
> EXECUTE is not even reached. ' does the abort. Therefore, in the case
> of GForth, ' <word> execute is not (always) equivalent. Even when
> interpreting.
> 
> 

I've just seen Anton's posts on the subject, and apologise for getting it
wrong here. I'll cover in a reply to him.

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

#39031

People are really getting TICKed off in here. 
:^)

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

#39027

Mark Wills <markwills1970@gmail.com> writes:
>Agree. It should be the business of the word itself to abort if invoked
>in the wrong the state.

On the contrary.  STATE-smart words check STATE at the wrong time
(during execution), and you usually don't want that if you tick or
POSTPONE them.  When text-interpreting, you don't notice the
difference (because then FIND and EXECUTE happen in the same STATE),
that's why many people fall into this trap.

For more information, read 

@InProceedings{ertl98,
  author = 	 {M. Anton Ertl},
  title = 	 {\texttt{State}-smartness --- Why it is Evil and How
                  to Exorcise it},
  booktitle = 	 {EuroForth'98 Conference Proceedings},
  year =	 {1998},
  address =	 {Schlo\ss{} Dagstuhl},
  url = 	 {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
  abstract = 	 {\texttt{State}-smart words provide a number of unpleasant
                  surprises to their users. They are applied in two
                  contexts, and they fail in both: 1) for providing an
                  arbitrary combination of interpretation and
                  compilation semantics; 2) for optimizing with a
                  special implementation of the (default) compilation
                  semantics. This paper discusses these issues and
                  shows programmers and system implementors how to
                  avoid \texttt{state}-smart words. It also reports our
                  experiences in converting the \texttt{state}-smart
                  words in Gforth into a clean solution: little work
                  and few problems.}
}

Overall, my recommendation ist to avoid anything that makes you think
about using STATE, SET-COMPILER, or SET-COMPSEM (proper use of
SET-COMPILER is ok, but the danger is that you use it improperly).

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39063

On Tuesday, May 12, 2015 at 5:21:01 AM UTC-7, Mark Wills wrote:
> On Monday, 11 May 2015 19:32:56 UTC+1, hughag...@gmail.com  wrote:
> > 
> > All of this is nonsense! We shouldn't have any "ambiguous conditions or undefined semantics." It should just be an error to execute words like IF and ; etc. in interpretation mode (STATE is zero). This is not ambiguous in the sense that pretty much anything could happen and not the same thing every time --- this is an error in the sense that the system aborts with an error message. Also, there is no reason to cripple FIND and ' so that it is an ambiguous condition if they are applied to a word that can't execute in interpretation mode. FIND should just return the xt and a flag of 1 to indicate that it is immediate (all of these words such as IF etc. that currently are defined as "interpretation semantics for this word are undefined" should just be defined as immediate and should just abort with an error message if they are used in interpretation mode). If the xt is given to EXECUTE and executed, it checks STATE and aborts if it is in interpretation mode but executes if it is in compilation mode. I have explained the situation as it should be in one paragraph using plain English so that any novice should be able to understand. 
> 
> Agree. It should be the business of the word itself to abort if invoked
> in the wrong the state. It is not the business of subordinate words such
> as ' and FIND.

It has always been a fundamental principle of Forth that there is no syntax. Words like IF ; BEGIN etc. aren't a part of the language, in the sense that the outer-interpreter special-cases them --- all of the knowledge of what the word means, is contained within the word itself. 

The only thing that the outer-interpreter knows about any word is that it is immediate or non-immediate. During compilation it executes the immediate ones (with EXECUTE) and it compiles the non-immediate ones (with COMPILE,) --- words like IF ; BEGIN etc. are immediate, so they execute at compile-time --- the immediate words are supposed to know how to compile appropriate code to represent their concept.

If a word like IF ; BEGIN etc. gets executed in interpretation mode, the word should know enough about itself to abort with an error message. Some words, such as S" are state-smart and they can execute meaningfully in interpretation mode, but they have to know this about themselves. 

As Anton and pretty much everybody else has pointed out, state-smart words are problematic. This is why ' isn't state-smart anymore, but now we have ' for interpretation-mode and ['] for compilation mode. I agree that state-smart words are a bad idea, and I would like to get rid of them altogether --- but this has nothing to do with the present argument of whether Forth should have syntax or not.

It is really fundamental that Forth not have syntax --- the outer-interpreter should only know if words are immediate or non-immediate --- this is called "information hiding" and it is a pillar of computer science, without which almost all programming would fail and we would be back to COBOL and Fortran of the 1960s.

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

#39026

hughaguilar96@gmail.com wrote:

> when ANS-Forth came out however, Forth suddenly
> became abstruse and just plain bizarre, making C
> look simple by comparison (and, Forth simultaneously
> became extremely unpopular, so there was no longer
> any economic reason to learn it).

It was my impression at the time that ANS-Forth took
the fun out of Forth.

And I believe that after ANS-Forth the number of Forth
vendors declined drastically.

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

#39127

On Monday, May 11, 2015 at 9:37:40 AM UTC-7, beeflo wrote:
> The standards also are helpful in helping people learn forth.  It would be nice to have 25 years of forth hacking experience, having seen umpteen variations of forth, many of them derivatives of earlier ones. But to someone who doesn't have that benefit, a standard is a great place to start.  
> 
> That's true even if forth experts think the standard isn't perfect (or worse) because they have abstruse ideas about what for is, is not, or should be.

I don't think it is a good idea for any aspiring Forth programmer to learn ANS-Forth, because the brave novice will get his concept of Forth corrupted; he will never understand the fundamental principle of Forth if all he knows is ANS-Forth.

ANS-Forth betrayed the idea that Forth should not have syntax. The outer-interpreter doesn't *know* about words such as IF and ; etc., so they are not syntax in Forth. The outer-interpreter only knows what a words xt is, and whether the word is immediate or non-immedate (it uses FIND to find this out on every space-delimited string in the input-stream), and it only knows that in compilation mode the non-immediate words are given to COMPILE, and the immediate words are given to EXECUTE --- and in interpretation mode both kinds of words are given to EXECUTE. Charles Moore may have his faults, but this idea was really genius-level thinking --- all of the complicated syntax of other languages (Fortran, COBOL, C, etc.) got wiped away --- everything became simple and understandable; this idea is truly the heart of Forth.

Nobody on the ANS-Forth committee understood this fundamental idea. ANS-Forth is a language with syntax. All 56 of the words that I redefine with my disambiguifiers are special-cased either by FIND (gForth) or by COMPILE, (VFX), and according to the ANS-Forth standard, using tick or FIND on them results in an ambiguous condition. This is a gross betrayal of the fundamental principle that Forth doesn't have syntax. The cause of this problem is that Elizabeth Rather's only programming experience prior to becoming the chairperson of the ANS-Forth committee, was as a COBOL programmer. She didn't understand the fundamental principle that made Forth different from other languages (Fortran, COBOL, C, etc.), and she strove to give ANS-Forth a syntax similar to COBOL that she was familiar with.

Charles Moore knew that the fundamental principle couldn't be adhered to totally. Some words need to extract text from the input stream and use it. These include ' CHAR \ ( etc. --- but soon it became apparent that they should not be state-smart, so we got ['] and [CHAR] for compilation mode and ' and CHAR for interpretation mode. The ['] and [CHAR] still are a kind of syntax because they are reading from the input stream, but they work okay. For the most part, it is best to avoid these syntactical words though. The ANS-Forth committee, in a complete failure to understand the fundamental principle, gratuitously added TO to this list of words however.

Now we have the two leaders of Forth-200x, Bernd Payson and Anton Ertl, continuing to fail to understand the fundamental principle of Forth. They want TO to be polymorphic and to compile different code depending upon the data-type of the variable that it is working with. This is just increasing the complexity of TO --- they should just discard TO because it is already a betrayal of the fundamental principle of Forth, which is that the language should not have syntax.  

In this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/-oys3Hf2PkM%5B101-125%5D

We have this:

On Wednesday, May 13, 2015 at 7:23:14 PM UTC-7, hughag...@gmail.com wrote:
> On Wednesday, May 13, 2015 at 6:27:14 PM UTC-7, Bernd Paysan wrote:
> > Anton Ertl wrote:
> > 
> > > Bernd Paysan <bernd.paysan@gmx.de> writes:
> > >>That pattern works for literals and also for the to-recognizer, where the
> > >>final action is just ! (however, which ! depends on the data type of the
> > >>value... and the literal-like does so, too, so it's not that simple).
> > > 
> > > Yes, but that's a problem coming of wanting a to-recognizer, that,
> > > like TO, applies to lots of different kinds of words.  So you have to
> > > make the recognizer polymorphic, like TO.
> > 
> > The current way is just reusing the polymorphic part of TO, which interprets 
> > or compiles the correct stuff.
> 
> The Forth-200x committee makes even the simplest problem sooooooooo complicated! Rube Goldberg would be proud!
> 
> Get rid of TO altogether. Make local variables provide an address. Make each local variable big enough to hold a char, single-cell, double-cell or float variable. Then store your data with c! ! 2! or F! --- as the "Thinking Forth" book says: "Let the dictionary do the deciding."
> 
> Duh!
> 
> > Bernd Paysan
> > "If you want it done right, you have to do it yourself"
> 
> You should change your tag-line to read:
> "If you want it done in the most over-complicated and feature-bereft manner possible, you have to have Bernd do it!"

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

#39524

On Thursday, May 14, 2015 at 6:26:50 PM UTC-6, hughag...@gmail.com wrote:
> On Monday, May 11, 2015 at 9:37:40 AM UTC-7, beeflo wrote:
> > The standards also are helpful in helping people learn forth.  It would be nice to have 25 years of forth hacking experience, having seen umpteen variations of forth, many of them derivatives of earlier ones. But to someone who doesn't have that benefit, a standard is a great place to start.  
> > 
> > That's true even if forth experts think the standard isn't perfect (or worse) because they have abstruse ideas about what for is, is not, or should be.
> 
> I don't think it is a good idea for any aspiring Forth programmer to learn ANS-Forth, because the brave novice will get his concept of Forth corrupted; he will never understand the fundamental principle of Forth if all he knows is ANS-Forth.

I'm corrupted.  So, too bad.

But anyhow, I didn't mean to single you out by calling your arguments abstruse. I meant that for every expert here, and I didn't mean it to be offensive.  It just is.  Computing is complex.

The aspect of forth which makes it simple is also what makes it complex.  It enables the programmer to simultaneously consider low level and high level code.  That is what I think is the dream of computation.

Consider this situation - A man drew a picture which was simple enough for everyone to draw, and everybody liked it.  He encouraged others to draw it, but most of them drew it differently. Then he became angry because the picture was lost.

Was the picture lost?  Were the people better or worse off in this situation even though the guy was unhappy?  Why did he become angry?

I don't think the goal of existence (or computing) is minimalism.  Minimal things are often beautiful and helpful, but complete minimalism is nothing and useless.  Life is more than a 2kB program.

I'm sure Judas did some wonderful things, but he didn't betray Jesus because he was thrifty.  He betrayed Jesus because he was jealous.

Best of luck.

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

#39533

On Tuesday, June 2, 2015 at 10:21:09 AM UTC-7, betti...@gmail.com wrote:
> On Thursday, May 14, 2015 at 6:26:50 PM UTC-6, hughag...@gmail.com wrote:
> > I don't think it is a good idea for any aspiring Forth programmer to learn ANS-Forth, because the brave novice will get his concept of Forth corrupted; he will never understand the fundamental principle of Forth if all he knows is ANS-Forth.
> 
> I'm corrupted.  So, too bad.
> 
> But anyhow, I didn't mean to single you out by calling your arguments abstruse. I meant that for every expert here, and I didn't mean it to be offensive.  It just is.  Computing is complex.
> 
> The aspect of forth which makes it simple is also what makes it complex.  It enables the programmer to simultaneously consider low level and high level code.  That is what I think is the dream of computation.

A simple design at a fundamental level allows for complexity to be built on top of it. Originally Forth didn't have any syntax in the sense that the language knew about words such as IF but rather the immediate words knew how to compile themselves. This allowed all of the control structures and so forth to be provided, while keeping the fundamental language simple, and making the language extensible so common programmers could write their own control structures (such extensibility is unheard of in other languages such as C that have only #DEFINE for string-expansion).

Now the ANS-Forth committee and the Forth-200x committee have betrayed the fundamentals of Forth by giving Forth a syntax. Words like IF are now part of the language at a fundamental level. The result is that ANS-Forth is crippled in that we can no longer tick words and get an xt value for them. ANS-Forth is really no better than C now, so there isn't any argument against just using C like everybody else.

> Consider this situation - A man drew a picture which was simple enough for everyone to draw, and everybody liked it.  He encouraged others to draw it, but most of them drew it differently. Then he became angry because the picture was lost.
> 
> Was the picture lost?  Were the people better or worse off in this situation even though the guy was unhappy?  Why did he become angry?
> 
> I don't think the goal of existence (or computing) is minimalism.  Minimal things are often beautiful and helpful, but complete minimalism is nothing and useless.  Life is more than a 2kB program.

You think that Forth not having syntax is minimalism and restricting. I've heard this before, mostly from C programmers --- their interpretation is that because Forth doesn't have syntax it can't have IF or anything else and is no better than hand-written machine-code. 

The exact opposite is true. Inherent complexity is restricting.

The idea of making Forth simple at a fundamental level, and putting the complexity in the words themselves (immediate words like IF that compile themselves) was genius-level thinking. Not all of Charles Moore's ideas are genius-level, and some of them are quite bad --- but this one idea was definitely genius-level.

Your analogy seems to be that Charles Moore's idea about having immediate words was comparable to drawing a stick-figure picture in five minutes with crayons, and that he then got angry when other people draw higher-quality artwork that garnered acclaim in the art shows. That is pretty insulting! I don't think you know what you are talking about --- you're a troll.

> I'm sure Judas did some wonderful things, but he didn't betray Jesus because he was thrifty.  He betrayed Jesus because he was jealous.

You've lost me on the Biblical analogy. 

I'm not a Christian, so I'm not going to debate Biblical interpretations, and this is pretty off-topic even by C.L.F.'s loose standards --- my impression though, is that you don't know any more about this subject than you do about Forth.

> Best of luck.

I know how to program in Forth --- so you've also lost me on your reference to luck.

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

#39642

> You've lost me on the Biblical analogy. 

I think we were talking different languages from the start. But, I think if you approached what I wrote with an open mind, you would find it rather clear.  If not, I'm sorry I wasn't clear.  

For the record, in my drawing story I *was not* talking about Chuck Moore.  I was just trying to show a situation where somebody had something good that was simple enough for everybody to understand well enough to change (like forth).  And that it didn't make sense to become angry about the situation.  Actually, I was thinking of the smiley-face symbol.  How often has that been changed?

Also for the record, I like forth and don't assume the ans-standard to be perfect.  But, I do not think it is my enemy.

Again for the record, my reference to Judas and Christ was not meant to be a bible argument or to attack people who aren't Christians.  It was to provide a way to think about the idea that an over zealous demand for minimalism is a symptom of jealousy.  I find that idea enlightening as I try to understand my own feelings, and perhaps unjustly, I was ascribing that to Hugh.

Hugh said, "my impression though, is that you don't know any more about this subject than you do about Forth".  I know that I have hopes and dreams.

I hope that by learning the language that it will help me in life.   I dream of a day when the whole computer system will be comprehensible as one (not in small part because of minimalism, elegance, and freedom).  I have seen others who strive for that dream as well.

Since you challenged my religion, I'll tell you something about it. I believe that one day we all will be restored to what we really are, deep down, and that much of what we are is what we strive to do each day.  So, when life gives us hopeless circumstances that we can't control, we ought not become bitter, angry, and fearful.  It isn't a good idea if we can help it.


I'm not your enemy,
Beeflo

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

#39882

hughaguilar96@gmail.com wrote:
> Now the ANS-Forth committee and the Forth-200x committee have betrayed the
> fundamentals of Forth by giving Forth a syntax. Words like IF are now part
> of the language at a fundamental level. The result is that ANS-Forth is
> crippled in that we can no longer tick words and get an xt value for them.
> ANS-Forth is really no better than C now, so there isn't any argument
> against just using C like everybody else.
Before I start off, I have to admit I'm feeling your frustration. So
consider this to be rather complementary to your argument than opposing.
The problem IMHO is that Chuck is a pragmatist - and "immediate" words are
IMHO a rather ugly patch. I think that if words had a "execution-token" and
a "compilation-token" things would have been more solid. If a word is
executed it is simply executed. If a word is compiled, it is compiled. Of
course, some words would have no interpretation or compilation semantics -
as it is now. And it would mean every single word is state-smart (which is
a horror to some, but greatly abstracts things for a "user").

If so, every word could be "ticked" and return ALWAYS its interpretation
semantics. It would probably also mean that [IF] and IF could be merged
into one single word. In this scheme it would mean that if you would want
to execute a word in compilation mode, it would require [ ], e.g.

: example < [ if ] ." smaller" [ else ] ." greater" [ then ] ;

(Of course I do not propose such a scheme, it is just an example of the
consequence of a rigid implementation of a scheme like that. IF would have
the compilation semantics of the current IF now. I think this is the very
reason Chuck choose for an "immediate" bit in the first place).

Through the years I have seen mindboggling constructs to illustrate the very
complex consequences of the current scheme ("immediate" bit) and endless
discusions of how a program should behave in a situation like that. My
scheme also blends in quite nicely with <BUILDS (compilation semantics) and
DOES> interpretation semantics.

Still, on the other hand great care has to be taken with words that change
mode (compilation -> interpretation and vice versa). Now, I don't think we
should ponder too long on this, because it would change our beloved
language beyond recognition.

On the other hand I fully agree with the amount of C constructs creeping in.
The horror of 'A' as a valid way to enter character constants has not been
stressed enough. Yes, one could define:

        char A constant 'A'

And it would work. But on a case-insensitive system this wouldn't:

        char a constant 'a'

I can live with user-defined words in case sensitivity, however the standard
requires all Forth words to be in uppercase. Personally, I find uppercase
unreadable - so that doesn't come in.

And don't talk to me about locals or S\" - these are even worse!

Hans Bezemer

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

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

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

csiph-web