HaloO,
Luke Palmer wrote:
The whole point was to deautomatize it! However, here's an
interesting solution: pairs are scanned for *syntactically* *on the
top level* of a function call (allowing named() or however we spell it
as a fallback when we want to be dynamic). However, :foo(bar) and foo
=> bar are equivalent again.
foo $x, $y; # two positionals, regardless of what they contain
foo $x, :y($y) # a positional and a named
foo $x, y => $y # a positional and a named
foo $x, (y => $y) # two positionals: $x and the pair y => $y
foo $x, (:y($y)) # same
In the fourth example, y => $y is no longer on the syntactic top
level, so it is not interpreted as a named argument.
Isn't that a task for the itemizer? I mean
foo $x, [y => $y] # syntactic arg type = (Item,Item)
# but static arg type = (Item,Pair)
foo $x, [:y($y)] # same
compared to
foo $x, y => $y # syntactic arg type = (Item,Pair)
# and static arg type = (Item,Pair)
foo $x, (y => $y) # same because () only groups for changed precedence
I hate to say it, but the named args should probably be marked
with : instead of + in the signature.
That's pretty cool. Can't say I like the secondary sigil: it's really
not marking a property of the variable, but a property of the
parameter list. That information should probably be kept inside the
parameter list alone.
I have changed my mind on $.foo and $:foo because these forms just lack
some identifyer chars between the two sigils $what.foo and $what:foo where
now $what indicates an item and .foo a method on it. Well, and :foo
indicates a keyed access on $what, but that isn't currently specced, right?
So what does 'what' default to in $.foo and $:foo? I think it simply is
'?SELF' and the twigil syntax gives a compile error if $?SELF is unbound.
The other two twigil combinations .$foo and :$foo in that logic would be
a method ref and a key ref respectively and as such both need something
on their left side. If that happens to be a bare word as in
blahh :$foo;
my interpretation is that first of all the symbol lookup for blahh has to
yield a sub. Since it's not sigiled &blahh it is a not yet invoked sub
invocation---to me this is not weirder than an unthrown exception---and
$foo has to contain a pair that is bound by name in the pending blahh
invocation. In other words it's a parametric, named parameter. BTW, if
you want the same through a sub call I would write it as
blahh :&foo();
See also my 'syntactic, static and dynamic type' mail. The forms
blahh .$foo;
blahh .&foo();
require blahh to be callable without params and return a suitable
invocant type for the method referenced by $foo and returned by
calling the sub foo respectively. This (il)logic can be applied
to other twigil combinations as well:
blahh [EMAIL PROTECTED]; # call on blahh ret val through method ref from
@foo[42]
blahh :%foo<some_pair> # call blahh with named param from %foo<some_pair>
All of these forms fail at runtime if e.g. @foo[42] doesn't yield a method
ref and even if it does the dispatch on the retval of blahh might fail. The
compiler could also warn or give errors if the invocations can be proven
to fail from the static type information, e.g.
my Int @foo;
blahh [EMAIL PROTECTED]; # Int not a Method subtype
Hmm, and if you mentally unify sub and class you get the idea that
$?SELF is bound to the current invocation err instance of the sub
and as such is amenable to the $:foo syntax for replacing placeholder
variables. That means
{ $:y < $:z && $:x != 2 }
is a shorthand for
sub ($x,$y,$z) { $y < $z && $x != 2 }
and hints at the possibility for writing sub definitions as
sub foo:(Item,Item,Item --> bool)
{
has $x; # first,
has $y; # second,
has $z; # and third Item
has $:trace;
if defined $:trace { say $:trace }
return $y < $z && $x != 2;
}
and call them as usual
foo 1,2,3; # no trace
foo 1,2,3, trace => 'should be false';
foo:trace<should be false> 1,2,3; # same
foo 1,2,3, :trace($count++);
foo 1,2,3, :$count++; # works?
and curry them with slot assignment
my &foo ::= &OUTER::foo:trace<foo called>;
foo 1,2,3; # prints traces
--
$TSa.greeting := "HaloO"; # mind the echo!
