On Wed, Apr 1, 2009 at 11:49 AM, Dave Whipp <d...@dave.whipp.name> wrote:
> The problem I see with this (other than implementation issues) is that it
> would lead to unintuitive behavior in some cases:
>
> my $x = one(10,20);
> if $x > 15 {
> # here, $x collapsed to "20"
> if $x > 5 { say "$x > 5" } else { say "not $x > 5" }
> }
> if $x > 5 { say "$x > 5" } else { say "not $x > 5" }
>
> Some people might be surprised if the two tests of "$x > 5" result in two
> different results.
That's surprising, yes, but I'd say the surprise comes from the fact that
it's a one() junction, which has extra weirdness on top of the general
junctional weirdnesses.
So yes, if we collapse the junction, $x is both > 5 and not > 5 according
to the output. If we *don't* collapse, $x will consistently fail the $x > 5
test - but then you have a value that is somehow both greater than 15 and
not greater than 5, which I would still call surprising.
I don't think that there is any single semantics that won't cause surprises
> (unintuitive behavior) in some cases.
Probably true.
> So I'd vote for going with simple semantics that are easy to explain --
> that is, don't attempt implicit junctional collapse. Provide operators to
> collapse when needed, but don't attempt to be too clever.
While it's easier to find clever programmers than to write clever software,
the gains from the latter are significant, as Larry's work pre- and
post-Perl has repeatedly demonstrated. When a language implementation
provides a feature like junctions that is arguably too clever by half to
start with, I'd rather there be a commensurate amount of cleverness in the
support of that feature.
Basically, I want the specified behavior to make sense as much as possible,
and for it to be easy to explain the places where it doesn't seem to make
sense. Even if it means we don't get that behavior in 6.0.0.
--
Mark J. Reed <markjr...@gmail.com>
