Re: THROW codes and ambiguous conditions

On 8/06/2025 9:31 am, albert@spenarnc.xs4all.nl wrote:

In article <87plff4938.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:

dxf <dxforth@gmail.com> writes:

For (.) (D.) (U.) that's certainly not the case in Gforth.

I said the Standard hadn't factored them out.  Several forths of course
have factored them out.

>
Well I think you were saying the standard SHOULD have factored them out,
presumably because they are both useful to users, and reasonably
necessary parts of the underlying implementation that could have been
exported, as opposed to just giving more clutter for implementers to
supply.

 
It is occasionally useful to have conversions to a string that
not immediately prints. Even figforth had a (D.R) that was a
D.R without the type.

Not standard FigForth which only had D.R

But thanks to the #-set a conversion is very short :
   : (.) 0 <# #S #> ;
I tend to define such word in the application , otherwise you end up
adding (.) (U.) (D.) (UD.) (D.R) to the standard.

The first three anyway.  That it seems wrong to you and others that
a forth should logically include them only serves to illustrate
what 50 years of conditioning by the Standard has done to the forth
consciousness.  It makes a person say 'I will only have Standard
words'.

So now I have to also wonder what they do and what they are good for.
>

As for /CHAR >CHAR >DIGIT HELD MU* MU/MOD TRIM UNNEST

>
Same for these.  I can sort of guess at a few.

 
People tend to use additions and forget that they are not standardized,
making programs unreadable and/or unusable.
 
I prefer specifying library functions that are used as source and
can be looked up as source, and if need be can be added to the application
if porting.
 
Groetjes Albert