| Type | Issue | Status | submitted | Date | 3-Nov-2014 13:56 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Evaluation | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Decide on behavior for STR/WORD where STR is ANY-STRING! |
|---|---|
| Description |
Currently Red/System's path evaluation allows you to index into strings without requiring indication of dereference. So if STR is "Hello", INDEX is 2, this happens: >> str/index == #"e" Rebol gives you: *** ERROR ** Script error: cannot access index in path str/index In Rebol you would have to write STR/:INDEX or STR/(INDEX) to get this behavior. Red proper gives you back "Hello", which is presumably wrong...and it would either work (as Red/System does) or have an error (as Rebol does). The offered rationale for the Red/System behavior is that there is no meaning for STR/INDEX. So if one is free to make the rules "however one wants" in the path evaluation matrix, then allowing the dereference to be implicit is better than an error. It allows you to write code that "looks less ugly", and although STR/(INDEX) is not all that ugly compared to STR/:INDEX it still "costs more", both in typing and in the need to allocate a PAREN! series somewhere. While that's not usually a big deal, in Red/System code being generated it can add up more than usual. At first look I really didn't like it. Because there do not seem to be other path options that eval in this way. Even weird ones don't evaluate...such as how FILE! and URL! will use TO-STRING! on the word and append it when path selection is done in this way: >> root-dir: %/foo/bar >> full-dir: root-dir/baz >> type? full-dir == file! >> full-dir == %/foo/bar/baz Nothing else dereferences without either a PAREN! or a GET-WORD!. And above we have some precedent set for what kind of application a word in a non-evaluative context could have...namely, using the string of the spelling of the word. So if one were to try and be consistent and offer an unevaluated meaning for path selection of a WORD! from an ANY-STRING!, what might it be? Well if FILE! and URL! path eval can use TO-STRING on it, what if it was a FIND... >> str: "Hello World!" >> str/wor == "World!" That stays consistent with the "no dereference without a GET-WORD!". And if construction syntax could be meaningfully applied to give you any word you wanted, even with spaces, you could find anything e.g.: >> str/#[llo Wo] == "llo World!" Prior to #2178 I didn't believe the spelling of words should be "accessible" to the outside world, because it seemed like you were "leaking variable names" that were commentary in nature. I even wanted to forbid WORD! values in printing, so PRINT ['Hello] would be an error). But reasoning through why I thought what FILE! and URL! were doing was bad led me to reverse my stance to believing it was good. But that's an alternative, in any case. How do other people feel? Is allowing STR/WORD to dereference words "cleaning things up" by removing superfluous GET-WORD!s for the most common case? Or is it "junking up" the expectations people have about path evaluation? Either way, in the "hierarchy of badness"--the worst thing seems to be having Rebol and Red do this differently. If it's going to be accepted it should be accepted across the board. If it's going to be resisted then users need to speak up. If the answer is that Red and Rebol will both consider it an error, and only Red/System will permit it...then that seems like "another speedbump" in trying to use code patterns in Red/System that one is familiar with from Red. |
| Example code |
| Assigned to | n/a | Fixed in | - | Last Update | 4-Nov-2014 10:02 |
|---|
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 4-Nov-2014 10:02 | fork | Description | Modified | - |
| 4-Nov-2014 03:40 | fork | Description | Modified | - |
| 4-Nov-2014 03:39 | fork | Description | Modified | - |
| 3-Nov-2014 14:16 | Fork | Description | Modified | - |
| 3-Nov-2014 13:56 | Fork | Ticket | Added | - |