Perform the execution semantics given below.


( "<spaces>name ..." -- )

Skipping leading spaces, parse and discard space-delimited words from the parse area, including nested occurrences of [IF] ... [THEN] and [IF] ... [ELSE] ... [THEN], until the word [THEN] has been parsed and discarded. If the parse area becomes exhausted, it is refilled as with REFILL. [ELSE] is an immediate word.



Typical use: ... flag [IF] ... [ELSE] ... [THEN] ...


: [ELSE] ( -- )
    1 BEGIN                                          \ level
       BEGIN BL WORD COUNT DUP WHILE                  \ level adr len
         2DUP S" [IF]" COMPARE 0= IF                  \ level adr len
             2DROP 1+                                 \ level'
          ELSE                                        \ level adr len
            2DUP S" [ELSE]" COMPARE 0= IF             \ level adr len
                2DROP 1- DUP IF 1+ THEN               \ level'
            ELSE                                      \ level adr len
                S" [THEN]" COMPARE 0= IF              \ level
                   1-                                 \ level'
          THEN ?DUP 0= IF EXIT THEN                   \ level'
       REPEAT 2DROP                                   \ level
   REFILL 0= UNTIL                                   \ level


MitchBradleyavatar of MitchBradley [ELSE] without preceding [IF]Comment2018-05-13 18:36:50

There has been some discussion around the use of [ELSE] .. [THEN] without a preceding [IF]

As the culprit responsible for ANS Forth's [IF] [ELSE] [THEN], I can state that omitting [IF] was not one of my goals, and I don't recall even considering the possibility.

That said, I think it's nice that it happens to work, and it certainly seems useful, if a bit surprising to the naive user.

StephenPelcavatar of StephenPelc 2018-05-14 23:43:04

The idea that IF ... ELSE ... THEN can morph to ELSE ... THEN is repulsive.

For [ELSE] ... [THEN] it's an artefact of the implementation. Implementation artefacts have no place in a standard.

JennyBrienavatar of JennyBrien 2018-05-15 08:09:08

It's a natural consequence of the spec, and slightly more elegant than the common 0 [IF] but it will break if you ever put an [IF] in front.

StephenPelcavatar of StephenPelc 2018-05-15 14:49:07

We (MPE) use [IF] and friends a great deal to configure cross-compiled targets. We noticed that [IF] ... [ELSE] ... [THEN] is unchecked, so we recently implemented a check at the end of each source file to see if we actually use it correctly. Oops! Lots of errors. So [ELSE] without [IF] is a total no no for us. It's amusing that it works, but let's just leave it that way.

GerryJacksonavatar of GerryJackson 2018-06-10 19:02:54

I've only just realised that comments on this topic were here. Here is a post I made on the Yahoo Forth 200X group on 13 May copied here for completeness.

I've just realised what you were probably referring to with the [ELSE] ... [THEN]. That is specifically tested in the toolstest.fth file.I'd be surprised if it occurred in any other file.

That is just testing [ELSE] as written in the standard and I don't see any reason to remove it unless the specification for [ELSE] is rewritten to forbid it. Another silly thing is tested, [THEN] is a noop, so a lone [THEN] is valid and tested.

There are other dubious things tested in the test suite e.g. in coreplustest.fth multiple ELSE's in IF statements are tested e.g. ... IF...ELSE ... ELSE... ELSE...THEN ... which is perfectly valid standard Forth according to the specification for ELSE.

I believe test programs should test what's written in the standard, corner cases and sillinesses as well as usual usage.