develooper Front page | perl.perl6.internals | Postings from July 2002

Re: Perl 6 grammar progress?

Thread Previous | Thread Next
Erik Steven Harrison
July 1, 2002 11:18
Re: Perl 6 grammar progress?
Message ID:

On Sun, 30 Jun 2002 21:09:40  
 Sean O'Rourke wrote:
>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
>> 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,
>sufferer at the fickle hands of PerlQt.

Is your boss reading your email? ....Probably
Keep your messages private by using Lycos Mail.
Sign up today at

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About