Hi,
TSa wrote:
> Ingo Blechschmidt wrote:
>> Exactly. I'd like to add that, under the proposal, you always know
>> what things are passed how, only by looking for a "*".
>>
>> foo $var; # always positionally, even if $var isa Pair
>> foo *$pair; # always named
>
> But where is the name? Is it 'pair'? Like in
>
> foo :pair($pair);
No.
> or dynamically through
>
> foo $pair.key => $pair.value;
Yep.
> assuming that precedence of => is tighter than foo's.
I think it is.
> As I lengthyly ranted elsewhere in this thread the splat should just
defer the
> structural callability check until runtime. Well, and since everybody
> seems to be happy with .$pair denoting a call through a hardref stored
> in $pair, I don't understand why :$pair is not (yet) denoting a hard
> pairref. Both forms beeing interpreted in the context of the term to
Um, sorry, I don't understand... The only syntax I know of where a $
follows a . is calling method references:
my $meth = method (Foo $self: ...) {...};
$foo.$meth(...);
(But this syntax doesn't have, obviously, anything to do with
magical/non-magical pairs.)
> If full uncertainty isn't your thing, you might instruct the type
> system to make sure that $pair at least doesn't fail you on pairhood
>
> my Pair $pair;
Yep.
> foo $pair; # syntactically an item, thus a positional call
> foo *$pair; # guarranteed pair after splatting
>> foo [EMAIL PROTECTED]; # always positionally
>
> This makes perfect sense to me if you mean that the positionals
> that foo requests are satisfied in the order provided by @array
> without exceptions for pairs, not to mention subtypes of pairs
> or things that do the Pair role etc.
Yep, it's very important that Pairs are not exceptions.
>> foo *%hash; # always named (hash keys taken as parameter names)
>
> So that shall fail at compile time if foo has *anonymous* positionals?
Assuming that anonymous positionals exist, yes, I think so.
>> Previously, you wasn't able to know whether you passed something
>> positionally or by name:
>>
>> sub bar ($x) { grtz $x }
>> bar 42; # 42 passed to &grtz positionally
>> bar a => 42; # either the pair (a => 42) passed to &grtz
>> # positionally or the number 42 passed by name
>>
>> Under the new proposal, "grtz $x" always passes $x positionally. You
>> don't need &grtz's signature, nor do you need to know $x's type (is
>> $x a Pair?).
>
> Yep. But you could attempt to dispatch .key on $x in grtz:
>
> sub grtz ($item)
> {
> say $x.key;
> }
>
> and get a printout of 'Undef of Key' or so and 'a' respectively.
> HiHi, or a 'method not understood' exception if .key is not applicable
> to 42 ;)
Yep, of course. Pairs are, when not splatted with *, normal instances of
normal classes. (And when pairs are splatted, they are no longer pairs,
but syntactical constructs. (This might of course be implemented using
some class in the compiler, but this is an implementation detail.))
> Stuart Cook wrote:
>>>And look, if you really wanted to, you could define your own
>>>splat-style operator that works exactly as you describe. But I don't
>>>think it should be the default.
>
> I think that is difficult *without* parser support because
> a purely prefix thingy doesn't get the coderef the flattened
> array goes to.
Right, also &prefix:<*> can be faked as a normal subroutine (the PIL to
JavaScript compiler does this currently [1]), it has to be some kind of
grammatical rule or perhaps a macro if we want it to be implemented
properly.
>> Right. Under the proposal, you can -- *if you want to* -- use pairs
>> stuffed in arrays as named arguments:
>>
>> foo *hash(@array_of_pairs);
>> # @array_of_pairs's pairs used as named args
>
> This hash function there is hardly the same as the one from S06, that
> takes every other pair from @array_of_pairs, converts *the pair*
> to a key---which might preserve the key actually---and combines it
> with the next entry from the array as value?
Hm. I thought the hash() sub would be a bit more DWIMmy, so it can be
used for desugaring:
my %hash = (a => 1, "b",2, "c"); # desugared to
my %hash = hash(a => 1, "b",2, "c"); # which means
my %hash = (a => 1, b => 2, c => undef);
# thus:
sub hash ([EMAIL PROTECTED]) returns Hash {
my %hash;
while shift @things -> $thing {
given $thing {
when Pair { %hash{$thing.key} = $thing.value }
default {
my $value = shift @things;
%hash{$thing} = $value;
}
}
}
%hash;
}
But, looking at S06, the reference implementation of S06 isn't that
DWIMmy. Dunno whether this is simply a oversight in S06 or whether it
has been purposefully left out.
> @AoP = (a => 'a', b => 'b', c => 'c', d => 'd');
> %hash = hash @AoP;
> # = (AoP[0] => AoP[1], AoP[2] => AoP[3]);
> # = ( a => 'b' , c => 'd' );
>
> +%hash == 2; # true?
With my &hash, +%hash would be 4.
>> But if we made [EMAIL PROTECTED] mean that...
>>
>> * [EMAIL PROTECTED]'s pairs are always taken as named arguments,
>> there wouldn't be a simple way to pass pairs positionally.
>>
>> * [EMAIL PROTECTED]'s pairs are always taken as pairs,
>> there wouldn't be a simple way to use the pairs as named arguments.
>
> I might not sure that I get your idea correctly but haven't you
> shifted the magical pair filtering into your hash function?
Not quite. Under the proposal, you can be absolutely sure that you're
passing things positionally unless you explicitly use the splat
operator. And when you write "foo *%hash", you know exactly what
parameters are passed by names (as you can call %hash.keys).
Previously, you were not able to detect whether you pass things by name
unless you looked at the type of thing you're passing and the signature
of the sub you are calling.
>> * [EMAIL PROTECTED]'s pairs are taken as pairs or named arguments,
>> depending on the called subroutine (does it accept named params?
>> Do some parameters specifically want a Pair? etc.), we'd introduce
>> non-local non-determinism to a quite important part of the
>> language.
>
> It is *NOT* non-determinism! It is under-constraint behaviour.
> But that is considered a feature by the Perl 6 community, isn't it?
> Given the exact same &foo and @array_of_pairs a call
>
> foo [EMAIL PROTECTED];
>
> in a fixed environment should give the same result---always.
Yes, of course, sorry, I misused the term "determinism". I meant that
you, as a subroutine writer, can't know how things will end up being
passed:
sub foo ($thing) { bar $thing }
# Either $thing is passed positionally to &bar or
# $thing.value is passed by name ($thing.key).
So s[determinism][clear/manageable] please :)
--Ingo
