5.8.0, possible parsing bug?

This seems to only pop up when doing a one liner. Is this a bug in the parser or a feature?

I really think you should be able write '1 ? : 1' instead of being forced into '1 ? ( ) : 1' anyways....

On Wednesday, March 12, 2003, at 02:12  AM, Joshua Hoblitt wrote:

> This seems to only pop up when doing a one liner. Is this a bug in
> the parser or a feature?

Feature. Definitely. :-)

> I really think you should be able write '1 ? : 1' instead of being
> forced into '1 ? ( ) : 1' anyways....

I don't. You can always write "( )" instead.

[...]

> perl -e '1?:1'
> syntax error at -e line 1, near "?:"
> Execution of -e aborted due to compilation errors.
>
> BUT...
>
> perl -ew '1?:1'
>
> No error???

perl -ew '1?:1' is *not* the same as perl -w -e '1?:1'.
perl -ew is perl -e 'w' without warnings turned on. Try perl -w -ew and
watch it explode.
The '1?:1' part is ignored because perl does not look for a filename to
execute because of the -e.
See L<perlrun>.

Regards,

Kay

> perl -ew '1?:1' is *not* the same as perl -w -e '1?:1'.

My bad.

> perl -ew is perl -e 'w' without warnings turned on. Try perl -w -ew and
> watch it explode.

That still doesn't explain...

The problem is that perl -ew is not the same as perl -we. When it's after the
-e, the w is taken as a piece of perl code eg try

perl -edie

or

perl -e'some fabby one-liner'

so

perl -ew '1?:1'

is actually the same as

perl -e 'w' '1?:1'

So your script is just the bareword w which is treated as a string when not in
strict mode. Try perl -w -ew to see a warning about it.

2 reasons for not requiring a space between -e and the perlcode you want to
execute are: it let's you knock off 1 character in a game of Perl golf and
that's the way it's always been so changing it could break existing
one-liners.

Would a warning be appropriate? The patch attached adds Perl warn

No space between -e and script body

when it occurrs, although the Perl golfers are definitely not going to like
that so I doubt this patch is going in,

F

1?:1 is incorrect Perl. perl -e '1?:1' will also give a syntax error. The
problem was previously masked by the fact that perl -ew '1?:1' never executes
1?:1 as a piece of Perl. For perl -ew '1?:1' the script is 'w' and 1?:1 is an
argument to the script,

F

> 1?:1 is incorrect Perl. perl -e '1?:1' will also give a syntax error. The
> problem was previously masked by the fact that perl -ew '1?:1' never executes
> 1?:1 as a piece of Perl. For perl -ew '1?:1' the script is 'w' and 1?:1 is an
> argument to the script,

That is a very good answer to my question. So now on to question #2: Why isn't '1?:1' valid Perl?

-J

The ?: operator is ternary, i.e. requires three arguments. The first,
in front of the '?' is the condition to be tested, the second between
the ? and : is the return value if the condition is false, after the :
comes the value for the other case.

Clearly you are missing the second argument.

BTW I really don't think this is the right place to ask these kind of
questions, sorry to be so blunt.
A good place would be perlmonks.org, some appropriate newsgroup (such
as comp.lang.perl.misc) or the Camel Book.

Regards,

Kay

On Wednesday 12 March 2003 02:07, Joshua Hoblitt wrote:
> That is a very good answer to my question. So now on to question #2: Why
isn't '1?:1' valid Perl?

Explicitly saying undef or 0 or whatever is not that much work and doesn't
leave people wondering if you really meant ?: or was it just that you hit
both keys together by accident (they're adjacent on my keyboad).

$a =;

is invalid too.

If you let the absence of anything to be the same as undef. You get problems.
If you were to apply that across the board you'd end up with func() meaning
func(undef) and no way of calling func with 0 arguments. So it can't be
applied across the board, so it must just apply in certain cases which people
would then have to remember. Plus, the already stressed Perl deities would
have to build these special cases into the parser,

F

Ok, lets drop this off list after this post.

> > That is a very good answer to my question. So now on to question #2: Why
> isn't '1?:1' valid Perl?
>
> Explicitly saying undef or 0 or whatever is not that much work and doesn't
> leave people wondering if you really meant ?: or was it just that you hit
> both keys together by accident (they're adjacent on my keyboad).

undef and a null list are not equivalent. What I'm saying here is that *I* think a null list should be the default value returned if nothing is defined. As more often then not I think this is what people intend. This is based on how I see others and myself using the ': ?' operator. At least something more intelligent then "syntax error" should be returned.

-J

--

If you want to return an empty list, then specify an empty list:

1?():1

Your example *is* a syntax error; the current behavior is correct.

Ronald

On Wednesday 12 March 2003 02:47, Joshua Hoblitt wrote:
> undef and a null list are not equivalent. What I'm saying here is that *I*
think a null list should be the default value returned if nothing is defined.  
As more often then not I think this is what people intend.  This is based on 
how I see others and myself using the ': ?' operator.  At least something 
more intelligent then "syntax error" should be returned.

Yes, my mistake you did say null list but I forgot. Anyway, I think the point
is that it's not such a great burden to type two characters whereas it might
be a great effort to change Perl to accept the new syntax.

Yes, Perl's syntax error stuff sucks, it's often completely wrong about the
line number, especially when a big if/else is involved. I suspect it's a big
job to fix that although, I have no idea how to go about it,

F

Fergal Daly <fergal@esatclear.ie> wrote:
> Yes, Perl's syntax error stuff sucks, it's often completely wrong about the
> line number, especially when a big if/else is involved. I suspect it's a big
> job to fix that although, I have no idea how to go about it,

Use another parser generator than yacc ?

Woohoo! Now you're talking. I'll whip out the Parse::RecDescent manpage
and have you a Perl grammar by tomorrow! ;-)

Seriously, it is possible to track line numbers better with yacc, it's
just a royal pain in the ass (which is why almost no compiler that uses
yacc does it well). I'd recommend g++ as a reference since it does a
fair job and C++ has some grammar that really defies line-tracking. Then
again, they may be relying on bison extensions.

On Thursday 13 March 2003 11:54, Rafael Garcia-Suarez wrote:
> Fergal Daly <fergal@esatclear.ie> wrote:
> > Yes, Perl's syntax error stuff sucks, it's often completely wrong about
the
> > line number, especially when a big if/else is involved. I suspect it's a
big
> > job to fix that although, I have no idea how to go about it,
>
> Use another parser generator than yacc ?

Oops didn't mean to post that to the list, not for fear of offending but for
fear of anyone thinking I expected them to do anything about it. I don't
imagine it's as simple as it sounds (not that it actually sounds simple),

F

if if .. else line-numbers problem isn't the parser's fault anyway.
Perl will print the correct line number in something like

if ($p) {
;
} elsif ( hi!  I'm a syntax error) {
;
}

but not in

if ($p) {
;
} elsif ( die "dying" ) {
;
}

That's because Perl keeps the line numbers only in STATEOP's.
I see no other solution than bloating the produced code with
nextstates - just for that.
That would be really stupid.
And even if every elsif ( .. ) will become elsif ( { .. } )
some people will say it still sucks and give examples:

1,
2,
3,
warn "add three lines ";

Regards
Adi

It's fine for perl to rely on bison extensions, perl sources are distributed
with an already-processed perly.c.

Moreover, as Adrian points out, it must be distinguished between syntax
errors (reported via the familiar yyerror() function) and other errors
(reported via some perlish croak() call.) The latter uses line numbers
that have been stored in COPs during the combination. (Although there might
be scary bugs hidden here as well. I remember a couple of tickets about
this.)