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 
  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!

Reply via email to