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

Groups > comp.lang.forth > #54243

Re: Recognizers

Show all headers | View raw

Alex <alex@rivadpm.com> writes:
>Some recognizer observations.
>
>1. Using -2 STATE ! for POSTPONE actions is very useful as it provides a 
>simple index on (0 -1 and -2) NEGATE CELLS into the appropriate 
>RECOGNIZER: table. It remains ANS compliant:
>
>STATE is true when in compilation state, false otherwise. The true value 
>in STATE is non-zero, but is otherwise implementation-defined.

To me that means that both -2 and any other non-zero value just means
compilation state.  Postpone state is outside of the realm of existing
standards.

The important thing here is that a program can contain

state @ if comp-state-stuff else int-state-stuff then

and that program should work as expected in a standard system.

OTOH, such programs probably are not fit for postpone state anyway,
and even if the standard would say that only -1 means compile state,
and the program was written as

state @ case
  0 of int-state-stuff endof
  1 of comp-state-stuff endof
  true abort" unknown STATE"
endcase

(which is the best one could hope for) that would buy very little.

Bottom line: The problem is not the state value itself (it would be if
the following were not also the case), but that Forth-94/2012 excludes
any states except for interpretation and compilation.

What can we do?

1) Forget about postpone state.

   a) Forget about it completely.  Not very satisfactory.  See below
   why we want something in this direction.

   b) Implement ]] ... [[ to have its own loop instead of the text
   interpreter loop, like ] had in PolyForth.  That's somewhat against
   the grain of Forth-94/2012, which explicitly standardized the
   common interpreter loop.  But in any case, that's what is done in
   <http://www.complang.tuwien.ac.at/forth/compat/macros.fs>.

2) Actually have STATE=-2 (or some other special value) mean "postpone
state".  Existing words that use STATE would probably not work as
intended in postpone state, so users should avoid using such words in
postpone state, but they probably also won't work as intended in a
1b-style implementation.

Overall, whether you go with 1b or 2, there are some existing pieces
of code that won't work as intended in postpone state, so programmers
will have to be careful.  But a lot of code will work in the
cut-and-paste way described below, which is much better than if we did
not have ]]...[[ at all or if recognizers did not support it.

>2. There's an unintended consequence with numbers (in fact, any 
>non-FINDable words can be treated this way).
>
>: plit postpone literal ;
>
>   ' d>s
>   :noname d>s plit ;
>   :noname d>s plit postpone plit ;
>recognizer: r:number ( n 0 -- )
>
>: postpone  ( -<name>- )
>   -2 state dup @ >r !
>   parse-name recognize execute
>   r> state ! ; immmediate
>
>This allows POSTPONE 10 even though 10 isn't a "proper" word and can't 
>be ticked or found in the usual wordlist searches. I've not yet 
>considered a use for it.

That's an intended consequence, and the main reason for having support
for a postpone action in recognizers.  The first consequence is that,
with an appropriately written POSTPONE, you can write

POSTPONE 10

where a Forth-94/2012 programmer would write

10 POSTPONE literal

Furthermore, if you implement ]] ... [[ for defining macros, you can
now really cut and paste code between inside ]] ... [[, ordinary
compiled code, and interpreted code: E.g., you can write stuff like

]] dup 42 = [[

instead of

]] dup [[ 42 ]] literal = [[

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

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

Thread

Recognizers Alex <alex@rivadpm.com> - 2017-01-22 01:42 -0500
  Re: Recognizers Matthias Trute <matthias.trute@gmail.com> - 2017-01-22 03:06 -0800
  Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-22 14:42 +0000
    Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-22 17:26 -0500
    Re: Recognizers Bernd Paysan <bernd@net2o.de> - 2017-01-24 00:57 +0000
      Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-24 16:23 +0000
        Re: Recognizers Bernd Paysan <bernd@net2o.de> - 2017-01-24 21:47 +0000
  Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 08:30 -0500
    Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 08:57 -0500
    Re: Recognizers Matthias Trute <matthias.trute@gmail.com> - 2017-01-23 10:58 -0800
      Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 14:45 -0500
      Re: Recognizers JennyB <jennybrien@googlemail.com> - 2017-01-27 15:05 -0800
    Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-29 22:54 +0000
      Re: Recognizers JennyB <jennybrien@googlemail.com> - 2017-01-30 09:11 -0800
      Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-30 16:34 +0000
  Re: Recognizers Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-31 21:03 +0000
    Re: Recognizers albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-01 12:37 +0100

csiph-web