-- 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 >/(?<!\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. > >
Is your boss reading your email? ....Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com