develooper Front page | perl.perl6.language | Postings from September 2005

Re: Demagicalizing pairs

Thread Previous | Thread Next
September 20, 2005 09:04
Re: Demagicalizing pairs
Message ID:

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 $ 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 .@foo[42]; # 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 .@foo[42];  # 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!

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About