Type | Bug | Status | tested | Date | 1-May-2009 23:00 |
---|---|---|---|---|---|
Version | alpha 49 | Category | n/a | Submitted by | meijeru |
Platform | All | Severity | minor | Priority | normal |
Summary | numerical refinement allowed in function spec -- should be error |
---|---|
Description |
a refinement of the form /1 in the function spec is not caught as error, but a function call with that refinement is! ticket 733 relates: there is no reason to consider /1 as a valid refinement -- the fact that it may validly occur in a path expression is neither here nor there, because there are many more constructs that are allowed in a path expression, and are not a valid refinement (e.g. get-word, paren) |
Example code |
>> f: func[a /1 b][a] == make function! [[a /1 b][a]] >> f/1 0 0 ** Script error: incompatible refinement: 1 |
Assigned to | n/a | Fixed in | alpha 58 | Last Update | 22-Jun-2009 15:59 |
---|
Comments | |
---|---|
(0000610)
BrianH 2-May-2009 00:19 |
It turns out that the 1 in a/1 is the integer! 1, not the refinement! /1 or the word! to-word "1". That is why you get the incompatible refinement error. The problem is not that the function can't be called, it's that the call can't be directly specified in REBOL syntax.
>> a: func [/1] [get /1] == make function! [[/1][get /1]] >> a == none >> a/1 ** Script error: incompatible refinement: 1 >> type? second first [a/1] == integer! >> type? second first [a/b] == word! >> do reduce [to-path reduce ['a to-word /1]] == true >> apply :a [true] == true |
(0000612)
meijeru 2-May-2009 10:21 |
All the more reason to forbid /1 as a (free-standing) literal of type refinement! why not narrow refinement! down to slash+word? It seems clear to me that the lexical analysis of free-standing slash+word and that of path expressions are done separately, since /-1 is not allowed but a/-1 is. The language would become cleaner that way. |
(0000614)
BrianH 2-May-2009 20:06 |
Here's where that argument breaks down:
- Paths and refinements are not the same thing, and don't have the same syntax. - Refinements are not just used in function specs - they are used in other dialects where they are not translated from word elements in paths - Numeric elements in paths are not words, they are numbers. They are not converted to refinements on path decoding. - There are tricks you can do with refinements that make it worth supporting refinements that don't have the same syntax as words, even in function specs. I am leaning towards recommending that this be dismissed. |
(0000617)
meijeru 3-May-2009 12:21 |
"There are tricks you can do with refinements that make it worth supporting refinements that don't have the same syntax as words, even in function specs."
Would you care to elaborate? If you prefer, we can continue this dialogue by e-mail. |
(0000622)
BrianH 5-May-2009 00:58 |
R3 chat is best for such discussions. |
Date | User | Field | Action | Change |
---|---|---|---|---|
19-Feb-2012 19:48 | BrianH | Comment : 0000610 | Modified | - |
22-Jun-2009 15:59 | BrianH | Status | Modified | built => tested |
21-Jun-2009 00:07 | carl | Status | Modified | reviewed => built |
21-Jun-2009 00:07 | carl | Fixedin | Modified | => alpha 58 |
5-May-2009 00:58 | BrianH | Comment : 0000622 | Added | - |
3-May-2009 12:21 | meijeru | Comment : 0000617 | Added | - |
2-May-2009 20:06 | BrianH | Comment : 0000614 | Added | - |
2-May-2009 19:57 | BrianH | Comment : 0000610 | Modified | - |
2-May-2009 15:10 | meijeru | Description | Modified | - |
2-May-2009 10:21 | meijeru | Comment : 0000612 | Added | - |
2-May-2009 00:26 | BrianH | Comment : 0000610 | Modified | - |
2-May-2009 00:25 | BrianH | Code | Modified | - |
2-May-2009 00:19 | BrianH | Comment : 0000610 | Added | - |
2-May-2009 00:15 | BrianH | Code | Modified | - |
1-May-2009 23:36 | BrianH | Status | Modified | submitted => reviewed |
1-May-2009 23:36 | BrianH | Code | Modified | - |
1-May-2009 23:36 | BrianH | Description | Modified | - |
1-May-2009 23:00 | meijeru | Ticket | Added | - |