[119] 2019-10-01 18:34:20 AntonErtl wrote:

referenceImplementation - Reference implementation of SYNONYM

The existing reference implementation is broken (it produces STATE-smart words). Here's a one that works (in recent Gforth snapshots):

: s-to ( val nt -- )
  >body @ (to) ;
opt: ( xt -- )
  ?fold-to >body @ ]] literal (to) [[ ;

: s-defer@ ( xt1 -- xt2 )
  >body @ defer@ ;
opt: ( xt -- )
   ?fold-to >body @ ]] literal defer@ [[ ;

defer synonym-prototype
[: >body @ compile,     ;] set-optimizer
[: >body @ name>interpret ;] set->int
[: >body @ name>compile   ;] set->comp
' s-to set-to
' s-defer@ set-defer@

: synonym ( "name" "oldname" -- )
    ``synonym-prototype create-from  
    ?parse-name find-name dup 0= -13 and throw
    dup compile-only? if compile-only then
    , reveal ;

This implementation obviously uses a lot of system-specific stuff (you can read about that in "The new Gforth Header" in the EuroForth 2019 proceedings), but in general, system-specific stuff is necessary for implementing SYNONYM.

This SYNONYM not only implements inheritance of interpretation and compilation semantics, but almost everything else: That a word can have TO, DEFER@, or DEFER! applied to it, as well as its code generator. Things that a synonym defined with the SYNONYM above does not inherit are the nt (they are necessarily different in order for NAME>STRING to work), and you cannot apply DOES> or any of the SET-... words to the SYNONYM of a word and have it affect the original (for most SET-... words, this produces the expected result, but for DOES> and SET-DOES>, it does not).

[120] 2019-10-01 18:41:26 AntonErtl wrote:

testcase - Test cases for SYNONYM

t{ synonym my-+ + -> }t
t{ 1 2 my-+ -> 3 }t
t{ 1 2 ' my-+ ]execute[ -> 3 }t
t{ : comp-my+ postpone my-+ ; -> }t
t{ : ya-+ [ comp-my+ ] ; -> }t
t{ 1 2 ya-+ -> 3 }t

These test cases fail with the existing reference implementation (showing that this implementation is incorrect), and succeeds with the proposed reference implementation.

[r336] 2019-09-24 13:26:38 StephenPelc replies:

proposal - Right-justified text output

Committee response

This was discussed at the standards meeting. Our conclusions are

We can't vote on this until it is a proper proposal, which should include common practice

The committee felt that the proposal is unlikely to pass

The code is simple to implement, and is more of a "Wouldn't It Be Nice If" than satisfying a real need.

Stephen Pelc