RFC: ellipsis "..." statement parses as operator. What types would be better?

[perl-critic]

RFC: ellipsis "..." statement parses as operator. What types would be better?

[adamkennedy]

The lexing process is strongly based around the three core types of
statement, structure and token.

Adding something else to that trio would be either heavy to implement or
high risk.

One key thing to note is that the following is required for a full
statement...

...; print "Hello World!\n";

Using ... on it's own results in a syntax error.

... print "Hello World!\n";

Thus, ... is not a statement, but is some form of Token (perhaps a unique
one, PPI::Token::Unimplemented), with perhaps a matching
PPI::Statement::Unimplemented to wrap over it.

Sometimes it's best to examine how perl itself handles real world cases to
clear up any potential confusion emanating from the documentation.

Adam

On 16 February 2014 18:06, moregan [email protected] wrote:

Perl 5.12 introduced the ellipsis statement, "...". Currently "..." always
parses as a PPI::Token::Operator. perl5120delta.pod refers to it as an
operator, but perlsyn is pretty clear that it's really a statement, making
the use of Operator wrong.

It's not too bad that the ellipsis becomes a child of a simple
PPI::Statement, but, given the fact that it throws, would it be more
appropriate to have it be a child of PPI::Statement::Break? A new statement
type altogether?

The existing token types don't seem to fit the ellipsis. Should there be a
PPI::Token::Ellipsis (subclass of PPI::Token)?

comments?

Reply to this email directly or view it on GitHubhttps://github.com//issues/41
.

[moregan]

Seems fine to me to use statement + token, as in:

ppidump 'die'
                    PPI::Document
                      PPI::Statement
[    1,   1,   1 ]     PPI::Token::Word         'die'

I went for PPI::Token::Ellipsis initially because "Unimplemented" seemed like a parsing failure. I'm not picky about it, though.

Could use PPI::Statement (simplicity, Occam's Razor; vs. doesn't convey much information), PPI::Statement::Break (close to common semantics with goto, etc.; vs transfer of control is to someplace not actually in the program), or PPI::Statement::Unimplemented (unambiguous; vs. one more type for everything to know about.)