,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2020-06-21 09:31:29  MarekBrunda  wrote:
| comment - There is error in testing
| see: https://forth-standard.org/standard/core/SMDivREM#contribution-138
`------------------------------------------
This line:
T{      -7 S>D              3 SM/REM ->  1      -2 }T

should be:
T{      -7 S>D              3 SM/REM ->  -1      -2 }T


,---------.
| Replies |
`---------´


,------------------------------------------
| 2020-06-11 07:00:33  ruv  replies:
| 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#reply-376
`------------------------------------------
I like this idea. The `F>R` and `FR>` words can be useful to implement the `DESCRIPTOR-COMPOSITE ( td*i i -- td-new )` [word](https://forth-standard.org/standard/intro#reply-375).


,------------------------------------------
| 2020-06-11 12:24:07  ruv  replies:
| proposal - Recognizer RfD rephrase 2020
| see: https://forth-standard.org/proposals/recognizer-rfd-rephrase-2020#reply-377
`------------------------------------------
### Terms definitions

to **create a token descriptor** (informally): to create an implementation dependent *token descriptor object* producing its identifier or producing a named definition that returns this identifier.
(see other terms at GitHub/ForthHub/[fep-recognizer](https://github.com/ForthHub/fep-recognizer/blob/master/terms-and-datatypes.md))

### An approach to create any token descriptor

If we will add one special predefined descriptor, we will be able to express any possible semantics for the token descriptors, without providing a reproducing or a postponing action.

This descriptor should describe a token that is a pair of xt: `( xt-interpret xt-compile )`. Let's call it `TD-DUAL` for a while.

And let's consider an example: the [string literals](https://gist.github.com/ruv/67134d5eb0493969520f77d3f89f85d5#file-string-literal-via-recognizer-fth) (see the `parse-slit-end` definition there). The old recognizer: `rec-sliteral ( c-addr1 u1 -- c-addr2 u2 rectype-slit|rectype-slit-parsing | 0 )`

The new one:

```
\ Create the token descriptor for a token ( c-addr u  xt-interp xt-compil )
td-slit td-dual 2 descriptor constant td-slit-parsing

\ A helper that returns the second part of the fully qualified token
: token-slit-parsing ( -- xt-interp xt-compil td-slit-parsing ) ['] parse-slit-end  [: parse-slit-end slit, ;]   td-slit-parsing ;

\ The recognizer for a string literal: a lexeme that starts with '"' (quote)
: recognize-sliteral ( c-addr1 u1 -- c-addr2 u2 td-slit | c-addr2 u2 xt-interp xt-compil td-slit-parsing | 0 )
  dup 0= if nip exit then
  over c@ '"' <> if 2drop 0 exit then
  1 /string dup 0= if token-slit-parsing exit then
  \ todo: fail if '"' is found in the middle of the string (c-addr1 u1)
  2dup + char- c@ '"' = if char- td-slit exit then
  token-slit-parsing
;
```

NB: we have to provide neither a reproducing action nor a postponing action. `POSTPONE "abc"` works as expected.

`POSTPONE "x` **can** work in the same way as `POSTPONE S"` — i.e., to append the compilation semantics for the corresponding lexeme. And the compilation semantics for `"x` is to parse characters up to `"`, prepend the result string with "x " and compile this united string. Although, I don't sure it has a practical application. If supported, it should work in this way from conceptual point of view, but it is not obligated to be supported.



### Automation of POSTPONE action 

StephenPelc [wrote](https://forth-standard.org/standard/intro#reply-368):

> We cannot predict how recognisers will be used, so attempting to automate the POSTPONE actions is doomed to failure. 

I know only one case when POSTPONE action cannot be automated:  a special behavior that Anton suggested when `POSTPONE` is applied to a local variable, namely that `POSTPONE local-x` should be equivalent to `local-x POSTPONE LITERAL`, that is `local-x LIT,`.  Actually, this behavior violates the specification for `POSTPONE`, that should append the **compilation semantics** for `local-x` in this case.  And the only reason for this violation is to seamlessly use of local variables inside `]] ... [[` construct (in the simplest implementation).

Could somebody provide a correct POSTPONE action that cannot be automated?



,------------------------------------------
| 2020-06-22 16:56:58  AntonErtl  replies:
| comment - There is error in testing
| see: https://forth-standard.org/standard/core/SMDivREM#reply-378
`------------------------------------------
confirmed