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 3 of 3 — ← Prev page 1 2 [3]

#56483

On Thursday, 30 March 2017 03:58:41 UTC+1, Bernd Paysan  wrote:
> We of course can't know exactly what they would have, but judging from 
> the Forth 200x effort, we try to bend over backwards to make sure even 
> systems where one particular vendor did things all others think are 
> stupid (like using curly brackets for multi-line comments when everybody 
> else was using them for locals with a sane order), they certainly would 
> have made it possible for VFX to be standard.

And there is the problem.

If the intention is to accommodate everybody's systems and have them all
be compliant, then the goal is NOT portability, and this paragraph:


1.1 Purpose
 The purpose of this Standard is to promote the portability of Forth programs for use on a wide variety of computing systems, to facilitate the communication of programs, programming techniques, and ideas among Forth programmers, and to serve as a basis for the future evolution of the Forth language. 

Needs to be re-written, and have "portability" removed from it.

If the goal really IS portability, then the standard needs to tighten up,
and the vendors need to put their vested interests aside, suck it up and
start re-writing their code.

That's never going to happen though because it would piss off their 
customers.

I understand the criticism of Forth 83 in that it was too prescriptive
and ANS94 was the antidote to that. I wonder if the pendulum swung
too far in the opposite direction, however.

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

#56485

Mark Wills <markwills1970@gmail.com> wrote:
> On Thursday, 30 March 2017 03:58:41 UTC+1, Bernd Paysan  wrote:
>> We of course can't know exactly what they would have, but judging
>> from the Forth 200x effort, we try to bend over backwards to make
>> sure even systems where one particular vendor did things all others
>> think are stupid (like using curly brackets for multi-line comments
>> when everybody else was using them for locals with a sane order),
>> they certainly would have made it possible for VFX to be standard.
> 
> And there is the problem.
> 
> If the intention is to accommodate everybody's systems and have them all
> be compliant

It isn't.  Clearly we have made great efforts to accommodate
everyone's system, but there are limits.  There are also
disagreements: wasting { } on locals is one such.

Andrew.

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

#56486

On 3/30/2017 12:47, Andrew Haley wrote:
> Mark Wills <markwills1970@gmail.com> wrote:
>> On Thursday, 30 March 2017 03:58:41 UTC+1, Bernd Paysan  wrote:
>>> We of course can't know exactly what they would have, but judging
>>> from the Forth 200x effort, we try to bend over backwards to make
>>> sure even systems where one particular vendor did things all others
>>> think are stupid (like using curly brackets for multi-line comments
>>> when everybody else was using them for locals with a sane order),
>>> they certainly would have made it possible for VFX to be standard.
>>
>> And there is the problem.
>>
>> If the intention is to accommodate everybody's systems and have them all
>> be compliant
>
> It isn't.  Clearly we have made great efforts to accommodate
> everyone's system, but there are limits.  There are also
> disagreements: wasting { } on locals is one such.

I'm not sure to which side of the argument you're subscribing (the above 
is ambiguous, if you'll excuse the very obvious).

Do you mean wasting { } on locals as per SwiftForth and they should have 
modified it, or something else, such as the common practise using { } 
was wasteful?

>
> Andrew.
>


-- 
Alex

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

#56487

Alex <alex@rivadpm.com> wrote:
> On 3/30/2017 12:47, Andrew Haley wrote:
>> Mark Wills <markwills1970@gmail.com> wrote:
>>>
>>> If the intention is to accommodate everybody's systems and have them all
>>> be compliant
>>
>> It isn't.  Clearly we have made great efforts to accommodate
>> everyone's system, but there are limits.  There are also
>> disagreements: wasting { } on locals is one such.
> 
> I'm not sure to which side of the argument you're subscribing (the
> above is ambiguous, if you'll excuse the very obvious).

I'm saying that the intention is not to accommodate everybody's
systems and have them all compliant.  Given the wide range of Forth
and Forth-ish systems, that would be impossible anyway.

> Do you mean wasting { } on locals as per SwiftForth and they should have 
> modified it, or something else, such as the common practise using { } 
> was wasteful?

SwitftForth doesn't use { } for locals, it has used them for
multi-line comments for a long time.  The SwiftForth developers (and,
I suspect, a lot of their users) don't much use locals for anything.
For them it would be a waste to use { } to define locals.

Andrew.

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

#56493

On Thursday, March 30, 2017 at 4:47:51 AM UTC-7, Andrew Haley wrote:
> Mark Wills <markwills1970@gmail.com> wrote:
> > On Thursday, 30 March 2017 03:58:41 UTC+1, Bernd Paysan  wrote:
> >> We of course can't know exactly what they would have, but judging
> >> from the Forth 200x effort, we try to bend over backwards to make
> >> sure even systems where one particular vendor did things all others
> >> think are stupid (like using curly brackets for multi-line comments
> >> when everybody else was using them for locals with a sane order),
> >> they certainly would have made it possible for VFX to be standard.
> > 
> > And there is the problem.
> > 
> > If the intention is to accommodate everybody's systems and have them all
> > be compliant
> 
> It isn't.  Clearly we have made great efforts to accommodate
> everyone's system, but there are limits.  

Getting accommodated by the ANS-Forth committee primarily involves brown-nosing.

Ray Duncan would not have been able to get UR/Forth accommodated. Even if he had made UR/Forth ANS-Forth compliant to the most careful reading of the document, Elizabeth Rather would have continued to dismiss it as a non-standard wannabee. 

Everybody knew that UR/Forth was an order of magnitude higher quality than PolyForth --- there was no way that she was going to allow UR/Forth to be standard compliant --- to a large extent, the purpose of ANS-Forth was to kill UR/Forth, before the quality issue killed PolyForth.

> There are also
> disagreements: wasting { } on locals is one such.

Forth Inc. typically passes data between functions in global variables in order to avoid having too many data on the data-stack and having too much stack-juggling. Elizabeth Rather doesn't understand the concept of re-entrancy.

She says:
--------------------------------------------------------------------------
Truly, I don't see the point of all this paranoia about reentrancy,
particularly in systems without a multitasker. VARIABLE was *designed*
for things that would be used in multiple definitions. I remember the horror
of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 
30+ years of programming in Forth I never found them a problem. I think this 
is all about mythical dragons.
--------------------------------------------------------------------------

She also says:
--------------------------------------------------------------------------
I hate locals :-)
--------------------------------------------------------------------------

Andrew Haley is a total brown-noser --- he describes local variables as a "waste" for the purpose of supporting Elizabeth Rather in her hatred of local variables --- this brown-nosing eventually resulted in Elizabeth Rather appointing him to the Forth-200x committee.

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

#58430

Am Thu, 30 Mar 2017 06:47:45 -0500 schrieb Andrew Haley:
> It isn't.  Clearly we have made great efforts to accommodate everyone's
> system, but there are limits.  There are also disagreements: wasting { }
> on locals is one such.

You of course mean "wasting { } on multi-line comments, when ( ) does 
that job already" (and in ANS Forth, it does indeed, including 
SwiftForth ;-).

There's no reason to have another multi-line comment, when you already 
have one. And indeed, both words are defined exactly the same way in 
SwiftForth:

: ( [char] ) skip-past ; immediate
: { [char] } skip-past ; immediate

(reverse engineered from looking at the disassembler output).

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

#58431

On 4/30/17 3:33 PM, Bernd Paysan wrote:
> Am Thu, 30 Mar 2017 06:47:45 -0500 schrieb Andrew Haley:
>> It isn't.  Clearly we have made great efforts to accommodate everyone's
>> system, but there are limits.  There are also disagreements: wasting { }
>> on locals is one such.
>
> You of course mean "wasting { } on multi-line comments, when ( ) does
> that job already" (and in ANS Forth, it does indeed, including
> SwiftForth ;-).
>
> There's no reason to have another multi-line comment, when you already
> have one. And indeed, both words are defined exactly the same way in
> SwiftForth:
>
> : ( [char] ) skip-past ; immediate
> : { [char] } skip-past ; immediate
>
> (reverse engineered from looking at the disassembler output).

The reason is that sometimes extensive comments need to use parens, such 
as for stack arguments or describing words whose names have parens, such 
as (CREATE). If you use comments a lot, you really need an alternative 
to plain parens. That had been our policy for 10 years before ANS Forth.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#58432

On Sunday, April 30, 2017 at 6:50:53 PM UTC-7, Elizabeth D. Rather wrote:
> On 4/30/17 3:33 PM, Bernd Paysan wrote:
> > Am Thu, 30 Mar 2017 06:47:45 -0500 schrieb Andrew Haley:
> >> It isn't.  Clearly we have made great efforts to accommodate everyone's
> >> system, but there are limits.  There are also disagreements: wasting { }
> >> on locals is one such.
> >
> > You of course mean "wasting { } on multi-line comments, when ( ) does
> > that job already" (and in ANS Forth, it does indeed, including
> > SwiftForth ;-).
> >
> > There's no reason to have another multi-line comment, when you already
> > have one. And indeed, both words are defined exactly the same way in
> > SwiftForth:
> >
> > : ( [char] ) skip-past ; immediate
> > : { [char] } skip-past ; immediate
> >
> > (reverse engineered from looking at the disassembler output).
> 
> The reason is that sometimes extensive comments need to use parens, such 
> as for stack arguments or describing words whose names have parens, such 
> as (CREATE). If you use comments a lot, you really need an alternative 
> to plain parens. That had been our policy for 10 years before ANS Forth.

{ (the John Hopkins format) was used for locals since prior to ANS-Forth --- not 10 years --- but at least 5 years. There is a huge amount of legacy code that uses { for locals --- not at Forth Inc. though, because you "hate locals" and have largely banned their use at Forth Inc..

Anyway, I've had this in the novice-package since 2010:

: comment ( delimiter -- )                  \ Use a delimiter that isn't in your code. The & usually works.
    begin  dup parse? nip nip  while
        refill 0= abort" *** COMMENT never found its delimiter ***"
        repeat
    drop ;

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

#58453

In article <YZWdnRL_vNXlCZvEnZ2dnUU7-UPNnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 4/30/17 3:33 PM, Bernd Paysan wrote:
>> Am Thu, 30 Mar 2017 06:47:45 -0500 schrieb Andrew Haley:
>>> It isn't.  Clearly we have made great efforts to accommodate everyone's
>>> system, but there are limits.  There are also disagreements: wasting { }
>>> on locals is one such.
>>
>> You of course mean "wasting { } on multi-line comments, when ( ) does
>> that job already" (and in ANS Forth, it does indeed, including
>> SwiftForth ;-).
>>
>> There's no reason to have another multi-line comment, when you already
>> have one. And indeed, both words are defined exactly the same way in
>> SwiftForth:
>>
>> : ( [char] ) skip-past ; immediate
>> : { [char] } skip-past ; immediate
>>
>> (reverse engineered from looking at the disassembler output).
>
>The reason is that sometimes extensive comments need to use parens, such
>as for stack arguments or describing words whose names have parens, such
>as (CREATE). If you use comments a lot, you really need an alternative
>to plain parens. That had been our policy for 10 years before ANS Forth.

There is an alternative: the backslash.
Commenting out a block with backslashes is superior because at any
point it is perfectly clear that we are looking at comment.
The only thing needed is a good editor.
Multiline comments are especially unpleasant if code is commented out,
unless done that way.

>
>Cheers,
>Elizabeth
-- 
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]

#58462

On Monday, May 1, 2017 at 2:51:57 PM UTC-7, Albert van der Horst wrote:
> In article <YZWdnRL_vNXlCZvEnZ2dnUU7-UPNnZ2d@supernews.com>,
> Elizabeth D. Rather <erather@forth.com> wrote:
> >The reason is that sometimes extensive comments need to use parens, such
> >as for stack arguments or describing words whose names have parens, such
> >as (CREATE). If you use comments a lot, you really need an alternative
> >to plain parens. That had been our policy for 10 years before ANS Forth.
> 
> There is an alternative: the backslash.
> Commenting out a block with backslashes is superior because at any
> point it is perfectly clear that we are looking at comment.
> The only thing needed is a good editor.
> Multiline comments are especially unpleasant if code is commented out,
> unless done that way.

I only use COMMENT for commenting out code. Test code, for example, gets commented out. Also, I sometimes have working code, but I want to rewrite it, so I comment out the old code while I test the new code --- later on, one or the other will get deleted.

You idea of using \ on every line is nonsense.

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

#58500

Am Sun, 30 Apr 2017 15:50:47 -1000 schrieb Elizabeth D. Rather:

> The reason is that sometimes extensive comments need to use parens, such
> as for stack arguments or describing words whose names have parens, such
> as (CREATE). If you use comments a lot, you really need an alternative
> to plain parens. That had been our policy for 10 years before ANS Forth.

Yes, the alternative to plain parens for lots of comments was \ for lines 
(can contain anything), and \\ for the rest of the screen (can then also 
contain anything).  Everybody else was fine with that, that's why { } as 
multi-line comment didn't catch on.

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

#58522

On Tuesday, May 2, 2017 at 8:04:41 AM UTC-7, Bernd Paysan wrote:
> Am Sun, 30 Apr 2017 15:50:47 -1000 schrieb Elizabeth D. Rather:
> 
> > The reason is that sometimes extensive comments need to use parens, such
> > as for stack arguments or describing words whose names have parens, such
> > as (CREATE). If you use comments a lot, you really need an alternative
> > to plain parens. That had been our policy for 10 years before ANS Forth.
> 
> Yes, the alternative to plain parens for lots of comments was \ for lines 
> (can contain anything), and \\ for the rest of the screen (can then also 
> contain anything).  Everybody else was fine with that, that's why { } as 
> multi-line comment didn't catch on.

\\ isn't very useful for sequential files, but I have it in the novice package anyway:

: \\ ( -- )                                 \ comments out the remainder of the file
    BLK @ abort" *** \\ doesn't support block files ***"
    source-id 0=  source-id -1 =  or if     \ SOURCE-ID is EVALUATE or the console
        source >in ! drop
    else                                    \ SOURCE-ID is a file-id
        begin  refill 0= until
        then ;

\ I could make \\ support block files (just store 1024 in >IN should work) but I didn't bother with this because I don't want to take the time to test it.

\ The definition of \\ comes from this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/ixjIg7ETbnQ

In regard to block files, I used to use \\ for comments sometimes.

I read that F83 used shadow files for comments, with every block of source-code corresponding to a block of comments. I thought this was a good idea. I never used F83 though, so I don't have any experience with it.

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

#58526

On 5/2/2017 1:30 PM, hughaguilar96@gmail.com wrote:

> \ I could make \\ support block files (just store 1024 in >IN should work) but I didn't bother with this because I don't want to take the time to test it.
> 
> \ The definition of \\ comes from this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/ixjIg7ETbnQ
> 
> In regard to block files, I used to use \\ for comments sometimes.
> 
> I read that F83 used shadow files for comments, with every block of source-code corresponding to a block of comments. I thought this was a good idea. I never used F83 though, so I don't have any experience with it.
> 

I used Pygmy for a while and i used Shadow files, that was a nice 
feature that allowed very large comments without making the code hard to 
read. All it took was a keystroke to switch between code and comments, 
it also allowed comments in the code also.

-- 
Cecil - k5nwa

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

#58542

Am Tue, 02 May 2017 13:36:59 -0500 schrieb Cecil Bayona:
> I used Pygmy for a while and i used Shadow files, that was a nice
> feature that allowed very large comments without making the code hard to
> read. All it took was a keystroke to switch between code and comments,
> it also allowed comments in the code also.

Yes, and many block-based systems, AFAIK including PolyForth, supported 
that.

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

#56512

Bernd Paysan <bernd@net2o.de> writes:
>Am Thu, 23 Mar 2017 12:23:39 +0000 schrieb Anton Ertl:
>> As an example, let's turn IF into a deferred word:
>> 
>>   ' if defer if immediate is if
>> 
>> [Ok, you might argue that a standard program cannot ' IF; in that case,
>> use FIND instead; and is that stance really compatible with the "xt as
>> universal token" dogma?]
>
>Here is where your argument already breaks.  We don't know what ' IF 
>returns as xt, because that is left to the implementer - deliberately.  
>We know what IF does when it is encountered by the text interpreter in 
>compilation state.

And we know that COMPILE, has the stack effect ( xt -- ), that IF's
compilation semantics has the stack effect ( C: -- orig ), so a
standard system cannot perform the compilation semantics of IF through
COMPILE,.  So if the intention of the TC was that the user-defined
text interpreter sketched in
<http://forth-standard.org/standard/rationale#rat:core:COMPILE,>
works, FIND must return xt 1 (immediate) for IF.

>You can know if you use FIND and check if it is 
>immediate or not.  So if it is immediate, you can bind it with IS IF to 
>the new deferred IF.  If it is non-immediate,

the system's COMPILE, is non-standard.

> you can't, so you probably 
>need to define
>
>: IF  postpone IF ; immediate

Actually, if VFX wants to be a standard system, it should define IF in
that way itself (along with a bunch of other words; S" is a harder nut
to crack, though).

>There is simply no place in the 
>standard that says IF must be immediate, and that is on purpose.

It's a bit distributed (stack effect of COMPILE, and IF, what FIND
returns, and how FIND and COMPILE, are intended to be used in the
user-defined interpreter), but it's there.  IF has to be immediate in
a Forth-94 and Forth-2012 system.

As for "on purpose": The purpose was to allow cmForth's FIND to
report, say, + as "immediate", so that the text interpreter call the
+-compiler instead of compiling a call to the + routine; i.e., the
idea was to be able to report some traditionally (and, looking at the
way immediacy is defined in Forth-94/2012, also there) non-immediate
words as "immediate", not to be able to report words with non-default
compilation semantics as non-immediate.

>"xt as universal token" doesn't work well on systems with immediate 
>words, because the xt alone doesn't contain the information about 
>immediacy.
>
>The "xt as universal token" doctrine only works on a system without 
>immediacy at all, i.e. all compilation macro stuff is done through 
>COMPILE,.

So this doctrine incompatible with Forth-94 and Forth-2012.

>> Nor would they have.  Not everything that some system implementor
>> considers a good idea actually is.  We see ample demonstration of this
>> in the way gcc deals with "undefined behaviour", but the way that VFX
>> defines IF in connection with EXECUTE and COMPILE, is another example.
>
>The ANS Forth standard came into existence by making a survey what people 
>did and tried to figure out how to write the standard in a way that made 
>these different approaches fit.

Maybe in some cases.  But in others they put down the hammer and
prescribed behaviour to an extent that would lead to an immediate "But
that prescribes implementation!  That's against the spirit of ANS
Forth!" from some people here.  E.g., the standard is written in a way
that makes the then-existing technique of having ] as compiler loop
(rather than just changing the STATE of an external interpreter loop)
non-standard.

>We of course can't know exactly what they would have, but judging from 
>the Forth 200x effort, we try to bend over backwards to make sure even 
>systems where one particular vendor did things all others think are 
>stupid (like using curly brackets for multi-line comments when everybody 
>else was using them for locals with a sane order), they certainly would 
>have made it possible for VFX to be standard.

No, we don't bend over backwards for systems.  It's about programs:
There are reportedly a lot of SwiftForth programs that use "{" for
comments, including within colon definitions.  If we had standardized
on "{" for locals, that would have meant that SwiftForth will never
implement this locals syntax, that most SwiftForth users would not
load an implementation of the Forth-2012 locals syntax, and that most
SwiftForth users would not use libraries that use the new locals
syntax; the new locals syntax would have been a second-class citizen.

Of course, given that it's reportedly a "huge job" to include
extensions/locals.fs from
<http://www.forth200x.org/forth200x-code.zip> in SwiftForth (I could
do it in one line), it may still be that SwiftForth will never
implement the new locals syntax, but at least the other problems go
away with the new non-conflicting syntax, at the cost of having to
type two character more in every locals definition, and of quite a bit
of whining on c.l.f.

Anyway, back to the topic: They did not make the "]" compiler loop of
PolyForth standard-compliant, and there are a number of other cases
where they put down the hammer (e.g. CHAR and [CHAR] instead of
ASCII), and other cases where they were swayed by system implementors,
maybe too much (e.g., the not-required (but default) separate FP
stack).

Would they have been swayed by VFX?  Maybe, but I doubt it; there seem
to have been a number of people there who cared quite a bit about this
stuff, and who would probably not have accepted this nonsense,
especially given that the remedy is as easy as

: IF  postpone IF ; immediate

>The complexity of words with different interpretation and compilation 
>semantics can be shifted around, and of course, it will never completely 
>go away.  Each solution has its drawbacks and advantages.  "My solution 
>is the only one" is not the way a standard that tries to build on common 
>practice works.

Sorry, COMPILE, has already been standardized.  There is no need to
find common practice there.  This is just a question of whether VFX
complies or not.  At the moment it doesn't.

>2. Words with only compilation semantics and no interpretation semantics 
>can't be ticked meaningfully, because the user can't know whether they 
>are immediate or not - using FIND gives you that answer, but you need to 
>take it into account when you use that xt.

But the answer for IF can only be <xt-of-IF> 1.

>3. Words with both interpretation and compilation semantics, and we agree 
>that they have the same problems as the second class, and therefore we 
>also don't allow to ' them in a standard program

Even Gforth 0.4-0.7 did not go that far.  And the fact that it did not
allow ' IF has been repeatedly criticized by several people (and
that's one reason why you now can ' IF in the development version).
And being able to ' IF, but getting a result that is not useful for
EXECUTEing and performs a non-standard stack effect when COMPILE,ing
is worse than producing an error on ticking.

>4. User-defined word with non-default compilation semantics.  And this is 
>not a problem, because the user knows how he did it, and what caveats 
>that approach has.  This is reproducible.  If it's not the expected 
>behavior, the user will do something about it.

This would not be a problem for reproducability, but a problem for
usability: Forth would turn into a language with problematic corner
cases in lots of places (this property of Perl was a reason why our
attempt at using automake failed).  For every word that uses EXECUTE
or COMPILE,, you would have to document what kinds of xts are allowed;
and for every defining word, you would have to document how the xts of
that word can be used.  For someone who dislikes documenting as much
as you do, it's surprising that you advocate such an approach.  Of
course, you can also not document these things, and then blame the
user when he falls into the trap you set up.

>From a "avoid confusion" point of view, I'm for reducing the options.  
>Now, in development Gforth, the user has three possibilities to define a 
>word with non-default compilation semantics: state-smart, using set-
>optimize, and dual-xt with interpret/compile: or set-comp.  For typical 
>use, the user won't see a difference, as it's all fringe cases where you 
>actually see the difference.  You need to ' it, you need to start 
>POSTPONE or COMPILE, it.

Ok, let's reduce options:

1) make STATE one of those words that are not included from the start
(at least not with that name), and that the user has to type in if
they want it.

2) Don't mention SET-OPTIMIZER in the documentation.  To anyone who
uses it anyway, the name should be a hint as to its purpose (of
course, nowadays that "optimize" has reacquired the meaning "anything
goes" thanks to gcc, we cannot be sure about that).

3) Have a mode that uses 

: compile, postpone literal postpone execute ;

instead of the stuff coming from SET-OPTIMIZER.  If the program
behaves differently, it's likely a bug in the use of SET-OPTIMIZER.

BTW, there is no SET-COMP in Gforth.  There is a SET->COMP, but it's
undocumented.  So better use INTERPRET/COMPILE: for the moment.

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

#56518

On Friday, March 31, 2017 at 6:05:49 AM UTC-7, Anton Ertl wrote:
> Bernd Paysan <bernd@net2o.de> writes:
> > you probably 
> >need to define
> >
> >: IF  postpone IF ; immediate
> 
> Actually, if VFX wants to be a standard system, it should define IF in
> that way itself (along with a bunch of other words; S" is a harder nut
> to crack, though).

Disambiguifiers will utterly destroy any credibility that ANS-Forth ever had --- because they shine a spotlight on the fact that ANS-Forth is ambiguous.

The fact that two Forth-200x committee members are openly discussing the need for disambiguifiers implies that ANS-Forth is effectively dead --- if the committee members admit that ANS-Forth was a stupid design, then how likely is it that the rank-and-file Forth programmers will take ANS-Forth seriously?

It is not a coincidence that the two Forth-200x committee members are the two who are not directly employed by Forth Inc.. From the following Forth-200x committee members, we get a deafening silence on the subject of disambiguifiers:
Stephen Pelc --- because MPE does joint projects with Forth Inc.
Peter Knaggs --- because he works for MPE 
Andrew Haley --- because he works for Forth Inc. teaching their novice class

I think that if ANS-Forth is going to be saved, Elizabeth Rather just needs to pay Bernd Paysan and Anton Ertl to shut up about the disambiguifiers. Forth Inc. could hire them to do some simple little job, then because they are employees of Forth Inc., they would be required to support Forth Inc. on comp.lang.forth. Elizabeth Rather needs to spend some money --- you are saving a lot of money by moving out of Hawaii, so you should have some pennies to dribble on the Forth-200x committee --- make it worth their while to support ANS-Forth!

> >There is simply no place in the 
> >standard that says IF must be immediate, and that is on purpose.
> 
> It's a bit distributed (stack effect of COMPILE, and IF, what FIND
> returns, and how FIND and COMPILE, are intended to be used in the
> user-defined interpreter), but it's there.  IF has to be immediate in
> a Forth-94 and Forth-2012 system.
> 
> As for "on purpose": The purpose was to allow cmForth's FIND to
> report, say, + as "immediate", so that the text interpreter call the
> +-compiler instead of compiling a call to the + routine; i.e., the
> idea was to be able to report some traditionally (and, looking at the
> way immediacy is defined in Forth-94/2012, also there) non-immediate
> words as "immediate", not to be able to report words with non-default
> compilation semantics as non-immediate.

So, Elizabeth Rather was trying to appease Charles Moore, and get him to support ANS-Forth. LOL How well did that work out?

> >The ANS Forth standard came into existence by making a survey what people 
> >did and tried to figure out how to write the standard in a way that made 
> >these different approaches fit.
> 
> Maybe in some cases.  But in others they put down the hammer and
> prescribed behaviour to an extent that would lead to an immediate "But
> that prescribes implementation!  That's against the spirit of ANS
> Forth!" from some people here.  E.g., the standard is written in a way
> that makes the then-existing technique of having ] as compiler loop
> (rather than just changing the STATE of an external interpreter loop)
> non-standard.

It is necessary to define behavior, not implementation. 

You can't be totally liberal with implementation though, because that results in ambiguous behavior.

It should not be difficult to define behavior. Avoid making utterly stupid statements such as:
"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."
Nothing has been standardized! All in all, the ambiguity in the ANS-Forth document makes the entire Forth community look like low-grade morons.

> >We of course can't know exactly what they would have, but judging from 
> >the Forth 200x effort, we try to bend over backwards to make sure even 
> >systems where one particular vendor did things all others think are 
> >stupid (like using curly brackets for multi-line comments when everybody 
> >else was using them for locals with a sane order), they certainly would 
> >have made it possible for VFX to be standard.
> 
> No, we don't bend over backwards for systems.  It's about programs:
> There are reportedly a lot of SwiftForth programs that use "{" for
> comments, including within colon definitions.  If we had standardized
> on "{" for locals, that would have meant that SwiftForth will never
> implement this locals syntax, that most SwiftForth users would not
> load an implementation of the Forth-2012 locals syntax, and that most
> SwiftForth users would not use libraries that use the new locals
> syntax; the new locals syntax would have been a second-class citizen.

You bend over backwards for Forth Inc. --- it's about SwiftForth programs --- everybody else, you consider to be unimportant.

ANS-Forth was a marketing gimmick of Forth Inc. --- the time has come to abandon ANS-Forth --- this necessarily implies that Forth Inc. will be kicked out of the Forth community.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web