State smartness (again) 
Author Message
 State smartness (again)

  Another question about state-smartness... After reading Anton's paper
(State-smartness -- Why is it Evil and How to Exorcice it) I came to the
conclusion that it is difficult to modify an existing system to avoid
problems due to state-smartness. So I decided to modify my Forth system
the way Guido suggested several posts ago:
- No interpretation mode: everything is compiled (like in Smalltalk
systems for example). When state is OFF, the code is not compiled into
the dictionary, but into a scratch token buffer.
- ] and [ words are slightly modified:
    - ] enters compilation state, then executes the code that was
previously compiled into the buffer mentioned above (it modifies STATE's
value but also HERE's value);
    - [ just changes the values stored into STATE and HERE.
 There are many admantages to this approach, like:
- The interpretation loop is simplified;
- One can use control structures (and other "compile-only" words) on the
command line.

 Does this approach violates ANS Forth specifications?

 Cheers,

 Sebastien.



Sat, 07 Feb 2004 21:43:23 GMT  
 State smartness (again)

Quote:

>  Does this approach violates ANS Forth specifications?

What happens here? (Not that it would violate ANS, just curious.)

: foo s" : bar  3e FSQRT f. ; " evaluate ;



Sat, 07 Feb 2004 22:29:19 GMT  
 State smartness (again)

Quote:
>  Another question about state-smartness... After reading Anton's paper
>(State-smartness -- Why is it Evil and How to Exorcice it) I came to the
>conclusion that it is difficult to modify an existing system to avoid
>problems due to state-smartness. So I decided to modify my Forth system
>the way Guido suggested several posts ago:
>- No interpretation mode: everything is compiled (like in Smalltalk
>systems for example). When state is OFF, the code is not compiled into
>the dictionary, but into a scratch token buffer.
>- ] and [ words are slightly modified:
>    - ] enters compilation state, then executes the code that was
>previously compiled into the buffer mentioned above (it modifies STATE's
>value but also HERE's value);
>    - [ just changes the values stored into STATE and HERE.
> There are many admantages to this approach, like:
>- The interpretation loop is simplified;
>- One can use control structures (and other "compile-only" words) on the
>command line.

> Does this approach violates ANS Forth specifications?

> Cheers,

> Sebastien.

Funny I do it the other way around. My compiler does always
interpreter mode. My compiler doesn't has a state variable but if I
need to compile I extend the word with a ' symbol:

 5 DUP * . 25 ok
: ** DUP' *' .' ;
5 ** 25 ok
: test 5' **' ;
test 25 ok

My version sure violates ANS spec. but who cares?

If somebody wants to experiment with it here is a emulator for
win32Forth:

( 4Tron stateless compiler emulator )
( Only tested/working on Win32Forth4 )

DEFINED 4TRON-INTERPRET NIP [IF]
  CR .( 4Tron interpreter already loaded ) CR
[ELSE]
: 4TRON-INTERPRET
  BEGIN

    FIND IF
      EXECUTE ?STACK
    ELSE
      ( Does word end in ' )


        FIND IF
          COMPILE,
        ELSE
          NUMBER NUMBER,
        THEN
      ELSE
        NUMBER DROP
      THEN
    THEN
  REPEAT DROP ;

' 4TRON-INTERPRET IS INTERPRET

( Overrule ANS words, install one-color-forth versions )
: B,    C,' ;
: W,     ,' ;
: EXIT  R>' DROP' ;
: N,    LITERAL' ;

( Install 4Tron specific words, take note some may overrule existing
words in current Forth )
: Z               0' ;
: T              -1' ;
: BOOL  ( n -- f ; Convert value to boolean )
  IF T' ELSE Z' THEN ;
[THEN]

Greetz
Peter
pwsoft AT syntiac DOT com



Sat, 07 Feb 2004 23:15:05 GMT  
 State smartness (again)

Marcel Hendrix a crit :

Quote:

> >  Does this approach violates ANS Forth specifications?

> What happens here? (Not that it would violate ANS, just curious.)

> : foo s" : bar  3e FSQRT f. ; " evaluate ;

 What's (or what could be) the problem with this code?

 Regards,
 Sebastien



Sat, 07 Feb 2004 23:21:06 GMT  
 State smartness (again)


Quote:

> Funny I do it the other way around. My compiler does always
> interpreter mode. My compiler doesn't has a state variable but if I
> need to compile I extend the word with a ' symbol:

>  5 DUP * . 25 ok
> : ** DUP' *' .' ;
> 5 ** 25 ok
> : test 5' **' ;
> test 25 ok

 If I recall correctly, one of the first versions of the Forth language used
to work like yours (correct me if I'm wrong)?

Quote:

> My version sure violates ANS spec. but who cares?

 The problem concerning my implementation is that I *want* it to conform to
the Standard.

 Cheers,

 Sebastien



Sat, 07 Feb 2004 23:33:49 GMT  
 State smartness (again)

Quote:

> Marcel Hendrix a crit :

[..]
> > What happens here? (Not that it would violate ANS, just curious.)

> > : foo s" : bar  3e FSQRT f. ; " evaluate ;
>  What's (or what could be) the problem with this code?

This code nests the compiler in your system. Do you have more than one
scratch buffer? Nesting the interpreter is quite frequent when using
macros. With your system it translates to nested compilation. But
maybe I should give it more thought.

-marcel



Sat, 07 Feb 2004 23:59:26 GMT  
 State smartness (again)

Marcel Hendrix a crit :

Quote:

> > Marcel Hendrix a crit :

> [..]
> > > What happens here? (Not that it would violate ANS, just curious.)

> > > : foo s" : bar  3e FSQRT f. ; " evaluate ;

> >  What's (or what could be) the problem with this code?

> This code nests the compiler in your system. Do you have more than one
> scratch buffer? Nesting the interpreter is quite frequent when using
> macros. With your system it translates to nested compilation. But
> maybe I should give it more thought.

> -marcel

 No, it does not nest the compiler.
 The colon modifies STATE and HERE so that (in your example) foo is normally compiled into the
dictionary. No difference with conventional systems. When you type 'foo' in "STATE-OFF" mode,
the system compiles something like :NONAME FOO ; in a separate data space and EXECUTE it
immediately (execution occurs when enter is pressed or when ] is encountered). foo contains a
colon that compiles a new word into the dictionary. When the semicolon is encountered, STATE and
HERE are changed so that the system is in "STATE-OFF" mode when foo terminates. Have I missed
something?

 Cheers,

 Sebastien



Sun, 08 Feb 2004 00:24:44 GMT  
 State smartness (again)

Quote:

> [..]
> problems due to state-smartness. So I decided to modify my Forth system
> the way Guido suggested several posts ago:
> - No interpretation mode: everything is compiled (like in Smalltalk
> systems for example). When state is OFF, the code is not compiled into
> the dictionary, but into a scratch token buffer.
> [..]
>  Does this approach violates ANS Forth specifications?

Hopefully, I did mention some system that already does it - there are
quite some. Anyway, does this approach violate ANS Forth? The answer is,
yes, subtly. Have you tried the following snippet

HEX 29 EMIT DECIMAL

what does it print?

hex 33 emit decimal
 3
: xx hex 33 emit decimal ; xx
 !

cheers,
-- guido                            Edel sei der Mensch, hilfreich und gut



Sun, 08 Feb 2004 01:15:41 GMT  
 State smartness (again)
Quote:

> hex 33 emit decimal
>  3
> : xx hex 33 emit decimal ; xx
>  !

sorry for answering to myself - currently, the (interpret)-sequence
is about the same: next-word + lookup-token + handle-it, but now
you do it on a per-line basis while traditional forth will be on
a per-word basis. If there is some word that would modify the behaviour
of the tokenizer for the remaining words, you get into a difference.

However, this is otherwise correct - we are used to enter commands
in interactive mode one a line-by-line basis. However, I feel that
this is the way that it should have been anyway - the intent has been
that a user can put ":"/";" around the line that he/she just tried
interactivily, just for experimenting and debugging. After the
line has been memorized, it will do the exact same thing.

traditional forth has quite some instances where the interpret
mode would do something different than used to be known from
compiled mode, and this is just one case. I use state-smartness
to come over the problem, imitating the behaviour of the compiled
behaviour in interpret-mode - and I am okay with getting into
ambiguous conditions for `postpone` (as the ans forth standard
does often hint about).

Note also, that the advantages of using compiled-behaviour on
the commandline do not stretch beyond the end-of-line - most
prominently the string-literals. I imagined to re-defined the
behaviour of "\" as being a refill-interpret before executing
the scratch buffer - it allows you to extend the line-mode to
the following line(s). This is also the same for file-mode,
and it resembles strongly to the line-continues in shell-modes,
just added with the nice effect that the rest of the line
is not seen and it is still a comment.

cheers,
-- guido                            Edel sei der Mensch, hilfreich und gut



Sun, 08 Feb 2004 01:40:02 GMT  
 State smartness (again)
On Tue, 21 Aug 2001 17:33:49 +0200, =?iso-8859-1?Q?S=E9bastien?= Furic

Quote:


>> Funny I do it the other way around. My compiler does always
>> interpreter mode. My compiler doesn't has a state variable but if I
>> need to compile I extend the word with a ' symbol:

> If I recall correctly, one of the first versions of the Forth language used
>to work like yours (correct me if I'm wrong)?

The first forth I have a reference of has 2 compilers. One for 'ascii'
scripting and one compiling threaded tokens (1970?). It is possible
there is a earlier forth than that which does interpreter only. But
not known by me.

Mine does looks somewhat like machineForth. With two seperate
dictionaries for compiler words and normal words. But instead of
switching by state, I switch with extending the word with '.

Quote:
>> My version sure violates ANS spec. but who cares?

> The problem concerning my implementation is that I *want* it to conform to
>the Standard.

I've abandoned ANS-Forth completely because following it wouldn't
allow the following tricks:

," Some string" HERE : .SomeString LITERAL, COUNT TYPE ;

It almost looks ANS but unfortunatly the colon compiler can leave
items on the datastack. Which ; will cleanup (propably to support
locals). Plus the runtime action can leave as many items on the return
stack as required.

There are more resons though. But thats a different discussion...
(for those interested: unable to overload the standard interpreter,
using >IN and SOURCE in own code, unable to do portable tailrecursion
opt are some of them).

Peter



Sun, 08 Feb 2004 02:08:16 GMT  
 State smartness (again)


Quote:

> HEX 29 EMIT DECIMAL

> what does it print?

> hex 33 emit decimal
>  3
> : xx hex 33 emit decimal ; xx
>  !

HEX is not immediate, it's getting compiled into the word.
Numbers are translated _before_ being compiled.

------------------------------------------

: xx hex 33 emit decimal ;

GIVES

see xx

: xx
  hex 33 emit decimal ; ok

xx !  ok

------------------------------------------
BUT....

: xx [ hex ] 33 emit [ decimal ] ;
              OR
hex : xx 33 emit ; decimal
              OR
: [hex] hex ; immediate
: [decimal] decimal ; immediate
: xx [hex] 33 [decimal] emit ;

GIVES

see xx
: xx
  51 emit ; ok

xx 3 ok

------------------------------------------

Geoff



Sun, 08 Feb 2004 02:24:51 GMT  
 State smartness (again)


Quote:

> HEX is not immediate, it's getting compiled into the word.
> Numbers are translated _before_ being compiled.

<etc.>

Hmm...reply first, comprehension later, <sigh>

Geoff



Sun, 08 Feb 2004 02:30:20 GMT  
 State smartness (again)

Sbastien Furic a crit :

Quote:
>   Another question about state-smartness... After reading Anton's paper
> (State-smartness -- Why is it Evil and How to Exorcice it) I came to the
> conclusion that it is difficult to modify an existing system to avoid
> problems due to state-smartness. So I decided to modify my Forth system
> the way Guido suggested several posts ago:
> - No interpretation mode: everything is compiled (like in Smalltalk
> systems for example). When state is OFF, the code is not compiled into
> the dictionary, but into a scratch token buffer.
> - ] and [ words are slightly modified:
>     - ] enters compilation state, then executes the code that was
> previously compiled into the buffer mentioned above (it modifies STATE's
> value but also HERE's value);
>     - [ just changes the values stored into STATE and HERE.
>  There are many admantages to this approach, like:
> - The interpretation loop is simplified;
> - One can use control structures (and other "compile-only" words) on the
> command line.

>  Does this approach violates ANS Forth specifications?

>  Cheers,

>  Sebastien.

 I think I forgot to take account of the evil of global variables like BASE
and the special case of parsing words like CREATE (when beeing compiled).
After one night of reflexion I didn't find any satisfactory solution to
these problems...

 Thank you anyway,

 Sebastien



Sun, 08 Feb 2004 16:16:22 GMT  
 State smartness (again)

Quote:

>   Another question about state-smartness... After reading Anton's paper
> (State-smartness -- Why is it Evil and How to Exorcice it) I came to the
> conclusion that it is difficult to modify an existing system to avoid
> problems due to state-smartness.

I don't understand why you should think so.  Separating the compiler
loop and the interpreter loop solves the problems that Anton describes
and is simple to do.  It sounds like what you're trying is much harder.

Andrew.



Sun, 08 Feb 2004 16:51:13 GMT  
 State smartness (again)

Quote:

>  I think I forgot to take account of the evil of global variables like BASE
> and the special case of parsing words like CREATE (when beeing compiled).
> After one night of reflexion I didn't find any satisfactory solution to
> these problems...

>  Thank you anyway,

It is inherent to the forth language - the interpretation of forth sources
affect the further interpretation for the rest of the forth sources. You
have the *freedom* to create a whole new syntax on top of the inner forth
engine. And well, the "ambiguation" into interpreted-mode and compiled-mode
is a natural thing here that will create problems one way around or the
other way back. For everything that does not restrict itself to just doing
stack operations you have a good chance to create "side-effect"s when
switching between modes.

Actually, a forth programmer may try to make life a bit simpler - one thing
is the fact to just use one word that is supposed to run in both interpreted-
mode and compiling-mode - see `create`. Some words will differ in their "visible"
behaviour then - so one might need to memorize the two visible effects. So
in other places one will split up the word into different interpreted-
and compiled- executions. The traditional way to achieve this, well,
that's state-smartness. But Anton shows that state-smartness has problems
when propagates into areas that the depenendency on a state-variable is
just no good, and that splitting it up into two routines is possible
even w.r.t. to ansforth compatibility. Personally, I do not care - I just
add a marker that the word is dependent on `state`, and all words that use
it do get the dependency too.

The other thing is a bit more of a philosophical hint going'round in my
mind: what if we had moved up and defined that all words that parse ahead
or that affect the outer interpreter - that these *must* be immediate so
they show the same effect in compiled- and interpreted mode. Just consider
your case about `create` and `hex`, and imagine two words `[create]` and
`[hex]` that have the outer-effect inside of colon-definitions (disregarding
the question what that might be good for anyway). These words can be
`postpone`d just as well, and after all, the line-mode interpretation
would offer real profitibility where it does now have some unwanted
side-effects on traditional-forth sources. It goes again up into the
area where try-and-error on the command-line can be quickly memorized
with a pair of ":"/";" and whereas *today* you have to watch out for
words that will *change* its visible behaviour in that other mode, (and
that may be called mode-dependent - another word for the fact that
`(interpret)` is a state-smart word, isn't it ;-) ).

-- guido                            Edel sei der Mensch, hilfreich und gut



Sun, 08 Feb 2004 18:24:39 GMT  
 
 [ 30 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Getting rid of STATE-Smartness

2. Scheme vs ML again and again and again and again

3. Scheme vs ML again and again and again and again

4. Compiler smartness?

5. Checking the state of a tri-state input signal in a Verilog testbench

6. Help with large state machine design (62 states)

7. State Machine - State Definition Question

8. Return to Known State From Unused States

9. finite state machines, state cad

10. State of Parrot -- was: Re: State of Python

11. APL and J (again and again) (long)

12. APL and J (again and again)

 

 
Powered by phpBB® Forum Software