Proposal: [136] Same name token for different words

You can now add a new Version with the "New Version" button below which will then git diffed to the previous version. testing simple reply

Two definitions can have the different execution semantics when the interpretation semantics for them are the same and the compilation semantics are the same [1].

So, we should mention the same execution semantics too:

The different words may have the same name token if their names are identical, the actual interpretation semantics for them are equivalent, the actual compilation semantics for them are equivalent, and if the execution semantics defined for one of them, the execution semantics for another one are equivalent to the first one.

Or, in a shorter variant:

The different words may have the same name token if their are synonyms having identical names.

The idea is that if two words have the same name (what about case-sensitivity?), and they behavior indistinguishable, they may have the same nt.

OTOH, I don't insist that we should namely allow the same nt for the different words. But I think, we should either explicitly allow, or explicitly prohibit the same nt.

[1] Example:

: foo 0= ;
: bar ['] 0= state @ if compile, else execute then ; immediate

\ testcase that shows the different execution semantics
: [e] execute ; immediate
0 ' foo  ] [e] [ . \ prints -1
0 ' bar  ] [e] [ . \ prints 0 (or even throws an exception)

I remember that by Anton's view (in the last year at least), the interpretation semantics for them are different, and the compilation semantics for them are different too. But it seems, this view even isn't supported by the authors of the original reference implementation for SYNONYM.

Why it is important

If the same nt is allowed then:

1. SYNONYM may rely on that when newname and oldname are the same.

2. TRAVERSE-WORDLIST may produce the same nt several times during iteration of one word list, or between iterations of several word lists (see also the comment).

If the same nt is not allowed, it guarantees uniqueness of each nt during iterations of all available word lists via TRAVERSE-WORDLIST.

I can't see any useful implementation in which two definitions would share an nt. If you think to the dictionary as a database of all the properties of definitions then the nt is the key field. Several nt`s may share a name or an xt , but not vice versa.

A system is allowed to do it, but is not required to do it. The committee does not see a need to add such a clause to the standard. If you still want to go ahead with the proposal, you should make it more formal.

This contribution was originally intended as comment. A formal proposal should be prepared to go ahead with this.