| Type | Wish | Status | reviewed | Date | 20-Apr-2011 10:11 |
|---|---|---|---|---|---|
| Version | alpha 111 | Category | Native | Submitted by | Ladislav |
| Platform | All | Severity | major | Priority | normal |
| Summary | Implement conditional operators |
|---|---|
| Description |
==Conditional expressions By "conditional expressions" I mean expressions that are used to supply CONDITION arguments to control functions like IF, EITHER, UNLESS, ... Conditional expressions can also be found in BLOCK arguments of control functions like ANY, ALL, CASE, WHILE, UNTIL. In programming languages the purpose of operators like NOT, AND, OR, XOR is to combine simple conditional expressions yielding complex conditional expressions. However, in Rebol the only conditional operator I know is NOT, which is able to take a result of a conditional expression as an argument and yield a "conditional result". That is not the case of the AND, OR and XOR operators, which cannot take conditional values as arguments. (see the example expression below) The fact that NOT is conditional, while AND, OR and XOR are not makes the operators mutually incompatible. That confuses users not aware of such catches. My findings prove that too many users are being caught by that. Brian suggested that nonconditional AND, OR and XOR operators are better than conditional, since: * they can be used in conditional expressions with a help of the TRUE? function * they protect the user, since they "cut down on none propagation" There are serious objections to both of these, though: * users don't remember the differences between TRUE?, TO-LOGIC and FOUND?, using the most inappropriate of the three functions too often * the expressivity of the language suffers, since the users don't want to replace conditional expressions like if value1 AND value2 OR value3 [] by if (true? value1) AND (true? value2) OR (true? value3) [] * the "cut down on none propagation" property actually does not work for conditional expressions like the latter one anyway * virtually nobody knows that the counterpart of nonconditional AND, OR and XOR operators is not the conditional NOT operator, but the nonconditional COMPLEMENT operator. The usage of the COMPLEMENT operator is known to be much lower than the usage of the NOT operator. Notice hovewer that if the users wanted to enjoy the purported benefits of the nonconditional operators, they would use the COMPLEMENT operator more frequently. ==Summary * the conditional NOT operator is preferred by the users, when compared to its nonconditional COMPLEMENT variant (because, what the users want is to have a conditional operator, not a nonconditional one) * Rebol seems to be currently the only programming language not having conditional AND and OR operators ==Possible solution * Make the AND, OR and XOR operators conditional * Similarly as for the NOT operator, the AND, OR and XOR operators already have nonconditional counterparts. Naturally, the nonconditional AND counterpart is INTERSECT (currently just duplicating some of the functionality), the natural nonconditional counterpart of OR is UNION, and the natural nonconditional counterpart of XOR is DIFFERENCE. * My user poll results suggest that the majority of users would welcome this change. |
| Example code |
; OR cannot combine conditional subexpressions, ; the expression below triggers a script error none or none |
| Assigned to | n/a | Fixed in | - | Last Update | 20-Sep-2015 06:55 |
|---|
| Comments | |
|---|---|
|
(0004063)
fork 8-Oct-2013 21:43 |
This example:
if (true? value1) AND (true? value2) OR (true? value3) [] Is a very common one, and was an annoyance to me until I started using ANY and ALL. After which, I rarely touched AND/OR. But despite the flexibility ANY and ALL provide, there are some cases that would read better infix and without a block. Moreover, this is something every new user would struggle with prior to discovering ANY and ALL which they may not be as enthusiastic about as many experienced Rebol programmers are. So this sounds like a good idea to me. |
|
(0004097)
Gregg 17-Oct-2013 08:17 |
+1 |
|
(0004313)
BrianH 5-Mar-2014 09:26 |
Most languages which have conditional or logical operators, also have separate operators for bitwise operations. Rebol uses the same operators for both logical and bitwise operations. We would need to implement separate bitwise operators for AND, OR or XOR before we could make changes to those logical operators. Marked as problem until we agree to do that.
As for my opinion about this proposal, I find that these operators being strictly logical is only part of why they aren't used that much. The other part is that the expressions which generate these conditional values tend to be regular prefix Rebol expressions, which don't really interact well with any operators without using parens to handle the precedence (as Fork's code demonstrates). That awkwardness turns a lot of people towards the ANY and ALL functions, and would continue to do so even if the logical operators went conditional. Ignoring the awkwardness though (as we can with AND~, OR~ and XOR~, their prefix counterparts), I have no other objections to making these operators conditional. As long as we get separate bitwise operators to resolve the conflict, this seems like a nice way to unify Rebol semantics, which will make it easier to understand and teach. |
|
(0004323)
BrianH 6-Mar-2014 22:19 |
"Is there any other conditional operator in Rebol?"
You are proposing in this ticket that AND, OR and XOR be changed to conditional. So, for the existing Rebol behavior before this change would be implemented, substitute "logical" for "conditional" in that comment (actually, I'll edit the comment to clarify that is what I meant). And yes, the "not" operator has a conditional (or logical if you prefer) variant (NOT) and a bitwise variant (COMPLEMENT). That is similar to what would have to be done for AND, OR and XOR before we could go forward with this proposal. Make a separate proposal for those new bitwise operators and we will be able to move forward with both. |
|
(0004338)
Ladislav 7-Mar-2014 14:05 |
Having refreshed my memory, the current behaviour is as follows:
* AND is a logical and bitwise operator the change proposed above is to: * make AND a conditional operator * make INTERSECT a bitwise operator similarly for the OR (UNION) and XOR (DIFFERENCE) operators |
|
(0004339)
Ladislav 7-Mar-2014 14:07 |
I adjusted the severity to *major* since it would require changes to existing code. |
|
(0004340)
BrianH 7-Mar-2014 16:34 |
Sounds good to me - the set functions are in need of a revamp anyways (epic to come, I have a long list of existing tickets).
Treating set functions as binary operations is fine, but we need to keep them as prefix functions. The non-binary set-like behavior for non-block data needs function options, existing and new. So, the binary operations would be for binaries and integers, and any others that we think should be, probably shortcut evaluated for speed. The binary-operations change will still need another ticket (not enough info in "proposed above", and it's a different topic). I'll start it if it doesn't magically appear before I get back to Rebol stuff later today or tomorrow. OK about the severity, but "require changes to existing code" is not a blocking criteria until after 3.0, and this is intended as a pre-3.0 change. |
|
(0004342)
fork 7-Mar-2014 17:11 |
I proposed that breaking PRs must include a link to a script to find suspected breakages and offer adaptation code.
Whether anyone cares to use the script or not isn't the issue. It being perfect is also not the issue. But think about even the funct change; anywhere that had FUNCTION not followed by exactly three blocks will break non obviously. Not asking for the world here, just saying that people will waste time tracking stuff down if there's not some sort of due diligence. Cyphre's experience with TO LOGIC! reminded me of what a hassle the SHIFT sign interpretation between R2 and R3 was. Mapping out the impact of a change may question the basis of the change also. |
|
(0004343)
Ladislav 7-Mar-2014 17:25 |
"I proposed that breaking PRs must include a link to a script to find suspected breakages and offer adaptation code. " - this may be a problem in this specific case. The "logical operator" usage of AND, OR and XOR will not be influenced by this proposal.
If we added the logical capability to INTERSECT, UNION and DIFFERENCE, then it would be possible to just replace existing occurrences of AND, OR and XOR by INTERSECT, UNION and DIFFERENCE, but that is also problematic, since as BrianH mentioned, INTERSECT, UNION and DIFFERENCE are prefix. |
|
(0004344)
fork 7-Mar-2014 17:33 |
@Ladislav I said it did not have to be perfect. Start with just searching to find the words (like a text editor would) then filter. If you see a subtree where it's an AND under a PARSE but not in parens, put it in a "lesser" review queue for the person having to adapt to the change
I have done something similar with Draem as I keep changing the rules, so the rewriting is done with source-to-source transformations. |
|
(0004345)
BrianH 7-Mar-2014 17:35 |
It's not problematic, it just requires shifting to prefix expressions as well, which is not hard. It doesn't get to "problematic" until we try to do something impossible (which we can still do, but it takes more work). No worries here :) |
|
(0004365)
Ladislav 11-Mar-2014 18:37 |
To discuss it further, assuming that a consensus to change AND, OR and XOR to conditional operators is more or less present, I assume that:
* AND~, OR~ and XOR~ prefix versions should also be transformed to conditional operators * INTERSECT, UNION and DIFFERENCE should be transformed to work also as logic operators and bitwise operators for binaries and integers ? |
|
(0004371)
Ladislav 21-Mar-2014 20:03 |
An alternative to the above is a variant proposed by Cyphre with AND~, OR~ and XOR~ transformed to bitwise operators, renaming them to AND#, OR# and XOR#. The renaming is needed for users of international keyboards (the "~" character requires 4! keystrokes here). |
|
(0004639)
fork 28-Apr-2015 11:11 |
On naming, I believe the prefix versions of the conditional forms could simply be named AND?, OR?, and XOR?...compliant with the idea that functions ending with ? return LOGIC! results.
This raises the question of if the *non-question-mark* bearing infix forms should take advantage of that to return more interesting values than TRUE/FALSE. e.g. `a AND b` returning what `ALL [a b]` would, while `a OR b` could return what `ANY [a b]` would. Thus because: >> all [10 20] == 20 That would suggest that `10 and 20` be 20, while `and? 10 20` would be TRUE. This may or may not offer a potential shade of meaning for NOT? vs NOT, which being single arity would have a hard time being meaningful otherwise. Perhaps NOT could be more focused toward going to NONE the way it would work with `if false []`? There is of course no specific value besides true to generate from a FALSE or NONE...unless NOT NONE was chosen to be equivalent to a random value generator that promised not to return FALSE or NONE. :-) Food for thought. But the key here was in trying to name the prefix forms I realized AND?, OR?, and XOR? were perfectly fitting names. |
|
(0004661)
abolka 20-Sep-2015 06:55 |
Noting that I haven't expressly registered my agreement here: +1
- +1 for making infix AND, OR, XOR conditional - +1 for making prefix AND~, OR~, XOR~ conditional as well - +1 for introducing a separate set of infix bitwise operators for binaries and integers (AND*, OR+, XOR-; or AND#, OR#, XOR#) |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 20-Sep-2015 06:55 | abolka | Comment : 0004661 | Added | - |
| 28-Apr-2015 11:11 | Fork | Comment : 0004639 | Added | - |
| 21-Mar-2014 20:03 | Ladislav | Comment : 0004371 | Added | - |
| 21-Mar-2014 20:02 | Ladislav | Comment : 0004365 | Modified | - |
| 21-Mar-2014 20:00 | Ladislav | Comment : 0004365 | Modified | - |
| 11-Mar-2014 18:37 | Ladislav | Comment : 0004365 | Added | - |
| 7-Mar-2014 17:35 | BrianH | Comment : 0004345 | Added | - |
| 7-Mar-2014 17:33 | fork | Comment : 0004344 | Added | - |
| 7-Mar-2014 17:25 | Ladislav | Comment : 0004343 | Added | - |
| 7-Mar-2014 17:13 | fork | Comment : 0004342 | Modified | - |
| 7-Mar-2014 17:11 | fork | Comment : 0004342 | Added | - |
| 7-Mar-2014 16:34 | BrianH | Comment : 0004340 | Added | - |
| 7-Mar-2014 14:12 | Ladislav | Comment : 0004339 | Modified | - |
| 7-Mar-2014 14:10 | Ladislav | Status | Modified | problem => reviewed |
| 7-Mar-2014 14:09 | Ladislav | Comment : 0004338 | Modified | - |
| 7-Mar-2014 14:07 | Ladislav | Comment : 0004339 | Added | - |
| 7-Mar-2014 14:06 | Ladislav | Severity | Modified | minor => major |
| 7-Mar-2014 14:05 | Ladislav | Comment : 0004338 | Added | - |
| 7-Mar-2014 14:03 | Ladislav | Comment : 0004322 | Removed | - |
| 6-Mar-2014 22:24 | BrianH | Comment : 0004313 | Modified | - |
| 6-Mar-2014 22:19 | BrianH | Comment : 0004323 | Added | - |
| 6-Mar-2014 20:50 | Ladislav | Comment : 0004322 | Modified | - |
| 6-Mar-2014 20:45 | Ladislav | Comment : 0004322 | Modified | - |
| 6-Mar-2014 19:46 | Ladislav | Comment : 0004322 | Modified | - |
| 6-Mar-2014 19:45 | Ladislav | Comment : 0004322 | Modified | - |
| 6-Mar-2014 19:44 | Ladislav | Comment : 0004322 | Added | - |
| 5-Mar-2014 09:26 | BrianH | Status | Modified | submitted => problem |
| 5-Mar-2014 09:26 | BrianH | Comment : 0004313 | Added | - |
| 17-Oct-2013 08:17 | Gregg | Comment : 0004097 | Added | - |
| 8-Oct-2013 21:43 | fork | Comment : 0004063 | Added | - |
| 9-Sep-2013 09:42 | Ladislav | Description | Modified | - |
| 16-Aug-2013 14:02 | Ladislav | Category | Modified | Unspecified => Native |
| 23-Mar-2013 18:06 | Ladislav | Summary | Modified | Conditional operators in REBOL => Implement conditional operators |
| 23-Mar-2013 18:06 | Ladislav | Description | Modified | - |
| 23-Mar-2013 17:59 | Ladislav | Description | Modified | - |
| 23-Mar-2013 17:59 | Ladislav | Description | Modified | - |
| 23-Mar-2013 17:58 | Ladislav | Description | Modified | - |
| 26-Apr-2011 07:12 | Ladislav | Description | Modified | - |
| 26-Apr-2011 07:07 | Ladislav | Description | Modified | - |
| 20-Apr-2011 23:51 | Ladislav | Description | Modified | - |
| 20-Apr-2011 15:48 | Ladislav | Description | Modified | - |
| 20-Apr-2011 15:47 | Ladislav | Code | Modified | - |
| 20-Apr-2011 15:47 | Ladislav | Description | Modified | - |
| 20-Apr-2011 10:11 | Ladislav | Ticket | Added | - |