[75] 2019-03-03 06:20:52 kc5tja wrote:

proposal - F>R and FR> to support dynamically-scoped floating point variables

In writing an implementation of map and reduce operations for some floating point vectors, I've had a need to save and restore dynamic variables on the R-stack. Some of these variables are floating point variables.

The lack of a floating-point stack equivalent to R> and >R made this more difficult than it should have been, I think. Therefore, I'd like to propose the following two words for consideration in the FLOATING-EXT wordset:

Word	Run-time Semantics
F>R	Pushes the top of the floating point stack onto the return stack.
FR>	Pops the return stack, pushing the value removed onto the floating point stack.

On systems where the return stack cell size differs from the floating point stack cell size, multiple cells may need to be pushed onto the R-stack, padding as appropriate. Because of alignment issues, FR> and F>R are not guaranteed to be fast, as the implementation may have to store the floating point value in smaller parcels (e.g., storing a 64-bit or 80-bit FP value as a series of 16-bit cells on a 16-bit Forth).

Here's my current implementation written in 64-bit GForth 0.7.0 on x86-64 platform:

FVARIABLE realvar
: F>R ( r -- ) ( R: -- r )  R> realvar F!  realvar @ >R >R ;
: FR> ( R: r -- ) ( -- r )  R> R> realvar !  realvar F@ >R ;

I'd love to hear your thoughts. Thanks for entertaining my idea.

[r199] 2019-02-15 18:51:47 BerndPaysan replies:

requestClarification - [if] and [else] parse white space - including comments

We had that in Gforth, but removed it, because it was too smart. Example: postpone (. You can't really know what some Forth code actually does unless you actually interpret it, which the [ELSE] scanner doesn't.

\ The following was too smart for its own good; consider "postpone (".
\ Moreover, ANS Forth specifies that the next [THEN] ends an [IF]
\ (even if its in a '( ... )').

\ ' ( Alias (                          immediate ( keep fontify happy)
\ ' \ Alias \                          immediate

Yes, if I uncomment these two aliases, you can comment out an [ELSE].

[r200] 2019-02-16 07:59:01 AntonErtl replies:

requestClarification - [if] and [else] parse white space - including comments

The specification of [IF] is clear:

parse and discard space-delimited words from the parse area [...], until either the word [ELSE] or the word [THEN] has been parsed and discarded.

So \ and ( and everything else except [ELSE] and [THEN] will just be discarded (with [IF] increasing a nesting counter in addition). No clarification for \ needed in the normative text. If you think that users need a clarification, you can put it in your system's documentation, in a contribution here, or you can propose a change to the Rationale of [IF], [ELSE], and/or [THEN]

[r201] 2019-02-16 11:49:51 GerryJackson replies:

requestClarification - [if] and [else] parse white space - including comments

When 0 [IF] is scanning for [ELSE] then a string containing [IF] [ELSE] or [THEN] will cause a problem e.g.

0 [if] s" [else] or [then] follow [if]"

will either underflow due to the OR or fail to recognise FOLLOW (unless FOLLOW is defined. of course).