Michael Lazzaro writes:
>
> Think, think. What do these things have in common?
>
> # known from A4
>
> for @a, sub ($x) {...} # primitive spelling
> for @a -> $x {...} # pointy sub, looks great
>
> map {...} @a # old-style map syntax
> map sub ($x) {...}, @a # primitive spelling
> map -> $x {...} @a # pointy sub? Oof, kinda opaque, here.
suppose that
-> ( ... ) { ... } #(1)
is prefix way of saying
{ ... } is sig( ... ) #(2)
so "->" is a more like prefix form of "is signature" then alias for
"sub" . so suppose that .
I can even assume that another way to say (2)
can be
{ ... } ( ... ) <- #(3)
so -> and <- are just another ways to say "is signature" before or
after the block .
so now we have ( no piping operators !)
#nonempty signature
for @a -> $x { ... } ;
map { ... } $x <- @a
#empty signature
for @a -> { ... } ;
map { ... } <- @a
I am not sure but it seems that parser can handle both (1) and (3) .
the problem with (3) is that parser will have to wait till it see <-
to realize what is going on
this is meaningfull ( but probably not very usefull ) now
sub ->( $x ) { ... } ;
sub { ... } ( $x ) <-;
>
> # purely speculative alternatives
>
> for @a : sub ($x) {...} # indirect object syntax
> for @a : -> ($x) {...} # not as good as before
>
> map @a : {...} # indirect object syntax
> @a -> map {...} # L2R
now , if we make totally crazy assumtion that signature ->( ... ) is
allowed to be separated by something from its block then this works
@a ->($x) map {...} #==> @a .map { ... } is sig($x)
@a -> map {...} #==> @a .map { ... } is sig( <empty> )
and if several signature specifications for the same block will just
concatenate to form a single concatenated signature then this will
work :
for @a -> ( $x ),
@b -> ( $y ) { ... }
is equivalent to
for zip(@a,@b)
-> ($x,$y)
{ ... }
Here "for" will have to dispatch the signature pieces to the block .
and it also be able to notice the "stream separator" in the signature
because it gets signature in 2 pieces explicitely.
so
->( $x ) ->( $y ) { ... }
or
{ ... } is sig( $x ) is sig( $y )
is same as
{ ... } is sig( $x ,$y )
so
> map {...} <- @a # R2L (these look great)
this is postfix (empty) signature specification
>
> # But the combination of both meanings doesn't work at all.
> # (pointy sub doesn't work as well with indirect-object or
> # pipe-like syntax, and vice versa)
>
> map @a : -> $x {...} # indirect + pointy sub
> map @a : sub ($x) {...} # arguably better looking?
>
> @a -> map sub ($x) {...} # objpipe + primitive spelling (OK)
> @a -> map -> ($x) {...} # objpipe + pointy sub (very NOT OK)
> @a -> map ($x) {...} # 'implied' sub? (Nope, NOT OK)
>
> I mean, it _looks_ like there should be way to put those together by
> making '->' mean something more encompassing than pointy sub. There's
> some beautifully expressive syntax in there.
>
> Think, think...
>
> MikeL
>
>
>
