| Type | Bug | Status | dismissed | Date | 24-Jul-2015 22:09 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Evaluation | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Numbers after function in PATH! should raise an error |
|---|---|
| Description |
Validation checks noticed a problem with the code in #2050: o: make object! [n: 'o b: reduce [func [] [n]]] p: make o [n: 'p] o/b/1 ; == p - o expected! In the logic of Rebol, in the pattern o/b/XXX where o/b resolves to a function, the /XXX is processed as a refinement. It is *technically* possible to say that integers would behave differently somehow, as function refinements can't be numeric. Hence this *could* force an evaluation of the function and operate the /1 on the result. But that seems like a sloppy design to me. So o/b/1 here should just be an error about bad refinement (or something to that effect). To get the behavior requested here, you would have to write (o/b)/1 |
| Example code |
| Assigned to | n/a | Fixed in | - | Last Update | 15-Dec-2015 19:32 |
|---|
| Comments | |
|---|---|
|
(0004665)
Ladislav 14-Dec-2015 22:56 |
Where do you see a function in the o/b expression? (That should be a block.) |
|
(0004666)
fork 15-Dec-2015 06:05 |
(Note: While attention to the tickets is great, the CC import data has been completed; that means it would take another scrape and process if this database grows. It would be preferable if we can get together, finish the GitHub import, and work there.)
Yes, I think the problem that was actually manifesting here that I saw was that the function dispatch did not like "1" being the *label* for the dispatch. So o/b/1 came back with the position in the path being "1" which was not amenable to having a symbol extracted from it. It's gotten easier in the code to read and understand such situations, with comments...so it is less confusing and harder to misread. The presumed thing to do in this case is to treat a numeric path element the way one might treat any other nameless invocation (e.g. through an EVAL) and just give it the invocation label FUNCTION! (or something). Approaches which tried to clone arbitrary expressions to serve as the name would be possible, but would have associated cost and aren't a particular priority. |
|
(0004667)
abolka 15-Dec-2015 06:38 |
Thanks for catching my sloppiness, Ladislav. I originally tried to reproduce this with a simplified version matching my understanding of what @fork said in the summary and could successfully reproduce it. After that, I only superficially checked if @fork's code roughly looked like what I thought to be the case and fell victim to confirmation bias. Even more, trying to reproduce again what I thought I ran back then now fails as expected. So twice sloppy (I fear I tested on an intermediate version instead of a "known" build). Kudos again for the keen review, Ladislav. |
|
(0004668)
abolka 15-Dec-2015 07:41 |
To try to make up for the sloppy review, I pushed three very simple test cases to test for functions-called-via-path :)
https://github.com/rebolsource/rebol-test/commit/e02f62c902e85dc3e689b044f731834d77f802b5 |
|
(0004670)
Ladislav 15-Dec-2015 19:32 |
Thank you. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 15-Dec-2015 19:32 | ladislav | Comment : 0004670 | Added | - |
| 15-Dec-2015 09:18 | abolka | Comment : 0004668 | Modified | - |
| 15-Dec-2015 07:41 | abolka | Comment : 0004668 | Added | - |
| 15-Dec-2015 06:38 | abolka | Comment : 0004667 | Added | - |
| 15-Dec-2015 06:05 | Fork | Comment : 0004666 | Added | - |
| 14-Dec-2015 22:57 | ladislav | Comment : 0004665 | Modified | - |
| 14-Dec-2015 22:56 | ladislav | Status | Modified | reviewed => dismissed |
| 14-Dec-2015 22:56 | ladislav | Comment : 0004665 | Added | - |
| 26-Jul-2015 06:24 | abolka | Description | Modified | - |
| 26-Jul-2015 06:24 | abolka | Status | Modified | submitted => reviewed |
| 24-Jul-2015 22:09 | Fork | Ticket | Added | - |