Brent 'Dax' Royal-Gordon wrote:
Rod Adams <[EMAIL PROTECTED]> wrote: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.
Larry Wall wrote:...
I was afraid someone was going to say that. And I now must convert myJunctions 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.
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;
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.
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< == >.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?
Shifting plurality in programming languages also incurs changes to the code around it.
Which significantly weakens the "mapping naturally to human linguistic structures" argument, IMO.In my experience, English tends not to superimpose several values on a: - 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.
given noun at once.
No, but nor does it have a concept quite like a variable.
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
