develooper Front page | perl.perl5.porters | Postings from August 2012

junctions (was Re: fixing smartmatch just hard enough (and when,too))

Thread Previous | Thread Next
Nicholas Clark
August 29, 2012 05:48
junctions (was Re: fixing smartmatch just hard enough (and when,too))
Message ID:
On Fri, Aug 24, 2012 at 10:30:49AM +1000, Damian Conway wrote:

> But what about:
>      is_prime( all(2,3) )
> If the junction is passed in, is_prime() returns:
>     all()  # i.e. false
> which is wrong...whereas the "proper" semantics of:
>     all( is_prime(2), is_prime(3))
> produces:
>     all(1,1)  # i.e. true.
> So it's perfectly possible to have a sane and reasonable semantics for
> junctions and a sane and reasonable semantics for is_prime(), that are
> not sane and reasonable when used together.
> In fact, that's why junctive arguments are supposed to distribute across
> subroutine calls, rather than be passed into them: because subroutines
> that are not specifically designed for junctive arguments generally
> break when passed junctive arguments (especially conjunctive arguments).
> In exactly the same way that subroutines not designed for complex
> numbers or surreal numbers, or matrices, or quaternions, generally don't
> work correctly when passed those kinds of values. Subroutines are coded
> assuming a particular arithmetic model, and data that doesn't follow
> those particular rules just won't work right.

Does that mean that we *ought* to be changing the calling conventions to
spot junctions on the way in and multiplex a single call into multiple
calls? This is how Perl 6 does it?

What happens if we don't change that? ie that junctions are in @_, and
a non-junction aware function is called? In what circumstances do things
go wrong?

Nicholas Clark

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