,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2019-03-03 06:20:52 kc5tja wrote: | proposal - F>R and FR> to support dynamically-scoped floating point variables | see: https://forth-standard.org/proposals/f-r-and-fr-to-support-dynamically-scoped-floating-point-variables#contribution-75 `------------------------------------------ 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: ```forth 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. ,---------. | Replies | `---------´ ,------------------------------------------ | 2019-02-15 18:51:47 BerndPaysan replies: | requestClarification - [if] and [else] parse white space - including comments | see: https://forth-standard.org/standard/tools/BracketELSE#reply-199 `------------------------------------------ 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]```. ,------------------------------------------ | 2019-02-16 07:59:01 AntonErtl replies: | requestClarification - [if] and [else] parse white space - including comments | see: https://forth-standard.org/standard/tools/BracketELSE#reply-200 `------------------------------------------ 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] ,------------------------------------------ | 2019-02-16 11:49:51 GerryJackson replies: | requestClarification - [if] and [else] parse white space - including comments | see: https://forth-standard.org/standard/tools/BracketELSE#reply-201 `------------------------------------------ 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).