Comments on: Intermediate languages http://www.snell-pym.org.uk/archives/2008/04/11/intermediate-languages/ Sarah and Alaric Snell-Pym living in interesting times Wed, 19 Nov 2008 23:03:37 +0000 http://wordpress.org/?v=2.5 By: alaric http://www.snell-pym.org.uk/archives/2008/04/11/intermediate-languages/#comment-72594 alaric Sat, 12 Apr 2008 02:15:22 +0000 http://www.snell-pym.org.uk/archives/2008/04/11/intermediate-languages/#comment-72594 <p>As a side note: the desire to easily construct data/control-flow diagram representations of a stack language implies that one should totally disallow the already somewhat questionable practice of defining FORTH words that have variable stack pictures - eg, that do not move the stack pointer(s) by a constant amount on each execution... Otherwise, as well as it becoming difficult or impossible to extract the data flow within a word definition, it becomes equally hard to compute the overall stack effect of a word during its definition and store that in the dictionary to allow words that use this word to have THEIR data flow analysed.</p> <p>Standard FORTHs usually let you define such words, but most FORTH programmers don't, since it can confuse a human reader as easily as it can confuse the implementation. One notable exception is when reporting errors (pun intended); some words return a boolean at top of stack. If the boolean is false, the operation failed. If it's true, the operation succeeded, and the results are then underneath the boolean. This allows for programming style such as:</p> <pre><code>DB-LOOKUP IF ." Found: " . THEN ." Nothing found" ELSE </code></pre> <p>The <code>.</code> in the success arm of the conditional takes the number found in the database (and placed under the boolean consumed by the <code>IF</code>) and prints it, while the failure arm just prints a static message and consumes nothing from the stack, since there's nothing there.</p> <p>I see this as an argument for implementing exception handling, and then writing:</p> <pre><code>TRY DB-LOOKUP ." Found: " . CATCH ." Nothing found" ENDTRY </code></pre> As a side note: the desire to easily construct data/control-flow diagram representations of a stack language implies that one should totally disallow the already somewhat questionable practice of defining FORTH words that have variable stack pictures - eg, that do not move the stack pointer(s) by a constant amount on each execution... Otherwise, as well as it becoming difficult or impossible to extract the data flow within a word definition, it becomes equally hard to compute the overall stack effect of a word during its definition and store that in the dictionary to allow words that use this word to have THEIR data flow analysed.

Standard FORTHs usually let you define such words, but most FORTH programmers don't, since it can confuse a human reader as easily as it can confuse the implementation. One notable exception is when reporting errors (pun intended); some words return a boolean at top of stack. If the boolean is false, the operation failed. If it's true, the operation succeeded, and the results are then underneath the boolean. This allows for programming style such as:

DB-LOOKUP IF
." Found: " . THEN
." Nothing found" ELSE

The . in the success arm of the conditional takes the number found in the database (and placed under the boolean consumed by the IF) and prints it, while the failure arm just prints a static message and consumes nothing from the stack, since there's nothing there.

I see this as an argument for implementing exception handling, and then writing:

TRY
   DB-LOOKUP ." Found: " .
CATCH
   ." Nothing found"
ENDTRY
]]>