Perl Macros and Operators – How to Implement an Implies Macro or Operator

macrosoperatorsperl

(I read Writing a macro in Perl, but still need directions)

Eiffel has an implies operator (Implicative boolean operator, see "8.5.20 Syntax: Operators" in ECMA-367, 2nd edition), i.e.

a implies b

meaning

not a or b

So the first attempt was to use

# a implies b (a --> b)
sub implies($$)
{
    return !$_[0] || $_[1];
}

However that's a function, and not an operator.
Specifically the short-cut evaluation fails for cases like

implies(defined($a), $a eq '@')

(resulting in "Use of uninitialized value $a in string eq at …").

So the question is (for Perl 5.18.2):
Is there an elegant way to add such an "operator" to Perl?

Best Answer

You could use XS::Parse::Infix::FromPerl.

It provides a way of hooking into Perl's parser to provide a named infix operator. So,

You can introduce the EXPR1 implies EXPR2 syntax, and
you can implement short-circuiting behaviour.

Pragma module: (It's effect is lexically-scoped like use strict;.)

package Syntax::Feature::Implies;

# Usage: `use syntax qw( implies );`
# Provides: `EXPR1 implies EXPR2`

use strict;
use warnings;

use Optree::Generate           qw( newLOGOP newUNOP OP_OR OP_NOT );
use XS::Parse::Infix::FromPerl qw( register_xs_parse_infix XPI_CLS_LOGICAL_OR_MISC );

my $hintkey = __PACKAGE__;

sub import   { $^H{ $hintkey } = 1; }
sub unimport { $^H{ $hintkey } = 0; }

*install   = \&import;    # For syntax.pm
*uninstall = \&unimport;  # For syntax.pm

register_xs_parse_infix(
   implies => (
      cls => XPI_CLS_LOGICAL_OR_MISC,  # Same precedence as `||`.
      permit_hintkey => $hintkey,
      new_op => sub {
         #my ( $flags, $lhs, $rhs, $parsedata, $hookdata ) = @_;
         return newLOGOP( OP_OR, 0,
            newUNOP( OP_NOT, 0, $_[1] ),
            $_[2],
         );
      },
   )
);

1;

Test script:

#!/usr/bin/perl

use strict;
use warnings;

use feature qw( say );
use syntax qw( implies );  # Or use Syntax::Feature::Implies;

for my $p ( 0 .. 1 ) {
for my $q ( 0 .. 1 ) {
   my $rhs_evaluated = 0;
   my $r = $p implies do { ++$rhs_evaluated; $q };
   say "$p implies $q = $r  rhs ".( $rhs_evaluated ? "" : "not " )."evaluated";
}}

Output:

0 implies 0 = 1  rhs not evaluated
0 implies 1 = 1  rhs not evaluated
1 implies 0 = 0  rhs evaluated
1 implies 1 = 1  rhs evaluated

I gave it the same precedence as || (untested), but that can be tweaked.

`cls`	Same precedence as
`XPI_CLS_LOGICAL_AND_MISC`	`&&`
`XPI_CLS_LOGICAL_OR_MISC`	`\|\|`, `^^`, `//`
`XPI_CLS_LOGICAL_AND_LOW_MISC`	`and`
`XPI_CLS_LOGICAL_OR_LOW_MISC`	`or`, `xor`

Related Solutions

Python – Does Python Have a Ternary Conditional Operator?

Yes, it was added in version 2.5. The expression syntax is:

a if condition else b

First condition is evaluated, then exactly one of either a or b is evaluated and returned based on the Boolean value of condition. If condition evaluates to True, then a is evaluated and returned but b is ignored, or else when b is evaluated and returned but a is ignored.

This allows short-circuiting because when condition is true only a is evaluated and b is not evaluated at all, but when condition is false only b is evaluated and a is not evaluated at all.

For example:

>>> 'true' if True else 'false'
'true'
>>> 'true' if False else 'false'
'false'

Note that conditionals are an expression, not a statement. This means you can't use statements such as pass, or assignments with = (or "augmented" assignments like +=), within a conditional expression:

>>> pass if False else pass
  File "<stdin>", line 1
    pass if False else pass
         ^
SyntaxError: invalid syntax

>>> # Python parses this as `x = (1 if False else y) = 2`
>>> # The `(1 if False else x)` part is actually valid, but
>>> # it can't be on the left-hand side of `=`.
>>> x = 1 if False else y = 2
  File "<stdin>", line 1
SyntaxError: cannot assign to conditional expression

>>> # If we parenthesize it instead...
>>> (x = 1) if False else (y = 2)
  File "<stdin>", line 1
    (x = 1) if False else (y = 2)
       ^
SyntaxError: invalid syntax

(In 3.8 and above, the := "walrus" operator allows simple assignment of values as an expression, which is then compatible with this syntax. But please don't write code like that; it will quickly become very difficult to understand.)

Similarly, because it is an expression, the else part is mandatory:

# Invalid syntax: we didn't specify what the value should be if the 
# condition isn't met. It doesn't matter if we can verify that
# ahead of time.
a if True

You can, however, use conditional expressions to assign a variable like so:

x = a if True else b

Or for example to return a value:

# Of course we should just use the standard library `max`;
# this is just for demonstration purposes.
def my_max(a, b):
    return a if a > b else b

Think of the conditional expression as switching between two values. We can use it when we are in a 'one value or another' situation, where we will do the same thing with the result, regardless of whether the condition is met. We use the expression to compute the value, and then do something with it. If you need to do something different depending on the condition, then use a normal if statement instead.

Keep in mind that it's frowned upon by some Pythonistas for several reasons:

The order of the arguments is different from those of the classic condition ? a : b ternary operator from many other languages (such as C, C++, Go, Perl, Ruby, Java, JavaScript, etc.), which may lead to bugs when people unfamiliar with Python's "surprising" behaviour use it (they may reverse the argument order).
Some find it "unwieldy", since it goes contrary to the normal flow of thought (thinking of the condition first and then the effects).
Stylistic reasons. (Although the 'inline if' can be really useful, and make your script more concise, it really does complicate your code)

If you're having trouble remembering the order, then remember that when read aloud, you (almost) say what you mean. For example, x = 4 if b > 8 else 9 is read aloud as x will be 4 if b is greater than 8 otherwise 9.

Official documentation:

JavaScript Equality Operators – == vs ===

The strict equality operator (===) behaves identically to the abstract equality operator (==) except no type conversion is done, and the types must be the same to be considered equal.

Reference: JavaScript Tutorial: Comparison Operators

The == operator will compare for equality after doing any necessary type conversions. The === operator will not do the conversion, so if two values are not the same type === will simply return false. Both are equally quick.

To quote Douglas Crockford's excellent JavaScript: The Good Parts,

JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable. These are some of the interesting cases:

'' == '0'           // false
0 == ''             // true
0 == '0'            // true

false == 'false'    // false
false == '0'        // true

false == undefined  // false
false == null       // false
null == undefined   // true

' \t\r\n ' == 0     // true

The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use === and !==. All of the comparisons just shown produce false with the === operator.

Update

A good point was brought up by @Casebash in the comments and in @Phillipe Laybaert's answer concerning objects. For objects, == and === act consistently with one another (except in a special case).

var a = [1,2,3];
var b = [1,2,3];

var c = { x: 1, y: 2 };
var d = { x: 1, y: 2 };

var e = "text";
var f = "te" + "xt";

a == b            // false
a === b           // false

c == d            // false
c === d           // false

e == f            // true
e === f           // true

The special case is when you compare a primitive with an object that evaluates to the same primitive, due to its toString or valueOf method. For example, consider the comparison of a string primitive with a string object created using the String constructor.

"abc" == new String("abc")    // true
"abc" === new String("abc")   // false

Here the == operator is checking the values of the two objects and returning true, but the === is seeing that they're not the same type and returning false. Which one is correct? That really depends on what you're trying to compare. My advice is to bypass the question entirely and just don't use the String constructor to create string objects from string literals.

Reference
https://262.ecma-international.org/5.1/#sec-11.9.3

Best Answer

Related Solutions

Python – Does Python Have a Ternary Conditional Operator?

JavaScript Equality Operators – == vs ===

Update

Related Question