,---------------.
| Contributions |
`---------------´
,------------------------------------------
| 2021-06-27 15:30:11 NieDzejkob wrote:
| comment - Mistake in implementation?
| see: https://forth-standard.org/standard/double/TwoVALUE#contribution-204
`------------------------------------------
I believe that the usage of `POSTPONE 2LITERAL` here is a mistake. The literal that needs to be postponed is an address, so `POSTPONE LITERAL` seems to be the correct word to use here.
,---------.
| Replies |
`---------´
,------------------------------------------
| 2021-05-22 08:21:49 AntonErtl replies:
| referenceImplementation - Possible Reference Implementation
| see: https://forth-standard.org/standard/string/DivSTRING#reply-696
`------------------------------------------
Gforth, iForth, lxf, SwiftForth 3.11, and VFX 5.11 do not check for n<=u; so if n>u, the result is broken (I explored whether you could do something useful with strings with negative length, but did not come up with anything). I dimly remember that there are systems where /STRING behaves like OVER MIN /STRING, so the resulting string is always valid, but I don't remember which systems behave that way.
,------------------------------------------
| 2021-05-24 14:56:22 JimPeterson replies:
| referenceImplementation - Possible Reference Implementation
| see: https://forth-standard.org/standard/string/DivSTRING#reply-697
`------------------------------------------
I prefer your first implementation over the other two options. It seems like it would be the most efficient on many systems.
,------------------------------------------
| 2021-06-12 13:32:48 ruv replies:
| referenceImplementation - Portable implementation for SYNONYM
| see: https://forth-standard.org/standard/tools/SYNONYM#reply-698
`------------------------------------------
One problem with this definition for `synonym` is that in some cases it produces incorrect synonyms for the words that may change or access the return stack (R-related words), like `exit`, `>r`, `r@`, `i`, etc.
This definition for `synonym` assumes that if `find` returns _n_ value `-1` in interpretation sate, then the word is an ordinary word (according to [the clarification](https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-682)), and it can be redefined as an ordinary colon-definition.
In some systems `find` returns _n_ value `-1` in interpretation state for some R-related words, but an R-related word cannot be redefined as an ordinary word.
E.g, `: >r ( x -- ) >r ;` is an incorrect re-definition. So this `synonym` will create an incorrect synonym in such case.
I think, the standard should restrict the systems in such a way that it's impossible for `find` to return _n_ value `-1` in interpretation state for R-related words. But it's another discussion (see also "R-related words definition" sub-thread in comp.lang.forth ([google-groups](https://groups.google.com/g/comp.lang.forth/c/U0XhM-TDZV0/m/wSeUe-DQCAAJ)).
So, presently a portable definition for `synonym` should take into account these circumstances concerning R-related words.
,------------------------------------------
| 2021-06-12 13:43:19 ruv replies:
| referenceImplementation - Portable implementation for SYNONYM
| see: https://forth-standard.org/standard/tools/SYNONYM#reply-699
`------------------------------------------
The specification for `SYNONYM` doesn't require that the execution semantics for _newname_ are the same as for _oldname_ (if the latter are defined). But it looks like just an omission.
So the implementation bellow also guarantees that the execution semantics for _newname_ are to perform the execution semantics for _oldname_ (if they are defined).
This implementation relies on the full-fledged `FIND` (according to the [proposal](https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-682
)).
Also, this implementation takes into account that in some Forth systems `FIND` returns _n_ value `-1` in interpretation state for some R-related words, and makes a workaround for that.
If `POSTPONE` in the system correctly appends the compilation semantics of a user-defined STATE-dependent immediate word, then it correctly works for the words created by this `SYNONYM` too. Otherwise the system has the corresponding environmental restriction, and a program should obey to [a99-027](https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/xDvW74uzi30J/).
```
: fix-r-words-maybe< ( "name1 name2 ... nameN" -- )
begin >in @ bl word dup count nip 0= if 2drop exit then ( c-addr-in c-addr-name )
find -1 <> if 2drop else drop ( c-addr-in ) \ redefine only in the case of n=-1
dup >r >in ! : \ : oldname postpone oldname ; immediate
r> >in ! postpone postpone postpone ; immediate
\ NB: the implementation defined interpretation semanics for a redefined R-related word
\ are lost for the sake of a poor POSTPONE implementation.
then
again
;
fix-r-words-maybe< exit recurse itself
fix-r-words-maybe< >r r@ rdrop r> 2>r 2r@ 2rdrop 2r> n>r nr>
fix-r-words-maybe< i j unloop leave
[undefined] lit, [if]
: lit, ( x -- ) postpone literal ;
[then]
: error-no-interp ( -- ) -14 throw ;
: compilation ( -- flag ) state @ 0<> ;
: synonym ( "newname" "oldname" -- )
: \ start compilation of the new definition for newname
bl word \ parse oldname
\ find oldname in interpretation state
dup >r postpone [ find ] \ NB: revert compilation state
\ if oldname is not found in interpretation state,
\ then provide a replacement, since it can still be found in compilation state
dup 0= if 2drop ['] error-no-interp 1 then ( xt1 n1 ) ( R: c-addr )
\ if n1=-1, then the word is ordinary, it's the simplest case
\ : newname [xt1] ;
-1 = if compile, postpone ; r> drop exit then ( xt1 )
\ otherwise, find oldname in compilation state (that is the current state)
r> find dup 0= -13 and throw 1 = if \ n1=1 n2=1 ( xt1 xt2 )
\ if xts are the same, the word is immediate, create a wrapper
\ : newname [xt1] ; immediate
2dup = if drop compile, postpone ; immediate exit then
\ otherwise, create an immediate word using both xt-s
\ : newname compilation if [xt2] exit then [xt1] ; immediate
2>r postpone compilation postpone if ( R: xt1 xt2 )
r> compile, postpone exit postpone then
r> compile, postpone ; immediate exit
then \ n1=1 n2=-1 - it could be something like "leave"
\ create a possibly dual-semantics word as
\ : newname compilation if xt2 compile, exit then [xt1] ; immediate
2>r postpone compilation postpone if ( R: xt1 xt2 )
r> lit, postpone compile, postpone exit postpone then
r> compile, postpone ; immediate
;
```
-----
A side note.
We have a [proposal](https://forth-standard.org/proposals/tighten-the-specification-of-synonym-version-1-) for a more advanced `SYNONYM` that also guarantees that _newname_ have the same "TO _oldname_" run-time semantics, "IS _oldname_" run-time semantics, "defined by CREATE" property, "defined by DEFER" property, etc, if they have place for _oldname_.
It's difficult to make all these requirements formally consistent, they produce changes in many other glossary entries of the standard, and it can be difficult to implement them in some Forth systems. So a more simple `SYNONYM` could be good enough option at the present time.
,------------------------------------------
| 2021-06-24 16:37:28 JimPeterson replies:
| proposal - The value of STATE should be restored
| see: https://forth-standard.org/proposals/the-value-of-state-should-be-restored#reply-700
`------------------------------------------
```
The best that we could do now is to DEFER CATCH and THROW.
```
Are CATCH and THROW compatible with DEFER! / DEFER@ ? I have concerns about reserving resources that won't be released with the given specification for CATCH/THROW, but those concerns would be alleviated if I could interject code via hooks into standard CATCH/THROW mechanics.
Simply redefining CATCH/THROW would be problematic, of course, given that previous code might already have the older definitions baked in, and could surround redefined versions... The more I think about it, the more I believe the standard should prohibit (or at least discourage) redefinitions of CATCH and THROW.