Re: THROW codes and ambiguous conditions

albert@spenarnc.xs4all.nl writes:

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.

It's not in the fig-Forth Installation Manual / Glossary / Model Release !

http://wiki.yak.net/1089/fig-FORTH_Manuals_May79.pdf

nor in the source code.

https://raw.githubusercontent.com/ForthHub/FIG-Forth/refs/heads/master/fig.fth

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.

Your (.) looks more like (U.) to me.

Alternatively, add

  >string-execute ( ... xt – ... c-addr u  ) gforth-1.0 "to-string-execute"
 
  Execute xt while the standard output (type, emit, and everything that
  uses them) is redirected to a string. The resulting string is c-addr
  u, which is in heap memory; it is the responsibility of the caller of
  >string-execute to free this string.

Then you can do

' d.r >string-execute

instead.  This approach has some overhead, however.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/