On Sun, 30 Jun 2002, Ashley Winters wrote:
> I don't know how the grammars are going, and I'm not fit to write one
> myself,
Hey, neither am I, but that hasn't stopped me from taking a stab or two,
figuring that through pain comes fitness. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
> but I wrote a list of variables I'll try to parse using any
> grammars which go by. Are all of these legal? I suppose that's more of
> a -language question.
Cc'd accordingly.
> # need more tests for ${}, I'm not evil enough for it
> ${foo};
Neither am I, but we might as well throw in @{foo}, %{foo}, &{foo}, maybe
even $*{foo} (global symbolic reference?).
> # Also, there are globals to consider
> [...]
And the wonderous *@$*foo (flattened dereferenced global $foo?).
> # off the subject, but lets make sure $foo.. is parsed correctly
> $foo..1;
> $foo..[1];
> $.foo..{1};
Color me slow, but are these even legal? What does an anonymous list
constructor do on the LHS of a range operator? I suppose it could just be
one example of something that is always true, but could it possibly be
useful other than by the perversity of overloading ".."? And would the
second require whitespace before the '{' to be parsed as a closure/block?
> @foo{1}; # I ass_u_me {} [] and () can be overloaded?
Blech! Even if it's legal, this seems like it should be a mandatory smack
upside the head. If we allow this, someone will overload {} to do hash
slices on %foo, and we'll be right back to Perl 5 ;).
> @foo(1);
> @foo();
Strange overloading again, or am I missing something? If we allow
subscripting and calling to be overloaded on variables with any kind of
sigil, what's the point of having sigils at all?
> foo{1}; # foo is unary here
Is this a hash subscript on a no-argument function returning a hash, or a
block passed to foo(&block), or a malformed hash constructor being passed
to foo(%hash)? I vote for the first, because I thought blocks' and
hashes' opening brackets always needed preceding whitespace (or at least
/(?<!\w){/).
> foo.(); # Is this &{ foo() }() or foo()? I would vote former
aka foo()()? Sick...
> # As a final sanity check, lets chain these things
>
> @.proc[$*PID].ps.{RSS};
== "@{.proc()[$*PID].ps().{RSS}}", right?
> @proc.[$*PID].ps().{RSS};
== "@{proc().[$*PID].ps().{RSS}}"? Or is that '[]' overloaded on a '.'
operator on '@proc'? In either case, we may have to do a sick amount of
look-ahead and guess-work to figure out whether the leading '@' is a sigil
or a dereference. Which has higher precedence: prefix '@' or infix '.'?
You might also want to add a couple of directly-chained subscriptings,
e.g.
@foo[1]{2}(3)[4..6].
/s,
sufferer at the fickle hands of PerlQt.
