Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

Bug? (was Re: proposal: functional C<if>...)

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


perl-diddler at tlinx

May 5, 2012, 12:27 AM

Post #1 of 9 (165 views)
Permalink
Bug? (was Re: proposal: functional C<if>...)

Linda W wrote:
> Why should this yield an error:
>
> @_ ? #if (@_) {
> ($M, $tM)=(shift, 100*$H+$M)
> : #}else{
> ($H, $M) = (int $H/100, $tM % 60);
> #}
> Assignment to both a list and a scalar at /tmp/pp.pl line 12, near ");"
>
> Where's the assignment to a scalar?
---
Seems like this might also be a problem in 5.14... as it doesn't work
there either.

Is there some other interpretation that I'm missing?


uri at stemsystems

May 5, 2012, 12:50 AM

Post #2 of 9 (165 views)
Permalink
Re: Bug? (was Re: proposal: functional C<if>...) [In reply to]

On 05/05/2012 03:27 AM, Linda W wrote:
> Linda W wrote:
>> Why should this yield an error:
>>
>> @_ ? #if (@_) {
>> ($M, $tM)=(shift, 100*$H+$M)
>> : #}else{
>> ($H, $M) = (int $H/100, $tM % 60);
>> #}
>> Assignment to both a list and a scalar at /tmp/pp.pl line 12, near ");"
>>
>> Where's the assignment to a scalar?
> ---
> Seems like this might also be a problem in 5.14... as it doesn't work
> there either.
>
> Is there some other interpretation that I'm missing?
>

a classic bug in your code. = binds tighter than ?:. the rule is never
to use ?: for side effects like =. it should be used for its result
expression only. you broke the rule.

uri


perl-diddler at tlinx

May 5, 2012, 1:46 AM

Post #3 of 9 (160 views)
Permalink
Re: Bug? (was Re: proposal: functional C<if>...) [In reply to]

Uri Guttman wrote:
> On 05/05/2012 03:27 AM, Linda W wrote:
>> Seems like this might also be a problem in 5.14... as it doesn't work
>> there either.
>>
>> Is there some other interpretation that I'm missing?
>>
>
> a classic bug in your code. = binds tighter than ?:. the rule is never
> to use ?: for side effects like =. it should be used for its result
> expression only. you broke the rule.
>
> uri
---
'=' binds tighter, hmmmm....

I seem to remember that being so, but it sounds alot like the rules of
Fizzbin (APotA). Hmm....this operator precedence came from "C"? But as
it's written that way...would be a bit of a problem to change,

But it CAN'T why isn't it like the REGEX parser -- if it is obvious that
parsing it with = higher, won't work, why not parse it the way it would
work?

I.e. if it hits a ternary before an =, it's parsed as a ternary, else
assignment. Or can you show me code that would break, if the original
example were to work, as it *seems* to accomplish what the OP wanted.

When the parser hits the first ?, it should know to look for an
expression, the result of which would made available for assignment, a
return value, or thrown away; When it starts parsing the next
statement, it would have already pushed a level on the parser with the
close token being a ':'.

It sorta sounds like its a bug in the example code because it is
defined 'NOT TO WORK', not because it couldn't be parsed safely.


zefram at fysh

May 5, 2012, 2:33 AM

Post #4 of 9 (160 views)
Permalink
Re: Bug? (was Re: proposal: functional C<if>...) [In reply to]

Uri Guttman wrote:
> the rule is
>never to use ?: for side effects like =.

Unnecessary rule (although it might be considered good style to follow
it). Linda's precedence problem can be trivially fixed by adding
more parens.

-zefram


zefram at fysh

May 5, 2012, 2:36 AM

Post #5 of 9 (162 views)
Permalink
Re: Bug? (was Re: proposal: functional C<if>...) [In reply to]

Linda W wrote:
> But it CAN'T why isn't it like the REGEX parser -- if it is obvious that
>parsing it with = higher, won't work, why not parse it the way it
>would work?

Consistency. Switching operator precedence based on semantic requirements
would get very confusing. The regexp parsing behaviour of falling
back to interpreting metacharacters as literals is a source of bugs,
something we'd like to change rather than emulate.

-zefram


uri at stemsystems

May 5, 2012, 7:42 AM

Post #6 of 9 (156 views)
Permalink
Re: Bug? (was Re: proposal: functional C<if>...) [In reply to]

On 05/05/2012 05:33 AM, Zefram wrote:
> Uri Guttman wrote:
>> the rule is
>> never to use ?: for side effects like =.
>
> Unnecessary rule (although it might be considered good style to follow
> it). Linda's precedence problem can be trivially fixed by adding
> more parens.

true but i didn't want to show that fix. as you said it is a style rule
i teach and use. if i want side effects i use if/else.

uri


perl-diddler at tlinx

May 5, 2012, 4:53 PM

Post #7 of 9 (156 views)
Permalink
Re: enhancement request ;-) -- use 'default_to_working'; [In reply to]

Zefram wrote:
> Linda W wrote:
>
>> But it CAN'T why isn't it like the REGEX parser -- if it is obvious that
>> parsing it with = higher, won't work, why not parse it the way it
>> would work?
>>
>
> Consistency. Switching operator precedence based on semantic requirements
> would get very confusing.
Scratch operator precedence, strictly consider legal interpretations.

I.e. As you mentioned, I could use parens (I use the ('if' construct in my
original code, so they are already there ;-)).

However, generally, parens are required when you need to override
operator precedence to override 'defaults', that (like precedence), that
if NOT there,
would lead to ambiguity.

In this instance, there can be no ambiguity, as interpreting the
statement with
= as higher precedence, leads to a syntax error -- thus there is no
'guessing' -- it should never have tried to parse the statement
illegally but defaulted to the only legal interpretation.

I.e. rather than having defaults that *create errors*, why not have
defaults that produce working code? With the use of the ternary
operator, it is known in advance that there will be 3 expressions. It
makes no sense to interpret ambiguous situations to the deficit of the
user. The only sense where one would want to increase user errors, is if
you are a sadist or needing to scrutinize for security (is there a
difference?).

What I would propose is that the default to die w/errors be
override-able with a
use default_to_workable, vs. the current default which seems to prefer
errors over working code if there is any ambiguity.

It would be purely *optional*... i.e. not a default, but usable by
anyone in their code.

Does that sound more reasonable? Would it be a major pain with the
current parser?


ikegami at adaelis

May 6, 2012, 5:13 PM

Post #8 of 9 (153 views)
Permalink
Re: enhancement request ;-) -- use 'default_to_working'; [In reply to]

On Sat, May 5, 2012 at 7:53 PM, Linda W <perl-diddler [at] tlinx> wrote:

> It should never have tried to parse the statement illegally but defaulted
> to the only legal interpretation.


It didn't. Not even in your example. There is no error parsing

f() ? ($x,$y) = z() : ($i,$j) = k();

It's a compilation error. But that's not really relevant.

Your idea isn't good. This is what we'd get:

f() ? $x = 2 : $i = 3; # ( f() ? $x : $i ) = 3.
f() ? $x = 2 : ($i) = 3; # f() ? ( $x = 2 ) : ( $i = 3 );

How does one explain that to anyone?! Magically fixing just the rare case
makes no sense.

- Eric


davidnicol at gmail

May 7, 2012, 10:20 PM

Post #9 of 9 (153 views)
Permalink
Re: Bug? (was Re: proposal: functional C<if>...) [In reply to]

> Linda W wrote:
>
>> Why should this yield an error:
>>
>> @_ ? #if (@_) {
>> ($M, $tM)=(shift, 100*$H+$M)
>> : #}else{
>> ($H, $M) = (int $H/100, $tM % 60);
>> #}
>>
>
how about: because if it didn't yield an error, when @_ is non-empty
($M,$tM) would get assigned to twice, which is surely not what the coder
wants.

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.