Digest #156 2021-06-28
Contributions
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
referenceImplementation - Possible Reference Implementation
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.
referenceImplementation - Possible Reference Implementation
I prefer your first implementation over the other two options. It seems like it would be the most efficient on many systems.
referenceImplementation - Portable implementation for SYNONYM
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), 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).
So, presently a portable definition for synonym should take into account these circumstances concerning R-related words.
referenceImplementation - Portable implementation for SYNONYM
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).
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.
: 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 ( "\<spaces\>newname" "\<spaces\>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 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.
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.