Programmers

[ ] 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.

Change history

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.