| Type | Wish | Status | problem | Date | 21-Sep-2013 14:39 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Unspecified | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Make unused refinements FALSE, not NONE |
|---|---|
| Description |
Currently, a refinement is in use in the invocation of a function, then the body of the function sees its value as TRUE. If it is not, then it sees it as NONE. Not being able to take for granted that the refinement is a LOGIC! is frustrating, and has caused me personally several avoidable errors. @DocKimbel has changed this in Red so that unused refinements are FALSE. Rebol and Red should be able to be in sync on this, and I believe having the refinement always be a LOGIC! is the cleaner invariant. |
| Example code |
;; Current behavior
test: func [x /foo y /bar z] [
print x
if foo and bar [
print y
print z
]
]
>> test "Hello"
Hello
** Script error: and does not allow none! for its value2 argument
** Where: test
** Near: test "Hello"
;; Desired behavior
test: func [x /foo y /bar z] [
print x
if foo and bar [
print y
print z
]
]
>> test "Hello"
Hello
|
| Assigned to | n/a | Fixed in | - | Last Update | 12-Nov-2013 08:55 |
|---|
| Comments | |
|---|---|
|
(0004036)
fork 4-Oct-2013 03:42 |
This has been complicated by me learning that there is nothing special about /local, and that refinements can be used as a method of declaring local variables.
e.g. foo: func [value /local x y z] [ ... ] is rather similar to: foo: func [value /x /y /z] [ ... ] Given this equivalence, it starts to seem a bit weird that these refinements would be initializing x, y, and z to false. It's not a terrible idea considering the more common application is to use the /local convention. It just introduces a new angle to the question. |
|
(0004037)
BrianH 4-Oct-2013 03:57 |
That method of quickly declaring local variables is pretty common in user code, particularly experienced user code. We don't do it in mezzanine code, but that is held to a different standard. If this goes through, this practice will likely die out in Rebol 3 code.
There is a lot of code that will continue to work with this proposal, and a lot that will fail in ways that will be difficult to track down. If we do this, it must be documented thoroughly. The conditionally-truthy treatment of APPLY refinement parameters would need to remain - they would be translated to true or false, instead of true or none the way they are now. |
|
(0004045)
Gregg 7-Oct-2013 08:01 |
I would like Red and REBOL to be in sync as much as possible. The AND argument is less convincing to me. It's always seemed counter-intuitive to me that refinements used are seen as TRUE. I understand the reason, but expect them to be their actual value or none more than expecting unused refinements to be FALSE. |
|
(0004055)
maxim 7-Oct-2013 20:57 |
The culprit here is 'AND... it should simply behave and allow NONE! and switch to normal conditional evaluation, instead of math based bit fields.
I have NEVER needed /refinements to be TRUE/FALSE in over 15 years... because all conditional code reacts equally to none/false. in fact, AND is used very rarely in Rebol. |
|
(0004081)
DideC 15-Oct-2013 14:11 |
Funily I have never used 'AND in Rebol. I even did not kow it exists and would have used 'ALL [...] in this usage case.
Changing unset refinment to false instead of none does not hurt me. But I wonder about the code that rely on this specific value ! |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 12-Nov-2013 08:55 | Ladislav | Status | Modified | submitted => problem |
| 15-Oct-2013 14:11 | DideC | Comment : 0004081 | Added | - |
| 7-Oct-2013 20:57 | maxim | Comment : 0004055 | Added | - |
| 7-Oct-2013 08:01 | Gregg | Comment : 0004045 | Added | - |
| 4-Oct-2013 03:57 | BrianH | Comment : 0004037 | Added | - |
| 4-Oct-2013 03:42 | fork | Comment : 0004036 | Added | - |
| 21-Sep-2013 14:39 | fork | Description | Modified | - |
| 21-Sep-2013 14:39 | fork | Code | Modified | - |
| 21-Sep-2013 14:39 | fork | Ticket | Added | - |