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>.
( "<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 ;
Peter Knaggs <pkna...@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.
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.
> 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. > ...
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.
> >> 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.
> > >> 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.
>> >> 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.
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.
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, stephen...@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
"Stephen Pelc" <stephen...@mpeforth.com> wrote in message news:469a728d.297146515@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.
> > > >> 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
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.
> > > > >> 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
> 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.
> 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 <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.
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:
: 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.
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.
Jonah Thomas <j2tho...@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.
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." ==================================================
an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Jonah Thomas <j2tho...@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 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.
On Mon, 16 Jul 2007 13:49:03 +1000, "Ed" <nos...@invalid.com> wrote: >"Stephen Pelc" <stephen...@mpeforth.com> wrote in message news:469a728d.297146515@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.
Stephen
-- Stephen Pelc, stephen...@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
"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184568332.408872.223070@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.
"Stephen Pelc" <stephen...@mpeforth.com> wrote in message news:469b9ffe.374315187@192.168.0.50... > On Mon, 16 Jul 2007 13:49:03 +1000, "Ed" <nos...@invalid.com> wrote:
> >"Stephen Pelc" <stephen...@mpeforth.com> wrote in message news:469a728d.297146515@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.
"Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184488307.713440.192910@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).
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!
Stephen
-- Stephen Pelc, stephen...@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 wrote: > "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in message news:1184488307.713440.192910@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.
Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
> > >> 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.
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).
> "Gerry" <ge...@jackson9000.fsnet.co.uk> wrote in messagenews:1184568332.408872.223070@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. The proposal for SYNONYM states that using IMMEDIATE on the new name is ambiguous so it is not even following existing usage.
|
