Signature for the series operator

[Moritz Lenz]

Hi,

I had the pleasure to implement the series operator (&infix:<...>) in
Rakudo(*), and came across the difficulty to come up with a signature
for it. These are the use cases I want to cover:

1, 2 ... { $^a + $^b }
1 ... { $_ + 1 }

The first one can clearly be written as

sub infix:<...>(@values, Code $geneator)

but the second will fail to bind to that signature, because the 1 isn't
a list. I'd like to write

sub infix:<...>(*@values, Code $generator)

instead, but I think that required positional parameters are forbidden
after slurpy arrays. Do I have to install another multi that accepts a
single scalar? Or is there a neat trick to cover both use cases with a
single signature?

(*) Of course only the eager version works for now, ie the closure must
return a null list at some point

Cheers,
Moritz

[Jon Lang]

On Thu, Jun 25, 2009 at 1:20 PM, Moritz Lenz<mor...@faui2k3.org> wrote:
> Hi,
>
> I had the pleasure to implement the series operator (&infix:<...>) in
> Rakudo(*), and came across the difficulty to come up with a signature
> for it. These are the use cases I want to cover:
>
> 1, 2 ... { $^a + $^b }
> 1 ... { $_ + 1 }
>
> The first one can clearly be written as
>
> sub infix:<...>(@values, Code $geneator)
>
> but the second will fail to bind to that signature, because the 1 isn't
> a list. I'd like to write
>
> sub infix:<...>(*@values, Code $generator)
>
> instead, but I think that required positional parameters are forbidden
> after slurpy arrays. Do I have to install another multi that accepts a
> single scalar? Or is there a neat trick to cover both use cases with a
> single signature?

I'm surprised that '1, 2 ... { $^a + $^b }' binds properly. I suppose
that it's because of the relative precedences of '...' vs ','. ','
gets evaluate first, combining 1 and 2 into a two-element list; then
that list gets fed into the left side of '...'. If that's not the
case, then I don't see why '...' isn't just grabbing the '2', and then
failing to bind it because '2' isn't a list.

Perhaps non-associating infix operators should be an exception to the
usual rules concerning signatures, seeing as how you are guaranteed to
have exactly two positional parameters. In particular, I'm thinking
that a non-associating infix operator might be permitted to have a
slurpy array as either _or both_ of its positional parameters, on the
theory that Perl 6 should strive to allow as much flexibility as
possible within the constraints of ambiguity. (Currently, I believe,
it's sheer nonsense to have a slurpy array in either position.)

Or perhaps not; this may open a can of worms that we don't want to
mess with. I can think of two complications off the top of my head:
pipes and reducing operators. If you allow a slurpy list on either
side of an infix operator, how does that interact with piping
operators? If you allow one on both sides, how do you determine which
one you're piping to? If you reduce the operator so that it operates
according to function syntax (i.e., name first; then parameters) and
the first parameter is a slurpy list, how will you know when the first
parameter ends and the second begins? Do you use an "all but the
last" rule? etc.

--
Jonathan "Dataweaver" Lang

[Yary]

S02 says-

Anywhere you can use a single type you can use a set of types, for
convenience specifiable as if it were an "or" junction:

my Int|Str $error = $val; # can assign if $val~~Int
or $val~~Str

so would
sub infix:<...>(Array|Scalar $values, Code $generator)
be kosher?

I'm with Jon, wondering about two slurpies for infix operators.