Proposal: Same name token for different words

Informal

This proposal has been moved into this section. Its former address was: /standard/tools

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv Same name token for different wordsProposal2020-06-09 16:36:22

Have a look at 3.1.3.5 Execution tokens:

Different definitions may have the same execution token if the definitions are equivalent.

Should we have to add a similar clause for name tokens? E.g.

Different words may have the same name token if their names are identical, the interpretation semantics for them are equivalent, and the compilation semantics for them are equivalent.

GeraldWodniavatar of GeraldWodni

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

ruvavatar of ruv

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.

ruvavatar of ruv

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.

JennyBrienavatar of JennyBrien

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.

Reply New Version