RFI: Simple CASE Statement 
Author Message
 RFI: Simple CASE Statement

RFI: Simplified CASE Statement

Being Standard is not as important as being Portable.

I believe that the Simplified CASE Statement can be defined portably:

: CASE  0 ; IMMEDIATE
: ESAC  BEGIN ?DUP WHILE [COMPILE] THEN REPEAT ; IMMEDIATE
: OF    COMPILE OVER COMPILE = [COMPILE] IF COMPILE DROP ; IMMEDIATE

with COMPILE and [COMPILE] replaced by POSTPONE in Standard Forth.

I know that this is implementation dependent, but an earlier RFI
showed that all implementations use the data stack for the
control-flow stack.

In implementations that do not have Compiler Security for control
flow, 0 is impossible.

The implementations that I know with Compiler Security just
happen to use other values for tags.  E.g.: in Compiler Security
the figForth way, 1, 2, 3, and maybe 4, are used; in F83, -1 is
used.

If the first two definitions don't work, then the following
should.

VARIABLE case-sys

: ESAC

      case-sys !
; IMMEDIATE

If I have misspoken, would you please flame me.

And show me how to do it your way.
--
Procedamus in pace.     Wil Baden    Costa Mesa, California



Thu, 30 Apr 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

Quote:
>I know that this is implementation dependent, but an earlier RFI
>showed that all implementations use the data stack for the
>control-flow stack.

With a little work we can remove that environmental dependency.

Quote:
>VARIABLE case-sys

>: ESAC

>      case-sys !
>; IMMEDIATE

This looks workable.  I'd write it as follows:

: CASE 0 ; IMMEDIATE
: ESAC ( n*orig n -- ) 0 DO POSTPONE THEN LOOP ; IMMEDIATE
: OF ( n -- n+1 )
    >R POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP R> 1+ ;
 IMMEDIATE
: ENDOF ( n -- ) >R POSTPONE ELSE R> ; IMMEDIATE

By temporarily saving the number of items on the return stack, we can
nest CASE statements if we really need to.

This will crash with an empty CASE, one that has no OF's.
It can only be compiled into a definition, you can't define a
CASE structure while interpreting.  Within those limits, I believe
it should work identically on any standard system whatsoever.

Quote:
>If I have misspoken, would you please flame me.

No flames here.  You've got something.
Quote:
>And show me how to do it your way.



Fri, 01 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement
I have not made myself clear.  I don't care about removing
environmental dependency.

I have two sets of non-standard definitions.  Since all known
implementations use the data stack for the control-flow stack,
one or the other should "just happen" to work.

: CASE  0 ; IMMEDIATE
: ESAC  BEGIN ?DUP WHILE POSTPONE THEN REPEAT ; IMMEDIATE

VARIABLE case-sys

: ESAC

      case-sys !
; IMMEDIATE

The second set _is_ Standard with an environmental dependency on
the data stack as control-flow stack.

Both are nestable.

CASE marks the control-flow stack with an element to be used as a
sentinel.

ESAC keeps resolving the control-flow stack with THEN until the
sentinel is reached.

CASE and ESAC can be used with OF IF ORIF ANDIF and others.

Contrived example.

: range ( x lo hi -- x flag ) 2>R DUP 2R> WITHIN ;

: char-class                        ( c -- )
      CASE  DUP 32 U< ORIF DUP 127 = THEN
      IF DROP     ." control character "
      ELSE  32
      OF          ." space "
      ELSE  CASE
                  48 58 range ORIF 65 91 range ORIF 97 123 range
            ESAC
      IF DROP     ." alphanumeric "
      ELSE  128 0 RANGE
      IF DROP     ." not ascii "
      ELSE DROP   ." special character "
      ESAC
;

--
Procedamus in pace.     Wil Baden    Costa Mesa, California



Fri, 01 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

Quote:
>I have not made myself clear.  I don't care about removing
>environmental dependency.

You have 2 versions, and you figure that one or the other will work on
any existing standard Forth system and one or the other will work on
most of the systems that will ever get built.  I have a slight
modification of one of your versions which I believe will run on any ANS
system whatsoever.  It behaves the same at runtime, and has a very few
extra steps at compile-time.  Why not use one version instead of two?  


Fri, 01 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

: >I have not made myself clear.  I don't care about removing
: >environmental dependency.

: You have 2 versions, and you figure that one or the other will work on
: any existing standard Forth system and one or the other will work on
: most of the systems that will ever get built.  I have a slight
: modification of one of your versions which I believe will run on any ANS
: system whatsoever.  It behaves the same at runtime, and has a very few
: extra steps at compile-time.  Why not use one version instead of two?  

I still have not made myself clear, have I?

The Simple CASE Statement _cannot_ be defined in Standard Forth.

Standard Forth cannot:

        Test what is on the control-flow stack.

        Determine the depth of the control-flow stack.

      Create a new type of element for the control-flow stack.

Your code is not Standard, and not portable.  My code is not
Standard but I hope that it "just happens" to be portable.

In your code

Quote:
> : CASE 0 ; IMMEDIATE

        What do you think this does?

Quote:
> : ESAC ( n*orig n -- ) 0 DO POSTPONE THEN LOOP ; IMMEDIATE

        Where did n come from?

Quote:
> : OF ( n -- n+1 )
>     >R POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP R> 1+ ;

        Where did n come from?  Are you confusing the sample
        implementation in the rationale with what the Standard says?

Quote:
>  IMMEDIATE
> : ENDOF ( n -- ) >R POSTPONE ELSE R> ; IMMEDIATE

        Where did n come from?  The Simple CASE Statement does not
        need ENDOF.  Or for old times' sake

        : ENDOF POSTPONE ELSE ; ELSE

Please read my previous post.  Try my contrived example with
your definitions.

Then try my contrived example with each of my sets of
definitions.

Let me know if they work or not.

For your convenience, here is my contrived example again.

: range ( x lo hi -- x flag ) 2>R DUP 2R> WITHIN ;

: char-class                        ( c -- )
      CASE  DUP 32 U< ORIF DUP 127 = THEN
      IF DROP     ." control character "
      ELSE  32
      OF          ." space "
      ELSE  CASE
                  48 58 range ORIF 65 91 range ORIF 97 123 range
            ESAC
      IF DROP     ." alphanumeric "
      ELSE  128 0 RANGE
      IF DROP     ." not ascii "
      ELSE DROP   ." special character "
      ESAC
;

--
Procedamus in pace.     Wil Baden    Costa Mesa, California



Fri, 01 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement
In my previous or next post, depending on your mailer, it should be

        : ENDOF POSTPONE ELSE ; IMMEDIATE



Fri, 01 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement
I'm making the mistake of answering before testing code, pardon me if I mess
up.


Quote:


>: You have 2 versions, and you figure that one or the other will work on
>: any existing standard Forth system and one or the other will work on
>: most of the systems that will ever get built.  I have a slight
>: modification of one of your versions which I believe will run on any ANS
>: system whatsoever.  It behaves the same at runtime, and has a very few
>: extra steps at compile-time.  Why not use one version instead of two?  
>I still have not made myself clear, have I?
>The Simple CASE Statement _cannot_ be defined in Standard Forth.

Ooops!  I must have  misunderstood.

Quote:
>Standard Forth cannot:
>    Test what is on the control-flow stack.

I didn't do that.

Quote:
>    Determine the depth of the control-flow stack.

I counted as it built up.

Quote:
>      Create a new type of element for the control-flow stack.

I didn't do that either.

Quote:
>Your code is not Standard, and not portable.  My code is not
>Standard but I hope that it "just happens" to be portable.

My code isn't standard?  Not portable?  Why not?

Quote:
>In your code
>> : CASE 0 ; IMMEDIATE
>    What do you think this does?

It puts a 0 on the data stack at compile-time.

Quote:
>> : ESAC ( n*orig n -- ) 0 DO POSTPONE THEN LOOP ; IMMEDIATE
>    Where did n come from?

That's what the original zero turns into, every time we do another IF we add
one to it.

Quote:
>> : OF ( n -- n+1 )
>>     >R POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP R> 1+ ;
>    Where did n come from?  Are you confusing the sample
>    implementation in the rationale with what the Standard says?

No, that n started out as zero and increases one for each IF .  Is there a
sample implementation in the rationale?  I didn't notice it, maybe it
dropped out.

Quote:
>>  IMMEDIATE
>> : ENDOF ( n -- ) >R POSTPONE ELSE R> ; IMMEDIATE
>    Where did n come from?  The Simple CASE Statement does not
>    need ENDOF.  Or for old times' sake

It's the same n that CASE made and OF incremented.  But you're right, your
Simple CASE Statement didn't need it.  I can do OF and ENDOF this way, but I
don't see how to do random IFs like that.  I don't have any way to count IFs
whenever they show up, unless I build my own parser for CASE to use -- a
sledgehammer solution.

Quote:
>Please read my previous post.  Try my contrived example with
>your definitions.
>Then try my contrived example with each of my sets of
>definitions.
>Let me know if they work or not.

I started writing something similar, that worked, but it wasn't the same.  I
did enough to get convinced it was workable and then quit, I only have so
much time for these things.

I get a better idea of it now, though.  You do THEN until the data stack
balances, so you don't have to count the IFs.  So you can do any combination
of conditional commands and have them all balance out at the end.  I don't
see an elegant way to do that with the standard.  I can write OF and ENDOF
and ANDIF and ORIF to work, but I can't write unbalanced IFs and expect to
balance them automatically.



Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

Quote:

> I'm making the mistake of answering before testing code, pardon me if I mess
> up.

I've been asking you to test some code for me.  I can excuse
you but I can't pardon you.

Quote:
> ...

> >   Determine the depth of the control-flow stack.

> I counted as it built up.

How?  There's nothing in the Standard that can do this.

Quote:
> ...

> >Your code is not Standard, and not portable.  My code is not
> >Standard but I hope that it "just happens" to be portable.

> My code isn't standard?  Not portable?  Why not?

See below.  And above.  And I doubt that my contrived example
will work on _your_ system.

Quote:
> ...
> >> : ESAC ( n*orig n -- ) 0 DO POSTPONE THEN LOOP ; IMMEDIATE

> >   Where did n come from?

> That's what the original zero turns into, every time we do another IF we add
> one to it.

Who are we?  The Standard doesn't say that IF does that.

Quote:
> >> : OF ( n -- n+1 )
> >>     >R POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP R> 1+ ;

> >   Where did n come from?  Are you confusing the sample
> >   implementation in the rationale with what the Standard says?

> No, that n started out as zero and increases one for each IF . ...

The Standard does not say this.

Quote:
> >> : ENDOF ( n -- ) >R POSTPONE ELSE R> ; IMMEDIATE

> >   Where did n come from?  The Simple CASE Statement does not
> >   need ENDOF.  ...

> It's the same n that CASE made and OF incremented.

Once again, the Standard does not say that anything is
incremented by OF or IF.

Quote:
> But you're right, your
> Simple CASE Statement didn't need it.  I can do OF and ENDOF this way, but I
> don't see how to do random IFs like that.  I don't have any way to count IFs
> whenever they show up, unless I build my own parser for CASE to use -- a
> sledgehammer solution.

Do you call the following a sledgehammer solution?

( The Standard CASE Statement )
( Environmental dependency on data stack for control-flow stack. )
VARIABLE case-sys

: ESAC                              ( C: case_sys ... -- )

      case-sys !
; IMMEDIATE
: OF postpone OVER postpone = postpone IF postpone DROP ; IMMEDIATE
: ENDOF postpone ELSE ; IMMEDIATE
: ENDCASE postpone DROP postpone ESAC ; IMMEDIATE

Quote:
> >Please read my previous post.  Try my contrived example with
> >your definitions.

> >Then try my contrived example with each of my sets of
> >definitions.

> >Let me know if they work or not.

Pretty please.

Quote:
> I started writing something similar, that worked, but it wasn't the same.  I
> did enough to get convinced it was workable and then quit, I only have so
> much time for these things.

> I get a better idea of it now, though.  You do THEN until the data stack
> balances, so you don't have to count the IFs.  So you can do any combination
> of conditional commands and have them all balance out at the end.  I don't
> see an elegant way to do that with the standard.

         ^^^^^^^

There isn't _any_ way do do it in the Standard.  But since all
known implementations use the data stack for the control-flow
stack, my "sledgehammer" will just happen to work.

And I do think my "sledgehammer" is elegant.

Quote:
> I can write OF and ENDOF
> and ANDIF and ORIF to work, but I can't write unbalanced IFs and expect to
> balance them automatically.

IFs are not unbalanced -- each one must be matched with ELSE or
THEN.  ESAC balances all IFs and ELSEs back to CASE with THENs.

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

I'm going to try one more time.

To every one who reads this,

I have some code that is Standard with an environmental
dependency on the data stack as the control-flow stack. I
believe that it will work on _all_ known implementations --
because all known implementations use the data stack as the
control-flow stack.

Would you please, as a favor to me, test the code and tell me if
there is an implementation for which it fails.

My contrived example is a fair test.
--
Let us go forth in peace.     Wil Baden    Costa Mesa, California



Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

Quote:



[snip]

Quote:

>> >   Determine the depth of the control-flow stack.

>> I counted as it built up.

>How?  There's nothing in the Standard that can do this.

That's true, but the method that JEThomas used perfomed a similar
function. He counted the number of IFs compiled via his OF word.

[snip]

Quote:
>> My code isn't standard?  Not portable?  Why not?

>See below.  And above.  And I doubt that my contrived example
>will work on _your_ system.

His code is not portable to EVERY standard system since the Standard
CASE, OF, and ENDOF do not leave anything on the data stack, unless
the control stack is the data stack. His code is standard with an
environmental dependency upon the control stack residing upon the data
stack.

Quote:
>> >> : ESAC ( n*orig n -- ) 0 DO POSTPONE THEN LOOP ; IMMEDIATE

>> >   Where did n come from?

>> That's what the original zero turns into, every time we do another IF we add
>> one to it.

>Who are we?  The Standard doesn't say that IF does that.

He was imprecise.  "Every time we do another IF (via the word OF) we
add one to it" would have been less confusing.

Quote:

>> >> : OF ( n -- n+1 )
>> >>     >R POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP R> 1+ ;

>> >   Where did n come from?  Are you confusing the sample
>> >   implementation in the rationale with what the Standard says?

>> No, that n started out as zero and increases one for each IF . ...

>The Standard does not say this.

Did you even READ his code?  How about "No, that n started out as zero
and increases one for each IF compiled via OF."

Quote:

>> >> : ENDOF ( n -- ) >R POSTPONE ELSE R> ; IMMEDIATE

>> >   Where did n come from?  The Simple CASE Statement does not
>> >   need ENDOF.  ...

>> It's the same n that CASE made and OF incremented.

>Once again, the Standard does not say that anything is
>incremented by OF or IF.

Well, if you're going to be picky then the Simple CASE Statement
*cannot* be Standard since you do not use ENDOF.

The standard DOES indicate that <case-sys> can change after an ENDOF
by the control stack comment.  Of course, he can only claim that <n>
is part of <case-sys> when the control stack and data stack are the
same.

Quote:

>> But you're right, your
>> Simple CASE Statement didn't need it.  I can do OF and ENDOF this way, but I
>> don't see how to do random IFs like that.  I don't have any way to count IFs
>> whenever they show up, unless I build my own parser for CASE to use -- a
>> sledgehammer solution.

>Do you call the following a sledgehammer solution?

I call it almost the same solution as JEThomas' with two
differences:

1) He does not require the use of a variable (which you don't seem to
initialize).  You'd have to make a headerless variable or put it in a
throwaway wordlist so I can't get to it.  Otherwise, I can make an
immediate word that zaps case-sys and break the CASE statement.

2) You can handle "random" IF statements within the CASE
statement. His cannot.

[snip]

Quote:
>-------------------------------

>I'm going to try one more time.

>To every one who reads this,

>I have some code that is Standard with an environmental
>dependency on the data stack as the control-flow stack. I
>believe that it will work on _all_ known implementations --
>because all known implementations use the data stack as the
>control-flow stack.

>Would you please, as a favor to me, test the code and tell me if
>there is an implementation for which it fails.

Any system with a variable name collision with "colon-sys" can
fail. Easy to fix, but you *do* have to fix it.

Quote:

>My contrived example is a fair test.
>--
>Let us go forth in peace.     Wil Baden    Costa Mesa, California

I've seen a similar concept in DRUMA Forth-83, namely their IFCASE,
CASED construction.  An example would be:

: TEST.NKEY ( n --)
        IFCASE
                ASCII 0 <       IFC NOT.NUM     ENDC
                ASCII 0 =       IFC ." <0>"     ENDC
                ASCII 1 =       IFC ." <1>"     ENDC
                ASCII 2 =       IFC ." <2>"     ENDC
                ASCII 3 =       IFC ." <3>"     ENDC
                BETWEEN.4-6     IFC ." <4> <5> or <6>"  ENDC
                BETWEEN.7-9     IFC ." <7> <8> or <9>"  ENDC
                NOT.NUM         \ default case
        CASED
;

In their version, IFC expects a flag versus performing a test as OF
does. The method they used required system knowledge and is not
directly portable.

--

Someday I may speak for BNR/NT.  Someday pigs may howl at a full moon.
Expect the latter to occur first.



Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement
My flaky netserver missed a dozen messages, including the one this is a
reply to.  I'll switch servers as soon as I can arrange it.


Quote:
Flacy) writes:

(W.Baden) writes:

>[snip]
>>> >   Determine the depth of the control-flow stack.
>>> I counted as it built up.
>>How?  There's nothing in the Standard that can do this.
>That's true, but the method that JEThomas used perfomed a similar
>function. He counted the number of IFs compiled via his OF word.

Yes.

Quote:
>[snip]
>>> My code isn't standard?  Not portable?  Why not?
>>See below.  And above.  And I doubt that my contrived example
>>will work on _your_ system.
>His code is not portable to EVERY standard system since the Standard
>CASE, OF, and ENDOF do not leave anything on the data stack, unless
>the control stack is the data stack. His code is standard with an
>environmental dependency upon the control stack residing upon the data
>stack.

My code is portable if I redefine CASE OF ENDOF and ENDCASE myself.  I
don't depend on the control stack being on the data stack, I _put_ part
of the control stack onto the data stack.  I do it carefully so that
what I do doesn't interfere with what the system does, whether it uses
the data stack or not.  Code which has an environmental dependency which
_requires_ that the control stack _not_ be the data stack won't run with
this version.  However, Wil points out that such systems are quite
uncommon; we haven't turned one up yet.  So the code that failed on my
words would not be very portable anyway.

Quote:
>>> >> : ESAC ( n*orig n -- ) 0 DO POSTPONE THEN LOOP ; IMMEDIATE
>>> >   Where did n come from?
>>> That's what the original zero turns into, every time we do another
>>>IF we add one to it.
>>Who are we?  The Standard doesn't say that IF does that.
>He was imprecise.  "Every time we do another IF (via the word OF) we
>add one to it" would have been less confusing.

Yes, sorry.

Quote:
>The standard DOES indicate that <case-sys> can change after an ENDOF
>by the control stack comment.  Of course, he can only claim that <n>
>is part of <case-sys> when the control stack and data stack are the
>same.

No, I claim that I can write standard code to implement CASE independent
of the system.  I use the data stack, and the system can use it or not
despite what I do.

Quote:
>>> But you're right, your
>>> Simple CASE Statement didn't need it.  I can do OF and ENDOF this
>>> way, but I don't see how to do random IFs like that.  I don't have
>>> any way to count IFs whenever they show up, unless I build my own
>>> parser for CASE to use -- a sledgehammer solution.
>>Do you call the following a sledgehammer solution?

I meant I don't have a standard way to do it without an environmental
dependency like the one you used.  It would be a lot of trouble to write
a parser that counted the IFs as it executed them.  Or maybe not that
much trouble, but I think more than CASE is worth.  Some years ago
someone wrote an FD article on Parnas's  IT ... TI construction.  In my
copious spare time ( 8-) I might dust that off and look for a standard
way to write it.

Quote:
>I call it almost the same solution as JEThomas' with two
>differences:
>1) He does not require the use of a variable (which you don't seem to
>initialize).  You'd have to make a headerless variable or put it in a
>throwaway wordlist so I can't get to it.  Otherwise, I can make an
>immediate word that zaps case-sys and break the CASE statement.

He doesn't need to initialize it; he never uses the first instance.  
Every time he uses it he saves the old version and restores it later.  
The first time he might be saving and restoring garbage, but who cares?
A headerless variable would work.

Quote:
>2) You can handle "random" IF statements within the CASE
>statement. His cannot.

Yes.  Wil's version is more flexible.  I'm not certain yet whether that
flexibility is useful, but it's good to know that it's possible even
with a minor environmental dependency.


Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

: >Can I take it from this that at last you have tested my contrived
: >example with each of my definitions for CASE and ESAC ?

: Yes, they work as advertised for me.

Thank you.

Anyone else?
--
Procedamus in pace.    Wil Baden    Costa Mesa, California



Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement
W.Baden writes Re: RFI: Simple CASE Statement

The CASE ESAC code compiles correctly with iForth. The contrived
example runs ok (only limited testing done). I used the following
definition for ORIF (your previous posts were lost):

  : ORIF  S" ?DUP 0= IF" EVALUATE ; IMMEDIATE

-marcel

PS: I do not recommend redefining CASE structures already available
on a system. A native code compiler (like iForth) might be frustated
in its attempt to convert them to efficient jumptables.



Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

Quote:

> OK, I see the problem.  I can't mix-and-match my OF ENDOF structures
> with IF structures, because the IF things will (in some systems)

                                                 ^^^^^^^^^^^^^^^^^

                                            (in all known systems)

Quote:
> leave their origs on the data stack on top of my count.  It works,
> but not with the flexible abandon of Wil's method.

                   ^^^^^^^^^^^^^^^^

Flexible abandon?  I prefer "generality" or "consistency".

Can I take it from this that at last you have tested my contrived
example with each of my definitions for CASE and ESAC ?

Quote:
> [The rest deleted because of irrelevance.]

This thread was a Request for Information.  It is not meant to be
a discussion on the best way to do something.  
--
Wil Baden


Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

Quote:
>Can I take it from this that at last you have tested my contrived
>example with each of my definitions for CASE and ESAC ?

Yes, they work as advertised for me.


Sat, 02 May 1998 03:00:00 GMT  
 RFI: Simple CASE Statement

Quote:


>Flacy) writes:

[snip]

Quote:
>>His code is not portable to EVERY standard system since the Standard
>>CASE, OF, and ENDOF do not leave anything on the data stack, unless
>>the control stack is the data stack. His code is standard with an
>>environmental dependency upon the control stack residing upon the data
>>stack.

>My code is portable if I redefine CASE OF ENDOF and ENDCASE myself.  I
>don't depend on the control stack being on the data stack, I _put_ part
>of the control stack onto the data stack.  I do it carefully so that
>what I do doesn't interfere with what the system does, whether it uses
>the data stack or not.  Code which has an environmental dependency which
>_requires_ that the control stack _not_ be the data stack won't run with
>this version.  However, Wil points out that such systems are quite
>uncommon; we haven't turned one up yet.  So the code that failed on my
>words would not be very portable anyway.

OK, *but* if you redefine CASE, OF, ENDOF, and ENDCASE in a manner not
consistent with the Standard, the result ain't standard.  So what if I
had changed the first sentence to read "His code does not result in a
Standard system when implemented on EVERY ...." ?

[snip]

Quote:
>>The standard DOES indicate that <case-sys> can change after an ENDOF
>>by the control stack comment.  Of course, he can only claim that <n>
>>is part of <case-sys> when the control stack and data stack are the
>>same.

>No, I claim that I can write standard code to implement CASE independent
>of the system.  I use the data stack, and the system can use it or not
>despite what I do.

Not so.

: PRISTINE  BEGIN DEPTH WHILE DROP REPEAT ; IMMEDIATE

can be used within a Standard OF ... ENDOF construct where the data
stack and control stacks are not the same. {Now _why_ anyone would
want to do so is another story....}

[snip]

Quote:
>>1) He does not require the use of a variable (which you don't seem to
>>initialize).  You'd have to make a headerless variable or put it in a
>>throwaway wordlist so I can't get to it.  Otherwise, I can make an
>>immediate word that zaps case-sys and break the CASE statement.

>He doesn't need to initialize it; he never uses the first instance.  
>Every time he uses it he saves the old version and restores it later.  
>The first time he might be saving and restoring garbage, but who cares?

<shrug>  Bad form.

Quote:
>A headerless variable would work.

[rest snipped]

--

Someday I may speak for BNR/NT.  Someday pigs may howl at a full moon.
Expect the latter to occur first.



Sun, 03 May 1998 03:00:00 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. SIMPLE Case statement

2. case statement flipflop statement

3. difference if statement with case statement?

4. [Fwd: Case statements, decision trees, and good OO design]

5. SUNOS NAWK - TOLOWER - In a print statement convert string to lower case

6. CASE STATEMENT

7. Case statements in parallel

8. Detecting Multiple Events (was: Case Statements...)

9. Case Statements...

10. Eaker CASE statement words ....

11. programatically add item to case statement

12. Controlling program flow and case statements

 

 
Powered by phpBB® Forum Software