On 1/4/06, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> > The point was that you should know when you're passing a named
> > argument, always. Objects that behave specially when passed to a
> > function prevent the ability to abstract uniformly using functions.[1]
> > ...
> > [1] This is one of my quibbles with junctions, too.
>
> I'm confused at the confusion. To me, junctions are just magical
> values, not magical scalars. In theory, one should be able to create
> junctions of arrays, hashes, or subs just as easily.
This really has nothing to do with what I was talking about. Here's
what I was talking about:
my $j = get_junction(); # asks for a junction from the user
if $j.values > 4 { die "Too many values" }
my $k = get_junction();
if $k.values > 4 { die "Too many values" }
my $l = get_junction();
if $l.values > 4 { die "Too many values" }
You'd like to abstract this to:
sub toomany($j) {
if $j.values > 4 { die "Too many values" }
return $j;
}
my ($j,$k,$l) = map { toomany(get_junction()) } ^3;
But junctions are so "special", that this abstraction wouldn't work.
Yes, yes, you say "oh, just put a 'Junction' type on the $j
parameter". That's not the point. The point is that now I have to be
aware whenever I'm using a junction, and I have to declare all my
generics as being able to take junctions, instead of it just being
obvious that they do because I didn't put any constraints on the
values. I figure that if you don't have any constraints on the
values, you're not assuming anything about them, so using a junction
should be fine.
Of course, this was introduced for a reason:
sub min($x,$y) {
$x <= $y ?? $x !! $y
}
sub min2($x, $y) {
if $x <= $y { return $x }
if $x > $y { return $y }
}
In the presence of junctions, these two functions are not equivalent.
In fact, it is possible that both or neither of the conditionals
succeed in min2(), meaning you could change the order of the if
statements and it would change the behavior. This is wacky stuff, so
we said that you have to be aware that you're using a junction for
"safety".
But now I'm convinced, but I've failed to convince anyone else, that
the behavior's being wacky doesn't mean that it should be declared,
but that the behavior is just plain wrong. I figure that if something
says it's totally ordered (which junctions do simply by being allowed
arguments to the <= function), both of these functions should always
be the same. The fact is that junctions are not totally ordered, and
they shouldn't pretend that they are.
The other thing that is deeply disturbing to me, but apparently not to
many other people, is that I could have a working, well-typed program
with explicit annotations. I could remove those annotations and the
program would stop working! In the literature, the fact that a
program is well-typed has nothing to do with the annotations in the
program; they're there for redundancy, so they can catch you more
easily when you write a poorly-typed program. But in order to use
junctions, using and not using annotations can both produce well-typed
programs, *and those programs will be different*.
So that's what I was talking about. It didn't have anything to do
with the read-onlyness of junctions.
Luke
