Issue #14951 has been updated by danga (Dan Garubba).


jeremyevans0 (Jeremy Evans) wrote:
> sawa (Tsuyoshi Sawada) wrote:
> > I propose to extend the exclusive or operator `^` to be defined on `Object`. For `Integer`, the method would be overwritten by the current bitwise operator, and it would not benefit from the extension, but making it available for other classes can be useful for the OP's use case (as long as it does not encounter `Integer`), which would then be written as follows:
> > 
> > ```
> > raise MyError if in_scenario_x? ^ actions_performed_for_scenario_x?
> > ```
> 
> I don't think this is a good idea.  For `String#^`, the most natural operation would be a bitwise OR of each byte, and for collection classes, the most natural operation would be the exclusive disjunction of the two collections (returning a collection of elements in exactly one of the two collections).  Once `Object#^` has been added, redefining it for more natural operations in other classes would break backwards compatibility, so I think adding it would be short-sighted.

I agree. Because of the existing mixed semantics, and predicates returning `Integer`s, I'm wary of using `^` as a general purpose logical operator. However, `!a ^ b` appears to be tersest expression of truthiness-friendly logical equivalence (though your peers will probably debate you on the readability).



nobu (Nobuyoshi Nakada) wrote:
> danga (Dan Garubba) wrote:
> > Sure. In my day job, I write testing code. So I've written an expression like:
> > 
> > ~~~ ruby
> > raise MyError unless in_scenario_x? == actions_performed_for_scenario_x?
> > ~~~
> > 
> > To express: "raise an error unless the actions are performed for scenario X if and only if we are in scenario X".
> 
> The code and the explanation differ.
> 
> If the former is correct, the latter should be:
> "raise an error unless the actions are performed for scenario X and we are in scenario X, or the actions aren't performed for scenario X and we aren't in scenario X".
> 
> If the latter is correct, the former should be:
> ~~~ruby
> raise MyError unless in_scenario_x? && actions_performed_for_scenario_x?
> ~~~

I'm using "if and only if" as a natural language representation of Ʊ per https://ja.wikipedia.org/wiki/%E5%90%8C%E5%80%A4 (i.e., what I'm referring to as "logical equivalence").

> "raise an error unless the actions are performed for scenario X and we are in scenario X, or the actions aren't performed for scenario X and we aren't in scenario X".

This is appears to be have natural language expression of `(a && b) || (!a && !b)`, which is an alternative definition of logical equivalence (per https://en.wikipedia.org/wiki/Logical_equivalence).



----------------------------------------
Feature #14951: New operator to evaluate truthy/falsy/logical equivalence
https://bugs.ruby-lang.org/issues/14951#change-73259

* Author: danga (Dan Garubba)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
I propose adding a new operator for truthy/falsy equivalence, similar to what was proposed on https://bugs.ruby-lang.org/issues/13067, but with new syntax. The main purpose would be for writing expressions for logical equivalence (i.e., "if and only if" relationships) that only considers the truthiness the operands. Since predicate methods like `File#size?` and operators like `=~` follow truthy semantics without returning the `true` and `false` singletons, using them in logical expressions that evaluate for logical equivalence can be error-prone without the proper return type awareness and conversions. This proposed operator would be equivalent to `!!a == !!b`, but I feel that a new operator would be more concise and more expressive of the concept of logical equivalence.

Attached is a prototype implementation of the operator as '=?'.
 

---Files--------------------------------
teq.patch (3.47 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>