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

#56474

On Thursday, March 23, 2017 at 7:12:16 AM UTC-7, peter....@gmail.com wrote:
> 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). 

This is true. The question came up in regard to MFX --- how do we define vocabularies in TARG mode? --- my answer was: you don't.

I didn't consider vocabularies in a cross-compiler to be important, and Testra didn't either, so the issue was not pursued.

Other than cross-compiling, I've never really used vocabularies for anything. The only common use is ASSEMBLER that allow you to have OR AND etc., that would clash with the FORTH versions --- in those days, ASSEMBLER words always had a comma on the end as a naming convention: OR, AND, etc. --- so vocabularies were solving a non-problem anyway.

> Also when you redefine
> a word you need to remember to do it in both vocabularies.

I don't know what you mean here. In MFX, when you defined a word in TARG mode you internally defined two words --- the word in TARG that executes on the target processor, and the word in HOST that compiles the TARG word with the same name.

Also, in MFX it was common for me to write a file of code and then compile it both in HOST and in TARG mode --- I typically wrote code first in HOST mode because testing and debugging was easier on the host machine (because I had a REPL) --- I then compiled it in TARG mode so I would have it on the MiniForth.

> 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 

I would be okay with that. This is essentially what I would have done in MFX if the issue of having vocabularies in TARG mode had been pursued.

ANS-Forth is just utterly stupid! ANS-Forth allows a wide variety of contradictory FIND versions, and calls them all compliant. ANS-Forth even allows Gforth to be compliant with its bizarre FIND in which FIND returns different xt values depending upon what STATE @ is at the time FIND executes --- that is double-decker stupidity! --- ANS-Forth's ambiguity is a foundation layer of stupid, then gForth's bizarre FIND is another layer of stupid on top of the first layer of stupid.

Straight Forth is somewhat ambitious. As an interim standard, I think Traditional Forth would be a good idea. This would be very similar to Forth-83 except with a few simple improvements (such as making my rquotations standard). I would be okay with Traditional Forth having a dual-xt system, but it would have to be designed in a way that makes sense (not the absurd gForth way, but rather with your FIND-COMPILE and FIND-INTERPRET), and it would have to be standardized so all implementations of Traditional Forth behave in the same thing (not wildly ambiguous, which is the ANS-Forth way).

The important thing is that Forth Inc. would not be allowed to contribute to 
Traditional Forth --- their contributions have been consistently stupid from 1982 onward --- the Forth community can really do without Forth Inc..

Forth Inc. is the reason why Forth lost popularity --- if Forth is going to succeed, the first necessity is to jettison Forth Inc.. 

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

#56185

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> 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?

You do, but the effect can be very different.  In the systems I'm
thinking of from the time of ANS, you would make two definitions,
which would go into different vocabularies.  So, there might be two
definitions of + visible, and the search order would determine which
you got.  This isn't like a single word in a single wordlist with 2
XTs.

Andrew.

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

#56471

Am Thu, 23 Mar 2017 10:22:21 -0500 schrieb Andrew Haley:

> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>> 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?
> 
> You do, but the effect can be very different.  In the systems I'm
> thinking of from the time of ANS, you would make two definitions, which
> would go into different vocabularies.  So, there might be two
> definitions of + visible, and the search order would determine which you
> got.  This isn't like a single word in a single wordlist with 2 XTs.

I see dual-wordlist as the original dual-xt thing the ANS Forth standard 
tried to accommodate; the dual-xt way with a single word in one wordlist 
came later, when we tried to wrap Gforth around the literal 
interpretation of the ANS Forth standard.

It turned out that the original dual-xt (with two wordlists) cmForth 
approach was not fully compatible with the Standard (with a literal 
interpretation), and Chuck didn't care, and it didn't catch on, either.

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

#56481

Bernd Paysan <bernd@net2o.de> wrote:
> Am Thu, 23 Mar 2017 10:22:21 -0500 schrieb Andrew Haley:
> 
>> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>>> 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?
>> 
>> You do, but the effect can be very different.  In the systems I'm
>> thinking of from the time of ANS, you would make two definitions, which
>> would go into different vocabularies.  So, there might be two
>> definitions of + visible, and the search order would determine which you
>> got.  This isn't like a single word in a single wordlist with 2 XTs.
> 
> I see dual-wordlist as the original dual-xt thing the ANS Forth standard 
> tried to accommodate;

I think that interpretation makes sense, yes.

> the dual-xt way with a single word in one wordlist came later, when
> we tried to wrap Gforth around the literal interpretation of the ANS
> Forth standard.
>
> It turned out that the original dual-xt (with two wordlists) cmForth
> approach was not fully compatible with the Standard (with a literal
> interpretation), and Chuck didn't care, and it didn't catch on,
> either.

That's how I remember it, too.  There were such severe disadvantages
to dual-wordlist that it had to die.  Dual-xt gets rid of some of
those disadvantages.

Andrew.

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

#56488

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd@net2o.de> wrote:
>> It turned out that the original dual-xt (with two wordlists) cmForth
>> approach was not fully compatible with the Standard (with a literal
>> interpretation), and Chuck didn't care, and it didn't catch on,
>> either.
>
>That's how I remember it, too.  There were such severe disadvantages
>to dual-wordlist that it had to die.

I guess if it was more popular, even the cmForth variant would be
defended with the same argument that people use for defending
STATE-smart implementations of S": "Yes, it's not compatible with the
standard as written, but the intention was to allow this
implementation, so we should not use a literal reading of the standard
for this".

Apart from that, it is possible to make the dual-wordlist approach
(and also the STATE-smart S") fully compatible with a literal reading
of the standard, but the resulting dual-wordlist implementation is
more complicated than the single-wordlist/dual-xt implementation.

The main issue with the dual-wordlist approach is: AFAIK the compiler
wordlist is searched first in compile state, so an older IF in the
compiler wordlist will be found before (i.e., instead of) a newer IF
in the FORTH wordlist.  This can be fixed by searching both, and
returning the later-defined one (i.e., the one with the bigger
address).

Other issues are:

User-defined words with special compilation semantics need to be
defined with syntax specific to this model (but that's the same for
other models).

Supporting the search-order wordset gets quite complex, in particular
if you want to have special compilation semantics for words in other
wordsets than the Forth wordset; probably the best way would be if
each WORDLIST call creates a corresponding compilation wordlist, and
FIND searches the corresponding compilation wordlist along with the
general wordlist for each wordlist in the search order.

>Dual-xt gets rid of some of
>those disadvantages.

You need none of the comlexity outlined above.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#56490

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Bernd Paysan <bernd@net2o.de> wrote:
>>> It turned out that the original dual-xt (with two wordlists) cmForth
>>> approach was not fully compatible with the Standard (with a literal
>>> interpretation), and Chuck didn't care, and it didn't catch on,
>>> either.
>>
>>That's how I remember it, too.  There were such severe disadvantages
>>to dual-wordlist that it had to die.
> 
> I guess if it was more popular, even the cmForth variant would be
> defended with the same argument that people use for defending
> STATE-smart implementations of S": "Yes, it's not compatible with the
> standard as written, but the intention was to allow this
> implementation, so we should not use a literal reading of the standard
> for this".

Standard compatibility was not the major issue in this case: the
problem with dual-vocabulary was that it was (as implemented)
hellishly confusing and error-prone.

> The main issue with the dual-wordlist approach is: AFAIK the
> compiler wordlist is searched first in compile state, so an older IF
> in the compiler wordlist will be found before (i.e., instead of) a
> newer IF in the FORTH wordlist.  This can be fixed by searching
> both, and returning the later-defined one (i.e., the one with the
> bigger address).

Not really.  If you have, say

: s"   ... ;  immediate
: s"   ... ;

then in compilation state you want the first one, not he second.  I
suppose you could establish a convention of putting the compiler's
version after the one for the interpreter, but eurgh.  No.
 
> Other issues are:
> 
> User-defined words with special compilation semantics need to be
> defined with syntax specific to this model (but that's the same for
> other models).

As I recall, all IMMEDIATE had to do was move a word from one list to
another.  That's exactly the same syntax as standard, but different
semantics.

> Supporting the search-order wordset gets quite complex, in particular
> if you want to have special compilation semantics for words in other
> wordsets than the Forth wordset; probably the best way would be if
> each WORDLIST call creates a corresponding compilation wordlist, and
> FIND searches the corresponding compilation wordlist along with the
> general wordlist for each wordlist in the search order.

This is exactly what was done on the system I used.

Andrew.

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

#56494

On Thursday, March 30, 2017 at 10:03:29 AM UTC-7, Andrew Haley wrote:
> As I recall, all IMMEDIATE had to do was move a word from one list to
> another.  That's exactly the same syntax as standard, but different
> semantics.

I have said many times that it is necessary for the user to be able to obtain and change the attributes of a word, given the xt of the word:

: immediate@ ( xt -- flag )  \ is the word immediate? 
: vocabulary@ ( xt -- voc# )  \ what vocabulary was the word defined in? 
: smudge@ ( xt -- flag )  \ is the word smudged? 
: smudgeable@ ( xt -- flag ) \ will the word be smudged by END-MODULE ? 

: immediate! ( flag xt -- )  \ set the word to immediate (if true) or non-immediate
: vocabulary! ( voc# xt -- )  \ set what vocabulary the word is in
: smudge! ( flag xt -- )  \ smudge the word (if true) or unsmudge it
: smudgeable! ( flag xt -- )  \ set the words smudge-ready flag

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

#56507

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>That's how I remember it, too.  There were such severe disadvantages
>>>to dual-wordlist that it had to die.
>> 
>> I guess if it was more popular, even the cmForth variant would be
>> defended with the same argument that people use for defending
>> STATE-smart implementations of S": "Yes, it's not compatible with the
>> standard as written, but the intention was to allow this
>> implementation, so we should not use a literal reading of the standard
>> for this".
>
>Standard compatibility was not the major issue in this case: the
>problem with dual-vocabulary was that it was (as implemented)
>hellishly confusing and error-prone.

That has not stopped STATE-smart systems, nor "smart" COMPILE,
systems, and when a confusion or error with these systems shows up,
the defenders give us the old doctor joke ("Doctor, it hurts if I do
that" "Well, then don't do that").

>> The main issue with the dual-wordlist approach is: AFAIK the
>> compiler wordlist is searched first in compile state, so an older IF
>> in the compiler wordlist will be found before (i.e., instead of) a
>> newer IF in the FORTH wordlist.  This can be fixed by searching
>> both, and returning the later-defined one (i.e., the one with the
>> bigger address).
>
>Not really.  If you have, say
>
>: s"   ... ;  immediate
>: s"   ... ;
>
>then in compilation state you want the first one, not he second.

In a standard system, I certainly want to find the second one in every
case.  And for implementing S", I would have to write, say

: s" ... interpretation semantics ... ;
: s" ... compilation semantics ... ; >comp-wordlist
  I
>suppose you could establish a convention of putting the compiler's
>version after the one for the interpreter, but eurgh.  No.

Does not look any worse than putting it before.

>> Other issues are:
>> 
>> User-defined words with special compilation semantics need to be
>> defined with syntax specific to this model (but that's the same for
>> other models).
>
>As I recall, all IMMEDIATE had to do was move a word from one list to
>another.  That's exactly the same syntax as standard, but different
>semantics.

Ok, that's worse, but easily fixed by renaming the word that puts the
last definition in the compilation wordlist, e.g., into >COMP-WORDLIST.
Then you have just special syntax for the non-standardized stuff, and
standard syntax has standard semantics.

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

#56511

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>That's how I remember it, too.  There were such severe disadvantages
>>>>to dual-wordlist that it had to die.
>>> 
>>> I guess if it was more popular, even the cmForth variant would be
>>> defended with the same argument that people use for defending
>>> STATE-smart implementations of S": "Yes, it's not compatible with
>>> the standard as written, but the intention was to allow this
>>> implementation, so we should not use a literal reading of the
>>> standard for this".
>>
>>Standard compatibility was not the major issue in this case: the
>>problem with dual-vocabulary was that it was (as implemented)
>>hellishly confusing and error-prone.
> 
> That has not stopped STATE-smart systems, nor "smart" COMPILE,
> systems, and when a confusion or error with these systems shows up,
> the defenders give us the old doctor joke ("Doctor, it hurts if I do
> that" "Well, then don't do that").

Indeed, don't do that.  But dual-wordlist caused confusion even if you
weren't trying to play tricks to implement words like S" : "ordinary"
immediate words, i.e. those not intended to be used interpretatively,
were adversely affected as well.

>>> The main issue with the dual-wordlist approach is: AFAIK the
>>> compiler wordlist is searched first in compile state, so an older IF
>>> in the compiler wordlist will be found before (i.e., instead of) a
>>> newer IF in the FORTH wordlist.  This can be fixed by searching
>>> both, and returning the later-defined one (i.e., the one with the
>>> bigger address).
>>
>>Not really.  If you have, say
>>
>>: s"   ... ;  immediate
>>: s"   ... ;
>>
>>then in compilation state you want the first one, not he second.
> 
> In a standard system,

It's not a standard system, it's a dual-wordlist system.  As I said,
standard compatibility really isn't the point.  Besides, nobody is
advocating dual-wordlist systems, so I don't understand your point in
pursuing this.

Andrew.

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

#56535

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
[...]
>But dual-wordlist caused confusion even if you
>weren't trying to play tricks to implement words like S" : "ordinary"
>immediate words, i.e. those not intended to be used interpretatively,
>were adversely affected as well.

Can you give an example?

>>>: s"   ... ;  immediate
>>>: s"   ... ;
>>>
>>>then in compilation state you want the first one, not he second.
>> 
>> In a standard system,
>
>It's not a standard system, it's a dual-wordlist system.

You make it sound as if these were incompatible, but that is contrary
to the intention of the Forth-94 TC.

>Besides, nobody is
>advocating dual-wordlist systems, so I don't understand your point in
>pursuing this.

The dual-wordlist approach looked so attractive to the Forth-94 TC
that they specified that standard in a way that can be implemented
with a dual-wordlist approach.  OTOH, the implementors of Forth-94
then did not want to take this approach, and the implementors of
dual-wordlist systems did not want to take the extra steps to become
Forth-94 compliant.  This is a somewhat paradoxical result, and I am
interested in understanding the issues involved.

One thing the present discussion turned up is that the system you used
had a non-standard meaning of IMMEDIATE (more along the lines of
IMMEDIATE COMPILE-ONLY in Gforth, but without shadowing the
interpretation semantics of other definitions with the same name); it
also did not obey the rule that the latest definition of a name within
a wordlist (pair) takes precedence.  Both of these can be fixed
without much implementation effort (the bigger problem may be existing
programs for the system).

For the standard IMMEDIATE, two implementations come to mind: make a
SYNONYM of the last definition in the compiler wordlist; or have an
immediate flag in each word in the regular wordlist.

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

#56544

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> [...]
>>But dual-wordlist caused confusion even if you weren't trying to
>>play tricks to implement words like S" : "ordinary" immediate words,
>>i.e. those not intended to be used interpretatively, were adversely
>>affected as well.
> 
> Can you give an example?

Sure.  If you defined an immediate word and later defined a non-
immediate word of the same name, the non-immediate word would work
from the interpreter but the older immediate word would be used when
compiling.  Please note that I'm talking about the dual-wordlist
systems that I used at the time, not some theoretically possible ones.

>>>>: s"   ... ;  immediate
>>>>: s"   ... ;
>>>>
>>>>then in compilation state you want the first one, not he second.
>>> 
>>> In a standard system,
>>
>>It's not a standard system, it's a dual-wordlist system.
> 
> You make it sound as if these were incompatible, but that is contrary
> to the intention of the Forth-94 TC.

Perhaps it was contrary to their intention, but I never saw a
dual-wordlist system which was Forth-94 compatible, and it would be
difficult unless you had COMPILE-ONLY and also an IMMEDIATE provided
for compatibility.  Programs you wrote for that system (using
COMPILE-ONLY rather than IMMEDIATE) would not be standard programs.  I
don't think that anybody at the time thought that would have been a
good idea: dual wordlists were intended to replace the traditional
IMMEDIATE behaviour, not supplement it.

>>Besides, nobody is advocating dual-wordlist systems, so I don't
>>understand your point in pursuing this.
> 
> The dual-wordlist approach looked so attractive to the Forth-94 TC
> that they specified that standard in a way that can be implemented
> with a dual-wordlist approach.  OTOH, the implementors of Forth-94
> then did not want to take this approach, and the implementors of
> dual-wordlist systems did not want to take the extra steps to become
> Forth-94 compliant.  This is a somewhat paradoxical result, and I am
> interested in understanding the issues involved.

I don't think there was any reasonably elegant way to do it.

> For the standard IMMEDIATE, two implementations come to mind: make a
> SYNONYM of the last definition in the compiler wordlist; or have an
> immediate flag in each word in the regular wordlist.

Right, so you'd have the problem I described above.

Andrew.

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

#56187

Bernd Paysan <bernd@net2o.de> writes:
>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,.

This is not just about S" and TO.  If it was, we would just disallow
ticking S" (' TO is already disallowed), and refine FIND
appropriately, and not worry about it.  But some people (e.g., you)
like to create new words with (approximations to) non-default
non-immediate compilation semantics at a high rate, and they even
create defining words that create such words.

And at some point somebody will need to use either the interpretation
or the compilation semantics of such a word in the form of an xt where
requirement 2 holds, and that's when the trap you want to set up for
all Forth users springs.  Just as the trap set up by putting STATE @
IF in all kinds of places sprang when I demonstrated Forth's
metaprogramming capabilities to a student (who then chose to use a
different language for his master's project).

And it's not just OO.  E.g., you wrote a word DEFERS that's compiles
the current xt contained in a deferred word into the current
definition (i.e., it resolved the deferred word during compilation
instead of at run-time), used for refining deferred words.

  [undefined] defer@ [if]
    cr .( warning: defer@ absent )
    : defer@ >body @ ; \ works on SwiftForth
  [then]

  : Defers ( compilation "name" -- ; run-time ... -- ... )
    \ Compiles the present contents of the deferred word @i{name}
    \ into the current definition.  I.e., this produces static
    \ binding as if @i{name} was not deferred.
    ' defer@ compile, ; immediate

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

Let's see if our new IF works as IF should:

  : foo1
    0 ?do
      dup c@ [char] a [char] z 1+ within if
        dup c@ emit then
      1+ loop
    drop ;
  
  s" 123abcABC" foo1 cr

Let's have a variant that counts the number of total performed IF's and
which of those take the then-branch:

  variable total-ifs
  variable then-branches
  : inc-total ( -- ) 1 total-ifs +! ;
  : inc-thens ( -- ) 1 then-branches +! ;
  
  :noname ( compilation -- orig ; run-time f -- )
    postpone inc-total defers if postpone inc-thens ;
  is if

Let's use our enhanced if in the same code:

  : foo2 ( c-addr u -- )
    0 ?do
      dup c@ [char] a [char] z 1+ within if
        dup c@ emit then
      1+ loop
    drop ;
  
  s" 123abcABC" foo2 total-ifs ? then-branches ? cr

Ok, running this on SwiftForth, I get

IF isn't unique. abc
abc9 3 

Apart from the "isn't unique" warning, as intended.  Let's see what
Gforth (development version) does:

xxx.fs:5:5: redefined Defers
xxx.fs:11:5: IF is compile-only
xxx.fs:12:9: redefined IF with ifabc
abc9 3 

A few redefinition warnings, a warning about ticking a compile-only
word, and then the expected output.

Now VFX:

IF is redefined 
Err# -14 ERR: Attempt to interpret a compile only definition.
 Source: "xxx.fs" on line 17 
 ->       dup c@ [char] a [char] z 1+ within if
                                              ^sh: 1: 

What is happening is this: In the definition of FOO, our IF calls the
system IF in a way that invokes the compile-only error.  Ok, ticking
gets us an xt that has this behaviour, fair enough.  In that case,
requirement 2 says that we should also see this behaviour when
compiling FOO2.  So, after commenting FOO1 out, what do I get?

VFX reports the redefinition of IF and then hangs, consuming 100% of
one core.  A little debugging reveals that the COMPILE, in DEFERS IF
performs the compilation semantics of IF (instead of appending the
compilation semantics, as intended), which has two problems:

A) The requirement 2) above is not satisfied.  If it was, we would get
   the same error, as can be easily verified by prepending
     : compile, postpone literal postpone execute ;

B) The stack effect of VFX's COMPILE, is not standard-compliant when
   you pass the xt of IF to it: ( xt -- orig ).


Back to the requirements: One of Forth's assets is that it has just
one class of words, unlike, e.g., Algol-family languages with their,
keywords, operators, and identifiers.  You just have words, and you
can use them in any context.  That's why people complained when Gforth
did not allow to tick compile-only words, and that's why we now allow
ticking compile-only words.

Dividing words into two classes, those where requirement 2 holds, and
those where it does not hold, makes Forth conceptually more complex,
and eliminates the advantage of having only one word class.  So,
great, you now have a "universal token", but now you have two word
classes, and you can use the "universal token" of some words for OO
programming and DEFERred words, but not the "universal token" of
others words.

If you want to create words like S" and TO, this introduces
complexity, and it either shows up as conceptual complexity in the
form of traps and (usually after someone fell in) "don't do this"
rules, or as implementation complexity in properly implementing
interpretation and compilation semantics; and in the present case that
implementation complexity is actually relatively small.

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

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.

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

#56188

On 3/23/2017 12:23, Anton Ertl wrote:
>     postpone inc-total defers if postpone inc-thens ;

DEFERS ?

-- 
Alex

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

#56192

Alex <alex@rivadpm.com> writes:
>On 3/23/2017 12:23, Anton Ertl wrote:
>>     postpone inc-total defers if postpone inc-thens ;
>
>DEFERS ?

Explation and code earlier in the posting.

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

#56194

On 3/23/2017 17:38, Anton Ertl wrote:
> Alex <alex@rivadpm.com> writes:
>> On 3/23/2017 12:23, Anton Ertl wrote:
>>>     postpone inc-total defers if postpone inc-thens ;
>>
>> DEFERS ?
>
> Explation and code earlier in the posting.
>
> - anton
>

Sorry, I cut & paste in haste.

Case 1:

STC Experimental 32bit: 0.06.08 Build: 783
   defer if immediate
         ^^
Warning -4100 in c:/w32f/v608/src/testifs.fs at line 13 : if is redefined
       dup c@ [char] a [char] z 1+ within if
                                          ^^
Error -14 in c:/w32f/v608/src/testifs.fs at line 18 : if is compilation only

Case 2:

STC Experimental 32bit: 0.06.08 Build: 783
   defer if immediate
         ^^
Warning -4100 in c:/w32f/v608/src/testifs.fs at line 13 : if is redefined
     postpone inc-total defers if postpone inc-thens ;
                                                     ^
Error -320 in c:/w32f/v608/src/testifs.fs at line 33 : ; control stack 
mismatch

COMPILE, doesn't do anything with the ORIG on the stack left from 
compiling IF, and it craps out at the end of the definition.

-- 
Alex

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

#56200

On 3/23/2017 17:58, Alex wrote:
> On 3/23/2017 17:38, Anton Ertl wrote:
>> Alex <alex@rivadpm.com> writes:
>>> On 3/23/2017 12:23, Anton Ertl wrote:
>>>> postpone inc-total defers if postpone inc-thens ;
>>>
>>> DEFERS ?
>>
>> Explation and code earlier in the posting.
>>
>> - anton
>>
>
> Sorry, I cut & paste in haste.
>
> Case 1:
>
> STC Experimental 32bit: 0.06.08 Build: 783 defer if immediate ^^
> Warning -4100 in c:/w32f/v608/src/testifs.fs at line 13 : if is
> redefined dup c@ [char] a [char] z 1+ within if ^^ Error -14 in
> c:/w32f/v608/src/testifs.fs at line 18 : if is compilation only
>
> Case 2:
>
> STC Experimental 32bit: 0.06.08 Build: 783 defer if immediate ^^
> Warning -4100 in c:/w32f/v608/src/testifs.fs at line 13 : if is
> redefined postpone inc-total defers if postpone inc-thens ; ^ Error
> -320 in c:/w32f/v608/src/testifs.fs at line 33 : ; control stack
> mismatch
>
> COMPILE, doesn't do anything with the ORIG on the stack left from
> compiling IF, and it craps out at the end of the definition.
>

For clarity (and Anton will know this), case 2 is incorrect behaviour.



-- 
Alex

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

#56221

Alex <alex@rivadpm.com> writes:
>Sorry, I cut & paste in haste.

To save others the effort to combine the fragments, I have put the
code in the web:

<http://www.complang.tuwien.ac.at/forth/test-comp-exec.fs>

>Case 1:
>
>STC Experimental 32bit: 0.06.08 Build: 783
>   defer if immediate
>         ^^
>Warning -4100 in c:/w32f/v608/src/testifs.fs at line 13 : if is redefined
>       dup c@ [char] a [char] z 1+ within if
>                                          ^^
>Error -14 in c:/w32f/v608/src/testifs.fs at line 18 : if is compilation only
>
>Case 2:
>
>STC Experimental 32bit: 0.06.08 Build: 783
>   defer if immediate
>         ^^
>Warning -4100 in c:/w32f/v608/src/testifs.fs at line 13 : if is redefined
>     postpone inc-total defers if postpone inc-thens ;
>                                                     ^
>Error -320 in c:/w32f/v608/src/testifs.fs at line 33 : ; control stack 
>mismatch
>
>COMPILE, doesn't do anything with the ORIG on the stack left from 
>compiling IF, and it craps out at the end of the definition.

That's pretty similar to the VFX way, except that VFX produces an
endless loop if the definition is a :NONAME definition (the behaviour
is similar to your system if the definition is named).

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

#56197

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>If you want to create words like S" and TO, this introduces
>complexity, and it either shows up as conceptual complexity in the
>form of traps and (usually after someone fell in) "don't do this"
>rules, or as implementation complexity in properly implementing
>interpretation and compilation semantics; and in the present case that
>implementation complexity is actually relatively small.

If you don't want that implementation complexity, the proper
alternative is to just have words with default compilation semantics
and immediate words.  Get rid of S" and S\" (use the string recognizer
instead), TO and IS (use the ->... recogizer instead), and ACTION-OF
(use DEFER@ instead).  Of course, this means that you cannot have
interpretive [: (use :NONAME instead), DOES> (just put it in a colon
definition) etc.  Its the solution I would prefer, but I fear that
people are so much in love with dual-semantics words that they will
misuse other features (in particular STATE, or SET-OPTIMIZER) to
approximate them, and that's how we got where we are now.

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

#56473

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.  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, you can't, so you probably 
need to define

: IF  postpone IF ; immediate

first to get a reliable immediate IF, and then create the deferred IF.

When you don't know what IF is, you can't tick it (and expect some 
meaningful xt as result), and therefore, your program is non-standard and 
will break in various ways depending on what's different between your 
assumption and the actual system.  There is simply no place in the 
standard that says IF must be immediate, and that is on purpose.

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

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

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.

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.

Red herrings in a discussion don't help.  If the example already requires 
carnal knowledge, it is a non-standard program, and therefore doesn't 
need to work on every system.

We already went through that discussion.  The result was:

1. Words with default compilation semantics are no problem.

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.  Your examples don't, and ANS 
Forth already said it will fail.

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 (results are not 
reproducible across systems, this is not meaningful).  Here, we needed to 
fix the standard, as ANS Forth did not say "here be dragons" with S".

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.

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.

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

#56475

On Wednesday, March 29, 2017 at 7:58:41 PM UTC-7, Bernd Paysan wrote:
> 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.  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, you can't, so you probably 
> need to define
> 
> : IF  postpone IF ; immediate
> 
> first to get a reliable immediate IF, and then create the deferred IF.
> 
> When you don't know what IF is, you can't tick it (and expect some 
> meaningful xt as result), and therefore, your program is non-standard and 
> will break in various ways depending on what's different between your 
> assumption and the actual system.  There is simply no place in the 
> standard that says IF must be immediate, and that is on purpose.

Disambiguifiers are the heart and soul of ANS-Forth programming! :-D

> "xt as universal token" doesn't work well on systems with immediate 
> words, because the xt alone doesn't contain the information about 
> immediacy.

In Traditional Forth I would provide these words:
: immediate@ ( xt -- flag )  \ is the word immediate?
: vocabulary@ ( xt -- voc# )  \ what vocabulary was the word defined in?
: smudge@ ( xt -- flag )  \ is the word smudged?
: smudgeable@ ( xt -- flag ) \ will the word be smudged by END-MODULE ?

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

Traditional Forth would most certainly have immediate words --- having COMPILE, special-case the words that would normally be immediate, as done in VFX, is a terrible idea --- this is not traditional, and it breaks from the simple and understandable virtue of Forth.

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

Thinking is very important! Making decisions by taking a survey of expert-posturing idiots is a guaranteed failure.

I remember when I was in high-school algebra class that the "wisdom of the crowd" idea came up. The idea was that if a crowd of people guessed at a bull's weight, and their guesses were averaged, this would be more accurate than one person guessing. The algebra teacher, who owned a cattle ranch and was familiar with bulls, was unimpressed. He said that one person guessing is going to be accurate if that person knows the subject, but if you put that one person in a crowd of idiots and give each of them one vote, then his vote will get cancelled out.

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

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

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

csiph-web