Proposal: split ternary ?? :: into binary ?? and //
Thomas Sandlass
I'm still contemplating how to get rid of the :: in the
ternary and make :: unequivocally available for a type
sigil and as a binary infix for symbol lookup.
Here's a possible solution:
1) ?? becomes a binary operator that behaves as follows:
a) it evaluates its lhs in boolean context
b) if this is true, ?? evaluates its rhs such that it
can't be undef
c) if this is false, ?? returns undef
2) the precedence of ?? is above // which naturally catches
the undef of a false condition.
This gives
$x = $y < 3 ?? "small" // "large";
and possibly even a low precedence version
$x = $y < 3 then "small" err "large"; # hmm
thence # old fashioned
therefore # long, but clear
An implementation could read:
&*infix:<??> (&cond, &code)
is parsed(...) # trait needed to insert {}?
{
if &cond() { return &code() but defined }
else { return undef }
}
Comments?
TSa
Juerd
> b) if this is true, ?? evaluates its rhs such that it
> can't be undef
But
$foo ?? undef // 1
then is a problem.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Damian Conway
> I'm still contemplating how to get rid of the :: in the
> ternary
>
> Comments?
I believe that the single most important feature of the ternary operator is
that it is ternary. That is, unlike an if-else sequence, it's impossible to
leave out the "else" in a ternary operation. Splitting the ternary destroys
that vital characteristic, which would be a very bad outcome.
Damian
Damian Conway
> At OSCON I was also thinking that it'd be really nice to get rid of
> the :: in the ternary and it occurred to me that perhaps we could use
> something like '?:' as the 'else' token instead:
>
> (cond) ?? (if_true) ?: (if_false)
>
> However, I'll freely admit that I hadn't investigated much further
> to see if this might cause other syntax ambiguities.
I think the main problem there would be the *visual* similarity
between the two.
Damian
Ashley Winters
Indeed. The "logical" (bad pun intended) operator to match with ?? is !!
(cond) ?? (if_true) !! (if_false)
Ashley Winters
Luke Palmer
> Thomas Sandlass skribis 2005-09-05 14:38 (+0200):
> > b) if this is true, ?? evaluates its rhs such that it
> > can't be undef
>
> But
>
> $foo ?? undef // 1
>
> then is a problem.
Yeah. Hmm, but I kinda like the look of ?? //, and I don't like the
overloading of :: in that way anymore. So it's possible just to add
a ternary ?? // in addition to, and unrelated to (from the parser's
perspective), the regular //.
?? !! ain't bad either.
Luke
Damian Conway
> Yeah. Hmm, but I kinda like the look of ?? //, and I don't like the
> overloading of :: in that way anymore. So it's possible just to add
> a ternary ?? // in addition to, and unrelated to (from the parser's
> perspective), the regular //.
Bad idea. This useful construct would then be ambiguous:
$val = some_cond()
?? $arg1 // $arg1_default
// $arg2 // $arg2_default;
> ?? !! ain't bad either.
It's definitely much better that sabotaging the (highly useful) // operator
within (highly useful) ternaries.
Damian
Luke Palmer
> Luke wrote:
>
> > Yeah. Hmm, but I kinda like the look of ?? //, and I don't like the
> > overloading of :: in that way anymore. So it's possible just to add
> > a ternary ?? // in addition to, and unrelated to (from the parser's
> > perspective), the regular //.
>
> Bad idea. This useful construct would then be ambiguous:
>
> $val = some_cond()
> ?? $arg1 // $arg1_default
> // $arg2 // $arg2_default;
Huh, yeah. We'd have to go one way or the other on that, and neither
of those are what you intend.
Not that being explicit is always a bad thing:
$val = some_cond()
?? ($arg1 // $arg1_default)
// ($arg2 // $arg2_default)
And I question your notion of "highly useful" in this case. Still, it
is probably linguistically not a good idea to overload // like that.
>
> > ?? !! ain't bad either.
>
> It's definitely much better that sabotaging the (highly useful) // operator
> within (highly useful) ternaries.
I guess the thing that I really think is nice is getting :: out of
that role and into the type-only domain.
Luke
Damian Conway
> Not that being explicit is always a bad thing:
>
> $val = some_cond()
> ?? ($arg1 // $arg1_default)
> // ($arg2 // $arg2_default)
No. What's a bad thing is creating new linguistic traps for when people
inevitably forget to be explicit.
> And I question your notion of "highly useful" in this case.
Huh??? Both // and the ternary are unquestionably highly useful constructs. My
point was that making them not work together is a Very Bad Idea.
> I guess the thing that I really think is nice is getting :: out of
> that role and into the type-only domain.
Yes, I'd certainly like that too. But not at the cost of turning // into a
bear-pit for the unsuspecting.
Damian
Patrick R. Michaud
At OSCON I was also thinking that it'd be really nice to get rid of
the :: in the ternary and it occurred to me that perhaps we could use
something like '?:' as the 'else' token instead:
(cond) ?? (if_true) ?: (if_false)
However, I'll freely admit that I hadn't investigated much further
to see if this might cause other syntax ambiguities.
Pm
Thomas Sandlass
Luke wrote:
> > > ?? !! ain't bad either.
> >
> > It's definitely much better that sabotaging the
> > (highly useful) // operator
> > within (highly useful) ternaries.
>
> I guess the thing that I really think is nice is getting :: out of
> that role and into the type-only domain.
Right. To make :: indicate type or meta was my primary concern.
So I see the following situation:
unwanted
?? ::
ASCII replacements
?? // # two binaries
?? \\ # I would like it as chaining binary nor
?? !! # wasn't binary ! the none() constructor
# and !! the binary nor---at least in Pugs?
Latin1 replacements
?? ¦¦
?? ¡¡
?? ¿¿
@Larry's choice?
--
TSa
arcadi....@gmail.com
can have define a binary
&*infix:<??> (&cond, Pair)
The trinary ?? :: will be imitated as
?? ... => ...
$x = $y < 3 ?? "small" => "large";
such ?? may be useful on its own as it impose Pair context on its
second argument.
Luke Palmer
> Right. To make :: indicate type or meta was my primary concern.
Okay, now why don't you tell us about this new binary :: you're proposing.
Luke
Thomas Sandlass
Luke wrote:
> Okay, now why don't you tell us about this new binary :: you're proposing.
Well, not a new one. Just plain old foo::bar::blahh and 'my ::blubb $x'
with relaxed whitespace rules. The ternary ?? :: is a splinter in my
mind's eye because it is not a compile time or symbol lookup construct.
The driving idea is to let tokens always mean the same or at least very
similar things in different contexts. And I thought that is your rating
as well. For :: that should be 'symbol table management'. E.g. ::= fits
that notion perfectly while the alternative separation of the ternary
doesn't.
There's yet another approach, to make ternary listfix:
$val = $cond ?? "true" ?? "false";
and perhaps we change it from ternary to (n > 2)-ary:
$val = $tested_only ?? $val_or_test ?? $other_or_test ?? $final;
But in both ways, recursive "ternary" needs parens.
Which can be regarded as a good thing. This listfix ??
behaves more like a rhs returning ||. As the RegularityGuy(TM)
I like the chaining triple // || \\ where // returns the first
defined, || returns the first true and \\ returns the first false.
And of course there are low precedence counterparts err, or, nor.
And the binary \ for none() construction. BTW is (\) indicating
the relative complement of the set operators? Even the unary ref
prefix makes sense as \ because it means 'not the value' or
'not right here but keep for later reference'.
--
TSa
Nicholas Clark
> There's yet another approach, to make ternary listfix:
>
> $val = $cond ?? "true" ?? "false";
So
^^ that one
doesn't do the same thing as
^^ that one?
I'd find that confusing in itself.
And that's without considering the change from the C<? :> of C and Perl 5.
[contents of this message may settle in transit, particularly if your mail
reader uses a proportional font.]
Nicholas Clark
Larry Wall
:
: Luke wrote:
: > Okay, now why don't you tell us about this new binary :: you're proposing.
:
: Well, not a new one. Just plain old foo::bar::blahh and 'my ::blubb $x'
: with relaxed whitespace rules. The ternary ?? :: is a splinter in my
: mind's eye because it is not a compile time or symbol lookup construct.
:
: The driving idea is to let tokens always mean the same or at least very
: similar things in different contexts. And I thought that is your rating
: as well. For :: that should be 'symbol table management'. E.g. ::= fits
: that notion perfectly while the alternative separation of the ternary
: doesn't.
I think that's a powerful argument even if we don't have an infix:<::>.
Plus I hate all infix "nor" operators due to my English-speaking bias
that requires a "neither" on the front. So let's go ahead and make
it ??!!. (At least this week...)
Larry
Patrick R. Michaud
>
> I think that's a powerful argument even if we don't have an infix:<::>.
> Plus I hate all infix "nor" operators due to my English-speaking bias
> that requires a "neither" on the front. So let's go ahead and make
> it ??!!. (At least this week...)
Yay !!
Pm
Juerd
> I think that's a powerful argument even if we don't have an infix:<::>.
> Plus I hate all infix "nor" operators due to my English-speaking bias
> that requires a "neither" on the front. So let's go ahead and make
> it ??!!. (At least this week...)
I was going to object based on !!foo being ! ! foo, but that !! is
spelled ? now, so nevermind.
Simon Cozens
> So let's go ahead and make it ??!!. (At least this week...)
I hereby christen this "the interrobang operator".
(http://en.wikipedia.org/wiki/Interrobang)
--
"Your fault: core dumped"
-- MegaHAL