Re: Why dial-a-standard is not a thing in Forth

On 30-04-2025 12:57, albert@spenarnc.xs4all.nl wrote:
 > In article <nnd$7cd5eca1$455e887d@ea22aa12ceb9f46f>,
 > Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
 >> On 21-04-2025 09:38, dxf wrote:
 >>> On 21/04/2025 6:34 am, albert@spenarnc.xs4all.nl wrote:
 >>>> In article <757e2ced7a6ff4b73d9fa4531d29ff611dc72e10@i2pn2.org>,
 >>>> dxf  <dxforth@gmail.com> wrote:
 >>>>> On 20/04/2025 6:18 pm, Paul Rubin wrote:
 >>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
 >>>>>>> : DECIMAL ( -- )   10 BASE ! ;
 >>>>>>> does not contain an invocation of DECIMAL before this use of "10".
 >>>>>>
 >>>>>> : DECIMAL ( -- ) 5 5 + BASE ! ;
 >>>>>>
 >>>>>> should usually work.
 >>>>>
 >>>>> Perhaps it's been updated since as the SwiftForth file I have has:
 >>>>>
 >>>>> : DECIMAL ( -- )   $0A BASE ! ;
 >>>>>
 >>>>> Closest thing to a BASE issue I've encountered was invoking the
 >>>>> screen editor while in HEX.  After doing that a few times I fixed
 >>>>> the editor!
 >>>>>
 >>>>> Really annoying was LMI which on error switched to DECIMAL ...
 >>>>
 >>>> They had it half right. All error numbers should be printed in
 >>>> decimal. First aid read the paragraphs in de documentation
 >>>> pertaining to this error.
 >>>
 >>> I notice I did that for THROW numbers that don't have a message - after
 >>> which it reverts to the current BASE.  I should document that
 >> somewhere...
 >>
 >> To force myself to add messages to THROWs (especially in libs with
 >> special conditions) I added THROW" - it works like a combination of
 >> ABORT" and THROW. You need to specify a THROW code, you need to specify
 >> a flag and you need to specify a message.
 >
 > This perpetuates the myth that a message is documentation.
 > Error documentation in my manual can run over half a page, as
 > did the FORTRAN errors in IBM manual.
 > You don't actually want an error message, you want to know what
 > you can do about it.
I always loved "Error 1014" messages. That really helped me to track down what I was doing wrong. Recently I was porting FFL modules - and while I was running a test script, 4tH came back with "Unhandled exception".
Now - I knew two things:
1. My libraries don't die without a message;
2. Dick's libraries don't die without a message - unless it's an allocation error.
So yeah, 5000 random numbers added to a binary tree would probably exceed the small 16K heap. And yeah, that was it.
Although it's wonderful to list in detail what might have caused the error - and how to fix it - sometimes all you need is a clue to hang a picture on.
Hans Bezemer