conflict between CS-PICK and control structure checking

conflict between CS-PICK and control structure checking

Author

Message

Wonyong K#1 / 5

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:

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:

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

Peter Lawrenc#2 / 5

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

Tom Al#3 / 5

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

Anton Er#4 / 5

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

Wonyong K#5 / 5

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.