Re: Capture Object: why no verb?

Dave Whipp wrote:
> Perhaps I'm not fully groking the abstraction of the capture-object, but
> it seems to me that there should be a slot in it for the method. For
> dispatch, all three things are needed (invocant, method, args); so if
> you're going to put two of them in one object, then maybe the third
> thing belongs, too.

Hm, Perl 6 actually has two different ways of putting Capture to some
Code object... Following yesterday's P6AST draft I'll call them Call and
Apply respectively:

    moose($obj: 1, 2);     # this is Call
    &moose.($obj: 1, 2);   # this is Apply

    elk(named => 'arg');   # this is Call
    &elk.(named => 'arg'); # this is Apply

The difference is whether the Code is an object (Apply), or a "message"
name (Call).  As the same argument list can be reused in both cases, it
seems the "method" part is better left out from the abstraction.  That
allows:

    my $cap = \("Hello", "World");
    outs(*$cap);  # Sub Call (may optimize to Apply if &outs is lexical)
    $fh.say(*$cap); # Method Call
    $output(*$cap); # Apply

This also makes multiple Captures easily composable:

    say(*$cap, *$cap, *$cap); # "HelloWorldHelloWorldHelloWorld"

<P6C>
Of course, if we go all Smalltalkish, we can say that Apply is merely
sending the "postcircumfix:<( )>" message to the Code object, so that we
can treat _everything_ as a closure by defining:

    # Below demonstrates a (IMHO) bad idea
    sub postcircumfix:<( )> ($inv: \$cap) { say "Foo!" }
    1.(); # "Foo!" - method call falling back to sub call

But this defeats common closure-based optimizations, and penalizes
functional programming style for no apparent gain, so I think the
method-full form and method-less form are still better separated in the AST.
</P6C>

Audrey

• Capture Object: why no verb? by Dave Whipp
• Re: Capture Object: why no verb? by Audrey Tang
• Re: Capture Object: why no verb? by Dave Whipp
• Re: Capture Object: why no verb? by Audrey Tang