issues and words share the same name space

Submitted by: Sunanda

The documentation does not seem clear to me. Nowhere can I see that

  #x
is the _same_word as
  x

This is likely to be a major gotcha for anyone contining with the pre-a107 world view that issue name space is separate to word name space.

>> set #iss-word 9999
== 9999

>> get #iss-word
== 9999

>> get iss-word  ;; same value as #iss-word
== 9999

^{Imported from: CureCode [ Version: alpha 107 Type: Issue Platform: All Category: Unspecified Reproduce: Always Fixed-in:none ]} ^{Imported from: https://github.com/rebol/rebol-issues/issues/1663}

Comments:

Rebolbot commented on Sep 26, 2010:

Submitted by: meijeru

AFAIK, the same was already the case with refinements, and it looks more like a property of SET than anything else.

>> set /ref-word 9999
== 9999
>> get ref-word
== 9999

In other words, what gets set is the word i.e. the value of type word! that is converted from the value of type refinement! or issue!

This means that SET #1 3 will work, but one get never get back at the value of the "word" 1 ... !

Rebolbot commented on Sep 26, 2010:

Submitted by: BrianH

Unfortunately that is not true at the moment.

>> set #1 2
== 2
>> get #1
== 2
>> get to-word #1
== 2
>> to-word #1
== 1

Those last two are a problem, because in theory something like this is supposed to happen:

>> to-word "1"
** Syntax error: invalid character in: "1"

We'll have to make a separate ticket for that bug, and finalize the issue-to-word behavior after #1657 is settled.

Rebolbot commented on Sep 28, 2010:

Submitted by: Carl

Dismissed this ticket. The fact that all of these: a 'a a: :a /a #a refer to the same word (symbol) is the objective.

Whether they reference the same value in a name-space is dependent on binding, not on datatype.

Non-representable word conversion is a separate issue worthy of discussion.

Rebolbot commented on Sep 28, 2010:

Submitted by: Sunanda

It may not be a bug, but I think it remains an issue, which is the category I submitted it as.

As meijeru implies, we really need some careful and precise documentation about how issue! can be used as word!, and the limitations. Otherwise, well meaning code may be strewn with gotchas. For example:

>> set #b [v: 1]
== [v: 1]

>> b/v: 2
== 2

>> #b/v: 3
== 3

>> get #b      
== [v: 2]     ;; the #b/v: 3 appears to have been thrown away, silently.

Rebolbot commented on Sep 28, 2010:

Submitted by: meijeru

The gotcha is that #b/v is NOT a path. Paths must start with a word, get-word, or lit-word (they are paths, get-paths and lit-paths). Paths cannot start with a value of any other type in any-word! (not refinement!, not issue!). This has always been the case. Try to evaluate #b/v ... the result is /v (#b is evaluated and discarded).

Rebolbot commented on Sep 29, 2010:

Submitted by: Sunanda

I think the gotcha may be subtler than that.

#xxx/yyy is being parsed with an implied space before the /

So:

   set #b/v 999
is being parsed as:
   set #b /v
   999

Implied spaces are very much the exception in REBOL (which is why we have to write 1 + 2 rather than 1+2), and it is not always possible to second guess accurately where they will be inserted.....

....These four lines exhibit quite different behavior:

set #b/v 99   ;; attempted path access in #b 
set #b%v 99   ;; attempt to create an issue! called b%v
set #b'v 99   ;; attempt to create an issue! called b'v
set #b@v 99   ;; attempt to create an issue! called b@v

Rebolbot mentioned this issue on Jan 12, 2016: Rename the issue! datatype

Rebolbot added the Status.dismissed on Jan 12, 2016

Oldes / Rebol-issues

issues and words share the same name space #1663

Comments: