Extending the interpreter?

[lehs]

I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

[Anton Ertl]

lehs <skydda...@gmail.com> writes:
>I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

Not sure if that is what you have in mind, but there has been a
discussion on recognizers for some time. Recognizers are a
generalization of what the text interpreter does for "words": Instead
of just recognizing strings as names from the search order or as
numbers, they can also recgnize other things. E.g., you could have a
recognizer for strings ("bla"), or for date specifications
(2016-02-08). Some expect recognizers to be standardized in the
not-too-distant future.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

[lehs]

Could such a recognizer be set to recognize i.e.

{1,2,{3,4},5} and
123+27i

as userdefined strucured data?

http://forthmath.blogspot.se

[Anton Ertl]

lehs <skydda...@gmail.com> writes:
>Could such a recognizer be set to recognize i.e.=20

>
>{1,2,{3,4},5} and
>123+27i
>
>as userdefined strucured data?

Yes. However, you typically also need some way to build structures
where not all components are literals. If you have that, do you still
need the literal-only recognizer? Of course, you might also consider
supporting, say, {a,{1,b},2}, where a and b are locals, and that would
be possible, too, but where do you stop? I guess we will see a period
of overuse while people explore that feature (and, of course, other
people claiming that recognizers are devil's work), until we get a
good feel for where it is appropriate and where not.

[lehs]

As it is now, the interpreter can recognize integers, double integers and floating point numbers, and that is all except from the wordlist. It wouldn't be a bad thing if the user could extend the number of recognizable data types written for input of data.

Of course, the user must define the pattern as well as the words handling the data recognized by the pattern. And I would stop with certain patterns of numbers and a set of signs (i.e. "()[]{}./-+iE").

It couldn't be too difficult to design an efficient extendable interpreter. I would even consider to make a patch if I just know where the interpreter was hidden. :)

http://forthmath.blogspot.se

[Anton Ertl]

lehs <skydda...@gmail.com> writes:
>As it is now, the interpreter can recognize integers, double integers and f=
>loating point numbers, and that is all except from the wordlist. It wouldn'=
>t be a bad thing if the user could extend the number of recognizable data t=
>ypes written for input of data.=20

Yes, that's the idea.

>Of course, the user must define the pattern as well as the words handling t=

>he data recognized by the pattern.

Yes.

[Albert van der Horst]

lehs <skydda...@gmail.com> writes:

>Den tisdag 9 februari 2016 kl. 07:53:56 UTC+1 skrev Anton Ertl:
>> lehs <skydda...@gmail.com> writes:

>> >Could such a recognizer be set to recognize i.e.=3D20

>> >
>> >{1,2,{3,4},5} and
>> >123+27i
>> >
>> >as userdefined strucured data?

>>=20

>> Yes. However, you typically also need some way to build structures
>> where not all components are literals. If you have that, do you still
>> need the literal-only recognizer? Of course, you might also consider
>> supporting, say, {a,{1,b},2}, where a and b are locals, and that would
>> be possible, too, but where do you stop? I guess we will see a period
>> of overuse while people explore that feature (and, of course, other
>> people claiming that recognizers are devil's work), until we get a
>> good feel for where it is appropriate and where not.

>>=20
>> - anton
>> --=20

>> 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 2015: http://www.rigwit.co.uk/EuroForth2015/

>As it is now, the interpreter can recognize integers, double integers and f=
>loating point numbers, and that is all except from the wordlist. It wouldn'=
>t be a bad thing if the user could extend the number of recognizable data t=
>ypes written for input of data.=20

>Of course, the user must define the pattern as well as the words handling t=
>he data recognized by the pattern. And I would stop with certain patterns o=

>f numbers and a set of signs (i.e. "()[]{}./-+iE").

>It couldn't be too difficult to design an efficient extendable interpreter.=
> I would even consider to make a patch if I just know where the interpreter=

> was hidden. :)

>http://forthmath.blogspot.se

My basic idea with recognizers has always been
1. it must be a prefix:
only the first part of a word determines what kind recognizer is
used:
a decimal digit, or one of : & $ 0x "
2. The result must be a compile time constant.
STATE determines whether it is compiled or put on the stack.

If it starts with a digit, it may discriminate between sort of numbers
(single or double precision).

Long ago I demonstrated that this can be made available by adding
two lines to a Forth.

What is easy to parse for a computer is easy to parse for a human.
Expressions with three slots like (in c)
.. ? ... : ...
are cursed for unreadibility. (Though I think this ?: is not --yet-- over
the top.)
If a programmer can add multiple slot expressions at a whim you
end up with a very unreadable language. I'm good with r.e. but
apparently few people are.

I'm not against but e.g. an expression for complex expressions can be
done with an operator not with a tangle containing i.
Algol 68
<complex> := <real> <bold>i</bold> <real>

I've now 15 years experience with implementing numbers via
prefixes. I've explored other possibilities for strings and
environment variables. I've not experienced a need for making
things more complicated.

Yes of course. One could make a recognizer for 1235H Intel suffix
strings, while there is $ that is more Forthish and trivial to
implemented. We need the power to recognize hex numbers, not
the power to emulate not-well-thought-out expressions of other
languages.

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Chris Curl]

On Monday, February 8, 2016 at 12:06:37 PM UTC-5, lehs wrote:
> I would like the possibility of "extending the interpreter",
> letting it recognize new data structures. Could this be done?

I'm having a hard time understanding your question.

Is there anything keeping you from being able to completely re-write
the interpreter if you want to behave however you want it to behave?

[Chris Curl]

So if you want an interpreter that does more than the current one does,
why not write your own? Then you have complete control over what it
does and how it does it.

[minf...@arcor.de]

Am Montag, 8. Februar 2016 18:06:37 UTC+1 schrieb lehs:
> I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

Recognisers have been discussed....

Are you aware of data structures extensions eg. in the Forth200x Standard discussion? (but there are others too)

[Doug Hoffman]

The idea is to be able to portably move a recognizer from one Forth to
another. The hook(s) for doing so will be the same. Much simpler than
digging into each Forth's interpreter even if that were allowed.

-Doug

[lehs]

Prefixes would be fast but a somewhat more freely method could be made almost as fast, I think. Writing

"Hello world!"

is perfect with prefix and would hopefully put the string on a string stack. But I think that an easy pattern recognization

[lehs]

To change the interpreter I have to find it and understand it.

[lehs]

Ignorance? But I would love to have my own interpreter.

Also, the idea of an extendable interpreter is interesting as such.

[lehs]

Extending the interpreter need:

1. the pattern for recognizing the input data
2. the word that compute the numerical representation and store it someheow
3. the word that reset stacks and variables on error
4. the words that handle the data

In my set environment ZET I have to write

{ 1 2 3 } { 0 1 } cartprod zet. {(3,1),(3,0),(2,1),(2,0),(1,1),(1,0)} ok

instead of

{1,2,3} {0,1} cartprod zet. {(3,1),(3,0),(2,1),(2,0),(1,1),(1,0)} ok

and I have to reserve { and } for set inputs. It's okay, but not perfect. Here the pattern would be {*} or just {. In my implementation the words does what the interpreter should do, put "bundles" on a stack called zst:

1 2 3 -6 0 1 -4 <cartprod zet.> 3 1 -5 3 0 -5 2 1 -5 2 0 -5 1 1 -5 1 0 -5 -36

and check for duplicate elements in all levels. On error some stacks (xst, yst, zst) and some variables must be reset. Can error handling be extended in ANS Forth today?

The words that handles sets are words like: set=, member, subset, union, intersection, diff, powerset, cartprod etc.

With such an interpreter Forth would be too good: I might get so excited that I would be paralyzed...

http://forthmath.blogspot.se

[hughag...@gmail.com]

On Tuesday, February 9, 2016 at 6:23:18 AM UTC-7, Chris Curl wrote:
> So if you want an interpreter that does more than the current one does,
> why not write your own? Then you have complete control over what it
> does and how it does it.

ANS-Forth was purposely sabotaged to prevent the users from writing their own outer-interpreter --- this was done for the purpose of preventing the users from writing cross-compilers (the compiler vendors make their money primarily from cross-compilers and they want a monopoly; they want to prevent people such as myself from writing cross-compilers such as MFX which I wrote in UR/Forth prior to the introduction of ANS-Forth).

Section 4.1.2 of the ANS-Forth document has the ominous heading: "Ambiguous Conditions." One of the ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." There are over 50 words in the ANS-Standard that have undefined interpretation semantics, so tick and FIND will fail on all of them --- this was done to make writing an outer-interpreter in ANS-Forth impossible --- but my disambiguifiers work around this sabotage so that tick and FIND work they way that they did in Forth-83 on all ANS-Forth implementations.

[lehs]

Is it possible to read about those disambiguifiers?

[hughag...@gmail.com]

They were discussed here:
https://groups.google.com/forum/#!searchin/comp.lang.forth/bug$20vfx/comp.lang.forth/oXXQAGDKP7w/iMLU1ExXOAIJ

Tick and FIND were sabotaged with section 4.1.2. that make their behavior ambiguous (gForth crashes when tick is used on IF etc. and FIND returns different xt values depending upon what STATE is when FIND is executed, which is horribly confusing). Also, whether a word is immediate or non-immediate is implementation-defined (another term that essentially means "ambiguous"), so words such as IF that were always immediate can now be non-immediate (VFX and some others make these non-immediate and special-case them in COMPILE, so they execute like immediate words rather than just get compiled by COMPILE, which is typical for non-immediate words).

The solution is simple though! Tick and FIND are hopelessly sabotaged, but POSTPONE was not sabotaged. So, this is a disambiguifier:

: if
state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ;
immediate

We get these advantages:

1.) Previously tick and FIND would have ambiguous behavior when trying to look up IF but now they always provide an xt value that works (and it is always the same xt value, despite Anton saying that it should sometimes be one xt value and sometimes another xt value depending upon STATE).

2.) Previously IF could be immediate in some ANS-Forth systems and non-immediate in other ANS-Forth systems, but now IF is always immediate.

3.) Previously the behavior of IF in interpretation-mode (when STATE is FALSE) was "undefined" (yet another word that essentially means "ambiguous") so what actually happened would vary from one ANS-Forth system to another, but now IF will always abort with a helpful error-message when used in interpretation-mode (as it should, as this is obviously a screw-up on the programmer's part).

So, with the above disambiguifier, we dodge all of the weird ambiguity of ANS-Forth and we are back on the solid ground of Forth-83 --- Elizabeth Rather defeated!

There are over 50 words in ANS-Forth that need to be disambiguified. Just look for the phrase "Interpretation semantics for this word are undefined" in the ANS-Forth document and write a disambiguifier for all of them. There are some caveats:

1.) SwiftForth doesn't have [COMPILE] (so SwiftForth isn't really ANS-Forth compliant), so if you try to disambiguify [COMPILE] this will cause SwiftForth to abort and so your code won't be portable. Nobody really uses [COMPILE] (I have no idea why it is in the ANS-Forth document as it is obsoleted by POSTPONE) so you might was well just not bother with this one.

2.) TO theoretically can't be disambiguified because section 6.2.2295 of the ANS-Forth document says: "An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO." In VFX however, TO can be disambiguified, so if you need this one to work you have to use VFX rather than some other ANS-Forth system (but you do have to disambiguify it yourself, as VFX doesn't disambiguify anything).

I have written all of these disambiguifiers. The code, as well as a text file documenting the disambiguifiers, will be in my next novice package release. I'm holding off on that right now because the www.forth.org website is down (what you see is the August version, but the web-master David Jaffe is not able to modify it and the only person who knows how to modify it is recovering from a stroke and may never get back to work on the website). So, I'm going to have to post my novice package and STUNDURD.TXT etc. somewhere else on the internet --- in the meantime, if you want this stuff, contact me by email and I will email it to you.

I have been aware of how to disambiguify for almost a whole year now. Weirdly enough, Anton Ertl actually told me how to disambiguify ANS-Forth way back in 2009 in this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ
I didn't at the time follow through with this and write all of the disambiguifiers, and it took me until last year to realize that this was necessary in order to write an outer-interpreter (the issue didn't come up until last year when I had a job writing a cross-compiler and ran into the sabotage problem and had to figure out a work-around). So, disambiguification has been well-known for many years now --- and yet people such as Stephen Pelc and Anton Ertl continue to refuse to just provide the disambiguifiers in their compilers (VFX and gForth respectively) --- the reason is that they are obliged to support Elizabeth Rather (or she will kick them off the Forth-200x committee) and so they pretend that ANS-Forth can't be disambiguified.

Stephen Pelc makes his money by selling cross-compilers --- he wants to do everything he can to prevent common Forth programmers such as you or I from writing our own cross-compiler in ANS-Forth --- I think that my MFX (I wrote it in 1994) scared the ANS-Forth committee because they realized that Forth-83 was powerful enough to allow unauthorized Forthers to write their own cross-compiler (Elizabeth Rather made a sales pitch at Testra for Forth Inc. to write the cross-compiler for the MiniForth, but was turned down because her price was "exorbitant," and Testra hired me instead). To prevent Forth Inc. from losing any more sales on cross-compilers, the ANS-Forth committee sabotaged ANS-Forth to make this impossible (but now I have found a work-around that dodges their sabotage and allows the unauthorized Forthers to write their own cross-compiler).

The disambiguifiers are all about empowering the common Forthers and defeating the corporate honchos who want to chain our ankles to a boat-anchor and call that Standard (with a capital 'S').

[hughag...@gmail.com]

On Tuesday, February 9, 2016 at 3:52:33 PM UTC-7, hughag...@gmail.com wrote:
> I have written all of these disambiguifiers. ...

> if you want this stuff, contact me by email and I will email it to you.

Actually, I'll just post the disambiguifiers here:

: +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate
: ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate
: ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate
: >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate
: abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate
: begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate
: do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate
: does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate
: else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate
: exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate
: I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate

: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate

: J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate
: leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate
: literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate
: loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate
: postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate
: r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate
: r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate
: recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate
: repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate
: s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate
: then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate
: unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate
: until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate
: while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate
: [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate
: ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate
: [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate
: 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate
: 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate
: 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate
: ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate
: again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate
: c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate
: case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate
: compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate
: endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate
: endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate
: of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate
char & comment
: [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate
&
: 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate
: abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate
: fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate
: (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate
: locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate
: ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate
: ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate
: cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate
: cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate
: sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate

VFX? [if]
: to postpone to ; immediate
[then]

[lehs]

Den måndag 8 februari 2016 kl. 18:06:37 UTC+1 skrev lehs:
> I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

Using 'see' with trial and error I'd made this

: extended_interpret \ --
space ." Ok" cr
begin clear-tibstack
tib max#tib @ accept #tib ! input-start-line tib c@
case
[char] + of endof
[char] { of endof
[char] ( of endof
dup of interpret endof
endcase space ." Ok" cr
again ;

that accepts anything starting with '+', '{' or '(' without error messages. Between of and endof there should be a word for handling those inputs.

I don't know the exact consequences of the routine, but when started it works like quit(?) and keep working until an error.

[lehs]

I forgot to mention that this is GForth. It works in Windows and Android.

[lehs]

Den måndag 8 februari 2016 kl. 18:06:37 UTC+1 skrev lehs:

> I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

A cleaner variant that works for GForth Win, GForth Android and SP-Forth Win..

: bladd \ ad1 -- ad2
begin dup c@ bl =
while 1+
repeat ;

: .ok space ." OK" cr ;

: xinterpreter .ok
begin 0 >in !
tib 80 accept #tib !
tib bladd c@
case
[char] + of ." +" endof
[char] { of ." {" endof
[char] ( of ." (" endof
dup of interpret endof
endcase .ok
again ;

But there is some problems left.

Leave xinterpreter with 'abort'.

[Anton Ertl]

lehs <skydda...@gmail.com> writes:
>Den l=F6rdag 13 februari 2016 kl. 23:55:23 UTC+1 skrev lehs:
>> Den m=E5ndag 8 februari 2016 kl. 18:06:37 UTC+1 skrev lehs:
>> > I would like the possibility of "extending the interpreter", letting it=

> recognize new data structures. Could this be done?

>>=20
>> Using 'see' with trial and error I'd made this=20
>>=20
>> : extended_interpret \ --=20
>> space ." Ok" cr=20

>> begin clear-tibstack
>> tib max#tib @ accept #tib ! input-start-line tib c@
>> case
>> [char] + of endof
>> [char] { of endof
>> [char] ( of endof
>> dup of interpret endof

>> endcase space ." Ok" cr=20
>> again ;=20
>>=20
>> that accepts anything starting with '+', '{' or '(' without error message=

>s. Between of and endof there should be a word for handling those inputs.

>>=20
>> I don't know the exact consequences of the routine, but when started it w=

>orks like quit(?) and keep working until an error.
>
>I forgot to mention that this is GForth. It works in Windows and Android.

For some value of "works". E.g., it does not use REFILL, but ACCEPT,
and therefore only works on the command line. Also, the + { ( must be
at the start of the line (preceding spaces allowed with your BLADD
extension), but not after another word; is this intended?

If you want to work at the word level, defining a recognizer is the
way to go. Get a development version of Gforth and look for r:fail to
see examples of recognizers. This is a work in progress, so it may
change, but it's probably still more sensible to work with that than
to try to replicate the text interpreter, badly. Even if you have to
do it again if we change the recognizer interface, it will be less
work and provide better function.

- anton
--

[Albert van der Horst]

You may want a very simple Forth, if you are experimenting with
that kind of thing. You could use "yourforth" with is at the same
time simple and accomodates prefixes.

: { <do you thing> ; PREFIX
: + <do you thing> ; PREFIX
etc.
Note that the latter word would hide +! if you're not careful
with the search order. (Best have these in a separate wordlist
at the end of the search order. )
With lehs approach one has the same problem, e.g. +! at the
start of a line.

>- anton

[humptydumpty]

On Monday, February 8, 2016 at 7:06:37 PM UTC+2, lehs wrote:
> I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

Hi!

For inspiration, 24game I wrote some time ago:

\ 24 Game, using Gforth.
\ The goal of the game is find a way to obtain number 24
\ from a randomly chosen four numbers
\ using only * / + - arithmetic operations.
\
\ It use post-fix operators, ex: 4 9 + to obtain 13
\ As game run once, it starts with EMPTY stacks.
\

include random.fs

FVARIABLE Top
VARIABLE Found

: end-game? ( -- )
FDEPTH 1 =
IF
." You "
24E0 F= IF ." WIN!" ELSE ." loose." THEN
CR BYE
THEN
;
: (fextract)
FDEPTH 0= IF EXIT THEN
FDUP Top F@ F=
IF
Found ON FDROP EXIT
ELSE
F>D RECURSE
THEN
D>F
;
: fextract ( F: r0..ri-1 x ri+1..rn x -- r0..ri-1 ri+1..rn;S: -- x>D | TERMINATE PROGRAM )
Found OFF Top F!
(fextract) Found @
IF
Top F@ F>D
ELSE
." Do not cheat! :)" CR BYE
THEN
;

WORDLIST CONSTANT SECURE-WORDLIST
GET-CURRENT SECURE-WORDLIST SET-CURRENT
: + 2SWAP D>F D>F f+ ;
: - 2SWAP D>F D>F f- ;
: * 2SWAP D>F D>F f* ;
: / 2SWAP D>F D>F f/ ;
SET-CURRENT

: word-interpret ( .. ca u -- ... )
2DUP SECURE-WORDLIST SEARCH-WORDLIST
IF
NIP NIP CATCH THROW end-game?
ELSE
>FLOAT IF fextract THEN
THEN
;
: secure-interpret ( -- )
BEGIN
parse-name DUP
WHILE
word-interpret
REPEAT 2DROP
;
: run ( -- )
BEGIN
REFILL
WHILE
secure-interpret
REPEAT
;

." Make 24 using only + - * / from this numbers"
:noname 8 4 7 8 TIME&DATE + + + + +
0 DO 3 ROLL DROP 9 RANDOM 1+ LOOP ; EXECUTE .S CR
:noname 4 0 DO S>D D>F LOOP ; EXECUTE
STDIN ' run EXECUTE-PARSING-FILE CR BYE

[lehs]

The prefix approach was just a demonstration. It has to be a pattern search in my case and then, in case, a transformation of input stream to something that Forth recognize.

[lehs]

I will try to find the recognizers. Thanks!