Rod Adams wrote:
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.
But much less obvious. This is the core of my qualms. You're proposing we have all three of:
»foo« @x, @y;
foo [EMAIL PROTECTED], [EMAIL PROTECTED];
foo [EMAIL PROTECTED] @y»;all meaning very different things. That really worries me. I'd especially prefer that we didn't overload »« to mean both "linear vector" and "cross-product".
I certainly like the idea of having both abilities available; I'm just think the syntaxes need to be better differentiated.
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.
No, if I'd wanted to do that, I'd have written:
say for $substring.values;
Simply put, you're ignoring the fact that junctions have a boolean predicate. Which they do.
Yep. Isn't it useful that you can do that, and get more functionality out of a single construct?
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.
But that was precisely my point:
sub say (none(Junction) [EMAIL PROTECTED]) {...}I am completely convinced of this. Please express your reservations so I can address them.
sub get_matches { my @in = split /<ws>/, prompt 'search for: '; my @out = split /<ws>/, prompt 'but not: '; return %data{any(@in) & none(@out)}; }
my $data = get_matches();
No booleans anywhere in sight.
Err, no. Junctions *are* values, and those values are unique.
$x = one(2,3,3);
squishing the duplicate 3 is not allowed here.
True. one() is special in that regard. The other junctions squish/ignore duplicates.
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.
Then perhaps you need to think about it a little more. A hash is a mapping. In Perl 5 that mapping is restricted to Str->Any. In Perl 6 it's normally the same, but can be Any->Any. Which finally realizes the full power of the concept of mappings. For example:
my %seen is shape(IO) of Bool; # %seen maps IO objects to boolean values
while get_next_input_stream() -> $in {
next if %seen{$in};
$text ~= slurp $in;
%seen{$in} = 1;
}> 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.
for values $set {...}
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?
No, of course not. But you *can* change the index to any enumerable type:
my @weekly_rainfall is shape(Day);
@weekly_rainfall[Day::Wed] = 42; # millimetres
> 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.
I certainly don't like it. But that should be a different thread.
TMTOWTDI is a good thing. Personally I think my way was clearer. Your mileage may vary.> @s = 'item' _ [EMAIL PROTECTED];
That's:
@s = 'item »_« @x;
It does. Significantly. I like the idea, but hate the syntax. I'd much rather something more explicitly named. Like:
@s = 'item' »~« every(@x);
and:
say every(@first_name) ~ every(@surname);
But, y'know, this one almost convinces me. Especially when you consider:
sub func ($i, $j, $k) {...}
@x = func($a, [EMAIL PROTECTED], @z);
Which would again be more obvious as:
@x = func($a, every(@y), @z);
> 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.
Me too.
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.
Agreed. Let's leave it aside.
I consider the Prime Rule as essential to junction sanity.
I consider it an unnecessary and unhelpful restriction on the utility of junctions.
Without it, you're free to ignore that predicate
Yep.
If you're ignoring the predicate, a junction is just a list of values.
No. You can ignore the predicate because you don't need it *yet*.
Treat it as such. A list. Hyperquotes will deal with those situations nicely, though explicitly.
No they don't. See my C<get_matches> example above.
And I'm still very concerned that using hyperquote to parallelize functions and data *in different ways* will make the autothreading syntax harder to understand and differentiate.
Damian
PS: I'll be away for the rest of the week, but will happily continue to
argue when I return. ;-)
