Damian Conway wrote:
Rod Adams wrote:
> The purpose of a junction is to allow for performing several tests at a
> given time, with the testing code needing no knowledge of that junctions
> are present. While a junction can represent several values at the same
> time, such notions as "hold" and "contain" should be avoided, and they
> can be very misleading, they betray the fact that a junction is a single
> entity. As such, junctions are best thought of as Scalar. (Like other
> scalars, it may reference to something much more complex, but that's
> beside the point). Therefore the result of a junction evaluation should
> be Scalar.
Everything is okay to here.
[snip]
> Therefore, the only place that it makes sense to evaluate a junction > is in a place where a boolean value is expected. This brings us to our > "Prime Junction Rule": > > Junctions can only be evaluated as part of a boolean expression.
No.
> Attempting to evaluate a junction anywhere else is an error.
No.
This is my major point of the post. In my opinion, your example of:
# Print a list of substrings...
my $substring = substr("junctions", any(1..3), any(3..6));
say $substring.values();Is a perfect example of a place where saying:
# Print a list of substrings...
my @substring = substr("junctions", »1..3«, »3..6«);
say @substring;Is far more in line with what you're doing. Not to mention you likely wanted it to do:
my @substring = substr("junctions", »1..3«, »3..6«);
say [EMAIL PROTECTED];instead, putting nice "\n"s between values. My way also guarentees a certain order to the output.
Simply put, you're ignoring the fact that junctions have a boolean predicate. Which they do.
In this example, it didn't matter if you had used any/all/one/none.
> - There is still a limited case of "Nasty Side Effect Syndrome" that can
> be caused by having an assignment, output, or other undesirable type of
> function/operator as part of a boolean expression. There will therefore
> need to be a "is unautothreadable" trait to be had for functions. All
> builtin I/O and assignment functions should have this on. This
> protection is shallow. If the call is not in the text of the evaluated
> expression, it is not guaranteed to be tested.
I need to think about this. I'm not sure I'm convinced this isn't covered by
none(Junction) typing on parameters.
It is not.
By my proposal:
$j = any(1,2,3);
unless say($j) { die '...' }The say would thread, because of the boolean expression in the 'unless'. C< say > does not get the junction as a parameter. But C< say > needs to be marked that it's a no-no to thread over it.
> - If you wanted to thread a junction in a non-boolean way, you probably > didn't want a junction. You likely either wanted an array or a set, and > some combination of hyper operators. See below.
Not convinced of this.
I am completely convinced of this. Please express your reservations so I can address them.
> Sets > ==== > > Despite several surface similarities between a set and a junction, they > are quite different. Sets actually contain other things. Junctions hold > several values at once, and can even hold the same value more than once > at once.
Err, no. Junctions *are* values, and those values are unique.
$x = one(2,3,3);
squishing the duplicate 3 is not allowed here.
> Sets are inherently plural in thought process. Junctions are > inherently singular. The operations one wishes to perform on a set are > radically different from those performed on a junction.
True.
> Sets and hashes are an odd pair. Hashes are not a good basis for Sets > due to the restriction that the keys are strings. Even if this is not > the case,
It's not.
Changing the index type of hashes away from Str makes as much sense to me as changing the index type of arrays to something non-integral. None.
> In addition, a set evaluated in a list context returns it's members.
Err...then how do you create a list of sets???
grumble. Didn't think of that. I was looking for a simple way to say:
for $set {...}without throwing all kinds of special cases around.
> In addition to C< ~~ > for membership, we will borrow the {} > subscripters from hashes (not sure about the <> or «» variants).
You'd have to take them, I'm afraid. Introducing gratuitous inconsistencies would be a Bad Idea.
That's acceptable.
> In this form, a C< $set{$key} > reference will look for the element > that matches the place in the sort identified by $key (in other > words, the element with the matching .key() or value). If something > is there, it then returns C< .value||$_ >, assuming $_ is the element > at that place. > > This seemingly bizarre set of semantics gives us something very > powerful. One can make a Set of Pairs, which behaves much like a hash, > only with the ability to use any data type as the key.
Hashes already have this ability. I don't think overloading the hash access
syntax on Sets is worth the trouble.
And the same hash function would nicely handle non-strings? And I'll have to ask: Can you also change the index of arrays to Double?
I'd prefer to keep all the optimizations that hashs have as is. Throw all the abject weirdness elsewhere.
> Sets will borrow at least the following methods from Arrays: > grep, map, elems > and these from hashes: > keys, values, each, delete, exists
Keys? Surely sets only have values???
Sets have elements. Those elements can have .key and .value methods on them. Pairs for example. Any element that can't .key or .value will default to it's value.
btw, this whole Sets mimic hashes thing can be ripped out of my Sets proposal if nobody else likes it.
> HyperQuotes > =========== > > Just to round out any corner cases that the existing hyper operators do > not cover, and to add a clearer way to do some of them, we will allow > any list surrounded with » «, called hyperquotes, to thread the > immediate function, treating each element of the list as a scalar, and > have the expression return a list of the results. Some samples: > > @s = 'item' _ [EMAIL PROTECTED];
That's:
@s = 'item »_« @x;
TMTOWTDI is a good thing. Personally I think my way was clearer. Your mileage may vary.
> $x = 'abcdabc'; > @x = split »/a/, /c/, /d/«, $x;
That's:
@x = »split« [/a/, /c/, /d/], $x;
but I can see the appeal. Though I still think it's more readble to write:
@x = values split any(/a/, /c/, /d/), $x;
> @x = func($a, [EMAIL PROTECTED]);
That's:
@x = »func«($a, @y);
But, y'know, this one almost convinces me. Especially when you consider:
sub func ($i, $j, $k) {...}
@x = func($a, [EMAIL PROTECTED], @z);
I knew I wasn't coming up with good examples. It was 3:30am by the time I got to this part of the post.
> With these and all the other hyper operator, one should be able to easy
> perform the equivalent threading operation that they lost with the Prime
> Junction Rule.
I very much doubt we're going to lose it. ;-)
I was referring to losing the threading outside of boolean expressions.
> These are also infinitely more useful, since you can be guaranteed that > they won't short circuit, and they are in exactly the order you > specified.
This is admittedly very nice.
> So that's how I feel about things. The Prime Junction Rule was the big > revelation I had the other night. The rest of this was the logical > consequence spawned off that single thought to make it a complete idea. > > I think that overall in this process I've done the following: > - Kept the real power of Junctions intact. > - Provided fairly strong protection for newbies, without sacrificing > power. > - Kept Nasty surprises to a minimum. > - Got rid of the need for "half on" features. > - Provided back any power that the Prime Rule removed through sets and > expanded hyper ops.
Leaving aside the Unnecessary Restriction on junctions (a.k.a. Prime Rule ;-),
the main downside is that we would be multiplying our entities.
We'd need to be certain that the increased cognitive load is worth
the benefits.
Well, let me say this: Consider the Sets a separate issue. That should drastically help in "multiplying our entities". I'm not sure why I had convinced myself that the Set proposal was tied to the Prime Rule.
I consider the Prime Rule as essential to junction sanity. Without it, you're free to ignore that predicate, and begin a path of "junction explosion", where one simple junction suddenly converts vast swatches of execution into junctions, with no easy collapsing back down to what the author had in mind.
If you're ignoring the predicate, a junction is just a list of values. Treat it as such. A list. Hyperquotes will deal with those situations nicely, though explicitly.
-- Rod Adams
-- Rod Adams.
