RfD: Synonyms

11 views
Skip to first unread message

Peter Knaggs

unread,
Jul 11, 2007, 12:49:04 PM7/11/07
to forth200x
Stephen Pelc, 21 August 2006

20060922 Enhanced current practice section.
Fixed some typos.
20060821 First draft.


Rationale
=========
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
synonym FACILITY EXT

( "<spaces>newname" "<spaces>oldname" -- )
For both strings kip 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:
The word newname is parsed by ' or ['] or POSTPONE.
oldname is not found.
IMMEDIATE is used for a word defined by SYNONYM.

Labelling
=========
TBD

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
;

Test Cases
==========
TBD

Anton Ertl

unread,
Jul 14, 2007, 12:31:20 PM7/14/07
to
Peter Knaggs <pkn...@bournemouth.ac.uk> writes:
>Solution
>--------
...

> SYNONYM <newname> <oldname>
>where <newname> will behave identically to <oldname>.
...

>Proposal
>========
>10.6.2.xxxx SYNONYM
>synonym FACILITY EXT
>
>( "<spaces>newname" "<spaces>oldname" -- )
>For both strings kip 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:
> The word newname is parsed by ' or ['] or POSTPONE.

If OLDNAME can be ticked or POSTPONEd (BTW, you missed [COMPILE]),
then NEWNAME will not behave identical to OLDNAME if it has this
restriction.

Actually NEWNAME would not be a proper Forth word. I am strongly
against standardizing a defining word that would create such broken
words.

Moreover, this ambiguous condition is completely unnecessary. It's
not easy (but possible) to define SYNONYM without that restriction
portably, but for each system, it is relatively easy to define a
SYNONYM without that restriction. E.g., for the classical
single-xt-plus-immediate-flag systems, an implementation of a proper
SYNONYM would look like this:

: synonym ( "newname" "oldname" -- )
: bl word find dup if ( xt n )
>r compile, POSTPONE ; ( R: n )
r> 0> if
immediate
then
else
-13 throw
then ;

This works for all words on a single-xt+immediate systems, except for
words that access the return stack.

I also gave you another variant of this word at the last Forth200x
meeting; that variant is easier to adapt to also support return stack
words.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/

Gerry

unread,
Jul 14, 2007, 4:03:20 PM7/14/07
to
On 11 Jul, 17:49, Peter Knaggs <pkna...@bournemouth.ac.uk> wrote:

<snip>

>> Ambiguous conditions:
> The word newname is parsed by ' or ['] or POSTPONE.
> oldname is not found.
> IMMEDIATE is used for a word defined by SYNONYM.
>

If newname doesn't behave in exactly the same way as the oldname,
including ' etc and being immediate then this definition is not a lot
of good and likely to lead to errors.

Also why not throw exception -13 "Undefined word" if oldname is not
found.

Gerry

Ed

unread,
Jul 15, 2007, 12:46:52 AM7/15/07
to

"Peter Knaggs" <pkn...@bournemouth.ac.uk> wrote in message news:46950A00...@bournemouth.ac.uk...
> ...

As no substantive change has been made since the last time
this was posted, I'll restate the case for AKA.

Like SYNONYM, competing word AKA has considerable
common practice being used in Forth Inc products since
early days. It is used in the form:

AKA <oldname> <newname>

AKA uses name ordering which is optimum and avoids
the hide/reveal machinations required by SYNONYM.
AKA is much easier to spell and shorter to type.

Ed

unread,
Jul 15, 2007, 1:37:29 AM7/15/07
to

"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184443400.2...@n2g2000hse.googlegroups.com...

> On 11 Jul, 17:49, Peter Knaggs <pkna...@bournemouth.ac.uk> wrote:
>
> <snip>
>
> >> Ambiguous conditions:
> > The word newname is parsed by ' or ['] or POSTPONE.
> > oldname is not found.
> > IMMEDIATE is used for a word defined by SYNONYM.
> >
>
> If newname doesn't behave in exactly the same way as the oldname,
> including ' etc and being immediate then this definition is not a lot
> of good and likely to lead to errors.

Those were included to avoid incompatibility with existing
implementations. At least one major vendor's synonyms
have differing xt's. Yes, it's a theoretical limitation but for
the vast majority of apps, it [apparently] has caused no problem.

The statement about immediate only refers to what happens
should IMMEDIATE be applied to a synonym that was already
immediate. On some systems this can result in the synonym
being made non-immediate; on others it's a no-op.

Gerry

unread,
Jul 15, 2007, 4:31:47 AM7/15/07
to
On 15 Jul, 06:37, "Ed" <nos...@invalid.com> wrote:
> "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in messagenews:1184443400.2...@n2g2000hse.googlegroups.com...

> > On 11 Jul, 17:49, Peter Knaggs <pkna...@bournemouth.ac.uk> wrote:
>
> > <snip>
>
> > >> Ambiguous conditions:
> > > The word newname is parsed by ' or ['] or POSTPONE.
> > > oldname is not found.
> > > IMMEDIATE is used for a word defined by SYNONYM.
>
> > If newname doesn't behave in exactly the same way as the oldname,
> > including ' etc and being immediate then this definition is not a lot
> > of good and likely to lead to errors.
>
> Those were included to avoid incompatibility with existing
> implementations. At least one major vendor's synonyms
> have differing xt's. Yes, it's a theoretical limitation but for
> the vast majority of apps, it [apparently] has caused no problem.
>

I think that introducing a new word into a standard should make the
specification for that word as good as possible, not simply capture
and perpetuate the imperfections of existing implementations. As it
stands the definition of SYNONYM is a lie, newname is not necessarily
a synonym.


> The statement about immediate only refers to what happens
> should IMMEDIATE be applied to a synonym that was already
> immediate. On some systems this can result in the synonym
> being made non-immediate;

Then those are poor implementations and should be improved to meet the
ANS specification for IMMEDIATE.

> on others it's a no-op.

As it should be

Gerry

Anton Ertl

unread,
Jul 15, 2007, 1:01:00 PM7/15/07
to
"Ed" <nos...@invalid.com> writes:
>
>"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184443400.2...@n2g2000hse.googlegroups.com...
>> On 11 Jul, 17:49, Peter Knaggs <pkna...@bournemouth.ac.uk> wrote:
>>
>> <snip>
>>
>> >> Ambiguous conditions:
>> > The word newname is parsed by ' or ['] or POSTPONE.
>> > oldname is not found.
>> > IMMEDIATE is used for a word defined by SYNONYM.
>> >
>>
>> If newname doesn't behave in exactly the same way as the oldname,
>> including ' etc and being immediate then this definition is not a lot
>> of good and likely to lead to errors.
>
>Those were included to avoid incompatibility with existing
>implementations.

Which existing implementations of SYNONYM cannot tick or POSTPONE
synonyms of words that can be ticked or POSTPONEd?

> At least one major vendor's synonyms
>have differing xt's.

No guarantee about the equality of xts was asked for. I would leave
that open.

>Yes, it's a theoretical limitation but for
>the vast majority of apps, it [apparently] has caused no problem.

How do you know? If I could not tick or POSTPONE ALIASes (and
synonyms are supposedly a proposal for a standard replacement for
ALIASes), a lot of my applications would have problems.

Andrew Haley

unread,
Jul 15, 2007, 2:06:32 PM7/15/07
to
Ed <nos...@invalid.com> wrote:

> As no substantive change has been made since the last time
> this was posted, I'll restate the case for AKA.

> Like SYNONYM, competing word AKA has considerable
> common practice being used in Forth Inc products since
> early days. It is used in the form:

> AKA <oldname> <newname>

I haven't got the Forth Inc source here so this is from memory, but I
thought it was

' <oldname> AKA <newname>

This is a more useful factoring: it can be used with :NONAME, for
example.

Andrew.

Stephen Pelc

unread,
Jul 15, 2007, 3:19:22 PM7/15/07
to
On Sun, 15 Jul 2007 14:46:52 +1000, "Ed" <nos...@invalid.com> wrote:

>Like SYNONYM, competing word AKA has considerable
>common practice being used in Forth Inc products since
>early days. It is used in the form:
>
> AKA <oldname> <newname>
>
>AKA uses name ordering which is optimum and avoids
>the hide/reveal machinations required by SYNONYM.
>AKA is much easier to spell and shorter to type.

And I'll restate the same answer. AKA is used hy several
systems in different ways/notations. Thus, staying with
AKA will break code, which is a very bad thing.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Ed

unread,
Jul 15, 2007, 11:49:03 PM7/15/07
to

"Stephen Pelc" <steph...@mpeforth.com> wrote in message news:469a728d....@192.168.0.50...

> On Sun, 15 Jul 2007 14:46:52 +1000, "Ed" <nos...@invalid.com> wrote:
>
> >Like SYNONYM, competing word AKA has considerable
> >common practice being used in Forth Inc products since
> >early days. It is used in the form:
> >
> > AKA <oldname> <newname>
> >
> >AKA uses name ordering which is optimum and avoids
> >the hide/reveal machinations required by SYNONYM.
> >AKA is much easier to spell and shorter to type.
>
> And I'll restate the same answer. AKA is used hy several
> systems in different ways/notations. Thus, staying with
> AKA will break code, which is a very bad thing.

Given that Forth Inc would have a considerable user base
at least equal to that of others, then I feel AKA deserves
equal consideration.

As for other systems using AKA differently, I don't know
about them. Do these systems even exist now and is it at
all relevent given Forth Inc's dominance. IMO it needs
to be demonstrated that code would be broken before
accepting as an objection.

People are now complaining of technical deficiences in
the SYNONYM proposal. If those limitations are removed,
then someone's SYNONYM will be affected and will
require modification. In that case, it's no longer possible
to argue "common practice". If one technical deficiency
is corrected then why not others, such as poor argument
ordering or difficult to use name.

IMO, SYNONYM is now beyond repair. If there is any real
objection to AKA, then forth should start from scratch and
define a new synonym word.

Ed

unread,
Jul 16, 2007, 12:07:12 AM7/16/07
to

"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184488307.7...@w3g2000hsg.googlegroups.com...

I misunderstood what you were getting at. I never considered that
anyone would seriously define synonyms via CREATE DOES> :(

I agree that synonyms should share immediacy and allow ticking.
However I wouldn't require xt's be the same as it can be difficult
to implement and complicate other functions such as dictionary
pruning.

Gerry

unread,
Jul 16, 2007, 2:45:32 AM7/16/07
to
On 16 Jul, 05:07, "Ed" <nos...@invalid.com> wrote:
> "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in messagenews:1184488307.7...@w3g2000hsg.googlegroups.com...

It must be too early in the morning but I haven't a clue how that
connects with what I said.

>
> I agree that synonyms should share immediacy and allow ticking.
> However I wouldn't require xt's be the same as it can be difficult
> to implement and complicate other functions such as dictionary
> pruning.

I agree about the xt's. Did I imply somewhere that they should be the
same? I didn't mean to.

Gerry

Jonah Thomas

unread,
Jul 16, 2007, 3:40:05 AM7/16/07
to

It used to be, the exception wordset was encouraged but not required. If
you're ready to require standard Forths to have THROW then it makes
sense to require specific throw codes for *some* specific circumstances
and reduce the number of ambiguous conditions.

If you want newname to behave exactly like oldname then on some systems
you have a problem. Certainly there's no portable way to get that result
using standard code. You have to know about each system's internals to
do it.

If we standardised at a lower level ... say we had a word that took an
xt and a name and made a dictionary definition with it.

( S: xt -- ) DEFINES <name>

Something like that. Then you get your perfect synonyms trivially, along
with some other benefits.

Avoiding other new words, it could be written something like:

: SYNONYM ( "oldname" "newname" -- )
BL WORD FIND
DUP 0= 13 AND THROW
SWAP DEFINES
1+ IF IMMEDIATE THEN ;

I can't expect a new standard to include DEFINES any time soon because
it isn't common practice. So I would like to encourage implementors to
include it so it can become common practice.

We have argued about SYNONYM etc for 20 years because we lack the
underlying machinery to do it in a standard way. DEFINES provides a
clean factor for : etc on some systems. And it can be emulated on any
standard system:

: DEFINES ( xt "name" -- )
CREATE -17 , , DOES> CELL+ @ EXECUTE ;

: CHANGE-XT ( xt -- xt' )
DUP >BODY @ -17 = IF
DUP >BODY CELL+ @ TUCK - IF RECURSE THEN
THEN ;
\ only works on systems that don't throw an error
\ when attempting >BODY on a nonCREATEd word.

: '
' CHANGE-XT ;
: [']
' POSTPONE LITERAL ; IMMEDIATE

And similarly for every other word that looks up a dictionary entry and
returns an xt. If there's one word like PARSE-WORDLIST that all the
others use, it could go in that one.

This approach wouldn't be terribly efficient but I believe it would be
portable except for modifying the interpreter. I'm not sure there isn't
still some gotcha beyond that, but I don't see it right now.

Anton Ertl

unread,
Jul 16, 2007, 4:32:37 AM7/16/07
to
Jonah Thomas <j2th...@cavtel.net> writes:
>Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
>> Peter Knaggs <pkna...@bournemouth.ac.uk> wrote:
>>
>> <snip>
>>
>> >> Ambiguous conditions:
>> > The word newname is parsed by ' or ['] or POSTPONE.
>> > oldname is not found.
>> > IMMEDIATE is used for a word defined by SYNONYM.
>> >
>>
>> If newname doesn't behave in exactly the same way as the oldname,
>> including ' etc and being immediate then this definition is not a lot
>> of good and likely to lead to errors.
>>
>> Also why not throw exception -13 "Undefined word" if oldname is not
>> found.
>
>It used to be, the exception wordset was encouraged but not required. If
>you're ready to require standard Forths to have THROW then it makes
>sense to require specific throw codes for *some* specific circumstances
>and reduce the number of ambiguous conditions.

In the cases where it's easy to do, Forth systems implementing THROW
do THROWs anyway (where the line for "easy" is drawn depends on the
quality of the system and the balance with other considerations, e.g.,
speed).

Anyway, unless we want to enable standard programs that use SYNONYM
with an undefined oldname, I don't see a point in standardizing the
behaviour in this case.

>If we standardised at a lower level ... say we had a word that took an
>xt and a name and made a dictionary definition with it.
>
>( S: xt -- ) DEFINES <name>

That word is traditionally called ALIAS. However, in earlier
discussions portability problems with ALIAS surfaced (e.g., some
systems propagate the immediate flag through the xt and thus through
alias, some don't). DEFINES would have the same problem, unless you
explicity eliminate it. These earlier discussions led to the SYNONYM
proposal. Didn't Stephen write about this in the RfD, or was he not
clear enough?

>Something like that. Then you get your perfect synonyms trivially, along
>with some other benefits.
>
>Avoiding other new words, it could be written something like:
>
>: SYNONYM ( "oldname" "newname" -- )
> BL WORD FIND
> DUP 0= 13 AND THROW
> SWAP DEFINES
> 1+ IF IMMEDIATE THEN ;

That would not work on Gforth. In Gforth, some words (e.g., S") are
not characterized by an XT and an immediate flag alone.

Elizabeth D Rather

unread,
Jul 16, 2007, 5:13:47 AM7/16/07
to
Jonah Thomas wrote:
> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
>> Peter Knaggs <pkna...@bournemouth.ac.uk> wrote:
>>
>> <snip>
>>
>>>> Ambiguous conditions:
>>> The word newname is parsed by ' or ['] or POSTPONE.
>>> oldname is not found.
>>> IMMEDIATE is used for a word defined by SYNONYM.
>>>
>> If newname doesn't behave in exactly the same way as the oldname,
>> including ' etc and being immediate then this definition is not a lot
>> of good and likely to lead to errors.
>>
>> Also why not throw exception -13 "Undefined word" if oldname is not
>> found.
>
> It used to be, the exception wordset was encouraged but not required. If
> you're ready to require standard Forths to have THROW then it makes
> sense to require specific throw codes for *some* specific circumstances
> and reduce the number of ambiguous conditions.

The way Forth94 dances around this is to declare it an ambiguous
condition and reserve a THROW code for it should the implementor choose
to use it. In this case, of course, there's already a perfectly
appropriate THROW code. It should be 'ambiguous'.

> If you want newname to behave exactly like oldname then on some systems
> you have a problem. Certainly there's no portable way to get that result
> using standard code. You have to know about each system's internals to
> do it.

It's perfectly ok for a standard to require things that can't be
implemented in standard code. It is not required that Standard Forth be
written in Standard Forth. There are many things that have to be done
under the table. The consequence, of course, is that it's up to the
implementor to provide it or not, and up to an application writer to
choose whether or not to establish a dependence on it.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Jonah Thomas

unread,
Jul 16, 2007, 9:54:48 AM7/16/07
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Jonah Thomas <j2th...@cavtel.net> writes:
> >Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> >> Peter Knaggs <pkna...@bournemouth.ac.uk> wrote:

> >It used to be, the exception wordset was encouraged but not required.
> >If you're ready to require standard Forths to have THROW then it
> >makes sense to require specific throw codes for *some* specific
> >circumstances and reduce the number of ambiguous conditions.
>
> In the cases where it's easy to do, Forth systems implementing THROW
> do THROWs anyway (where the line for "easy" is drawn depends on the
> quality of the system and the balance with other considerations, e.g.,
> speed).

Yes.



> Anyway, unless we want to enable standard programs that use SYNONYM
> with an undefined oldname, I don't see a point in standardizing the
> behaviour in this case.

It certainly doesn't make sense to do that unless you require systems to
include THROW .

> >If we standardised at a lower level ... say we had a word that took
> >an xt and a name and made a dictionary definition with it.
> >
> >( S: xt -- ) DEFINES <name>
>
> That word is traditionally called ALIAS. However, in earlier
> discussions portability problems with ALIAS surfaced (e.g., some
> systems propagate the immediate flag through the xt and thus through
> alias, some don't). DEFINES would have the same problem, unless you
> explicity eliminate it. These earlier discussions led to the SYNONYM
> proposal. Didn't Stephen write about this in the RfD, or was he not
> clear enough?

I didn't notice any details about that in Peter's RfD. If ALIAS has
contractory common practices, then it makes sense not to use the ALIAS
name. How about

( S: xt 1|-1 -- ) DEFINES <name>

Would it work on most systems if we provide a flag to make it easy to
propagate the immediate flag?

> That would not work on Gforth. In Gforth, some words (e.g., S") are
> not characterized by an XT and an immediate flag alone.

To my way of thinking, this is a bug. Not specificly a Gforth bug, it's
a Forth 94 bug. IMMEDIATE keeps coming back and biting us, over and
over. We've struggled with this for 20+ years. Forth-83 tried to do away
with standard state-smart words because they cause far more trouble than
they're worth. Then Forth-94 introduced S" and it gets in the way just
as much as the old state-smart words did.

I guess I'm ranting. Sorry about that. It's just -- I don't so much mind
that it's all this complex stuff to keep in mind when in theory it's
supposed to be Forth. What I object to is when it looks like a Sudoko
game with no solution at all.

Jonah Thomas

unread,
Jul 16, 2007, 10:00:44 AM7/16/07
to
Elizabeth D Rather <erath...@forth.com> wrote:
> Jonah Thomas wrote:

> > If you want newname to behave exactly like oldname then on some
> > systems you have a problem. Certainly there's no portable way to get
> > that result using standard code. You have to know about each
> > system's internals to do it.
>
> It's perfectly ok for a standard to require things that can't be
> implemented in standard code.

Of course that's OK. It's *better* when things can be written in
standard code, because then anybody can port them to systems where the
implementors haven't bothered. It makes things more portable.

So I like it when you can do things with standard code, and I like it a
bit less when you can't, but it's still OK when it has to go that way. I
think it's worth noting when the standard code implementation works out.

Stephen Pelc

unread,
Jul 16, 2007, 12:45:49 PM7/16/07
to
On Mon, 16 Jul 2007 13:49:03 +1000, "Ed" <nos...@invalid.com> wrote:

>"Stephen Pelc" <steph...@mpeforth.com> wrote in message news:469a728d....@192.168.0.50...

>> And I'll restate the same answer. AKA is used hy several
>> systems in different ways/notations. Thus, staying with
>> AKA will break code, which is a very bad thing.
>
>Given that Forth Inc would have a considerable user base
>at least equal to that of others, then I feel AKA deserves
>equal consideration.

There are incompatible definitions of AKA. Past practice
has been to give new names to avoid code breakage, of
which 0= and NOT leading to INVERT is the most (in)famous
example. This is IMHO still the best practice.

>IMO, SYNONYM is now beyond repair. If there is any real
>objection to AKA, then forth should start from scratch and
>define a new synonym word.

You're welcome.

Ed

unread,
Jul 17, 2007, 9:19:09 AM7/17/07
to

"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184568332.4...@n2g2000hse.googlegroups.com...

> On 16 Jul, 05:07, "Ed" <nos...@invalid.com> wrote:
> > ...

> > I misunderstood what you were getting at. I never considered that
> > anyone would seriously define synonyms via CREATE DOES> :(
>
> It must be too early in the morning but I haven't a clue how that
> connects with what I said.

IIRC you objected to the proposal's restrictions that a synonym couldn't
be ticked and it won't have the same immediacy as the original name.

These limitations are necessary if SYNONYM is implemented via
CREATE DOES> ... which apparently some forths do.

The proposal claims to accomodate all known usage of SYNONYM.
Were the restrictions to be removed then that will no longer be true,
leaving some forths with a non-conforming SYNONYM.

Ed

unread,
Jul 17, 2007, 10:23:00 AM7/17/07
to

"Stephen Pelc" <steph...@mpeforth.com> wrote in message news:469b9ffe....@192.168.0.50...

> On Mon, 16 Jul 2007 13:49:03 +1000, "Ed" <nos...@invalid.com> wrote:
>
> >"Stephen Pelc" <steph...@mpeforth.com> wrote in message news:469a728d....@192.168.0.50...
> >> And I'll restate the same answer. AKA is used hy several
> >> systems in different ways/notations. Thus, staying with
> >> AKA will break code, which is a very bad thing.
> >
> >Given that Forth Inc would have a considerable user base
> >at least equal to that of others, then I feel AKA deserves
> >equal consideration.
>
> There are incompatible definitions of AKA. Past practice
> has been to give new names to avoid code breakage, of
> which 0= and NOT leading to INVERT is the most (in)famous
> example. This is IMHO still the best practice.

That practice was conditional on there being a real potential
for conflict. Consider the case of NOT. According to recent
posts it was confirmed the ANS TC's intention was to reinstate
79-NOT once 83-NOT usage had lapsed.

Ed

unread,
Jul 17, 2007, 11:15:51 AM7/17/07
to

"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184488307.7...@w3g2000hsg.googlegroups.com...

> On 15 Jul, 06:37, "Ed" <nos...@invalid.com> wrote:
> ...

> > The statement about immediate only refers to what happens
> > should IMMEDIATE be applied to a synonym that was already
> > immediate. On some systems this can result in the synonym
> > being made non-immediate;
>
> Then those are poor implementations and should be improved to meet the
> ANS specification for IMMEDIATE.

The ANS spec only talks about making words immediate - not what
would happen if one applied IMMEDIATE to a word that was already
immediate (which IMO should be ambiguous).

Stephen Pelc

unread,
Jul 17, 2007, 12:03:49 PM7/17/07
to
On Wed, 18 Jul 2007 00:23:00 +1000, "Ed" <nos...@invalid.com> wrote:

>That practice was conditional on there being a real potential
>for conflict. Consider the case of NOT. According to recent
>posts it was confirmed the ANS TC's intention was to reinstate
>79-NOT once 83-NOT usage had lapsed.

This practice hasn't gone away yet!

Jerry Avins

unread,
Jul 17, 2007, 4:22:55 PM7/17/07
to

Why ambiguous? Why not IMMEDIATE? It is better for IMMEDIATE to turn on
the "immediate" bit than to toggle it.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

George Hubert

unread,
Jul 18, 2007, 3:45:08 AM7/18/07
to
On 15 Jul, 06:37, "Ed" <nos...@invalid.com> wrote:
> "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in messagenews:1184443400.2...@n2g2000hse.googlegroups.com...

There's also a problem where oldname isn't immediate and
IMMEDIATE is used on newname; on some systems where the
2 words share the same xt then both words are now
immediate, because the immediacy is a property of the
xt, rather than the name (systems than use dual compile
and execute xts for one).

George Hubert

Gerry

unread,
Jul 18, 2007, 5:19:55 AM7/18/07
to
On 17 Jul, 14:19, "Ed" <nos...@invalid.com> wrote:
> "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in messagenews:1184568332.4...@n2g2000hse.googlegroups.com...

I see. So those Forths that create a synonym using CREATE DOES>
presumably would at least permit users to make the synonym immediate
by the use of IMMEDIATE if the old name was immediate and they wished
new name to also be immediate. The proposal for SYNONYM states that
using IMMEDIATE on the new name is ambiguous so it is not even
following existing usage.

Gerry

Jonah Thomas

unread,
Jul 18, 2007, 10:21:10 AM7/18/07
to
Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> "Ed" <nos...@invalid.com> wrote:

> > The proposal claims to accomodate all known usage of SYNONYM.
> > Were the restrictions to be removed then that will no longer be
> > true, leaving some forths with a non-conforming SYNONYM.
>
> I see. So those Forths that create a synonym using CREATE DOES>
> presumably would at least permit users to make the synonym immediate
> by the use of IMMEDIATE if the old name was immediate and they wished
> new name to also be immediate. The proposal for SYNONYM states that
> using IMMEDIATE on the new name is ambiguous so it is not even
> following existing usage.

They don't want to standardise it until it's existing practice.
Standardising things that look like a good idea but that people don't
already do, tends to lead to things that have bugs or that people still
won't do. See for example ENVIRONMENT? which was a good idea, but which
nobody uses. If you could depend on Forth systems to use it well then
you could use it for porting. But there's a strong chance the Forth your
code gets ported to won't give you any useful information, and it's an
effort to write code *now* that might be useful for porting *later*, and
it mostly just sits there.

There might be people using SAVE-INPUT and RESTORE-INPUT but I don't
notice it. Those words let you get a whole lot more control of your
input buffer, but mostly only inside a single file. When you need them
they aren't sufficient.

So, the idea is to standardise existing practice. But at the same time,
if everybody already did the practice the same way we wouldn't need to
standardise it -- we'd already have everybody doing it the same way.

And when people are doing things different ways we don't want to tell
some of them that they're nonstandard. So rather than decide which way
will be standard and hope the offending versions are changed, we instead
simply warn users not to do the things that give varying results.

What good is it?

Well, if a new technique is just starting to spread, if it's obviously
good but not used all that much yet, standardising it at that point can
both publicise the method and also inhibit other versions. Forth-94 did
that some. The loops with multiple WHILEs were new and good, although it
turns out that people generally find code that uses them is less
readable. CATCH/THROW was very good. ALLOCATE . Having a standard locals
syntax was good although mostly nobody uses it. EVALUATE went a long way
toward cleaining up the QUERY input buffer mess. AHEAD gave the last
step for building new control structures in standard ways. I don't see
new control structures that need it, but it's *possible* now.
CELLS/CHARS gives portability across word size and ALIGN ports across
alignment.

There are lots of good things that Forth-94 provided that probably
wouldn't have spread as fast or as portably without the standard. It
missed out on DEFER and SYNONYM and some other things that were already
present in multiple versions then.

The choice now is to declare them standard and tell users not to do the
things that different versions do differently, OR standardise one
behavior with a new name, OR provide lower-level tools that let people
build it however they want, OR accept the status quo.

Jonah Thomas

unread,
Jul 18, 2007, 10:38:49 AM7/18/07
to
George Hubert <george...@yahoo.co.uk> wrote:
> "Ed" <nos...@invalid.com> wrote:

> > The statement about immediate only refers to what happens
> > should IMMEDIATE be applied to a synonym that was already
> > immediate. On some systems this can result in the synonym
> > being made non-immediate; on others it's a no-op.
>
> There's also a problem where oldname isn't immediate and
> IMMEDIATE is used on newname; on some systems where the
> 2 words share the same xt then both words are now
> immediate, because the immediacy is a property of the
> xt, rather than the name (systems than use dual compile
> and execute xts for one).

I want to point out yet again that IMMEDIATE has been biting us for *20+
years* and we still haven't gotten rid of it.

So far, the best alternative I've seen is like the proposed
cross-compiler standard. When you aren't cross-compiling, make HOST =
TARGET .

Interpreting in HOST, execute HOST/TARGET words.
Compiling in HOST, execute COMPILER words and compile HOST words.
Compiling in COMPILER, compile HOST words and what to do with COMPILER
words is an advanced topic that nobody has to think about until they
want to extend the compiler.

Of course there would be more to it than that, but for application
programmers who do not modify the compiler, all of the complications
vanish. That's the most important thing.

John Doty

unread,
Jul 18, 2007, 12:56:39 PM7/18/07
to
Jonah Thomas wrote:

> I want to point out yet again that IMMEDIATE has been biting us for *20+
> years* and we still haven't gotten rid of it.

Why get rid of it? STOIC, LSE, MAGIC/L, and Colorforth (and probably
others) have all gotten real mileage out of embracing it and
generalizing it. It's a lot of what makes a Forth a language rather than
just a code generation program.

--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
Specialization is for robots.

Jonah Thomas

unread,
Jul 18, 2007, 2:58:37 PM7/18/07
to
John Doty <j...@whispertel.LoseTheH.net> wrote:
> Jonah Thomas wrote:
>
> > I want to point out yet again that IMMEDIATE has been biting us for
> > *20+ years* and we still haven't gotten rid of it.
>
> Why get rid of it? STOIC, LSE, MAGIC/L, and Colorforth (and probably
> others) have all gotten real mileage out of embracing it and
> generalizing it. It's a lot of what makes a Forth a language rather
> than just a code generation program.

The particular ways that it's been done bites us practically every time
we want to add a portable compiler extension.

You might have a good way, or at least an adequate way to do it.
Forth-94 does not.

John Doty

unread,
Jul 18, 2007, 3:10:14 PM7/18/07
to
Jonah Thomas wrote:

> You might have a good way, or at least an adequate way to do it.
> Forth-94 does not.

Hardly matters what "it" is...

Jonah, you're a smart guy. Why not cut that anchor chain and sail free?

Coos Haak

unread,
Jul 18, 2007, 3:56:08 PM7/18/07
to
Op Wed, 18 Jul 2007 10:21:10 -0400 schreef Jonah Thomas:

> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
>> "Ed" <nos...@invalid.com> wrote:
>
>>> The proposal claims to accomodate all known usage of SYNONYM.
>>> Were the restrictions to be removed then that will no longer be
>>> true, leaving some forths with a non-conforming SYNONYM.
>>
>> I see. So those Forths that create a synonym using CREATE DOES>
>> presumably would at least permit users to make the synonym immediate
>> by the use of IMMEDIATE if the old name was immediate and they wished
>> new name to also be immediate. The proposal for SYNONYM states that
>> using IMMEDIATE on the new name is ambiguous so it is not even
>> following existing usage.
>
> They don't want to standardise it until it's existing practice.
> Standardising things that look like a good idea but that people don't
> already do, tends to lead to things that have bugs or that people still
> won't do. See for example ENVIRONMENT? which was a good idea, but which
> nobody uses. If you could depend on Forth systems to use it well then
> you could use it for porting. But there's a strong chance the Forth your
> code gets ported to won't give you any useful information, and it's an
> effort to write code *now* that might be useful for porting *later*, and
> it mostly just sits there.
>
> There might be people using SAVE-INPUT and RESTORE-INPUT but I don't
> notice it. Those words let you get a whole lot more control of your
> input buffer, but mostly only inside a single file. When you need them
> they aren't sufficient.

I certainly do not agree, these are meaningful parts of for implementing of
INCLUDE-FILE, LOAD[*] and EVALUATE and I've used this for years. This way
you can nest loading of files, blocks, strings in every conceivable order
and return in an orderly way.
And have look at Win32Forth, it's using the same constructs.
Gforth does too, but in a somewhat convoluted way.

[*] yes, i use block files sometimes, only to have a feeling how they work,
and trying low level access to floppies.

>
> So, the idea is to standardise existing practice. But at the same time,
> if everybody already did the practice the same way we wouldn't need to
> standardise it -- we'd already have everybody doing it the same way.
>
> And when people are doing things different ways we don't want to tell
> some of them that they're nonstandard. So rather than decide which way
> will be standard and hope the offending versions are changed, we instead
> simply warn users not to do the things that give varying results.
>
> What good is it?
>
> Well, if a new technique is just starting to spread, if it's obviously
> good but not used all that much yet, standardising it at that point can
> both publicise the method and also inhibit other versions. Forth-94 did
> that some. The loops with multiple WHILEs were new and good, although it
> turns out that people generally find code that uses them is less
> readable. CATCH/THROW was very good. ALLOCATE . Having a standard locals
> syntax was good although mostly nobody uses it. EVALUATE went a long way
> toward cleaining up the QUERY input buffer mess. AHEAD gave the last
> step for building new control structures in standard ways. I don't see
> new control structures that need it, but it's *possible* now.
> CELLS/CHARS gives portability across word size and ALIGN ports across
> alignment.
>
> There are lots of good things that Forth-94 provided that probably
> wouldn't have spread as fast or as portably without the standard. It
> missed out on DEFER and SYNONYM and some other things that were already
> present in multiple versions then.
>

I use DEFER.
SYNONYM I can handle with ALIAS, but there seems no need for it.
Perhaps this: SYNONYM SCHLIEßE-DATEI CLOSE-FILE

> The choice now is to declare them standard and tell users not to do the
> things that different versions do differently, OR standardise one
> behavior with a new name, OR provide lower-level tools that let people
> build it however they want, OR accept the status quo.

OK. (Seems to have a Dutch origin, M. van Buren ?)
--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

Jonah Thomas

unread,
Jul 18, 2007, 6:47:47 PM7/18/07
to
Coos Haak <chf...@hccnet.nl> wrote:
> schreef Jonah Thomas:

> > There might be people using SAVE-INPUT and RESTORE-INPUT but I don't
> > notice it. Those words let you get a whole lot more control of your
> > input buffer, but mostly only inside a single file. When you need
> > them they aren't sufficient.
>
> I certainly do not agree, these are meaningful parts of for
> implementing of INCLUDE-FILE, LOAD[*] and EVALUATE and I've used this
> for years. This way you can nest loading of files, blocks, strings in
> every conceivable order and return in an orderly way.
> And have look at Win32Forth, it's using the same constructs.
> Gforth does too, but in a somewhat convoluted way.

Systems are required to somehow save the input state before doing
INCLUDE-FILE LOAD or EVALUATE and and restore it afterward. There's no
need for systems to use a standard name for that. Users use INCLUDE-FILE
LOAD and EVALUATE and usually have little use for SAVE-INPUT and
RESTORE-INPUT . I'd be glad to be wrong about this, but they've never
quite met my needs and I don't notice others using them either.

> > There are lots of good things that Forth-94 provided that probably
> > wouldn't have spread as fast or as portably without the standard. It
> > missed out on DEFER and SYNONYM and some other things that were
> > already present in multiple versions then.
> >
> I use DEFER.
> SYNONYM I can handle with ALIAS, but there seems no need for it.
> Perhaps this: SYNONYM SCHLIEßE-DATEI CLOSE-FILE

If they had somehow become standard with Forth-83 or Forth-94 then we
wouldn't be having so much trouble trying to standardise them now. But
they never had a high enough priority.

Ed

unread,
Jul 19, 2007, 1:20:49 AM7/19/07
to

"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184750395....@m37g2000prh.googlegroups.com...

> On 17 Jul, 14:19, "Ed" <nos...@invalid.com> wrote:
> > "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in messagenews:1184568332.4...@n2g2000hse.googlegroups.com...
> > > On 16 Jul, 05:07, "Ed" <nos...@invalid.com> wrote:
> > > > ...
> > > > I misunderstood what you were getting at. I never considered that
> > > > anyone would seriously define synonyms via CREATE DOES> :(
> >
> > > It must be too early in the morning but I haven't a clue how that
> > > connects with what I said.
> >
> > IIRC you objected to the proposal's restrictions that a synonym couldn't
> > be ticked and it won't have the same immediacy as the original name.
> >
> > These limitations are necessary if SYNONYM is implemented via
> > CREATE DOES> ... which apparently some forths do.
> >
> > The proposal claims to accomodate all known usage of SYNONYM.
> > Were the restrictions to be removed then that will no longer be true,
> > leaving some forths with a non-conforming SYNONYM.
>
> I see. So those Forths that create a synonym using CREATE DOES>
> presumably would at least permit users to make the synonym immediate
> by the use of IMMEDIATE if the old name was immediate and they wished
> new name to also be immediate.

When implemented via CREATE DOES> newname does not directly
reflect the xt and immediacy of oldname, but only defers it. In fact
all newnames defined will be immediate and their xt will point to
the definer. That's the reason for the restrictions in the proposal
i.e. one can't count on newname having the xt and immediacy of
oldname.

In contrast other implementation methods do produce a newname
that reflects oldname's characteristics and therefore safer to use.

Ed

unread,
Jul 19, 2007, 2:02:18 AM7/19/07
to

"George Hubert" <george...@yahoo.co.uk> wrote in message
news:1184744708.3...@x35g2000prf.googlegroups.com...

The question then becomes - which is more important: having the
same immediacy, or allowing all possible forth implementation
techniques?

This raises a more general issue.

Standardization pulls in one direction and flexibility in the other.
Is there a point at which standards should restrict certain behaviours
lest it end up with a myriad of confusing exclusions and provisos.
We've already seen problems in this area such as the allowing of
multiple division behaviours.

Whose interests are best served - the majority of users who want
a Standard Forth that's predictable and simple to use; or the few
who insist on being catered for. IMO Standard Forth isn't for
everybody, nor should it try to be. There will always be people
who don't want/need Standard Forth and are doing well outside
of it.

Ed

unread,
Jul 19, 2007, 2:44:18 AM7/19/07
to

"Jerry Avins" <j...@ieee.org> wrote in message news:DrKdncp9K6u8uADb...@rcn.net...

> Ed wrote:
> > "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message
news:1184488307.7...@w3g2000hsg.googlegroups.com...
> >> On 15 Jul, 06:37, "Ed" <nos...@invalid.com> wrote:
> >> ...
> >>> The statement about immediate only refers to what happens
> >>> should IMMEDIATE be applied to a synonym that was already
> >>> immediate. On some systems this can result in the synonym
> >>> being made non-immediate;
> >> Then those are poor implementations and should be improved to meet the
> >> ANS specification for IMMEDIATE.
> >
> > The ANS spec only talks about making words immediate - not what
> > would happen if one applied IMMEDIATE to a word that was already
> > immediate (which IMO should be ambiguous).
>
> Why ambiguous? Why not IMMEDIATE? It is better for IMMEDIATE to turn on
> the "immediate" bit than to toggle it.

That's an implementation decision. Whether one *needs to* depends
on whether there's ever a case to apply IMMEDIATE multiple times
to a word. Because there hasn't been, many early forths implemented
IMMEDIATE in the shortest possible way.

BTW I looked it up and ANS simply repeats what '83 and '79 had said
- so it's not as if ANS had changed anything.

Gerry

unread,
Jul 19, 2007, 4:17:08 AM7/19/07
to
On 17 Jul, 14:19, "Ed" <nos...@invalid.com> wrote:
> "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in messagenews:1184568332.4...@n2g2000hse.googlegroups.com...

Hmm I replied to this a day ago but Google appears to have lost it,
apologies if this appears twice.

I see what you mean. So those Forths that use CREATE DOES> for
synomyns would allow the user to carry immediacy through to the new
name by using IMMEDIATE if they wanted to. The proposal makes use of
IMMEDIATE on the new name an ambiguous condition and so is not exactly
following established usage as it claims.

Gerry

Coos Haak

unread,
Jul 19, 2007, 6:08:00 AM7/19/07
to
Op Thu, 19 Jul 2007 16:44:18 +1000 schreef Ed:

No need to blame IMMEDIATE. It was the word SMUDGE that toggled a bit in
the header. And implementers borrowed the procedure.
Of course, I don't have SMUDGE and IMMEDIATE sets the bit ;)

Stephen Pelc

unread,
Jul 19, 2007, 8:38:52 AM7/19/07
to
On Thu, 19 Jul 2007 01:17:08 -0700, Gerry
<ge...@jackson9000.fsnet.co.uk> wrote:

>I see what you mean. So those Forths that use CREATE DOES> for
>synomyns would allow the user to carry immediacy through to the new
>name by using IMMEDIATE if they wanted to. The proposal makes use of
>IMMEDIATE on the new name an ambiguous condition and so is not exactly
>following established usage as it claims.

I think that you are reading far too much into the implementation
given in the proposal. The point of the proposal is that in many
implementations SYNONYM requires carnal knowledge of the underlying
Forth kernel, which is a major reason why it should be standardised.

SYNONYM is current in at least VFX Forth and Win32Forth.

Also, for cross compilers in particular, knowing the target xt
may not be enough, hence SYNONYM parses.

George Hubert

unread,
Jul 19, 2007, 8:50:27 AM7/19/07
to
On 18 Jul, 15:38, Jonah Thomas <j2tho...@cavtel.net> wrote:

SYNONYM works perfectly when you want newname to have the same
semantics as oldname for both interpretation and compilation.
Since IMMEDIATE alters that relationship (assuming oldname
wasn't already an immediate word) then it's not the right
word to be using to have 2 words that behave the same
interpretively, but differ in compilation behaviour.
Since you need to know whether oldname is an immediate word,
in order to know that newname needs the IMMEDIATE then use
of SYNONYM wouldn't be portable between systems where you
want to make a new IMMEDIATE version of a standard name,
however without IMMEDIATE, SYNONYM guarantees that
both compilation and interpretation semantics are the same,
irrespective of what they are, and how they're accomplished.

George Hubert

Ed

unread,
Jul 19, 2007, 11:28:14 PM7/19/07
to

"Ed" <nos...@invalid.com> wrote in message news:f7mum3$oqq$1...@news-01.bur.connect.com.au...

>
> "George Hubert" <george...@yahoo.co.uk> wrote in message
> news:1184744708.3...@x35g2000prf.googlegroups.com...
> > ...

> > There's also a problem where oldname isn't immediate and
> > IMMEDIATE is used on newname; on some systems where the
> > 2 words share the same xt then both words are now
> > immediate, because the immediacy is a property of the
> > xt, rather than the name (systems than use dual compile
> > and execute xts for one).
>
> The question then becomes - which is more important: having the
> same immediacy, or allowing all possible forth implementation
> techniques?
> ...

Thinking further on this. There may be a better reason to disallow
the application of IMMEDIATE to an alias - on the grounds that
it detracts from the intent of aliases and promotes confusion.

An alias is meant to provide an alternative name for an existing
function. Creating an alias and then altering its behaviour is at
best a trick designed to save a few bytes; at worst it's bad
programming style.

Here's an example. Which of the following is most direct and
to the point? Which is the least?

: CASE 0 ; IMMEDIATE

0 CONSTANT CASE IMMEDIATE

SYNONYM CASE FALSE IMMEDIATE ( * )

Just because one can do something doesn't mean it's necessarily a
good thing.

( * This also demonstrates the poor argument ordering of SYNONYM.
In the example it is less than clear whether CASE or FALSE was being
made immediate. Both AKA and ALIAS have <newname> last and
therefore don't suffer this obfuscation.)

Reply all
Reply to author
Forward
0 new messages