Improving "readability" of stack 
Author Message
 Improving "readability" of stack

 Good point!
   Even with such definitions of ROLL and -ROLL (<ROLL) the stack can
become most bothersome, such that we find we must pull our values
into temporary copies much like C itself does. I consider this
waste. But, lacking a firm grasp of the many functions that may call
this word or that word, I know how it can get out-of-hand.
   Perhaps, just perhaps, some energetic person out there will write
us a definition that will sort out things at compile time (hell, C
does it y'know!) and make our little boo-boo's a reason to scream to
high heaven! Maybe somthing that checks stack diagrams??? I dunno...
just thinking off the top of the head... or seat'o'the pants....
whatever...

--
via Fortress Gateway at uumind.mind.ORG



Sat, 21 Oct 1995 16:53:00 GMT  
 Improving "readability" of stack

Quote:

> Good point!
>   Even with such definitions of ROLL and -ROLL (<ROLL) the stack can
>become most bothersome, such that we find we must pull our values
>into temporary copies much like C itself does. I consider this
>waste. But, lacking a firm grasp of the many functions that may call
>this word or that word, I know how it can get out-of-hand.
>   Perhaps, just perhaps, some energetic person out there will write
>us a definition that will sort out things at compile time (hell, C
>does it y'know!) and make our little boo-boo's a reason to scream to
>high heaven! Maybe somthing that checks stack diagrams??? I dunno...
>just thinking off the top of the head... or seat'o'the pants....
>whatever...

I'll toot my horn one more time and then keep quiet.  As was posted three
months ago, I've already developed a system of stack-checking based on
methods described in the book _System Design from Provably Correct
Constructs_ by James Martin.  My Forth recognizes six basic constructs
which enforce the following i/o rules (pardon the use of infix for a
moment):

(case of parent_3 defined by child_1 and child_2)

       Construct:      Input/Output:

       seq             I3=I1     O3=O2     O1=I2                  
       par             I3=I1+I2  O3=O1+O2                        
       do/until        I3=I1     O3=O2     O1-1=I1  O1-1=I2      

(case of parent_4 defined by child_1 , child_2 , and child_3)

       if              I4=I1     O4=O3     O1-1=I2  O1-1=I3  O2=O4
       do/while        I4=I1     O4=O3     O1-1=I2  O1-1=I3  O2=I1
       3seq            I4=I1     O4=O3     O1=I2    O2=I3        

Three of these constructs define a deferred parent word by two deferred
child words, whereas the other three constructs define a parent word by
three child words.  If the stack pictures for the any of the words are
inconsistent with the above i/o rules for a given construct, the compiler
aborts with a message indicating where the declared stack pictures are
inconsistant.

To understand what follows, I need to describe two extra words not standard
in Forth:

       f  : means DEFER.  In fact, : f DEFER ; .
       (  : outside of colon definitions, means "compile the following
               stack picture into memory for later use by the compiler
               which does stack checking."

The parallel construct "par" is particularly useful for breaking complex
stack pictures into simpler patterns, as in this example:

f parent ( a b c x y z  -- e f g h u v w )  \ deferred here.
f child_1 ( a b c -- e f g h )
f child_2 ( x y z -- u v w )
par  parent  child_1 child_2
\ parent now defined in parallel by child_1 and child_2
\    according to the stack i/o rules for the "par" construct.

To make a program that actually does something, the children (or
grandchildren, or great(n)-grandchildren as the case often is) have to be
defined in either pure Forth or assembler.  These "leaf-node" words can
only be dynamically tested by the programmer to ensure their actual stack
i/o matches their declared stack pictures.  The compiler then guarantees
the correctness of stack i/o for the remainder of the program tree.



Mon, 23 Oct 1995 17:22:48 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Improving "readability" of stack

2. new, "improved" syntax

3. suggestion for "improving" prng implementation

4. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

5. "Stack Computers"

6. "Control Stack Full" error

7. "Floating point error: stack fault"

8. "Float Stack Check error"

9. TCL parameters on the "C" stack

10. Avoid stack trace on "error".

11. BEGIN{want[]={"s1o", "s2o", "s2q", "s3q"}

12. Parsing ""D""?

 

 
Powered by phpBB® Forum Software