11:17 <veltas> floatcomplex: THEN resolves a forward reference, i.e. in IF THEN the IF creates a forward reference, and THEN resolves it. That 'forward reference' is used if the thing popped from the stack is zero at runtime

11:17 <veltas> So it lets IF jump forwards

11:19 <veltas> WHILE creates a forward reference under the reference BEGIN leaves to loop back

11:20 <veltas> That forward reference is used to end the loop early when the thing popped is zero at runtime

11:21 <veltas> So WHILE and IF are very similar, and THEN can be used to consume the forward reference (i.e. choose a different location for the WHILE to jump to) if the loop is ended with UNTIL instead of REPEAT, or if there are additional WHILE's before a REPEAT.

11:22 <veltas> This is allowed by the forth200x standard, and is conventional for these words

11:24 <veltas> So the BEGIN..WHILE..WHILE..REPEAT THEN lets you have two conditions in a loop, which is quite a common need

11:25 <veltas> Two or more

17:55 <floatcomplex> veltas: yeah that makes sense, i think it might actually take some options off the table for how to implement it vs if "begin...until" and "begin...while...repeat" were the only allowed options though

17:56 <floatcomplex> maybe possible to have fastpath code for if only those are used

23:32 <veltas> floatcomplex: I think the only reason it's defined this way is because it was supported in FIG forth or something and too much code already relied on it

23:33 <veltas> So it is conventional now whether we like it or not, a bit like allotting and -allotting memory, you could argue is not optimal for hash forths

23:33 <floatcomplex> veltas: yeah it makes total sense now that i look at the spec for how it's expected to be implemented. but it does seriously constrain the implementation

23:34 <veltas> Well you could have non-standard words that are less constrained, or just not follow standard at all