Rod Adams <[EMAIL PROTECTED]> wrote:
> Larry Wall wrote:
> >Junctions can short circuit when they feel like it, and might in some
> >cases do a better job of picking the evaluation order than a human.
> >
> >
> I was afraid someone was going to say that. And I now must convert my
> reservations about junction autothreading from "very disturbing" to
> "you've got to be kidding".
...
> Not to mention it contradicts S09:
> "... that routine is "autothreaded", meaning the routine will be called
> automatically as many times as necessary to process the individual scalar
> elements of the junction in parallel."
>
> Now there is some wiggle room in there for short circuiting, but not very
> much.
The "wiggle room" is that the junction knows when it's being asked to
collapse into a Boolean, and can know if there's no possible way the
function it's running will have side effects. (That's why we're
declaring ties now. There may be cases where we can't know for sure
if there will be side effects or not--Halting Problem stuff--but we
can make sure the junction optimizer is conservative. The Halting
Problem becomes a lot easier if you ask whether a program *might* halt
instead of whether it *will*.)
In general, it seems to simply be an amazingly bad idea to autothread
a function with side effects. In fact, I'd recommend that we warn if
a side effect occurs during autothreading.
> Besides, people were telling me that my Sets were not needed, because
> they could be rendered with Arrays and Hashes. I fail to see how
> junctions are that different.
Junctions are intended to be used mainly within conditionals and other
statements; it's sort of a happy accident that they can be assigned to
variables. At the intra-statement level, there's nothing else (short
of involving a function like C<grep>) that'll do the job. From what I
saw, your sets are mainly designed to be used at the inter-statement
level, where we have arrays and hashes to do that sort of thing.
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?
> >: - 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. There's a
reason many people have trouble understanding what 'x' and 'y' are all
about in algebra. (And remember, algebra variables can sometimes have
multiple values--consider "y = x ** 2", for example.)
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") >>.) It's just a bit of
orthogonality that allows you to give "eggs, bacon, and toast" a name
and use it later.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
