On Wed, Nov 19, 2003 at 08:08:49AM +1100, Damian Conway wrote:
: Michael Lazzaro wrote:
:
: >So, just to make sure, these two lines are both valid, but do completely
: >different things:
: >
: > return if $a;
:
: Means:
:
: if ($a) { return }
:
:
: > return if $a { $a }
:
: Means:
:
: if ($a) { return $a } else { return undef }
No, it's a syntax error. You must write
return do { if $a { $a } }
to mean that. At least in my version of Perl 6. AIFIYP.
Sentences are a basic concept in all human languages. I've decided
that it's a bad psychological mistake to overgeneralize phrase-level
syntax to encompass sentence-level syntax. The Perl 6 grammar
will know when it's starting to parse a statement, and will
make distinctions based on that. That implies that any sub/macro
definitions for "if" have to be overloaded on parser state somehow.
We could play "multi" tricks, but I suspect the right solution is
more on the order of how we differentiate prefix:+ from infix:+.
So perhaps statement level "if" is statement:if, while modifier "if"
is modifier:if. Huffman says those should be long anyway.
It may well be that there is a generalization to be made here, but
it's more on the order of foo:bar refers to some grammar rule
or set of rules named foo.
Also, since multi is orthogonal to naming, it'd be possible to define
things such that all variants of "if" and "while" look like this:
multi sub *statement:if (...
multi sub *modifier:if (...
multi sub *statement:while (...
multi sub *modifier:while (...
But that sort of generality would completely screw up the optimizer,
I expect, since multi is an inherently run-time concept. It would
also create a great deal of magical action at a distance. Lexically
scoped macros (or other grammatical mods) are a much better approach
to control structure variation. There might be some room for lexically
scoped multi subs defining control structure, but you'd still probably
take the optimizer hit.
Larry
