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

Groups > comp.lang.forth > #60145

Re: Another recognizer discussion

Show all headers | View raw

On 6/1/2017 10:05, Stephen Pelc wrote:
> 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 ). From ANS onwards,
> these words were retired. I still see very little need to expose
> them again.

This isn't a proposal to do that, and I've not suggested it. I suspect 
this may be a peptic response to the original NAME>xxx words where I 
suspect you think they were snuck in under the radar (or at least, I got 
that feeling from the discussion at the time).

Proposed is an analog to SEARCH-WORDLIST that returns the NT; and the 
number of Forth systems that seem to have NTs and a word that searches 
and returns an NT is quite significant.

> 
>>> 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. I'm not trying to
> disenfranchise a system at all, I'm trying to retain the original
> ANS meaning of an XT.

The original meaning would imply that you can't do anything with it 
other than store, fetch, execute and compile. You certainly can't get 
its name or work out whether it's immediate or completely bent out of 
shape like S".

In WF32, I prefix the XT address with a pointer to the NT (actually, 
it's encoded as a 5 byte JMP to stop the disassembler from barfing or 
getting out of sync). That also means having a dummy entry to support 
:NONAME and quotations for orthogonality. It also means that code 
fragments that don't start at XT boundaries can't be processed by some 
tools, especially an optimizer, since there's no way to tell if an 
address has an NT or not. And they need the NT, as they have the 
semantic information to help the optimizer.

I'd say; a Heath Robinson collection of XT pieces to allow for quality 
tools.


> 
>>> 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. 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.e. not fixed?

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

Actually, an NT is just like an XT. There is absolutely nothing stopping 
a system having all NTs as XTs and using

: execute name>interpret xt-execute ;
: compile, name>compile xt-compile, ;

Where it falls down is the lack of support with SEARCH-WORDLIST and FIND 
to return an XT, when an NT analog SEARCH-NAME and FIND-NAME are required.

> 
>> 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. See DEFER and IS >
>> |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.
> 
> 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 ,
>    ...
> 

Not a problem with NTs. Just make a table of them.

> 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. The XT as a single
> point of contact promotes simplicity.

FIND is dead. An XT is too simple.


-- 
Alex

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