Synonym

[ RfDs/CfVs | Other proposals ]

Poll standings

See below for voting instructions.
Systems
[ ] conforms to ANS Forth.
bigForth
VFX Forth
MPE Forth Cross Compilers
iForth
SwiftForth
SwiftX Cross Compilers
Win32Forth
[ ] already implements the proposal in full since release [ ]:
VFX Forth (since 1998)
MPE Forth Cross Compiers (since 1999)
Win32Forth (since releae 1)
[ ] implements the proposal in full in a development version:
bigForth
[ ] will implement the proposal in full in release [ ].
bigForth 2.4.0
4tH 3.60.1
[ ] will implement the proposal in full in some future release.
iForth
SwitfForth
SwitfX Cross Compilers
[ ] There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full:
Programmers
[ ] I have used (parts of) this proposal in my programs:
Graham Smith
Bernd Paysan
Stephen Pelc
Marcel Hendrix
George Hubert
Michael D. Morris
[ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it:
Josh Grams
Leon Wagner
Michael D. Morris
Gerry Jackson
[ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard:
Josh Grams
Leon Wagner
Michael D. Morris
Gerry Jackson
[ ] I would not use (parts of) this proposal in my programs.
Hans Bezemer
Bruce R. McFarling
Informal results
Maybe some extra ambiguous conditions must be defined. I won't implement this proposal until it has gotten some serious thought.

Problem

Various words have been used to generate a new name for an existing word. This required when porting code and when generating application wordlists that contain a reference to an existing word, e.g. when providing limited access to Forth system kernel words.

Especially with native code compiling Forth systems and cross compilers, these words have not provided full access to the required behaviour. The behaviour may require carnal knowledge of the underlying system, which is one reason why SYNONYM should be standardised.

Current practice

The proposed form SYNONYM has been in use at MPE with cross compilers and VFX Forth since 1998. It is also implemented in Win32Forth and PFE.

Many people have suggested that we stay with words such as AKA, ALIAS or ALIAS:, usually of the form 

' oldname ALIAS newname
This has merit in terms of common practice, but will break code for several systems. Some systems, e.g. cross compilers, cannot generate enough information using the xt of a word alone. All surveyed systems can implement SYNONYM.

Solution

Although many people have objected to parsing words, parsing permits the host system the most flexibility in implementation and is thus the preferred solution. The syntax is: 
  SYNONYM <newname> <oldname>
where <newname> will behave identically to <oldname>. Note that <newname> may be the same as <oldname>.

Proposal

10.6.2.xxxx SYNONYM                                    FACILITY EXT
                                                          X:synonym
( "<spaces>newname" "<spaces>oldname" -- )
For both strings skip leading space delimiters. Parse name delimited by a space. definition for newname with the semantics defined below. Newname may be the same as oldname.

newname interpretation: ( i*x -- j*x )
Perform the interpretation semantics of oldname

newname compilation: ( i*x -- j*x )
Perform the compilation semantics of oldname

Ambiguous conditions:
oldname is not found.
IMMEDIATE is used for a word defined by SYNONYM.

Reference Implementation

The implementation of SYNONYM requires carnal knowledge of the host implementation, which is one reason why it should be standardised. The implementation below is imperfect and specific to VFX Forth. 
: Synonym	\ <"new-name"> <"curdef"> --
\ *G Create a new definition which redirects to an existing one.
  create immediate
    hide  ' ,  reveal
  does>
    @  state @ 0=  over immediate? or
    if  execute  else  compile,  then
;

Change history

2008-09-26
Updated ambiguous conditions.
2006-09-22
Enhanced current practice section.
Fixed some typos.
2006-08-21
First draft.

Voting instructions

Fill out the appropriate ballot(s) below and mail it/them to <vote@forth200x.org>. Your vote will be published (including your name (without email address) and/or the name of your system) here. You can vote (or change your vote) at any time, and the results will be published here.

Note that you can be both a system implementor and a programmer, so you can submit both kinds of ballots.

Ballot for systems
If you maintain several systems, please mention the systems separately in the ballot. Insert the system name or version between the brackets. Multiple hits for the same system are possible (if they do not conflict).
[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.
[ ] There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
If you want to provide information on partial implementation, please do so informally, and I will aggregate this information in some way.
Ballot for programmers
Just mark the statements that are correct for you (e.g., by putting an "x" between the brackets). If some statements are true for some of your programs, but not others, please mark the statements for the dominating class of programs you write.
[ ] I have used (parts of) this proposal in my programs.
[ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it.
[ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard.
[ ] I would not use (parts of) this proposal in my programs.
If you feel that there is closely related functionality missing from the proposal (especially if you have used that in your programs), make an informal comment, and I will collect these, too. Note that the best time to voice such issues is the RfD stage.

Credits

Proponent: Stephen Pelc
Votetaker: Peter J Knaggs