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 > > >