On 5/6/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, May 06, 2005 at 01:26:10PM -0400, Rob Kinyon wrote:
> : > : Does this mean that @{foo()} can be written as @ foo()?
> : >
> : > I would prefer not. Use foo()[] instead.
> :
> : Does this mean that some constructs in Perl are parsed immediately
> : (such as foo() ...) and some are deferred (such as the [ in [>>+^<<]
> : ...)? I would think this potentially makes a difference in how P6 code
> : is read ...
>
> I don't believe that [>>+^<<] does deferred parsing. Reduction
> operators are not a fancy form of eval. Like symbolic refs, they're
> a factoring out of something that would otherwise have to be done
> by eval. Basically, they're emulating what
>
> @x.join(" $op ").eval
>
> *would* do, which is why [<] and [|] can work. But that's because the
> list-associative operators actually have some kind of listy interface
> for the general reduction code to call, or else they have special
> code to bypass the left-associativity of the naïve solution.
I apologize - I didn't make myself clear. I meant as a human reader,
not as the compiler. The reader would have to defer parsing of the [
until they see the whole expression for [>>+^<<], but would have to
parse foo() immediately to provide the context for the [ seen right
after. (This kinda relates to the thread I created yesterday re:
operatizing.)
I understand that the reduce [] operator will have its standard forms
([+], [<], etc) which will be immediately recognizable just like all
the other 3-char operators (==>, etc) will be. I'm just concerned
about the extended form and readability.
Rob
