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

Re: Perl 6 grammar progress?

Thread Previous | Thread Next
Ashley Winters
July 1, 2002 13:42
Re: Perl 6 grammar progress?
Message ID:
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:

@x = (500..800);
$y = $x[rand($#x)];

$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:


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

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