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

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

Re: bug in VFX --- IF does't work

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2017-03-18 17:37 -0400
    Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-18 15:08 -0700
    Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-18 15:17 -0700
      Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-18 22:22 +0000
        Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2017-03-18 19:47 -0400
          Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-18 17:06 -0700
            Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2017-03-18 20:58 -0400
            Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-19 18:04 +0000
    Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-19 10:53 +0000
      Re: bug in VFX --- IF does't work Cecil Bayona <cbayona@cbayona.com> - 2017-03-19 12:57 -0500
        Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-19 13:39 -0500
        Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-19 14:48 -0700
          Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-19 22:05 +0000
      Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-19 17:57 +0000
      Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-19 12:18 -0700
      Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-03-22 22:57 +0000
        Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-22 17:18 -0700
        Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 04:03 -0500
          Re: bug in VFX --- IF does't work albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-23 15:01 +0100
            Re: bug in VFX --- IF does't work peter.m.falth@gmail.com - 2017-03-23 07:12 -0700
              Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-29 20:31 -0700
            Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 10:22 -0500
              Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-03-30 02:31 +0000
                Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 03:36 -0500
                  Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-30 15:45 +0000
                    Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 12:03 -0500
                      Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-30 14:04 -0700
                      Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-31 09:23 +0000
                        Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-31 07:43 -0500
                          Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 12:55 +0000
                            Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-01 11:52 -0500
        Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 12:23 +0000
          Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-23 15:57 +0000
            Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 17:38 +0000
              Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-23 17:58 +0000
                Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-23 19:16 +0000
                Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 09:52 +0000
          Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 18:26 +0000
          Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-03-30 02:55 +0000
            Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-29 20:49 -0700
            Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2017-03-30 03:04 -0700
              Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 06:47 -0500
                Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-30 12:56 +0100
                  Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 09:41 -0500
                Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-30 13:59 -0700
                Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-05-01 01:33 +0000
                  Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2017-04-30 15:50 -1000
                    Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-04-30 19:34 -0700
                    Re: bug in VFX --- IF does't work albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-01 23:53 +0200
                      Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-05-01 18:54 -0700
                    Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-05-02 15:01 +0000
                      Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-05-02 11:30 -0700
                        Re: bug in VFX --- IF does't work Cecil Bayona <cbayona@cbayona.com> - 2017-05-02 13:36 -0500
                          Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:57 +0000
            Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-31 09:45 +0000
              Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-31 20:09 -0700

Page 1 of 3  [1] 2 3  Next page →

#55906 — Re: bug in VFX --- IF does't work

On 4/1/2015 3:33 PM, hughaguilar96@gmail.com wrote:
> On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
>> wrote:
>>
>>> : my-if [ ' if ] literal execute ; immediate  ok : ttt ( flag --
>>> ) my-if ." true " else ." false " then ;=20 Err# -14 ERR: Attempt
>>> to interpret a compile only definition. -> : ttt ( flag -- )
>>> my-if ." true " else ." false " then ; ^ see my-if=20 MY-IF (is
>>> IMMEDIATE)=20 ( 004C7A80    E89B23F4FF )            CALL
>>> 00409E20        IF ( 004C7A85    C3 )                    NEXT, (
>>> 6 bytes, 2 instructions ) ok
>>
>> It works fine. You compiled MY-IF to use the interpretation
>> behaviour of IF. VFX compiled the interpretation behaviour of IF.
>> You ran MY-IF and got the interpretation behaviour of IF. What are
>> you complaining about?
>
> Well, you said "interpretation behavior" three times, so I felt
> inspired to look this up in the ANS-Forth document section on IF
> (6.1.1700): "Interpretation semantics for this word are undefined."
> You ask what I'm complaining about, but then your explanation comes
> to "undefined." That is funny! This is actually a familiar phrase, as
> I recently ran into the same thing in this thread:
> https://groups.google.com/forum/#!topic/comp.lang.forth/2OsjCUri9eY

This is simple enough that even I can understand it.

You exited compilation mode using [.  You ticked 'if'.  So what would 
you expect to get other than an execution token for the interpretation 
semantics of 'if'?

You complain that gForth doesn't return a token for a word that has no 
interpretation semantics and now you complain that VFX *does* return a 
token.


>> I have been saying for a couple of years now that the ANS
>> standard's definition of compilation and interpretation is
>> incomprehensible for mere mortals such as myself. Every time I
>> reread the standard on this topic, the more I believe that the
>> standard's description of compilation and interpretation needs a
>> complete rewrite.
>>
>> In essence, Forth is a language of simplicity. Complexity such as
>> an optimising compiler is hidden. However, we now have a standard
>> in which the classic Forth interpreter loop is broken according to
>> some. We need to fix this by going back to basics rather than
>> putting bandages on bad prose.
>
> I've been saying since 2009, which is more than a couple of years,
> that the solution is to define the language as a cross-compiler.

You continue to rant about how terrible ANS-Forth is... and also 
continue to pursue working with it.  I don't get why?  Do you like 
beating your head against the wall?  You won't learn how to use 
ANS-Forth.  Rather you insist on trying to bend it to your own will.

If you want something different, why don't you just write it?


> I wrote MFX in 1994/1995, and I figured it out on my own without
> doing any research on Forth cross-compilation.

So why are you here?

-- 

Rick C

[toc] | [next] | [standalone]

#55907

On Saturday, March 18, 2017 at 2:37:32 PM UTC-7, rickman wrote:
> On 4/1/2015 3:33 PM, hughaguilar96@gmail.com wrote:
> > On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
> >> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
> >> wrote:
> >>
> >>> : my-if [ ' if ] literal execute ; immediate  ok : ttt ( flag --
> >>> ) my-if ." true " else ." false " then ;=20 Err# -14 ERR: Attempt
> >>> to interpret a compile only definition. -> : ttt ( flag -- )
> >>> my-if ." true " else ." false " then ; ^ see my-if=20 MY-IF (is
> >>> IMMEDIATE)=20 ( 004C7A80    E89B23F4FF )            CALL
> >>> 00409E20        IF ( 004C7A85    C3 )                    NEXT, (
> >>> 6 bytes, 2 instructions ) ok
> >>
> >> It works fine. You compiled MY-IF to use the interpretation
> >> behaviour of IF. VFX compiled the interpretation behaviour of IF.
> >> You ran MY-IF and got the interpretation behaviour of IF. What are
> >> you complaining about?
> >
> > Well, you said "interpretation behavior" three times, so I felt
> > inspired to look this up in the ANS-Forth document section on IF
> > (6.1.1700): "Interpretation semantics for this word are undefined."
> > You ask what I'm complaining about, but then your explanation comes
> > to "undefined." That is funny! This is actually a familiar phrase, as
> > I recently ran into the same thing in this thread:
> > https://groups.google.com/forum/#!topic/comp.lang.forth/2OsjCUri9eY
> 
> This is simple enough that even I can understand it.
> 
> You exited compilation mode using [.  You ticked 'if'.  So what would 
> you expect to get other than an execution token for the interpretation 
> semantics of 'if'?
> 
> You complain that gForth doesn't return a token for a word that has no 
> interpretation semantics and now you complain that VFX *does* return a 
> token.

FIND in ANS-Forth is ambiguous --- FIND does something different in SwiftForth, VFX and Gforth --- all of them claim to be ANS-Forth compliant and are, in fact, compliant with different interpretations of the ANS-Forth document.

My disambiguifiers fix FIND though. There are 51 of the disambiguifiers (one for every word in the ANS-Forth document whose definition includes the statement: "Interpretation semantics for this word are undefined."). Section 4.1.2., with the ominous heading: "Ambiguous Conditions," lists one of the many ambiguous conditions as: 
"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, FIND in ANS-Forth is obviously ambiguous. My disambiguifiers fix this problem however, because they use POSTPONE internally and POSTPONE is not ambiguous, so now FIND can find the disambiguifer, and the disambiguifer can do what the word does. Also, these 51 words are ambiguous because they can be immediate or non-immediate --- the ANS-Forth standard failed to standardize whether they were immediate or non-immediate --- they vary from one ANS-Forth system (non-immediate in VFX) to another (immediate in SwiftForth) to another (in Gforth FIND returns a different value depending upon what STATE @ is at the time FIND executes; also ' and ['] abort with an mind-blowing error-message when give these words). With the disambiguifiers however, all of them are immediate (as they were in Forth-83, so this is: "common practice") and FIND only returns one xt no matter what STATE @ is.

I really consider the disambiguifiers to be the heart and soul of ANS-Forth! Nobody can program in ANS-Forth (at least, not use FIND for anything) unless they have disambiguifiers.

> You continue to rant about how terrible ANS-Forth is... and also 
> continue to pursue working with it.  I don't get why?  Do you like 
> beating your head against the wall?  You won't learn how to use 
> ANS-Forth.  Rather you insist on trying to bend it to your own will.
> ...
> So why are you here?

I'm trying to kill the ANS-Forth standard. I think my disambiguifiers are a big step toward killing ANS-Forth! Students have got to wonder: 
"Why does the ANS-Forth standard need to be disambiguified? Why is it ambiguous?"
The answer is obviously that ANS-Forth was never anything except a marketing gimmick from Forth Inc. and it never had any technical merit whatsoever. Anybody who continues to take ANS-Forth seriously after being told about the gross ambiguities in ANS-Forth is either a moron or a salesman --- no programmer wants to be in this category --- programmers will abandon ANS-Forth, which is necessary for Forth to succeed.

I actually do know how to use ANS-Forth; this is not something that I need to learn, and certainly not from an idiot troll such as yourself. I have written quite a lot of ANS-Forth code. This includes an early-binding MACRO: as well as SYNONYM FAST-SYNONYM and ALIAS --- all of these are possible only with the disambiguifiers installed --- nobody can write these in ANS-Forth without disambiguifiers (Stephen Pelc's SYNONYM is not ANS-Forth but relies on carnal knowledge of the internal workings of VFX, so he is as usual trying to trap VFX users in vendor lock-in).

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

#55908

On Saturday, March 18, 2017 at 2:37:32 PM UTC-7, rickman wrote:
> On 4/1/2015 3:33 PM, hughaguilar96@gmail.com wrote:
> > Well, you said "interpretation behavior" three times, so I felt
> > inspired to look this up in the ANS-Forth document section on IF
> > (6.1.1700): "Interpretation semantics for this word are undefined."
> > You ask what I'm complaining about, but then your explanation comes
> > to "undefined." That is funny! This is actually a familiar phrase, as
> > I recently ran into the same thing in this thread:
> > https://groups.google.com/forum/#!topic/comp.lang.forth/2OsjCUri9eY
> 
> This is simple enough that even I can understand it.
> 
> You exited compilation mode using [.  You ticked 'if'.  So what would 
> you expect to get other than an execution token for the interpretation 
> semantics of 'if'?
> 
> You complain that gForth doesn't return a token for a word that has no 
> interpretation semantics and now you complain that VFX *does* return a 
> token.

One of the many stupid things that ANS-Forth does, is provide STATE and give us this: 
"Note: A program shall not directly alter the contents of STATE."
How does the ANS-Forth system prevent somebody from storing into the address provided by the STATE standard word? It would have made more sense to provide STATE@ that gives us the value but doesn't give us the address so we can't store into it.

Also, STATE@ should have been defined to provide three values:
        
#1) Indicate that we are outside of a colon word definition (interpreting).
        
#2) Indicate that we are inside of a colon word definition and inside of [ ] brackets (interpreting).
        
#3) Indicate that we are inside of a colon word definition and not inside of [ ] brackets (compiling).

All in all, ANS-Forth is just stupid! Elizabeth Rather wrote ANS-Forth in an effort to keep the corpse of MicroForth warm --- that was 1970s technology however, and it included a lot of Charles Moore's early mistakes --- Elizabeth Rather actually has no understanding of Forth whatsoever, having never written a Forth program in her life.

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

#55909

On 3/18/2017 22:17, hughaguilar96@gmail.com wrote:
> Also, STATE@ should have been defined to provide three values:
>
> #1) Indicate that we are outside of a colon word definition (interpreting).
>
> #2) Indicate that we are inside of a colon word definition and inside of [ ] brackets (interpreting).
>
> #3) Indicate that we are inside of a colon word definition and not inside of [ ] brackets (compiling).

Why differentiate between 1 and 2?

-- 
Alex

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

#55911

On 3/18/2017 6:22 PM, Alex wrote:
> On 3/18/2017 22:17, hughaguilar96@gmail.com wrote:
>> Also, STATE@ should have been defined to provide three values:
>>
>> #1) Indicate that we are outside of a colon word definition
>> (interpreting).
>>
>> #2) Indicate that we are inside of a colon word definition and inside
>> of [ ] brackets (interpreting).
>>
>> #3) Indicate that we are inside of a colon word definition and not
>> inside of [ ] brackets (compiling).
>
> Why differentiate between 1 and 2?

That's obvious.  So you can know if you need to disambiguify.  Or is 
that too ambiguous?

-- 

Rick C

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

#55912

On Saturday, March 18, 2017 at 4:47:01 PM UTC-7, rickman wrote:
> On 3/18/2017 6:22 PM, Alex wrote:
> > On 3/18/2017 22:17, hughaguilar96@gmail.com wrote:
> >> Also, STATE@ should have been defined to provide three values:
> >>
> >> #1) Indicate that we are outside of a colon word definition
> >> (interpreting).
> >>
> >> #2) Indicate that we are inside of a colon word definition and inside
> >> of [ ] brackets (interpreting).
> >>
> >> #3) Indicate that we are inside of a colon word definition and not
> >> inside of [ ] brackets (compiling).
> >
> > Why differentiate between 1 and 2?
> 
> That's obvious.  So you can know if you need to disambiguify.  Or is 
> that too ambiguous?

Rickman is talking nonsense --- most likely doesn't know what the disambiguifiers do --- I've never seen any evidence to indicate that he knows Forth at all (posts as much Forth code as John Passaniti did, which is zilch).

This is a disambiguifier:

: if  
    state @ 0= if  cr ." WARNING: *** no interpretation semantics for: IF ***" cr  then  
    postpone if ; 
immediate

Now FIND and ' and ['] will all work on IF and will do so consistently between ANS-Forth systems.

I had previously done an ABORT" in there when STATE @ was 0 --- Anton Ertl complained that this prevents the disambiguified word from being used inside of [ ] so I now just issue a warning --- a lot of these, especially control-structure words such as IF etc., make sense to be used inside of [ ] inside of a colon word.

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

#55914

On 3/18/2017 8:06 PM, hughaguilar96@gmail.com wrote:
> On Saturday, March 18, 2017 at 4:47:01 PM UTC-7, rickman wrote:
>> On 3/18/2017 6:22 PM, Alex wrote:
>>> On 3/18/2017 22:17, hughaguilar96@gmail.com wrote:
>>>> Also, STATE@ should have been defined to provide three values:
>>>>
>>>> #1) Indicate that we are outside of a colon word definition
>>>> (interpreting).
>>>>
>>>> #2) Indicate that we are inside of a colon word definition and inside
>>>> of [ ] brackets (interpreting).
>>>>
>>>> #3) Indicate that we are inside of a colon word definition and not
>>>> inside of [ ] brackets (compiling).
>>>
>>> Why differentiate between 1 and 2?
>>
>> That's obvious.  So you can know if you need to disambiguify.  Or is
>> that too ambiguous?
>
> Rickman is talking nonsense ---

Lol!  I expect Hugh would know all about nonsense.  As soon as he gets 
off the technology of Forth he is full of nonsense.

-- 

Rick C

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

#55933

On 3/19/2017 00:06, hughaguilar96@gmail.com wrote:
> On Saturday, March 18, 2017 at 4:47:01 PM UTC-7, rickman wrote:
>> On 3/18/2017 6:22 PM, Alex wrote:
>>> On 3/18/2017 22:17, hughaguilar96@gmail.com wrote:
>>>> Also, STATE@ should have been defined to provide three values:
>>>>
>>>> #1) Indicate that we are outside of a colon word definition
>>>> (interpreting).
>>>>
>>>> #2) Indicate that we are inside of a colon word definition and
>>>> inside of [ ] brackets (interpreting).
>>>>
>>>> #3) Indicate that we are inside of a colon word definition and
>>>> not inside of [ ] brackets (compiling).
>>>
>>> Why differentiate between 1 and 2?
>>
>> That's obvious.  So you can know if you need to disambiguify.  Or
>> is that too ambiguous?
>
> Rickman is talking nonsense --- most likely doesn't know what the
> disambiguifiers do --- I've never seen any evidence to indicate that
> he knows Forth at all (posts as much Forth code as John Passaniti
> did, which is zilch).
>
> This is a disambiguifier:
>
> : if state @ 0= if  cr ." WARNING: *** no interpretation semantics
> for: IF ***" cr  then postpone if ; immediate
>
> Now FIND and ' and ['] will all work on IF and will do so
> consistently between ANS-Forth systems.
>
> I had previously done an ABORT" in there when STATE @ was 0 --- Anton
> Ertl complained that this prevents the disambiguified word from being
> used inside of [ ] so I now just issue a warning --- a lot of these,
> especially control-structure words such as IF etc., make sense to be
> used inside of [ ] inside of a colon word.
>

That doesn't answer the question. Why differentiate between 1
(indicate that we are outside of a colon word definition; interpreting) 
and 2 (indicate that we are outside of a colon word definition; 
interpreting).

-- 
Alex

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

#55921

rickman <gnuarm@gmail.com> writes:
>On 4/1/2015 3:33 PM, hughaguilar96@gmail.com wrote:
>> On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>>> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
>>> wrote:

[where does this thread necromancy come from? But anyway, I will bite]

>>>
>>>> : my-if [ ' if ] literal execute ; immediate  ok : ttt ( flag --
>>>> ) my-if ." true " else ." false " then ;=20 Err# -14 ERR: Attempt
>>>> to interpret a compile only definition. -> : ttt ( flag -- )
>>>> my-if ." true " else ." false " then ; ^ see my-if=20 MY-IF (is
>>>> IMMEDIATE)=20 ( 004C7A80    E89B23F4FF )            CALL
>>>> 00409E20        IF ( 004C7A85    C3 )                    NEXT, (
>>>> 6 bytes, 2 instructions ) ok
>>>
>>> It works fine. You compiled MY-IF to use the interpretation
>>> behaviour of IF. VFX compiled the interpretation behaviour of IF.
>>> You ran MY-IF and got the interpretation behaviour of IF. What are
>>> you complaining about?
>>
>> Well, you said "interpretation behavior" three times, so I felt
>> inspired to look this up in the ANS-Forth document section on IF
>> (6.1.1700): "Interpretation semantics for this word are undefined."
>> You ask what I'm complaining about, but then your explanation comes
>> to "undefined." That is funny! This is actually a familiar phrase, as
>> I recently ran into the same thing in this thread:
>> https://groups.google.com/forum/#!topic/comp.lang.forth/2OsjCUri9eY
>
>This is simple enough that even I can understand it.
>
>You exited compilation mode using [.  You ticked 'if'.  So what would 
>you expect to get other than an execution token for the interpretation 
>semantics of 'if'?

"Execution token for the interpretation semantics" is the dual-xt way
to think about it; in the dual-xt world view, some words have an xt
for the interpretation semantics and a different xt (or a two-cell
compilation token) for the compilation semantics.

Your variant of that view seems to be that it depends on the state
during ticking which of the two xts you get.  In Gforth, ticking
always gives you the xt for the interpretation semantics (or an error,
if there is none), and there is NAME>COMPILE for getting the
compilation token.

VFX implements a different view, though: A word has only one xt, and
you get the interpretation semantics if you EXECUTE it, and, for a
non-immediate word, you get the compilation semantics if you COMPILE,
it; words that would have different xts in a dual-xt system are
implemented as non-immediate in VFX.  This view works much of the
time, but fails in corner cases.  As a result, we get statements
such as this from Stephen Pelc:

>>> I have been saying for a couple of years now that the ANS
>>> standard's definition of compilation and interpretation is
>>> incomprehensible for mere mortals such as myself. Every time I
>>> reread the standard on this topic, the more I believe that the
>>> standard's description of compilation and interpretation needs a
>>> complete rewrite.

The problem is not in the standard, but in conflicting requirements:

1) The requirement to be able to cut and paste parsing words like S"
and TO between interpreted and compiled code.  And there are people
who invent more such stuff at every opportunity, as if it had no
downside.

2) The requirement of equivalence between COMPILE, and
POSTPONE LITERAL POSTPONE EXECUTE (used in various places in existing
code, e.g., in early-binding parts in OO packages).

3) The requirement of equivalence between performing the xt of a word,
or (through POSTPONE) the compilation semantics in interpretation and
in compilation state.  The standard makes an exception from this
requirement for TO, and we should probably also have exceptions for S"
S\" IS and ACTION-OF, but for other standard words this requirement
holds.

4) The requirement to have each named word be represented by a single
xt.  That is is not a standard requirement (explicitly not required
for FIND), but some people argue strongly in favour of having such a
requirement.

A system cannot satisfy all these requirements in all cases.  Let's
see at what different systems do:

SwiftForth satisfies requirement 2 and 4; 1 for only a few words (S"
and TO), and 3 for most words, except those where it satisfies 1.

VFX satisfies 1, 3, and 4; but it does not satisfy 2 for a number of
words (S", TO, but also, e.g., IF).

Gforth <=0.7 satisfies 1,2 and 3; but it does not satisfy 4 for a
number of words (S", TO, etc.).  The current development version
satisfies 1 and 3, maybe 2, and is somewhat closer to 4: It has nt=xt,
i.e., for most words, NAME>INTERPRET is a noop; but for others
NAME>INTERPRET gives a different xt, and none of the cells produced by
NAME>COMPILE is the original xt.

If we want to get rid of a requirement, my suggestion would be to get
rid of requirement 1 (by replacing most of its usages with
recognizers, and by making do without the other usages); that would
get us back to the good old times of a single xt plus immediate flag,
and all the newfangled concepts such as interpretation and compilation
semantics would go away.  We would make Forth great again!

But if you are one of those people who love the convenience of being
able to cut and paste, say, a quotation, from compiled to interpreted
code, then the way to go is to give up requirement 4.  And once you
have thrown the mental baggage of requirement 4 overboard, the
standard is doing pretty ok (not that it cannot be improved, but the
complaints I usually see have more to do with this mental baggage than
with real issues in the standard).

In any case, I don't think we have a consensus on dropping
requirements 1, 2, or 3, and not even a consensus on clarifying the
standard in a way that makes it clearer that 4 is not a requirement,
so I don't expect any rewrite attempts to be accepted, or even if
accepted, resulting in an an actual improvement.

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

#55931

On 3/19/2017 5:53 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 4/1/2015 3:33 PM, hughaguilar96@gmail.com wrote:
>>> On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>>>> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
>>>> wrote:
>
> [where does this thread necromancy come from? But anyway, I will bite]
>
>>>>
>>>>> : my-if [ ' if ] literal execute ; immediate  ok : ttt ( flag --
>>>>> ) my-if ." true " else ." false " then ;=20 Err# -14 ERR: Attempt
>>>>> to interpret a compile only definition. -> : ttt ( flag -- )
>>>>> my-if ." true " else ." false " then ; ^ see my-if=20 MY-IF (is
>>>>> IMMEDIATE)=20 ( 004C7A80    E89B23F4FF )            CALL
>>>>> 00409E20        IF ( 004C7A85    C3 )                    NEXT, (
>>>>> 6 bytes, 2 instructions ) ok
>>>>
>>>> It works fine. You compiled MY-IF to use the interpretation
>>>> behaviour of IF. VFX compiled the interpretation behaviour of IF.
>>>> You ran MY-IF and got the interpretation behaviour of IF. What are
>>>> you complaining about?
>>>
>>> Well, you said "interpretation behavior" three times, so I felt
>>> inspired to look this up in the ANS-Forth document section on IF
>>> (6.1.1700): "Interpretation semantics for this word are undefined."
>>> You ask what I'm complaining about, but then your explanation comes
>>> to "undefined." That is funny! This is actually a familiar phrase, as
>>> I recently ran into the same thing in this thread:
>>> https://groups.google.com/forum/#!topic/comp.lang.forth/2OsjCUri9eY
>>
>> This is simple enough that even I can understand it.
>>
>> You exited compilation mode using [.  You ticked 'if'.  So what would
>> you expect to get other than an execution token for the interpretation
>> semantics of 'if'?
>
> "Execution token for the interpretation semantics" is the dual-xt way
> to think about it; in the dual-xt world view, some words have an xt
> for the interpretation semantics and a different xt (or a two-cell
> compilation token) for the compilation semantics.
>
> Your variant of that view seems to be that it depends on the state
> during ticking which of the two xts you get.  In Gforth, ticking
> always gives you the xt for the interpretation semantics (or an error,
> if there is none), and there is NAME>COMPILE for getting the
> compilation token.
>
> VFX implements a different view, though: A word has only one xt, and
> you get the interpretation semantics if you EXECUTE it, and, for a
> non-immediate word, you get the compilation semantics if you COMPILE,
> it; words that would have different xts in a dual-xt system are
> implemented as non-immediate in VFX.  This view works much of the
> time, but fails in corner cases.  As a result, we get statements
> such as this from Stephen Pelc:
>
>>>> I have been saying for a couple of years now that the ANS
>>>> standard's definition of compilation and interpretation is
>>>> incomprehensible for mere mortals such as myself. Every time I
>>>> reread the standard on this topic, the more I believe that the
>>>> standard's description of compilation and interpretation needs a
>>>> complete rewrite.
>
> The problem is not in the standard, but in conflicting requirements:
>
> 1) The requirement to be able to cut and paste parsing words like S"
> and TO between interpreted and compiled code.  And there are people
> who invent more such stuff at every opportunity, as if it had no
> downside.
>
> 2) The requirement of equivalence between COMPILE, and
> POSTPONE LITERAL POSTPONE EXECUTE (used in various places in existing
> code, e.g., in early-binding parts in OO packages).
>
> 3) The requirement of equivalence between performing the xt of a word,
> or (through POSTPONE) the compilation semantics in interpretation and
> in compilation state.  The standard makes an exception from this
> requirement for TO, and we should probably also have exceptions for S"
> S\" IS and ACTION-OF, but for other standard words this requirement
> holds.
>
> 4) The requirement to have each named word be represented by a single
> xt.  That is is not a standard requirement (explicitly not required
> for FIND), but some people argue strongly in favour of having such a
> requirement.
>
> A system cannot satisfy all these requirements in all cases.  Let's
> see at what different systems do:
>
> SwiftForth satisfies requirement 2 and 4; 1 for only a few words (S"
> and TO), and 3 for most words, except those where it satisfies 1.
>
> VFX satisfies 1, 3, and 4; but it does not satisfy 2 for a number of
> words (S", TO, but also, e.g., IF).
>
> Gforth <=0.7 satisfies 1,2 and 3; but it does not satisfy 4 for a
> number of words (S", TO, etc.).  The current development version
> satisfies 1 and 3, maybe 2, and is somewhat closer to 4: It has nt=xt,
> i.e., for most words, NAME>INTERPRET is a noop; but for others
> NAME>INTERPRET gives a different xt, and none of the cells produced by
> NAME>COMPILE is the original xt.
>
> If we want to get rid of a requirement, my suggestion would be to get
> rid of requirement 1 (by replacing most of its usages with
> recognizers, and by making do without the other usages); that would
> get us back to the good old times of a single xt plus immediate flag,
> and all the newfangled concepts such as interpretation and compilation
> semantics would go away.  We would make Forth great again!
>
> But if you are one of those people who love the convenience of being
> able to cut and paste, say, a quotation, from compiled to interpreted
> code, then the way to go is to give up requirement 4.  And once you
> have thrown the mental baggage of requirement 4 overboard, the
> standard is doing pretty ok (not that it cannot be improved, but the
> complaints I usually see have more to do with this mental baggage than
> with real issues in the standard).
>
> In any case, I don't think we have a consensus on dropping
> requirements 1, 2, or 3, and not even a consensus on clarifying the
> standard in a way that makes it clearer that 4 is not a requirement,
> so I don't expect any rewrite attempts to be accepted, or even if
> accepted, resulting in an an actual improvement.
>
> - anton
>
Newbie here but when I used Pygmy a derivation of CMForth it did 
something interesting it had different vocabularies for compiling and 
interpreting. In that way you only found compiling words during 
compilation otherwise they were not found do there was less confusion 
when finding a word. It also made the creation of meta compilers a lot 
easier by keeping meta words in the meta compiler vocabulary.

Just a thought.

-- 
Cecil - k5nwa

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

#55934

Cecil Bayona <cbayona@cbayona.com> wrote:
>>
> Newbie here but when I used Pygmy a derivation of CMForth it did 
> something interesting it had different vocabularies for compiling and 
> interpreting. In that way you only found compiling words during 
> compilation otherwise they were not found do there was less confusion 
> when finding a word. It also made the creation of meta compilers a lot 
> easier by keeping meta words in the meta compiler vocabulary.

Umm, sort of.  The dual-vocabulary technique caused some very odd
results when redefining a word: a newer definition would override a
word in interpret mode, but the old definition would override the
newer one when compiling.

Also, the metacompiler was OK for recompiling Forth, but it was a real
PITA when compiling an application.

Andrew.

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

#55946

On Sunday, March 19, 2017 at 10:57:22 AM UTC-7, Cecil - k5nwa wrote:
> On 3/19/2017 5:53 AM, Anton Ertl wrote:
> > "Execution token for the interpretation semantics" is the dual-xt way
> > to think about it; in the dual-xt world view, some words have an xt
> > for the interpretation semantics and a different xt (or a two-cell
> > compilation token) for the compilation semantics.
> >
> > Your variant of that view seems to be that it depends on the state
> > during ticking which of the two xts you get.  In Gforth, ticking
> > always gives you the xt for the interpretation semantics (or an error,
> > if there is none), and there is NAME>COMPILE for getting the
> > compilation token.
> >
> > VFX implements a different view, though: A word has only one xt, and
> > you get the interpretation semantics if you EXECUTE it, and, for a
> > non-immediate word, you get the compilation semantics if you COMPILE,
> > it; words that would have different xts in a dual-xt system are
> > implemented as non-immediate in VFX.  This view works much of the
> > time, but fails in corner cases.  As a result, we get statements
> > such as this from Stephen Pelc:

I think that a standard is useful for standardizing the fundamental aspects of the language. It is a good idea to do this in a way that makes sense.

For example, OR should be an inclusive-or, rather than an exclusive-or.

Also, FIND should look up the word in the dictionary (according to the search-order rules for word-lists) and return the xt if it is found, and it should return a 1 for immediate or -1 for non-immediate. 

Words should be defined as being immediate or non-immediate so FIND doesn't return 1 or -1 for the same standard word on different standard systems.

You can't have a standard that says OR is sometimes inclusive-or and sometimes exclusive-or, and that both are standard compliant. You can't have a standard that says FIND sometimes does one thing given a standard word, and sometimes something else, and this may depend upon STATE at the time FIND is executed, etc.. You can't have a standard that says standard words are sometimes are immediate and sometimes non-immediate.

I could really do without Anton Ertl's blather about the: "dual-xt world view." I don't consider this to be Forth at all. I don't think Anton Ertl knows Forth very well --- he has never worked as a Forth programmer writing commercial Forth software --- he is an academic with little or no familiarity with the real world.

A Forth standard is not that hard! I would really think that writing a standard that standardizes basic aspects of Forth would be pretty easy. Forth-83 was straightforward and obvious --- there were some weaknesses (no local variables, for example) --- with a little bit of effort in the early 1990s these weaknesses could have been shored up (the John Hopkins format was well established as common practice for local variables by that time).

The fact that ANS-Forth became completely screwed up and infected with ambiguity indicates that the ANS-Forth committee didn't understand that the purpose of a standard is to standardize, for the purpose of making it possible to write programs that can be ported easily between standard systems.

> Newbie here but when I used Pygmy a derivation of CMForth it did 
> something interesting it had different vocabularies for compiling and 
> interpreting. In that way you only found compiling words during 
> compilation otherwise they were not found do there was less confusion 
> when finding a word. It also made the creation of meta compilers a lot 
> easier by keeping meta words in the meta compiler vocabulary.
> 
> Just a thought.

That sounds very similar to MFX. This is pretty much why Forth has vocabularies. Worked great for me in 1994/1995 when I wrote MFX --- should work great now too --- this is basic Forth programming.

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

#55947

On 3/19/2017 21:48, hughaguilar96@gmail.com wrote:

 > For example, OR should be an inclusive-or, rather than an
 > exclusive-or.
 >
 > You can't have a standard that says OR is sometimes inclusive-or and
 > sometimes exclusive-or, and that both are standard compliant.

ANS Forth 94

6.1.1980 OR ( x1 x2 -- x3 )
x3 is the bit-by-bit inclusive-or of x1 with x2.

-- 
Alex

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

#55932

On 3/19/2017 10:53, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 4/1/2015 3:33 PM, hughaguilar96@gmail.com wrote:
>>> On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>>>> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
>>>> wrote:
>
> [where does this thread necromancy come from? But anyway, I will bite]
>
>>>>
>>>>> : my-if [ ' if ] literal execute ; immediate  ok : ttt ( flag --
>>>>> ) my-if ." true " else ." false " then ;=20 Err# -14 ERR: Attempt
>>>>> to interpret a compile only definition. -> : ttt ( flag -- )
>>>>> my-if ." true " else ." false " then ; ^ see my-if=20 MY-IF (is
>>>>> IMMEDIATE)=20 ( 004C7A80    E89B23F4FF )            CALL
>>>>> 00409E20        IF ( 004C7A85    C3 )                    NEXT, (
>>>>> 6 bytes, 2 instructions ) ok
>>>>
>>>> It works fine. You compiled MY-IF to use the interpretation
>>>> behaviour of IF. VFX compiled the interpretation behaviour of IF.
>>>> You ran MY-IF and got the interpretation behaviour of IF. What are
>>>> you complaining about?
>>>
>>> Well, you said "interpretation behavior" three times, so I felt
>>> inspired to look this up in the ANS-Forth document section on IF
>>> (6.1.1700): "Interpretation semantics for this word are undefined."
>>> You ask what I'm complaining about, but then your explanation comes
>>> to "undefined." That is funny! This is actually a familiar phrase, as
>>> I recently ran into the same thing in this thread:
>>> https://groups.google.com/forum/#!topic/comp.lang.forth/2OsjCUri9eY
>>
>> This is simple enough that even I can understand it.
>>
>> You exited compilation mode using [.  You ticked 'if'.  So what would
>> you expect to get other than an execution token for the interpretation
>> semantics of 'if'?
>
> "Execution token for the interpretation semantics" is the dual-xt way
> to think about it; in the dual-xt world view, some words have an xt
> for the interpretation semantics and a different xt (or a two-cell
> compilation token) for the compilation semantics.
>
> Your variant of that view seems to be that it depends on the state
> during ticking which of the two xts you get.  In Gforth, ticking
> always gives you the xt for the interpretation semantics (or an error,
> if there is none), and there is NAME>COMPILE for getting the
> compilation token.
>
> VFX implements a different view, though: A word has only one xt, and
> you get the interpretation semantics if you EXECUTE it, and, for a
> non-immediate word, you get the compilation semantics if you COMPILE,
> it; words that would have different xts in a dual-xt system are
> implemented as non-immediate in VFX.  This view works much of the
> time, but fails in corner cases.  As a result, we get statements
> such as this from Stephen Pelc:
>
>>>> I have been saying for a couple of years now that the ANS
>>>> standard's definition of compilation and interpretation is
>>>> incomprehensible for mere mortals such as myself. Every time I
>>>> reread the standard on this topic, the more I believe that the
>>>> standard's description of compilation and interpretation needs a
>>>> complete rewrite.
>
> The problem is not in the standard, but in conflicting requirements:
>
> 1) The requirement to be able to cut and paste parsing words like S"
> and TO between interpreted and compiled code.  And there are people
> who invent more such stuff at every opportunity, as if it had no
> downside.
>
> 2) The requirement of equivalence between COMPILE, and
> POSTPONE LITERAL POSTPONE EXECUTE (used in various places in existing
> code, e.g., in early-binding parts in OO packages).
>
> 3) The requirement of equivalence between performing the xt of a word,
> or (through POSTPONE) the compilation semantics in interpretation and
> in compilation state.  The standard makes an exception from this
> requirement for TO, and we should probably also have exceptions for S"
> S\" IS and ACTION-OF, but for other standard words this requirement
> holds.
>
> 4) The requirement to have each named word be represented by a single
> xt.  That is is not a standard requirement (explicitly not required
> for FIND), but some people argue strongly in favour of having such a
> requirement.
>
> A system cannot satisfy all these requirements in all cases.  Let's
> see at what different systems do:
>
> SwiftForth satisfies requirement 2 and 4; 1 for only a few words (S"
> and TO), and 3 for most words, except those where it satisfies 1.
>
> VFX satisfies 1, 3, and 4; but it does not satisfy 2 for a number of
> words (S", TO, but also, e.g., IF).
>
> Gforth <=0.7 satisfies 1,2 and 3; but it does not satisfy 4 for a
> number of words (S", TO, etc.).  The current development version
> satisfies 1 and 3, maybe 2, and is somewhat closer to 4: It has nt=xt,
> i.e., for most words, NAME>INTERPRET is a noop; but for others
> NAME>INTERPRET gives a different xt, and none of the cells produced by
> NAME>COMPILE is the original xt.
>
> If we want to get rid of a requirement, my suggestion would be to get
> rid of requirement 1 (by replacing most of its usages with
> recognizers, and by making do without the other usages); that would
> get us back to the good old times of a single xt plus immediate flag,
> and all the newfangled concepts such as interpretation and compilation
> semantics would go away.  We would make Forth great again!
>
> But if you are one of those people who love the convenience of being
> able to cut and paste, say, a quotation, from compiled to interpreted
> code, then the way to go is to give up requirement 4.  And once you
> have thrown the mental baggage of requirement 4 overboard, the
> standard is doing pretty ok (not that it cannot be improved, but the
> complaints I usually see have more to do with this mental baggage than
> with real issues in the standard).
>
> In any case, I don't think we have a consensus on dropping
> requirements 1, 2, or 3, and not even a consensus on clarifying the
> standard in a way that makes it clearer that 4 is not a requirement,
> so I don't expect any rewrite attempts to be accepted, or even if
> accepted, resulting in an an actual improvement.
>
> - anton
>

This (for interested dimwits, of which I am one) requires examples. I 
*think* I see what you are driving at; but I'm not seeing it clearly.

-- 
Alex

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

#55937

On Sunday, March 19, 2017 at 5:14:42 AM UTC-7, Anton Ertl wrote:
> The problem is not in the standard, but in conflicting requirements:

The problem is in the standard because it tried to accommodate conflicting requirements. Elizabeth Rather is a professional name-dropper --- she was totally focused on collecting the names of supporters --- none of the Forth vendors in the ANS-Forth committee had compatible Forth systems, but she just told them that they would all be ANS-Forth compliant in exchange for proclaiming her to be the "leading expert" on Forth; this is why ANS-Forth is deeply infected with ambiguity.

> 1) The requirement to be able to cut and paste parsing words like S"
> and TO between interpreted and compiled code.  And there are people
> who invent more such stuff at every opportunity, as if it had no
> downside.

If there had been any leadership in the ANS-Forth committee then they would have said: "No! That is a bad idea! That will not become standard!"

In the early 1990s, Forth Inc. was bragging up their involvement with OpenBoot. This was another Forth Inc. screw-up. One of the many reasons why OpenBoot failed was because of this stupid idea that code can be cut-and-paste directly between interpretation and compilation mode. Now, of course, Elizabeth Rather blames everybody except herself for the OpenBoot failure and how this gave Forth a black-eye --- as always, Elizabeth Rather makes the Forth community look stupid, then blames the Forth community afterward for her own blunders.

> 4) The requirement to have each named word be represented by a single
> xt.  That is is not a standard requirement (explicitly not required
> for FIND), but some people argue strongly in favour of having such a
> requirement.

This requirement is obvious --- how could ANS-Forth have screwed up such an obvious requirement? --- this indicates stupidity on the part of the ANS-Forth committee!

The fact that Gforth takes advantage of this by implementing a "dual-xt" system indicates stupidity on the part of the Gforth developers --- I do not consider Gforth to be Forth at all because of this --- the fact that Gforth is considered to be ANS-Forth compliant just goes to show that ANS-Forth is a meaningless standard that should not be considered to be Forth at all.

Forth-83 had vocabularies. It was possible to have words in different vocabularies with the same name. For example, in MFX I had DUP in one vocabulary (this was the word that duplicated the top value of the data-stack on the target processor). I also had DUP in another vocabulary (this was the word that compiled the DUP in the other vocabulary). These are different words though! The idea of a single word DUP that has two xt values is just stupid! Don't you know what vocabularies are??? This is basic Forth programming!

On a related note, another failure of ANS-Forth is that it doesn't provide a way to examine an xt and obtain or change attributes:
1.) Is the word immediate or non-immediate?
2.) What vocabulary is the word in?
3.) Is the word smudged?
4.) Is the word smudge-ready?

I implemented this in UR/Forth. This was one of the very few cases in which I needed to resort to assembly-language and carnal knowledge of UR/Forth. This was a huge breakthrough in MFX development! I was able to write assertions that examined an xt and checked that it came from the correct vocabulary, before executing it or compiling it. This made locating bugs easy. Previously I had found the cross-compiler would go haywire and begin acting bizarrely, and I had no idea where the problem was, and it would take a full day to track down the bug which almost always was a word from the wrong vocabulary being used in the wrong place. After I had this way to automatically check that the xt came from the right vocabulary, I was able to fix bugs in minutes rather than hours. Development sped up and pretty soon there were no more bugs --- everything worked great!

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

#56147

Am Sun, 19 Mar 2017 10:53:41 +0000 schrieb Anton Ertl:
> 2) The requirement of equivalence between COMPILE, and POSTPONE LITERAL
> POSTPONE EXECUTE (used in various places in existing code, e.g., in
> early-binding parts in OO packages).

But these OO packages don't work with words like IF, let alone S" and TO 
in those places, but almost exclusively use :NONAME to define the xts 
used for these COMPILE,.  That is a red herring, and :NONAME words can't 
possibly have a second xt in the dual-xt world while they could have a 
special COMPILE, action.  These OOP packages and their users (like MINOS) 
work fine on VFX.

From the intention of the ANS Forth TC, it is pretty clear that they 
wanted to encourage people to find different solutions for the compiler 
actions, without actually mandating an implementation. The techniques 
available back then were state-smart and dual-xt.  Gforth's cross 
compiler already had the intelligent COMPILE, back then, but as 
undocumented feature, and not used for words like IF or S", so it took 
some more years until this appeared in VFX.

Fact is that by the word of the ANS Forth standard, dual-xt as 
implemented in Gforth later (which wasn't the way how dual-xt was 
implemented when they wrote the standard, and Gforth was purely state-
smart at that time) is the only valid implementation technique according 
to a very literal reading of the standard.  And of course, since the 
intelligent COMPILE, wasn't on the radar, the TC cold not define COMPILE, 
in a way that fits exactly with the way VFX uses it.

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

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

#56152

On Wednesday, March 22, 2017 at 4:00:38 PM UTC-7, Bernd Paysan wrote:
> Am Sun, 19 Mar 2017 10:53:41 +0000 schrieb Anton Ertl:
> > 2) The requirement of equivalence between COMPILE, and POSTPONE LITERAL
> > POSTPONE EXECUTE (used in various places in existing code, e.g., in
> > early-binding parts in OO packages).
> 
> But these OO packages don't work with words like IF, let alone S" and TO 
> in those places, but almost exclusively use :NONAME to define the xts 
> used for these COMPILE,.  That is a red herring, and :NONAME words can't 
> possibly have a second xt in the dual-xt world while they could have a 
> special COMPILE, action.  These OOP packages and their users (like MINOS) 
> work fine on VFX.
> 
> From the intention of the ANS Forth TC, it is pretty clear that they 
> wanted to encourage people to find different solutions for the compiler 
> actions, without actually mandating an implementation. The techniques 
> available back then were state-smart and dual-xt.  Gforth's cross 
> compiler already had the intelligent COMPILE, back then, but as 
> undocumented feature, and not used for words like IF or S", so it took 
> some more years until this appeared in VFX.
> 
> Fact is that by the word of the ANS Forth standard, dual-xt as 
> implemented in Gforth later (which wasn't the way how dual-xt was 
> implemented when they wrote the standard, and Gforth was purely state-
> smart at that time) is the only valid implementation technique according 
> to a very literal reading of the standard.  And of course, since the 
> intelligent COMPILE, wasn't on the radar, the TC cold not define COMPILE, 
> in a way that fits exactly with the way VFX uses it.

Just use the disambiguifiers!

I don't claim to have invented the disambiguifiers. Anton Ertl invented them in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D
That was in 2009 --- I later invented them myself, but then remembered that I had already been told about them by Anton Ertl above.

You yourself have disambiguifiers in Mini-OOF --- I don't know if you invented them independently, or got them from Anton Ertl --- it is possible that a lot of people have invented them independently.

All I invented was the name "disambiguifier" that everybody hates because it shines a spotlight on the ambiguity of FIND in ANS-Forth, and it is hard to spell. Maybe the ANS-Forth cult would have liked them better if I called them "awesomizers" and said that they make ANS-Forth even more awesome than it already is --- still hard to spell though.

Disambiguifiers are really the heart and soul of ANS-Forth programming! I would not consider anybody to have even a modicum of understanding of ANS-Forth without understanding the disambiguifiers. It is impossible to write ANS-Forth code without disambiguifiers (at least, any ANS-Forth code that uses FIND anywhere).

Without a FIND that works consistently and without ambiguity, a Forth system would not really be Forth at all --- the disambiguifiers allow ANS-Forth to have a FIND that works consistently and without ambiguity --- therefore, 
the disambiguifiers allow ANS-Forth to be Forth.

Please, don't all stand up to applaud at once --- the roar of applause could break the eardrums!
Actually, there are fewer than 20 ANS-Forth programmers on the planet, so the applause wouldn't be very loud --- and they aren't going to applaud anyway --- on the subject of the disambiguifiers, the ANS-Forth crowd are as quiet as a whore in church on the subject of sin.

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

#56166

Bernd Paysan <bernd@net2o.de> wrote:
> Am Sun, 19 Mar 2017 10:53:41 +0000 schrieb Anton Ertl:
>> 2) The requirement of equivalence between COMPILE, and POSTPONE LITERAL
>> POSTPONE EXECUTE (used in various places in existing code, e.g., in
>> early-binding parts in OO packages).
> 
> But these OO packages don't work with words like IF, let alone S"
> and TO in those places, but almost exclusively use :NONAME to define
> the xts used for these COMPILE,.  That is a red herring, and :NONAME
> words can't possibly have a second xt in the dual-xt world while
> they could have a special COMPILE, action.  These OOP packages and
> their users (like MINOS) work fine on VFX.
> 
> From the intention of the ANS Forth TC, it is pretty clear that they 
> wanted to encourage people to find different solutions for the compiler 
> actions, without actually mandating an implementation. The techniques 
> available back then were state-smart and dual-xt. 

And dual vocabulary.

> Fact is that by the word of the ANS Forth standard, dual-xt as
> implemented in Gforth later (which wasn't the way how dual-xt was
> implemented when they wrote the standard, and Gforth was purely
> state-smart at that time) is the only valid implementation
> technique according to a very literal reading of the standard.

Sure, but people here have pointed out that a purely literal
interpretation of programming language standards is inappropriate, and
that a combination of what the committee intended at the time, common
usage at the time, and today's circumstances should be used when
interpreting standards.

Andrew.

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

#56178

In article <48qdnYcMXuT0Ek7FnZ2dnUU7-fHNnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Bernd Paysan <bernd@net2o.de> wrote:
>> Am Sun, 19 Mar 2017 10:53:41 +0000 schrieb Anton Ertl:
>>> 2) The requirement of equivalence between COMPILE, and POSTPONE LITERAL
>>> POSTPONE EXECUTE (used in various places in existing code, e.g., in
>>> early-binding parts in OO packages).
>>
>> But these OO packages don't work with words like IF, let alone S"
>> and TO in those places, but almost exclusively use :NONAME to define
>> the xts used for these COMPILE,.  That is a red herring, and :NONAME
>> words can't possibly have a second xt in the dual-xt world while
>> they could have a special COMPILE, action.  These OOP packages and
>> their users (like MINOS) work fine on VFX.
>>
>> From the intention of the ANS Forth TC, it is pretty clear that they
>> wanted to encourage people to find different solutions for the compiler
>> actions, without actually mandating an implementation. The techniques
>> available back then were state-smart and dual-xt.
>
>And dual vocabulary.

Can you elaborate about the difference between dual-xt and dual
vocabulary. If I look up the same name in different vocabularies
don't I get different xt's?

>Andrew.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#56179

On Thursday, 23 March 2017 15:02:12 UTC+1, Albert van der Horst  wrote:
> In article <48qdnYcMXuT0Ek7FnZ2dnUU7-fHNnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
> >Bernd Paysan <bernd@net2o.de> wrote:
> >> Am Sun, 19 Mar 2017 10:53:41 +0000 schrieb Anton Ertl:
> >>> 2) The requirement of equivalence between COMPILE, and POSTPONE LITERAL
> >>> POSTPONE EXECUTE (used in various places in existing code, e.g., in
> >>> early-binding parts in OO packages).
> >>
> >> But these OO packages don't work with words like IF, let alone S"
> >> and TO in those places, but almost exclusively use :NONAME to define
> >> the xts used for these COMPILE,.  That is a red herring, and :NONAME
> >> words can't possibly have a second xt in the dual-xt world while
> >> they could have a special COMPILE, action.  These OOP packages and
> >> their users (like MINOS) work fine on VFX.
> >>
> >> From the intention of the ANS Forth TC, it is pretty clear that they
> >> wanted to encourage people to find different solutions for the compiler
> >> actions, without actually mandating an implementation. The techniques
> >> available back then were state-smart and dual-xt.
> >
> >And dual vocabulary.
> 
> Can you elaborate about the difference between dual-xt and dual
> vocabulary. If I look up the same name in different vocabularies
> don't I get different xt's?
 
I started with dual vocabularies when I developed my code generator.
It was very easy and simple, until I wanted also several vocabularies 
for other reasons (ASM, Virtual Compiler etc). Also when you redefine
a word you need to remember to do it in both vocabularies.

I then migrated to dual-xts. Conceptually I see it as the same thing
as the dual vocabularies with the difference that the compile vocabulary
is always hidden. I think it is simple and works really well.

But I also think that FIND is not well defined for this. I have in my
system FIND-COMPILE and FIND-INTERPRET 

Best Regards
Peter


>Andrew.
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web