Rod Adams writes:
> >Junctions are intended to be used mainly within conditionals and other
> >statements;
> >
> If the set of these "other statements" is limited, consider creating a
> Junction class (which needs a "use Junction;" to activate), which
> overloads the various comparison operators for when a Junction is
> involved, and defines any/all/none/one as constructors? Throw in some
> overloading or bindings for |/^/&, and it looks like you get
> everything your asking for. Having a method evaluate: C< 5 ==
> any(4,5,6) > means that the interpreter doesn't need to autothread.
> This also makes it where only functions that were explicitly designed
> to use Junctions, or ones which didn't declare their signature, and
> thus are making no assumptions about what they are given, will perform
> the Junctive evaluations.
Okay, I think your proposal is thinning. Perl is a dynamically typed
language. I have no doubts that people will continue to ignore the type
system even though it's there. I probably will.
Let me demonstrate something:
sub is_prime($x) {
my @primes;
for 2..sqrt($x) {
if $_ % none(@primes) == 0 {
push @primes, $_;
}
}
return 1 if $x % none(@primes) == 0;
}
Run through your mind how this would be done with a junction in $x.
Particularly focus on:
2..sqrt($x)
What the hell does that mean? Do you get a junction of lists out? Or
does sqrt die because it's not expecting a junction?
When I say:
if is_prime(any(@stuff)) {...}
I expect to run the codeblock if any of my stuff is prime. Instead I
get an error, always. I could always do this:
if @stuff.grep:{ is_prime($_) } {...}
But the whole point of junctions is to get rid of obscure expressions
like that. Brent makes a fantastic case here.
The point is that when you say "makes no assumptions", you're giving the
sub writers too much credit. I think a reasonable assumption
(especially for these alledged "novices" you keep talking about) that
these two code segments are equivalent:
if $x == 2 {...}
elsif $x == 3 {...}
And:
if $x == 2 {...}
if $x == 3 {...}
No matter what the value of $x.
Yet in the presence of junctions, they are not. Also note that this is
a practical example. I like the former, I know people who like the
latter. It's a matter of style, and it's one that will bite you if you
don't know about junctions.
So what's it going to be? Avoiding the evil side of autothreading, or
not crippling the usefulness of junctions in the presence of unwary
code? It is a trade-off indeed. Java would choose the former. Perl
is choosing the latter.
Luke
>
> This way, you get all the happy functionality, at the cost of typing
> "use Junction;", and I get loads of protection against the evil side of
> autothreading. Doing Junctions this way also makes the them extensible.
> If someone figures out what a "not" junction is, they can add it in
> later. And people like me can't complain about what the module is doing
> to the language, because "all's fair if you predeclare" would be in effect.
>
> >I think junctions are important at the statement level because they
> >help make similar things look similar. Consider these two statements:
> >
> > if($foo == $bar) { .. }
> > if(grep { $foo == $_ } $bar, $baz) { ... }
> >
> >What makes these two statements so fundamentally different from each
> >other that they should be expressed in ways that *look* so different?
> >
> >
> You mean besides the shift in plurality? A shift in plurality in English
> forces you to modify a hefty portion of your sentence to accommodate it.
> At a minimum, you change your verb, in this case the C< == >.
> Shifting plurality in programming languages also incurs changes to the
> code around it.
>
> >>>: - Edge cases which, IMHO, do not merit the huffman level of several
> >>>: single character operators. All of which can be accomplished without
> >>>the
> >>>: use of junctions, though not as gracefully.
> >>>
> >>>Grace is important. Even more important is mapping naturally to human
> >>>linguistic structures, to the extent that it can be done unambiguously.
> >>>
> >>In my experience, English tends not to superimpose several values on a
> >>given noun at once.
> >>
> >>
> >
> >No, but nor does it have a concept quite like a variable.
> >
> Which significantly weakens the "mapping naturally to human linguistic
> structures" argument, IMO.
>
> >Junctions are equivalent to the English sentence "Get eggs, bacon, and
> >toast from the store". (In Perl, that'd be something like C<<
> >$store->get("eggs" & "bacon" & "toast") >>.)
> >
> >
> Or just have C< get() > take a list, and it's:
>
> $store->get(<<eggs bacon toast>>); # is that the latest use of <<>>?
>
> >It's just a bit of
> >orthogonality that allows you to give "eggs, bacon, and toast" a name
> >and use it later.
> >
> @shopping list = <<eggs bacon toast>>;
>
> gives them a name you can use later, as well.
>
> -- Rod Adams
