Re: RFC 143 (v1) Case ignoring eq and cmp operators

[Nathan Torkington]

David L. Nicol writes:
> Any subroutine declaration, for instance
> 
>       sub Cmp:infix($$){
>               return uc($_[0]) cmp uc($_[1])
>       };
> 
> implicitly sets up a "catch unknown-keyword:Cmp" routine; that is,
> it installs the name of the function in a place the clarifier will know
> to look for the definition.
> 
> It doesn't convert it to opcodes, doesn't "parse" it yet, just stores
> the token string.
> 
> Later, while parsing some expression or other, Cmp is encountered.
> 
> BAREWORD:Cmp is looked up in the whaddayaknow table, and there it is,
> an infix subroutine taking two scalar arguments, so if that makes sense
> with what is in front of and behind it, it gets evaluated as such.

Ooookay.  I think there's compile-time and run-time confusion here.
Cmp will get *evaluated* at run-time.  But the decision on what it is
is made at compile-time.

I'd just been picturing:

  sub Cmp :infix { ... }

primes the parser to accept Cmp as an infix subroutine call.
When the parser sees:

  SOMETHING Cmp SOMETHING

it rewrite it as

  Cmp($foo, $bar)

I don't see the need for exceptions to manage that.

I also wonder how to specify the operator's precedence.

Nat