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

Groups > comp.lang.forth > #60146

Re: Another recognizer discussion

Show all headers | View raw

stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 01 Jun 2017 05:50:57 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>>IMHO name tokens had a rationale for TRAVERSE-WORDLIST, but I was
>>>afraid that they would open the FIG-Forth can of worms that ANS
>>>nailed shut with the XT. Now we see that indeed NTs are rampant, but
>>>just replicating existing practice.
>>
>>Can you elaborate on that?  Which can of worms do you mean?  Do you
>>think that FIND-NAME/SEARCH-NAME opens it, and if so, why?  I don't
>>understand what you mean with the last sentence at all.
>
>I mean exposing the whole header navigation word set. Internally,
>most systems have words to traverse dictionary headers. In FIG-Forth
>they were standardised, e.g. >NFA ( xt -- nfa ).

I guess you mean

NFA ( pfa -- nfa )

> From ANS onwards,
>these words were retired. I still see very little need to expose
>them again.

Noted.  But what does this have to do with FIND-NAME/SEARCH-NAME?

>>>The whole point of an XT was to provide a single point of reference to
>>>a word. an XT is an opaque type (anything the implementation wants it
>>>to be). In many systems it's the address of the interpretation
>>>behaviour of the word - it's optimised for EXECUTE. The cost of 
>>>providing a link to a name field or name token is a single
>>>instruction on most desktop CPUs and even just one on most modern
>>>embedded CPUs.
>>
>>In Gforth <=0.7 there is no reliable way to get to the name field, if
>>one even exists.  Do you want to disenfrenchise systems that are
>>implemented that way, and prescribe the implementation to provide a
>>link to the name field?
>
>To use one of your favourite phrases, it's a quality of implementation
>issue. MPE values the source management facilities provided by LOCATE
>and XREF enough to provide the access. If you make these tools using
>other techniques, you may not need direct access.

So LOCATE and XREF have nothing to do with the back link and even less
with FIND-NAME/SEARCH-NAME and are a red herring.

> I'm not trying to
>disenfranchise a system at all, I'm trying to retain the original
>ANS meaning of an XT.

The original ANS meaning is that you can EXECUTE it and COMPILE, it
(and do the things you can do with other cells), nothing more.  And
FIND-NAME/SEARCH-NAME don't take this away, so they retain the
original ANS meaning of xt.

>>>The ghastliness of multiple xts for compilation actions is just
>>>exposing internal structures that should not be exposed. The idea
>>>of the ANS XT applies today just as much as did in 1994.
>>
>>Your idea of xts is incompatible with ANS Forth.  Have you fixed VFX's
>>COMPILE, to be ANS Forth compliant already?  Remember, in ANS Forth
>>and Forth-2012 its stack effect is
>>
>>COMPILE, ( xt -- )
>>
>>I can dig out the bug report again that I sent you two years ago.
>
>Your bug report was very helpful in clarifying my view of
>interpretation and compilation in Forth-2012. The report basically
>says that COMPILE, cannot be used for words that parse or have a
>stack effect, e.g. IF.

You can certainly use COMPILE, on the xt of IF (that you get, e.g.,
from FIND), but that must not perform the compilation semantics of IF,
because that is incompatible with the stack effect of COMPILE,.  In
consequence, C" IF" FIND in compilation state has to return ( xt-if 1
), i.e., immeditae, and xt-if, when EXECUTEd, performs the compilation
semantics of IF.  COMPILE,ing that xt is like POSTPONE IF (which again
has the right stack effect).

>These are the words that have non-default
>compilation semantics (NDCS). In VFX I can define NDCS, as the
>analogue for COMPILE, for these words. In practice, the
>definition for VFX is:
>: NDCS,    ( i*x xt -- j*x ; may parse )  COMPILE,  ;

I don't see how that fixes the bug in COMPILE,.

>>Anyway, there are Forth systems that have an xt for interpretation and
>>something independent for compilation, in order to implement words
>>such as S" (ANS Forth).  On these systems you cannot get to the
>>compilation semantics from the interpretation semantics (or vice
>>versa).  Do you want to disenfrenchise these systems by prescribing the
>>implementation?
>
>These systems have already broken the idea of an XT. These systems
>are already broken.

They may have broken *your* idea of an XT, but so what?  Such systems
can certainly be compatible with the requirements of ANS Forth, unlike
VFX, where COMPILE, does not work as specified by ANS Forth,
demonstrating that your idea of an XT is incompatible with ANS Forth.

>>An NT provides access to interpretation and compilation semantics, and
>>to the word name.
>
>That's an implementation issue for a system with a broken XT.

System issues can be solved with system-specific approaches (aka
carnal knowledge), no need to standardize NTs for that.

No, the main benefit of these features is for standard programs: E.g.,
let's have a table of words

create word-table
s" if" find-name ,
s" 2*" find-name ,
s" then" find-name ,

: show-nts ( addr u -- )
   cells over + swap do i @ name>string type space 1 cells +loop ;

: compile-nts ( addr u -- )
   cells over + swap do i @ name>compile execute 1 cells +loop ;

word-table 3 show-nts \ prints "IF 2* THEN"
: foo [ word-table 3 compile-nts ] ;
see foo \ prints:
\ : foo  
\   IF     2* 
\   THEN ; ok
3 true foo . \ prints 6

There is no standard (and, on some systems, no non-standard) way to do
the this with a table of xts.  You may point out that the
initialization of the table uses the not (yet?)  standard FIND-NAME,
and that's the reason why it should be standardized, but if we are in
a pinch, we can get the nts of these words already in Forth-2012 using
TRAVERSE-WORDLIST.

>>An XT can only be EXECUTEd and COMPILE,d; you cannot get the
>>interpretation and compilation semantics of a word from it in ANS
>>Forth or Forth-2012, nor the word name.  That is reflected in the
>>definition of FIND (ANS Forth and Forth-2012):
>
>People regularly store XTs in variables and tables.

And they DUP and SWAP them.  So yes, you can also perform all general
cell operations on xts.  You can also perform them on nts, which are
also cells.  I did not think that they were worth mentioning.

> See DEFER and IS.

Yes, in Forth-2012 you can also use DEFER@, DEFER! and IS on them.

>>|For a given string, the values returned by FIND while compiling may
>>|differ from those returned while not compiling.
>>
>>If the xt was the single point of reference to a word as you claim,
>>this sentence would make no sense.
>
>cmForth made little sense at the time. That sentence is just a
>concession to cmForth. It was a mistake in 1994 and it's still
>unnecessary in 2017. The dual wordlist approach is just a bad
>design decision in the long term.

The ANS Forth TC obviously thought differently.  And not only have
they written that sentence into ANS Forth, they also specified FILE
S", which actually makes it necessary to return different xts if you
want to comply with ANS Forth even in corner cases; for TO they at
least ambiguified the corner cases.

And the Forth-2012 committee changed neither this sentence in FIND nor
did we change that aspect of FILE S", and we added two more words of
its ilk, IS and ACTION-OF (both with ambiguified corner cases).  Maybe
these things are a mistake in ANS Forth, but we obviously could not
find a consensus on a better solution; i.e., what they did is
apparently not that bad.

>Building tables of XTs when you do not know whether you can use the XT
>with COMPILE, just forces you to build special tools and double the
>size of the table by having separate interpretation and compilation
>entries. The simple way:
>create atable \ -- addr
>  ' foo ,
>  ' bar ,
>  ...
>The bad way:
>create atable \ -- addr
>  'interp foo ,  'comp foo ,
>  'interp bar ,  'comp bar ,
>  ...

You need to store the immediacy flag, too, for the compilation
semantics.

>Having two results from FIND disenfranchises simple techniques in
>Forth that have been available for a very long time. Multiple results
>from FIND is a mistake that leads to complexity.

It's what the standard (ANS and 2012) specifies, so if you want to
write a standard program, you have to deal with that.

By contrast, if you store NTs in atable, you can get to the
interpertation semantics with NAME>INTERPRET and to the compilation
semantics with NAME>COMPILE; you need to store only one cell.

create atable \ -- addr
s" foo" find-name ,
s" bar" find-name ,

And to be able to do that, FIND-NAME would be convenient.

>The XT as a single
>point of contact promotes simplicity.

Looking at the "bad way", I can't say I agree.  As for the "simple
way", it does not work in a standard program in general (i.e., when
words with non-default compilation semantics are involved).

I am not a fan of FIND, either, but as long as we have words with
funky combinations of interpretation and compilation semantics, the
idea that the xt can do it all is, as the saying goes, "clear, simple,
and wrong".  That's why I use FIND-NAME and want to see it
standardized.  It allows us to use a solution that leads to simple
code, no need to deal with the FIND mess.  It may not be as simple as
having only an xt, but correctness has it's price.

The other alternative is to destandardize S" (and throw in TO, IS,
ACTION-OF, and STATE for good measure), make all the words with
undefined interpretation semantics either immediate (most of them) or
normal words (stuff like COMPILE,).  Then we only have normal (default
compilation semantics) and immediate words, FIND returns the same xt
independent of STATE, and we can make ATABLE as follows:

create atable \ -- addr
'imm foo , ,
'imm bar , ,

where 'imm produces the results of FIND, i.e., an xt and 1 or -1.
Even that is not really simple, but at least there is just a single xt
per word now.  But my impression is that too many Forthers are too
much in love with "smart" words like S", and this approach is not
viable.

- 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 2017: http://www.euroforth.org/ef17/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:47 +0100
  Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:57 +0100
    Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-29 13:18 -0700
      Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 22:47 +0100
      Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:43 +0000
    Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:30 +0000
    Re: Another recognizer discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-30 09:53 +0200
    Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-30 22:02 +0100
      Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-31 01:27 -0700
        Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:12 +0100
      Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 03:43 -0700
        Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:03 +0100
        Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 16:46 +0000
      Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 11:28 +0000
        Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 12:17 +0000
        Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:10 +0100
          Re: Another recognizer discussion mhx@iae.nl - 2017-05-31 11:01 -0700
          Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-05-31 22:55 +0000
            Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 05:50 +0000
              Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 23:57 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 09:08 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-01 03:33 -0700
              Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-01 09:05 +0000
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 15:05 +0100
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 10:05 -0500
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 16:32 +0100
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-01 09:31 -0700
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 19:00 +0100
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 22:56 +0000
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-05 14:41 +0100
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:07 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 16:28 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-11 02:14 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-11 10:55 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-12 03:22 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:21 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-14 04:10 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 10:43 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-15 09:11 -0500
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 02:55 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-14 10:19 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 05:44 -0700
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 14:27 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 08:06 -0700
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 16:36 +0000
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 09:48 -0700
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 17:18 +0000
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 18:50 +0100
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 19:22 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-15 13:09 -0700
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:43 -0700
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-15 22:55 +0200
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 22:20 +0100
                pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 17:04 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 21:58 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 00:26 -0700
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) minforth@arcor.de - 2017-06-17 01:18 -0700
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 15:24 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 12:29 -0700
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:29 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-18 16:47 +0200
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 10:20 +0000
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:01 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:55 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 17:40 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:47 +0000
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 10:34 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 17:35 +0000
                Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-06-17 15:24 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:00 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 12:29 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 07:35 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 10:39 +0000
                Re: Another recognizer discussion Richard Owlett <rowlett@cloud85.net> - 2017-06-11 07:19 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 14:04 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 12:50 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 16:19 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 07:59 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 11:48 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 10:24 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 13:04 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 13:30 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 16:36 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 15:51 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 21:09 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 15:55 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 14:21 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 23:07 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 15:49 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 11:14 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-11 08:24 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:07 +0000
            Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 12:11 +0100
  Re: Another recognizer discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-30 11:03 -0700

csiph-web