Darren Duncan wrote:
> Maybe the problem is a technicality with the parser because ...
>
> I'm guessing that the problem is that until you see the <-- then what you've
> read so far on its left is ambiguous as to whether it is a result type or a
> parameter. I can understand that but I don't know if its a big problem.
>
> AFAIK the token <-- isn't used anywhere yet in Perl 6 and so its presence
> inside a parameterized list would be unambiguous once you've read up to it.
And AFAIK the token --> is used in exactly one place in perl 6: within
signature syntax, to mark the transition from the parameter signature
to the "return type" signature. As with Darren, I don't see why this
would be a big problem. The biggest stumbling block that I can think
of is that a return type cannot have an invocant, whereas the
parameter signature might be able to have one. May I inquire as to
the nature of the complications that I'm missing, for my own
edification? (If you can't afford the time, I'll understand.)
> Anyway, while I would appreciate if <-- worked, if it doesn't then I can
> live with one of the existing alternatives ('of' being my current
> preference). This is a "nice to have" but not something I would push as
> hard yet as some other issues.
Yeah; definitely not an urgent request. I wonder how hard it would be
to write a module that hacks the parser to enable this feature...
Spitballing here: you drew an analogy to the feed operators. I wonder
if that analogy could be taken further: use --> and <-- outside of
signatures as feed operators - but instead of feeding arrays back and
forth, have them feed capture objects and engage in some implicit
currying. That is:
foo <-- $capture
$capture --> foo
would both be equivalent to:
foo :assuming(|$capture)
...or something to that effect. So instead of composing a series of
functions by nesting them in each others' argument lists, you could do
so by chaining them together using --> or <--.
But, like Darren's request, this definitely isn't something that I'd
insist on for 6.0.0.
--
Jonathan "Dataweaver" Lang
