conflict between CS-PICK and control structure checking 
Author Message
 conflict between CS-PICK and control structure checking

I received today Forth Dimensions XVIII No.4. I found Mr. Borasky's
article very readable and informative. He implemented Dijkstra guarded
command control structures in my hForth and ZEN Forth. He needed
CS-PICK and CS-ROLL so he defined them as:

    : CS-PICK   PICK ;
    : CS-ROLL   ROLL ;

in hForth and ZEN as both of them use data stack as control flow
stack. These definitions look innocent, however, CS-PICK is not. Mr.
Borasky had to use non-Standard word 'dest+' with CS-PICK as:

    : |DO|  ( C: orig1 dest -- dest )
       0 CS-PICK  POSTPONE AGAIN
       dest+
       1 CS-ROLL  POSTPONE THEN ;

to work around the hForth and ZEN compilers which check control
structure matching. 'dest+' should not be necessary if ANS Standard
CS-PICK is used. In other words the above definition is not a correct
implementation of CS-PICK. 'dest+' is for internal use of hForth and
Mr. Borasky defines it in ZEN as:

    : dest+   1 bal +! ;

In ZEN, CS-PICK can be correctly implemented as:

    : CS-PICK    PICK  1 bal +! ;

Then the definition of '|DO|' will be:

    : |DO|  ( C: orig1 dest -- dest )
       0 CS-PICK  POSTPONE AGAIN
       1 CS-ROLL  POSTPONE THEN ;

as it should be.

The problem is that it is not possible to provide CS-PICK in hForth.

hForth checks control structure mismatch rigorously for different
control flow stack items. Four 4-bit fields are used to check
balancing of orig, dest, do-sys and of-sys. A 2-bit field overlapped
on 4-bit field for of-sys is used for case-sys. Each field increases
when an item is put on control flow stack and decreases when it is
consumed. All of these fields should be zero before the definition is
added to the current wordlist. Otherwise ';' issues "-22 THROW
(control structure mismatch)".

I made hForth in this way since I was burned to find a double mistake
such as that of-sys is incorrectly consumed by UNTIL. Simple balace
checking used in ZEN cannot detect this kind of mismatches.

hForth need to know whether the control flow stack item to be copied
by CS-PICK is orig, dest, do-sys, of-sys, or case-sys. But it is not
possible with typeless control flow stack! And this kind of balance
checking is not necessary at all for a control flow stack of which
items are tagged, in which each word consuming control flow stack
item, instead of ';', can issue "-22 THROW" for a mismatch.

However, this is not a limitation in practice. As demonstrated by Mr.
Borasky, a user of CS-PICK always knows which one to copy and can
solve this problem by adding 'dest+' or 'orig+' accordingly.

My question to clf readers is this: Is is worth to give up rigorous
balance checking to provide CS-PICK? (I do not want to add type-aware
control flow stack to hForth. It will be too much work.) Is there any
way that ANS Standard allow implementors more flexibility in this
regard (maybe in next revision)?

Wonyong Koh, Ph.D.



Tue, 04 May 1999 03:00:00 GMT  
 conflict between CS-PICK and control structure checking

Quote:

> .

.
.
 Is there any

Quote:
> way that ANS Standard allow implementors more flexibility in this
> regard (maybe in next revision)?

> Wonyong Koh, Ph.D.


I once implemented a high-level ROLL something like this:-

: ROLL
  DUP 2 < ( 1 ROLL is a no-op, and this is safe for smaller parameters )
  IF
    DROP
  ELSE
    1 - SWAP
    >R ( park the top of stack temporarily )
    RECURSE ( ROLL working on a smaller stack with a smaller parameter )
    R> ( recover the old top of stack )
    SWAP ( the old top of stack should be below what it was on top of )
  THEN ;

- but since I'm keying that in untested from memory, there is probably a
bug in it. A similar construct worked for PICK. Does any of this get you
any further forward? PML.



Tue, 04 May 1999 03:00:00 GMT  
 conflict between CS-PICK and control structure checking


Quote:

>My question to clf readers is this: Is is worth to give up rigorous
>balance checking to provide CS-PICK? (I do not want to add type-aware
>control flow stack to hForth. It will be too much work.) Is there any
>way that ANS Standard allow implementors more flexibility in this
>regard (maybe in next revision)?

I've come across problems like this before, where the Standard has assumed
certain implementation characteristics. I just document it as an exception
and move on.

Tom Almy



Tue, 04 May 1999 03:00:00 GMT  
 conflict between CS-PICK and control structure checking

Quote:

> My question to clf readers is this: Is is worth to give up rigorous
> balance checking to provide CS-PICK? (I do not want to add type-aware
> control flow stack to hForth. It will be too much work.)

Gforth uses control flow stack items that are larger than one cell
(presently three cells), and keeps them on the data stack. Each
control-flow stack item contains a tag, so the checking you desire can
be performed (and more accurately than with your coonters: if I
understand you correctly, your compiler will not complain about BEGIN IF
AGAIN THEN). Adding a tag for each control-flow item is not much work.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Fri, 07 May 1999 03:00:00 GMT  
 conflict between CS-PICK and control structure checking

Quote:

>hForth need to know whether the control flow stack item to be copied
>by CS-PICK is orig, dest, do-sys, of-sys, or case-sys. But it is not
>possible with typeless control flow stack! And this kind of balance
>checking is not necessary at all for a control flow stack of which
>items are tagged, in which each word consuming control flow stack
>item, instead of ';', can issue "-22 THROW" for a mismatch.

>However, this is not a limitation in practice. As demonstrated by Mr.
>Borasky, a user of CS-PICK always knows which one to copy and can
>solve this problem by adding 'dest+' or 'orig+' accordingly.

>My question to clf readers is this: Is is worth to give up rigorous
>balance checking to provide CS-PICK? (I do not want to add type-aware
>control flow stack to hForth. It will be too much work.) Is there any
>way that ANS Standard allow implementors more flexibility in this
>regard (maybe in next revision)?

I re-read the Standard document. Embarrassingly I found it is not
a problem at all. The Standard says:

CS-PICK   'c-s-pick'                                      TOOLS EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution:( C: destu ... orig0|dest0 --- destu ... orig0|dest0 destu )
          ( S: u -- )
Remove u.  Copy destu to the top of the control-flow stack. An
ambiguous condition exists if there are less than u+1 items, each of
which shall be an orig or dest, on the control-flow stack before
CS-PICK is executed.  If the control-flow stack is implemented using
the data stack, u shall be the topmost item on the data stack.

CS-PICK always copies dest. So correct implementation of CS-PICK in
hForth is:

    : CS-PICK   PICK dest+ ;

I am sorry for this disturbance.

Wonyong Koh, Ph.D.



Sat, 08 May 1999 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. adding fields to picked structures

2. picking up a name for a data structure

3. Is there a way I can configure LV To pick user controls from a different folder

4. This is PICK (and Pick like)

5. to CS: or not to CS: in F-PC assembler

6. Checking record structure of a data file

7. structure size : how can i check it?

8. Control Structure Question

9. More control structures

10. Proposal for control structures in APL

11. Proposal for control structures in APL

12. Proposal for control structures in APL (SAMSON)

 

 
Powered by phpBB® Forum Software