SYNONYM

( "<spaces>newname" "<spaces>oldname" -- )

For both strings skip leading space delimiters. Parse newname and oldname delimited by a space. Create a definition for newname with the semantics defined below. Newname may be the same as oldname; when looking up oldname, newname shall not be found.

An ambiguous conditions exists if oldname can not be found or IMMEDIATE is applied to newname.

newname interpretation:

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

newname compilation:

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

See:

Implementation:

The implementation of SYNONYM requires detailed knowledge of the host implementation, which is one reason why it should be standardized. The implementation below is imperfect and specific to VFX Forth, in particular HIDE, REVEAL and IMMEDIATE? are non-standard words.

: SYNONYM \ "newname" "oldname" --
\ 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
;

ContributeContributions

GerryJacksonavatar of GerryJackson Incomplete specification of SYNONYMComment2016-11-22 10:02:04

Shouldn't the synonym of a word inherit the restrictions of the parent word. For example

SYNONYM NEW-TO TO

' NEW-TO \ Is apparently valid because it isn't forbidden whereas

' TO \ Is an ambiguous condition

Also this is not forbidden and would be rather confusing

SYNONYM TO TO

' TO

All that it needs is to add a sentence such as:

All ambiguous conditions applying to oldname, also apply to newname.

AntonErtlavatar of AntonErtl 2016-12-08 09:43:19

Good point.

Other, less urgent issues are inheritance of TO <name> semantics, and inheritance of the property of being a child of a CREATEd word. Any other issues?

AntonErtlavatar of AntonErtl 2016-12-08 14:33:37

Once the "child-of-CREATE" property can be inherited (for >BODY), we need to specify if the following is standard and what it does:

: foo does> drop ." foo" ; : bar does> drop ." bar" ; create a foo synonym b a bar a

We did not standardize using IMMEDIATE on a synonym, should we allow using DOES>?

GerryJacksonavatar of GerryJackson 2016-12-09 08:57:19

That's an interesting point. Your example works on my system, as does the following variation:

: foo does> drop ." foo" ;
create a foo
a                         \ Displays foo
: bar does> drop ." bar" ;
synonym a a
a                         \ Displays foo
bar a                     \ Displays bar
foo a                     \ Displays foo

Where bar is defined after a is created. If this usage is deemed standard it provides a way of changing the action of a create ... does> word retrospectively without the need for defer. This is something I have wanted to do in the past. It works on GForth too.

If nothing else ISTM that this could be useful when debugging. For example, during development : could be redefined to generate a create does> drop ... definition. When something goes wrong synonym could be used to alter a word's action to provide debugging information without having to recompile the system. I've not tried it but I don't see in principle why it wouldn't work. So I would support standardising the use of does> for synonyms.

As noted recently on comp.lang.forth is for deferred words also needs to be considered and probably defer@ and defer!.

GerryJacksonavatar of GerryJackson 2016-12-09 11:00:57

I was a bit premature with my suggestion - it only works on my system. If my example is amended to include a definition calling a before the use of synonym i.e.

: foo does> drop ." foo" ;
create a foo
: baz a ; baz                        \ Displays foo
: bar does> drop ." bar" ;
synonym a a
bar baz                              \ Displays bar on my system but not on GForth

bar Modifies the behaviour of baz on my system but not GForth or VFX Forth.

In your original example:

: foo does> drop ." foo" ; : bar does> drop ." bar" ; create a foo synonym b a bar a

VFX Forth bar doesn't change the behaviour of a or band so is different compared to Gforth. Win32 Forth is different as it crashes. So four systems with four different behaviours using does> on synonyms.

AntonErtlavatar of AntonErtl 2016-12-09 11:10:06

I guess my example works (as in "does not produce an error") in many systems, but what is the effect? Is A changed or is it not? Do we want to standardize one of these behaviours, or not. One reason not to guarantee changing A is that it disallows optimizing DOES>. E.g.,

: method create ... does> ... ;
method draw
: foo ... draw ... ;

Here the compiler can inline DRAW. That's no longer possible if DRAW can be changed later.

Currently only interpretation and compilation semantics is copied by SYNONYM, so the property of being defined by CREATE is not guaranteed to be copied, and the example is non-standard.

Yes, synonyms of DEFERed words is another good point.

Another issue: Consider

wordlist constant W1
wordlist constant W2
W1 set-current create A1
W2 set-current
W1 >order synonym A2 A1
:noname name>string type true ; W2 traverse-wordlist

Will this output A2 or A1? It seems to me that a basic invariant for traverse-wordlist is that, if you SEARCH-WORDLIST for the name produced by NAME>STRING in the traversed wordlist, you will find a word with that name, so it should output A2.

JennyBrienavatar of JennyBrien 2016-12-11 20:32:42

If you make a synonym of a word with private data (e.g. a VALUE, a DEFER, or something with CREATE DOES>) then the two words share that data. Any change in the original is reflected in the synonym. If you don't want that, then instead you create a new instance with the same defining word.

So, if that is what you want, do you also need words like TO and IS to be applicable to the synonym as to the original?

That's fairly easy for user-defined definers, I think: All you need do is state that ticking or FINDing a synonym returns the xt of the original. But I think we've already decided not to go that route, and Synonyms may return a different xt from their originals. In any case, the xt of a DEFER or a VALUE is no use for changing the data, so all the Standard data - setting words might have to be modified to allow for the possibility of synonyms.

In short, a Synonym has the same interpretation and compilation behaviour of the original, affecting the same internal data. Any other behaviour that the original may have result from it being defined using a particular defining word, and are not inherited by the synonym.

JennyBrienavatar of JennyBrien 2016-12-11 20:42:18

"Will this output A2 or A1? It seems to me that a basic invariant for traverse-wordlist is that, if you SEARCH-WORDLIST for the name produced by NAME>STRING in the traversed wordlist, you will find a word with that name, so it should output A2."

Of course. A synonym may have the same xt as the original, but I don't see how it could have the same name token and still be a different word.

GerryJacksonavatar of GerryJackson 2016-12-11 21:17:31

I don't think optimisation should be a significant driver in the functionality of a word - it may help swing the balance in some cases.

What do we mean by synonym? Given synonym B A

  1. is B a snapshot or clone of A that then has a future independent of what happens to A or
  2. is B a reference to A so that it shadows whatever happens to A
  3. or something in between.

Cloning is easy and doesn't require the use of synonym so meaning 2 should be the desired aim.

We have identified issues with values, deferred words, children of create ... does> ... words, inheritance of ambiguous conditions, and possibly wordlists.

Dealing with the latter first, I don't see what the issue is in your example - A2 is clearly defined in wordlist W2, the invokation of traverse-wordlist is only looking in W2 so why would anybody argue that A1 whould be displayed?

Putting that aside and considering synonym B A again:

For synonyms of colon definitions, variables and constants it seems clear that if A is later redefined then B still refers to the old definition of A as the alternative would go against Forth tradition.

For values the question is whether to A affects the value of both A and B or A alone. Similarly to B. If we want consistency with variables and constants then to A should change the value of both A and B and that is what I would expect.

The situation with deferred words doesn't seem so clear. It could be argued that if the action of A is changed by is or defer! then that is equivalent to redefinition of A and so should not change the action of B, and vice versa. Alternatively it could be argued that A is not really being redefined, it is more like a variable or value being changed and the change in behaviour is incidental, so both A and B should remain in step. I would favour the latter.

For children of create ... does> it seems to me that the best argument is that after A has been created and there have been later definitions then the action of A cannot be changed by an execution of does>. Defining synonym B A is such a later definition which should, therefore prevent the action of A being changed by does>. My feeling is that we should probably make applying does> to a synonym either ambiguous or forbid it. Changing the action of A could easily lead to obscure bugs in a program. Of course the same could be said for deferred words.

JennyBrienavatar of JennyBrien 2016-12-12 20:20:37

For values the question is whether to A affects the value of both A and B or A alone. Similarly to B. If we want consistency with variables and constants then to A should change the value of both A and B and that is what I would expect.

I agree with that, but the question I was asking was rather:

Given Value A Synonym B A Is TO B guaranteed to work?

I think it would naturally for a flag-setting TO but it may fail on some systems with a parsing TO,

Perhaps the most logical way to think of a Synonym is that it creates a header that returns the same values for NAME>INTERPRET and NAME>COMPILE as the original. (I'm not saying this is the only way it can be done, but it is a way that the Standard allows - I think).

These are the only values (apart from the NAME) that a Standard application can derive from the dictionary structure.

They are also set by:

DOES> associates the xt with an action that uses the data space address that it previously returned IMMEDIATE sets the compilation action to execute the xt COMPILES> (or SET-COMPILER whatever else we decide to set a particular non-default compiliation action.)

In each case they can only be set for the current definition, and are invariant once that definition is complete.

Given this a synonym is an exact substitute for the original, with the same Standard behaviour in all situations. For example, if the original can be ticked, then ticking the synonym returns the same xt. If ticking the original is an ambiguous condition, then a Standard program cannot tick the synonym, it may or may not respond in the same fashion as the the original (which may for example have been marked as 'compile-only') but that is beyond the scope of he Standard.

It doesn't seem to make much sense to combine SYNONYM with any of the other behaviour-setting words, because that implies you want something other than a synonym - something that can be provided in other ways:

Synonym B A DOES> C probably wouldn't work, or would change the definition of A, but the intention can be achieved by:

' A >BODY CONSTANT D : B D C ;

Synonym B A IMMEDIATE is trivially : B A ; IMMEDIATE

And these definitions, not being synonyms of the original, do not share its xt.

Where A is defined by a user-defined CREATE …DOES> word (there must be a shorter way of saying that) any word that uses >BODY to manipulate its data will naturally also work on its synonym, which returns the same data and therefore references the same data.

I'm assuming that words manipulate DEFER and the like (which need not use CREATE … DOES>) also access their data solely through their xt and therefore will work for a synonym that return the same xt. It's possible that IS, TO etc. need access to some other information in the dictionary header, so SYNOYNYM would need to be smart enough to build the appropriate header for words defined by each of the Standard defining words.

That's another reason why the definition of SYNONYM is implementation-dependent, but I can't quite believe that any implementation would do things in such a roundabout way.

ruvavatar of ruv 2016-12-13 12:10:12

People, don't you think that GitHub/ForthHub is more more convenient for such discussions?

GerryJacksonavatar of GerryJackson 2016-12-13 20:21:46

@JennyBrien

For values the question is whether to A affects the value of both A and B or A alone. Similarly to B. If we want consistency with variables and constants then to A should change the value of both A and B and that is what I would expect.

I agree with that, but the question I was asking was rather:

I was responding to Anton's message and hadn't seen yours before I submitted mine. I think we were writing a reply at the same time!

Given Value A Synonym B A Is TO B guaranteed to work?

Yes I think so.

I think it would naturally for a flag-setting TO but it may fail on some systems with a parsing TO,

The standard insists on a parsing to, see the specification for to, so we don't need to consider that.

As regards the rest of your reply I think I agree with much of it. My system, which has detached headers, simply provides the same xt for both B and A for synonym B A so anything that is done to A or B is done to both whether by does> to is or defer!. And that seems reasonable to me although I wouldn't object to does> being forbidden.

Actually I've just thought of another issue that would break my system, I think, and that is if we have the sequence

create A
\ Possibly more definitions etc but no application of DOES> to A
: X  does> ...  ;
synonym B A  X

i.e. A is not a create ... does> word. This may be a good reason for banning does>

@ruv I don't mind where the discussion is held. This site was set up specifically for the Forth 200X standard with a provision for comments, and so it is not unreasonable to have a discussion here.

JennyBrienavatar of JennyBrien 2016-12-14 20:35:29

The standard insists on a parsing to, see the specification for to, so we don't need to consider that.

It insists that a parsing TO be allowed - so the name must always follow directly, without another word or line break in between as is possible with a non - parsing TO.

As regards the rest of your reply I think I agree with much of it. My system, which has detached headers, simply provides the same xt for both B and A for synonym B A so anything that is done to A or B is done to both whether by does> to is or defer!. And that seems reasonable to me although I wouldn't object to does> being forbidden.

Actually I've just thought of another issue that would break my system, I think, and that is if we have the sequence

create A
 \ Possibly more definitions etc but no application of DOES> to A
: X  does> ...  ;
synonym B A  X

i.e. A is not a create ... does> word. This may be a good reason for banning does>

Either way, I think what happens here is that both A and B are set to do X. That is definitely a bad idea: the definition of a word (in this case A) should not change after it has been used - unless of course it's a Deferred word, where you state at the outset that that's your intention.

This case is covered. B has not been defined using CREATE, so the code is already non - Standard.

AntonErtlavatar of AntonErtl 2016-12-31 22:02:53

On optimization: Stroustroup had a design rule when developing C++: a new language feature should not slow down the implementation of other, previously existing language features; if we follow this rule (and it sounds pretty sensible for a language like Forth), SYNONYM should not slow down the implementation of DOES>.

In particular, the ability to change a CREATEd word later (after having used it or already changed it once with DOES>) is something that is rarely used in Forth, and changing it through a synonym is likely to be used even more rarely; if it is really desired, this functionality can already be achieved with, e.g., DEFERred words. So the ability to change a CREATEd word later through a synonym would cost performance without gaining capability, and, in nearly all cases not even convenience.

[As an aside, this whole issue is another fallout of the design of CREATE...DOES> of having a word first and changing its behaviour later, which also makes problems in connection with flash-based Forth systems and with having an intelligent COMPILE,; a better design would fix the behaviour at creation time, which would avoid all three problems.]

Clone or reference: This plays a role for mutable words like variables, values, and deferred words. It seems to me that the intention is to be a reference; this is already clear for variables (executing the xt must give the same address), but for values and deferred words the specification is not yet specific enough to make that airtight.

However, when it comes to NAME>STRING, we want the synonym to have it's own name and therefore it needs its own nt; that's the issue the A1 A2 example points out. In some systems (especially some that want to have NT=XT) the most straightforward implementation of SYNONYM might produce the same NT for A1 and A2, and then the output of W2 TRAVERSE-WORDLIST might be A1. Implementations of SYNONYM that get this right will either deviate from the NT=XT dogma or will incur some complications when implementing TO, IS, ACTION-OF, DEFER@, DEFER!, and >BODY.

Overall, the consensus for a tightened synonym seems to be:

  • The synonym inherits the properties of being defined by CREATE or DEFER, and any ambiguous conditions about ticking and POSTPONEing from the original.

  • Concerning DOES>, one must not apply that to a synonym, like IMMEDIATE.

  • TO, IS, ACTION-OF, DEFER@, DEFER!, >BODY are allowed on the synonym if they are allowed on the original, and produce the same results for the synonym as for the original.

  • NAME>STRING produces the name of the original for the original, and the name of the synonym for the synonym.

  • NAME>INTERPRET and NAME>COMPILE: if they produce the same values for the synonym as for the original, the DEFER@ DEFER! >BODY, and probably also TO, IS, ACTION-OF issues fall out for free. But I don't think we need to require that; if some system wants to produce different values, what's the harm (apart from the fact that it probably has a more complicated implementation of the words mentioned above)?

Did I forget anything?

Reply

GerryJacksonavatar of GerryJackson Tighten the specification of SYNONYM (version 1)Proposal2018-06-08 10:09:18

Problem

Since SYNONYM has been incorporated into the Forth 2012 standard a number of use cases have been discussed that can result in different Forth 2012 systems giving different results. Therefore the specification for SYNONYM needs to be tightened to either specify the results of those cases or to make them ambiguous conditions. This RfD addresses those use cases and proposes solutions.

Terminology: in this RfD given this definition: SYNONYM BAR FOO FOO will be referred to as the original word, BAR as the synonym.

The guiding principle in this RfD is one of 'least surprise to the user'. Following use of SYNONYM a reasonable user expectation is that the synonym can be used in exactly the same way as the original word: the functionality and usage of them should be identical, the same operations should be applicable to them and they should have the same restrictions on usage.

Six aspects of the use of SYNONYM have identified that need to be clarified in the standard.

1) Restrictions (ambiguous conditions).

Given SYNONYM NEW-TO TO then ' NEW-TO is not designated an ambiguous condition by the standard whereas ' TO is

This particular example demonstrates that a synonym should inherit all the restrictions placed on the original word.

2) Values (VALUE, 2VALUE and FVALUE)

Given 123 VALUE FOO SYNONYM BAR FOO The view of the current Forth 2012 committee is that: 456 TO BAR is not permitted by the standard. but of course 456 TO FOO is permitted which may or may not result in FOO and BAR containing the same value.

Contrast this with synonyms of variables where storing a new value in a variable can be done on either the original word or the synonym and, in either case, their contents remain identical.

Therefore the guiding principle indicates that it should be legal for TO to be applied to the synonym of a value and that the values of the original word and its synonym should remain in step whichever word is updated using TO.

3) Deferred Words

Given DEFER FOO SYNONYM BAR FOO

As with TO above, writing ( xt ) IS BAR is not allowed whereas ( xt ) IS FOO is permitted and executing FOO is not guaranteed to give the same result as executing BAR

Similarly there are problems with DEFER!, DEFER@ and ACTION-OF ' some-word ' BAR DEFER! ' BAR DEFER@ and ACTION-OF BAR are invalid as BAR was not defined by DEFER

After ' some-word ' FOO DEFER! FOO and BAR are not guaranteed to hold the same xt

The guiding principle indicates it should be legal for IS, DEFER@, DEFER! and ACTION-OF to be applied to the synonym of a deferred word and for the XTs held by the synonym and original deferred word to be kept in step following the use of IS or DEFER! on either the synonym or original deferred word.

4) CREATE and >BODY

Given CREATE FOO SYNONYM BAR FOO should ' FOO >BODY and ' BAR >BODY give the same result?

At present ' BAR >BODY is an ambiguous condition since BAR was not defined directly via CREATE

This violates the guiding principle. Therefore >BODY should work on the synonym and the result should be the same address as for >BODY on the original word.

5) CREATE and DOES>

Given : DOESER DOES> ... ; CREATE FOO (zero or more definitions) SYNONYM BAR FOO DOESER should the use of DOESER be valid and, if so, should it operate on both FOO and BAR?

The current position in the standard is that it is invalid as it violates the rule that DOES> operates on the previous definition which has to have been CREATE'd.

If there are no definitions between CREATE FOO and SYNONYM BAR FOO then in some systems it is possible for DOES> to change the behaviour of both FOO AND BAR. But, in the general case if not impossible, that would cause severe implementation difficulties.

Therefore the guiding principle should be ignored in this case and applying DOES> to a synonym should be an ambiguous condition.

6) NAME>STRING

Given : FOO ... ; SYNONYM BAR FOO

TRAVERSE-WORDLIST will produce a name token for FOO and BAR. What result should NAME>STRING give for the name tokens of FOO and BAR?

In this case it seems clear that applying NAME>STRING on:

  • FOO's name token should be "FOO"
  • BAR's name token should be "BAR" Any other result would be surprising (remember that FOO and BAR may be in different wordlists)

Solution

Follow the recommendations listed in the Problem section above. See the proposal below.

Remarks

NAME>INTERPRET and NAME>COMPILE: if they produce the same values for the synonym as for the original, the DEFER@ DEFER! >BODY, and probably also TO, IS, ACTION-OF issues fall out for free. But identical xts are not required

SYNONYM is already forbidden on locals due to the prohibition on definitions inside a colon definition. But that could usefully be noted in a rationale.

Some of the proposed changes could be regarded as bad practice e.g. changing the synonym of a deferred word also changes the original word could be regarded as a hidden side effect, but this already possible with synonyms of variables and Forth is a sharp knife ...

Banning DOES> on a synonym of a CREATEd word is similar to banning IMMEDIATE in that both alter the characteristics of the preceding definition.

Reference Implementation

Not applicable - requires detailed knowledge of the system

Test Cases

1 VALUE val

T{ SYNONYM synval val -> }T

T{ val synval -> 1 1 }T

2 TO val

T{ synval -> 2 }T

T{ 3 TO synval -> }T

T{ val synval -> 3 3 }T

\ Similarly for 2VALUE and FVALUE

DEFER def :NONAME 4 ; IS def

T{ SYNONYM syndef def -> }T

T{ def syndef -> 4 4 }T

T{ :NONAME 5 ; IS syndef }T

T{ def syndef -> 5 5 }T

:NONAME 6 ; CONSTANT defxt

T{ defxt ' syndef DEFER! -> }T

T{ def syndef -> 6 6 }T

T{ ' syndef DEFER@ ' def DEFER@ -> defxt DUP }T

T{ ACTION-OF syndef -> defxt }T

CREATE cre

T{ SYNONYM syncre cre -> }T

T{ ' cre >BODY ' syncre >BODY = -> TRUE }T

\ Testing NAME>STRING is complicated by the facts that:

\ - TRAVERSE-WORDLIST is the only way to get a name token

\ - the order of nt's provided by TRAVERSE-WORDLIST is undefined

\ - names may be stored in the dictionary in upper or lower case

\ If anyone can suggest a simpler test please post it

WORDLIST CONSTANT synwl

GET-ORDER synwl SWAP 1+ SET-ORDER DEFINITIONS

CREATE n>s1

SYNONYM syn-n>s1 n>s1

PREVIOUS DEFINITIONS

: >lower ( ch -- ch' )

DUP 'A' 'Z' 1+ WITHIN IF BL OR THEN ;

\ Case independent string comparison

: i$= ( caddr1 u1 caddr2 u2 -- f ) \ f = TRUE if strings are equal

ROT OVER <> IF DROP 2DROP FALSE EXIT THEN

0 ?DO

    OVER C@ >lower OVER C@ >lower <>

    IF 2DROP FALSE UNLOOP EXIT THEN

    CHAR+ SWAP CHAR+

 LOOP 2DROP TRUE

;

: get-name ( nt -- caddr u true ) NAME>STRING TRUE ;

: check-names ( caddr1 u1 caddr2 u2 -- f1 f2 )

DUP 4 > IF 2SWAP THEN ( -- "syn-n>s1" "n>s1" )

S" n>s1" i$= >R

S" syn-n>s1" i$= R>

;

T{ ' get-name synwl TRAVERSE-WORDLIST check-names -- TRUE TRUE }T

\ Can't test DOES> on a synonym as there is no portable way to test ambiguous conditions`

Experience

GForth 0.7.9_20171101, VFX Forth 4.72, author's personal system run all test cases Win32 Forth 6.15.04 runs the test cases except for NAME>STRING (not implemented) SwiftForth 3.7.2 hasn't implemented SYNONYM Other systems not tried.

Proposal

In the Forth 2012 Standard document make the following amendments:

Section 15.6.2.2264 SYNONYM

If oldname was created by VALUE, 2VALUE, FVALUE or DEFER then the value held by newname shall be identical to that held by oldname at all times even if TO, IS or DEFER! is applied, as appropriate, to oldname or newname.

If oldname was defined using DEFER then DEFER@ and ACTION-OF applied to oldname shall produce the same xt as DEFER@ and AACTION-OF applied to newname

If oldname was created by CREATE then ' newname >BODY shall result in the same address as that given by ' oldname >BODY.

NAME>STRING shall produce the name of newname/oldname when applied to the name token of newname/oldname respectively.

All ambiguous conditions applicable to oldname shall apply to newname.

An ambiguous condition shall exist if DOES> is applied to newname.

Section 6.2.2295 TO

Amend the end of the Interpretation: and Compilation: paragraphs to read ... if name was not defined by a word with "TO name run time" semantics or the synonym of such a word.

Section 6.2.1725 IS

Amend the end of the Interpretation: and Compilation: paragraphs to read ... if name was not defined by DEFER or the synonym of such a word.

Sections 6.2.1175 DEFER! and 6.2.1177 DEFER@

Amend the end of the first paragraph to read ... word defined by DEFER or the synonym of such a word.

Section 6.2.0698

Amend the end of the Interpretation and Compilation paragraphs to read ... not defined by DEFER or the synonym of such a word, or if ...

Section 6.1.0550 >BODY

Amend the end of the description to read ... defined via CREATE or the synonym of such a word.

BerndPaysanavatar of BerndPaysan 2018-06-08 12:03:52

For the test cases: Since we have a proposal for FIND-NAME to produce NTs, you can use FIND-NAME as test vehicle.

A reference implementation of FIND-NAME using TRAVERSE-WORDLIST should be available in the FIND-NAME proposal soon (Anton is wrong that FIND-NAME-IN requires carnal knowledge).

JennyBrienavatar of JennyBrien 2018-06-11 13:24:32

So either quoting a synonym returns the original xt or >BODY etc. are aware of synonyms and do the necessary adjustment?

What happens when you make a synonym of another synonym?

BerndPaysanavatar of BerndPaysan 2018-06-13 20:18:38

This should pass (does so in Gforth):

create foo
synonym bar foo
t{ ' foo -> ' foo }t
synonym baz bar
t{ ' baz -> ' foo }t

No, >body and friends should not know anything about synonyms. The only place where synonym deserve special attention is in name>compile and name>interpret. Since this proposal is to tighten down synonym, it's better to make clear that it mandates where the treatment of synonyms has to happen.

BerndPaysanavatar of BerndPaysan 2018-06-13 20:19:59

Can I have an edit button?

First test shall be

t{ ' bar -> ' foo }t

GerryJacksonavatar of GerryJackson 2018-06-14 16:23:09

For the test cases: Since we have a proposal for FIND-NAME to produce NTs, you can use FIND-NAME as test vehicle

Yes that certainly simplifies things. The test for FIND-NAME of synonyms then becomes (i$= the case independent compare is still needed):

CREATE n>s1
SYNONYM syn-n>s1 n>s1
T{ S" n>s1" 2DUP FIND-NAME NAME>STRING i$= -> TRUE }T
T{ S" syn-n>s1" 2DUP FIND-NAME NAME>STRING i$= -> TRUE }T

GerryJacksonavatar of GerryJackson 2018-06-14 16:30:36

First test shall be: t{ ' bar -> ' foo }t

This requires the xt's to be the same, Anton didn't think that was necessary - I don't mind either way

AntonErtlavatar of AntonErtl 2018-06-15 17:39:24

Letting all synonyms have the same xt is certainly a good solution. Should we require it? I don't know a reason for or against (in particular, I don't think that there is a system that has SYNONYM where synonyms of the same word have different xts), so in the spirit of tightening, we probably should require it.

In the proposal, separate the TO cases from the IS/DEFER! to make it watertight.

AACTION-OF should be ACTION-OF

"shall": The style for ambiguous conditions has been: "An ambiguous condition exists if...".

6.2.0698: Mention that this is ACTION-OF

Put the test cases in code style (surround with ``` lines) or in a separate file.

There is no need to test for ambiguous conditions. These are the cases that a standard program should avoid.

JennyBrienavatar of JennyBrien 2018-06-16 08:44:38

Anton wrote:

Letting all synonyms have the same xt is certainly a good solution. Should we require it? I don't know a reason for or against (in particular, I don't think that there is a system that has SYNONYM where synonyms of the same word have different xts), so in the spirit of tightening, we probably should require it.

I don't see any objection. I picture SYNONYM as being equivalent to creating an identical header with a possibly different name in a system with detatched headers. I.e. it points to the same code and data space. I think all the restrictions above flow naturally from that.

I think there was, years ago, a proposal for a word ALIAS ( xt name -- ) , that only copied the execution and created a defition with default compiling semantics. Was it suggested that should return the same xt when ticked? I don't think it's possible, under VFX, to have two words with the same xt but different compiling semantics, though I could be wrong.

AntonErtlavatar of AntonErtl 2018-06-16 13:07:35

Yes, different systems would behave differently for ALIASes of immediate words, and when applying IMMEDIATE to an alias; and in particular, one passes an xt to ALIAS, and in Gforth, the xt is not associated with immediacy. That's why we standardized SYNONYM, no ALIAS, and why applying IMMEDIATE to a synonym is ambiguous.

JennyBrienavatar of JennyBrien 2018-06-17 06:33:56

I see. I was thinking of the twin xt syntax for defining dual word as a factor of SYNONYM

   i-xt c-xt DUAL: *name*  defines a dual word
   0    c-xt DUAL: *name*  defines a  compile-only word 
   xt dup  DUAL: *name*  defines an immediate word
     xt.      ALIAS:  *name* defines a default word

But I don't see how to make it work with VFX

AntonErtlavatar of AntonErtl 2018-06-17 12:56:01

Your DUAL: is quite simular to Gforth's INTERPRET/COMPILE:. In a system where the compilation semantics hangs on the i-xt, such a word would either set the compilation semantics of other words with the same i-xt, or would have to introduce a new i-xt (e.g., a deferred word), but then it becomes harder to use this word for defining a synonym. I guess we won't be seeing such a word standardized, though.

Reply