Ok, let me take a step back and see what's being suggested.

it certainly seems like a case can be made for a binary operator, say
??, that returns its rhs if the lhs is true, undef otherwise,
analogous to the shell's ${var+val} construct.

At first glance it appears that the desired ternary behavior could be
achieved by  chaining such an operator with //:

A ?? B // C

But that fails if B happens to be undef. And it seems to me that
anything you do to the chaining rules to fix that case is going to be
pretty confusing in general.

So I prefer keeping a single construct, but perhaps the else-part
could be optional?

On 6/11/07, Jonathan Lang <[EMAIL PROTECTED]> wrote:
Audrey Tang wrote:
> Jonathan Lang wrote:
> > A variation of chaining associativity gets
> > used, with the "chaining rule" being '$v1 op1 $v2 // $v1 op2 $v3'
> > instead of '$v1 op1 $v2 && $v2 op2 $v3', as is the case for comparison
> > chaining.
> But wouldn't that make:
>    True ?? undef !! Moose;
> evaluate to Moose, instead of undef as we wanted?

Nope; because of the short-circuiting behavior:

    True ?? undef !! Moose
    True ?? undef // True !! Moose

The condition evaluates to True, causing the ?? to evaluate its RHS
and then short-circuit the rest of the expression.  The fact that the
RHS evaluates to undef is irrelevant.

In a sense, ?? and !! would invert the usual short-circuiting
behavior: with normal short-circuiting operators (&& and ||), the RHS
is evaluated if and only if the operator does not short-circuit; with
?? and !!, the RHS would be evaluated if and only if the operator
_does_ short-circuit.

NeonGraal wrote:
> Surely if you defined !! to return "undef but true" and both operators
> to be left associative then it all works.
>  1==0 ?? "True" !! "False" -> (undef) !! "False" which seems right to
> me.
>  1==1 !! "False" ?? "True" -> (undef but true) ?? "True" also good.

...except that '1==1 !! "False"' would return 'undef but true' on a
failure.  I'm sure that a rationale could be provided for doing this;
but it's a potentially surprising result which could get you in
trouble.  Best to keep to a simple 'undef' result on a failure.

Hakim: I'm not familiar with Haskell, so I can't follow your code as
well as I need to to provide an informed response.

Juerd Waalboer wrote:
> Zev Benjamin wrote:
> > ?? and !! could always return some kind of result object that boolizes
> > to true or false.
> Can we *please* keep simple things simple?

Agreed.  I'm in favor of this proposal to the extent that it breaks a
simple trinary operator down into equally simple binary operators
(with the trinary form continuing to exist as an emergent property of
the interaction of the binaries); if those binary operators become
more complex than the trinary form, or if you lose the ability to
recover the trinary form from them, there's no point in pursuing this

Jonathan "Dataweaver" Lang


Reply via email to