On Sunday 30 June 2002 09:09 pm, 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.
I don't want to do it in Parse::RecDescent, I want to do it in Parse::FastDescent! Too bad it's not written yet... Damian? > > Neither am I, but we might as well throw in @{foo}, %{foo}, &{foo}, maybe > even $*{foo} (global symbolic reference?). $*{foo} was in there, at least. I'm still not quite diabolical to come up with the really screw-your-parser-up kind of stuff. ${"}"} and such come to mind, assuming that's legal. Also, where does $() come in? Is statement scalarification ever useful outside a string? > > > # Also, there are globals to consider > > [...] > > And the wonderous *@$*foo (flattened dereferenced global $foo?). I didn't do any sigil stacking at all in there, just context characters. I don't think there will be much sigil stacking, if any, beyond just stacking $$$$$'s to dereference scalar refs. > > > # 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? Well, perhaps PDL will have a reason to overload .. that way. There's no reason for the parser to choke on it by default - the compiler certainly should, though. As for .{}, that's an interesting thing to ponder. From the apocalypse, it says a { found where an operator is expected without preceding whitespace would be considered a subscript. Since '.' or '..' is the operator, the next brace would *normally* start a hash constructor or sub. I would guess '.' forces the next opening brace to start a subscript, but without the whitespace rule. $foo . { $x + 10 } # really means $foo{$x + 10}; Or maybe using binary . in this fashion is Bad? > > @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 ;). Well.... it's unambiguous, so I expect someone out there will try to be funky. > > > @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? There isn't much of a 'point' anymore except overlapping variable names. I would guess the p52p6 translator could do something silly like this: #!/usr/bin/perl5 @x = (500..800); $y = $x[rand($#x)]; #!/usr/bin/perl6 $x_array := @x_array; @x_array = (500..800); $y_scalar = $x_array[rand($x_array.length)]; The Highlander RFC (009) suggested making @x %x and &x all mean $x, and Larry liked the idea in general, but he wanted to keep them separate because people were used to it that way. Since $foo can be subscripted in all ways, I can see how other people might want to subscript @% as well. If someone were particularly perverted, they could make subscripts on &foo have reflective consequences. *shrug* > > 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){/). I would guess: foo{1} => ${ foo() }{1} foo.{1} => ${ foo() }{1} foo {1} => foo(sub {1}); foo {a => 1} => foo(hash(a => 1)); > > foo.(); # Is this &{ foo() }() or foo()? I would vote former > > aka foo()()? Sick... Hey, it has to mean something. > > # As a final sanity check, lets chain these things > > > > @.proc[$*PID].ps.{RSS}; > > == "@{.proc()[$*PID].ps().{RSS}}", right? Depends on if @.member means @{.member()}. I thought @.member accesses the actual data, and .member is the accessor function. == @.proc[$*PID].ps().{RSS} or .proc().[$*PID].ps().{RSS} via accessor > > > @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 '.'? No, @ never dereferences. @ is part of the variable name, it never specifies context. It's really doing: {{{{@proc}.[$*PID]}.ps()}.{RSS}} If you were specifying context, you'd parse the context thingy before the first brace parsing-wise. *@proc => *{@proc} > You might also want to add a couple of directly-chained subscriptings, > e.g. > > @foo[1]{2}(3)[4..6]. Yes, it needs those too. > /s, > sufferer at the fickle hands of PerlQt. Oh no, someone who recognizes me! I really butchered Perl's OO syntax when I did PerlQt-3. Someone should shoot me for that. Ashley Winters