Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #54611

Re: CASEs compared

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.forth
Subject Re: CASEs compared
Date 2017-02-03 14:40 -0500
Organization A noiseless patient Spider
Message-ID <o72m7j$hs3$1@dont-email.me> (permalink)
References (6 earlier) <c11c660a-9699-423a-abce-9aaf0ae48b6a@googlegroups.com> <3ba54b8a-380a-4fc5-84d7-80271d7cd313@googlegroups.com> <o6v0nr$1id1$1@gioia.aioe.org> <o70kdn$j50$1@dont-email.me> <56357cbe-2d52-4469-a674-4562fd36af7a@googlegroups.com>

Show all headers | View raw


On 2/3/2017 5:11 AM, Mark Wills wrote:
> On Friday, 3 February 2017 00:57:05 UTC, rickman  wrote:
>> On 2/2/2017 5:12 AM, HAA wrote:
>>> hughaguilar96@gmail.com wrote:
>>>> ...
>>>> Since the title of this thread is "CASEs compared," here is a comparison:
>>>>
>>>> : ccc ( n -- )
>>>>     case
>>>>     2 of  1  endof
>>>>     3 of  2  endof
>>>>     5 of  3  endof
>>>>     7 of  4  endof
>>>>    11 of  5  endof
>>>>    13 of  6  endof
>>>>    17 of  7  endof
>>>>    19 of  8  endof
>>>>    23 of  9  endof
>>>>    29 of 10  endof
>>>>     -1  swap endcase ;  ok
>>>>
>>>> 1 ccc . -1  ok
>>>> 2 ccc . 1  ok
>>>> 29 ccc . 10  ok
>>>> 30 ccc . -1  ok
>>>>
>>>> What usually messes me up when using CASE is that the test value is still on the stack
>>>> after the last ENDOF and it has to be left on the stack so ENDCASE can discard it. That
>>>> is why we have a SWAP in there.
>>>
>>> Having the selector left on the stack when all comparisons fail seems natural and
>>> can be useful.  What gets in the way is ENDCASE wanting to DROP it for you.
>>
>> I've thought the same thing.  Would it make sense for the selector to be
>> held on the return stack so that it can be be accessible and out of the
>> way?  Every iteration of "OF" requires an OVER for the comparison, R@
>> isn't really any harder and the ENDCASE still removes it.  In fact,
>> rather than have OF remove the selector with a DROP, it can be left on
>> the return stack until jumping to the ENDCASE where it is removed.  That
>> saves a bit of code.  It would be a change to the standard of course.
>>
>> --
>>
>> Rick C
>
> I went through this, too, in 2013. As a result I did this:
>
> http://turboforth.net/resources/case.html
>
> CLF thread here: https://groups.google.com/forum/#!topic/comp.lang.forth/sXcSd_5F6bs%5B1-25%5D

As Hugh points out using default: has one issue, the default code not 
knowing what the selector value was.

Here is an idea.  I still like the idea of shoving the selector out of 
the way on the return stack.  So default: can do just that, be a synonym 
for >R.  The default code can access the selector with R@ or invent a 
word to fetch this so the user doesn't need to remember where the 
selector is, say selector@.  Then the default clause is completed by a 
word that is a synonym for R>, say ENDDEFAULT or maybe :DEFAULT.  No 
jumps required and ENDCASE continues doing what it has always done with 
no changes.

Any downsides to this?

I'm not too sure of the names.  Seems like colon has special meanings at 
the beginning and end of word names.  Perhaps something different should 
be used?  There are not many special chars that *don't* have a special 
meaning in Forth.  Here are the special chars I found that have no 
particular use that might create confusion, % & ^ _ ~.  How about the 
tilde?  default~  ~default  Or the underscore?  default_  _default  Or 
the carat?  default^  ^default

BTW, when searching for the carat in the 2012 standard, I found the 
carat in the text is not the same char as the carat in the character 
list at the footer of the glossary pages.  ˆ and ^ ???

-- 

Rick C

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

CASEs compared "HAA" <someone@microsoft.com> - 2017-01-30 22:34 +1100
  Re: CASEs compared anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-30 15:56 +0000
    Re: CASEs compared hughaguilar96@gmail.com - 2017-01-30 09:57 -0800
      Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-01-31 14:26 +1100
        Re: CASEs compared hughaguilar96@gmail.com - 2017-01-31 08:12 -0800
          Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-01 11:39 +1100
            Re: CASEs compared hughaguilar96@gmail.com - 2017-01-31 22:37 -0800
              Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 12:26 -0800
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 16:50 -0800
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 18:02 -0800
                Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-02 21:12 +1100
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 13:46 -0800
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 17:01 -0800
                Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 12:43 +1100
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:52 -0800
                Re: CASEs compared Alex <alex@rivadpm.com> - 2017-02-04 11:10 +0000
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-02 19:57 -0500
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 17:05 -0800
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-02 21:55 -0500
                Re: CASEs compared Mark Wills <markwills1970@gmail.com> - 2017-02-03 02:11 -0800
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 10:52 -0800
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:38 -0800
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 22:08 -0500
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 21:40 -0800
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 01:16 -0500
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 14:40 -0500
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:47 -0800
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 22:04 -0500
                Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 12:39 +1100
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 23:32 -0500
                Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 22:50 +1100
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 11:07 -0500
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-04 08:48 -0800
                Re: CASEs compared Mark Wills <markwills1970@gmail.com> - 2017-02-04 10:01 -0800
                Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 16:43 -0500
                Re: CASEs compared hughaguilar96@gmail.com - 2017-02-04 18:53 -0800
                Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-05 19:12 +1100
    Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-01-31 14:25 +1100
  Re: CASEs compared Elliott Chapin <elliott.chapin@gmail.com> - 2017-02-05 08:25 -0800
    Re: CASEs compared Coos Haak <htrofhc@gmail.com> - 2017-02-06 00:42 +0100
  Re: CASEs compared jacko <jackokring@gmail.com> - 2017-02-16 17:46 -0800
    Re: CASEs compared hughaguilar96@gmail.com - 2017-02-17 09:09 -0800

csiph-web