Digest #156 2021-06-28
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.
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.
I prefer your first implementation over the other two options. It seems like it would be the most efficient on many systems.
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
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.
: >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.
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.
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.