«

"Anno Siegel" <> wrote in message
news:ctgif2$seo$...
> [defunct newsgroup comp.lang.perl trimmed]
>
> Jeremy Morton <> wrote in comp.lang.perl.misc:
>> Probably been mentioned before but I fail to see why Perl changed the
>> 'break' keyword to 'last', in loops. Bear with me on this - it seems
>> semantically more accurate to say 'break' - you're immediately breaking
>> out
>> of the loop. 'last' makes it sound like the current loop will be the
>> last,
>> but not that the execution should be stopped immediately, whereas break
>> makes it sound like the latter.
>
> It makes perfect sense when you name the loops appropriately:
>
> line: while ( <DATA> ) {
> next line if /^\s*#/;
> chomp;
> last line if $_ eq '__END__';
> # ...
> }
>
> What could be clearer? That's the idea behind "next" and "last", even
> if the label is not present.

Heh, well assume that the loop is:
line: while ( <DATA> ) {
next line if /^\s*#/;
chomp;
last line if $_ eq '__END__';
print $_ . "\n";
# ...
}

Personally, i'd find 'break' a lot more semantically sensible there. "If
the line says end, break out NOW." Using 'last' makes it look like "If the
line says end, make this the last loop iteration, eg. Finish this current
iteration and print $_." Oh well.


--
Best regards,
Jeremy Morton (Jez)

On 2005-01-30, Anno Siegel <> wrote:
> Not about bad choices. The real problem with brace-less statements under
> "if" is an different one. It happens with nested "if"s and a following
> "else":
>
> if ( $alive ) if ( $well ) get_up() else stay_put();
>
> is essentially ambiguous. You can't indicate if "else" is an alternative
> to the first condition:

In C, the else would get parsed as belonging to the innermost if.
I think that's fairly logical, especially if one indents their code
appropriately, eg:

if ( $alive )
if ( $well )
get_up();
else
stay_put();

Whereas this looks more sketchy, at least to my eye:

/* OMG! it smell like python! */
if ( $alive )
if ( $well )
get_up();
else
stay_put();

Though it's understandable that this can generate confusion. And
personally I wouldn't use ambiguous syntax like that. Even in the
first case, my code would be like this:

if ( $alive ) {
if ( $well )
get_up();
else
stay_put();
}

Just because you can do something doesn't mean you have to or should.
I'd really have liked to just be able to write simple code like this w/o
braces:

if ( $alive )
get_up();
else
stay_put();

And although the ?: operator can sometimes fill in the gap, it doesn't
work so well when there is one of more 'elsif' conditions.

But my name's not Larry Wall, and I don't make decisions around here.
So I'll shutup now.

On 2005-01-30, Jeremy Morton <> wrote:

> Heh, well assume that the loop is:
> line: while ( <DATA> ) {
> next line if /^\s*#/;
> chomp;
> last line if $_ eq '__END__';
> print $_ . "\n";
> # ...
> }
>
> Personally, i'd find 'break' a lot more semantically sensible there. "If
> the line says end, break out NOW." Using 'last' makes it look like "If the
> line says end, make this the last loop iteration, eg. Finish this current
> iteration and print $_." Oh well.

If that's what I wanted, I'd do

line: while ( <DATA> ) {
next line if /^\s*#/;
chomp;
print $_ . "\n";
# ...
last line if $_ eq '__END__';
}

--keith

--
kkeller-
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
see X- headers for PGP signature information

On 2005-01-30, Jussi Mononen <> wrote:
> You want to change Perl syntax to suit your personal preferences, although
> by definition the if-statement executes a {block} of code and needs braces
> because of that.

If there's no braces, then the block could be comprised of only the very next
statement.

> How would the compiler know what you meant if you are not using
> else-statements?
>
> if( $hungry )
> eat();
> drink();

It would then really mean this:

if( $hungry )
eat();
drink();

Instead of this:

> if( $hungry ){
> eat();
> drink();
> }

Jeremy Morton <> wrote in comp.lang.perl.misc:
>
> "Anno Siegel" <> wrote in message
> news:ctgif2$seo$...
> > [defunct newsgroup comp.lang.perl trimmed]
> >
> > Jeremy Morton <> wrote in comp.lang.perl.misc:
> >> Probably been mentioned before but I fail to see why Perl changed the
> >> 'break' keyword to 'last', in loops. Bear with me on this - it seems
> >> semantically more accurate to say 'break' - you're immediately breaking
> >> out
> >> of the loop. 'last' makes it sound like the current loop will be the
> >> last,
> >> but not that the execution should be stopped immediately, whereas break
> >> makes it sound like the latter.
> >
> > It makes perfect sense when you name the loops appropriately:
> >
> > line: while ( <DATA> ) {
> > next line if /^\s*#/;
> > chomp;
> > last line if $_ eq '__END__';
> > # ...
> > }
> >
> > What could be clearer? That's the idea behind "next" and "last", even
> > if the label is not present.
>
> Heh, well assume that the loop is:
> line: while ( <DATA> ) {
> next line if /^\s*#/;
> chomp;
> last line if $_ eq '__END__';
> print $_ . "\n";
> # ...
> }
>
> Personally, i'd find 'break' a lot more semantically sensible there. "If
> the line says end, break out NOW." Using 'last' makes it look like "If the
> line says end, make this the last loop iteration, eg. Finish this current
^^^^^^^^^
Ah... last time you said "loop" instead of "iteration". That made it
hard to understand. (The *loop* it the whole thing, it can be iterated
any number of times.)

> iteration and print $_." Oh well.

I have already answered to this elsewhere in the thread. To recapitulate,

- I don't see why anyone would assume such an awkward behavior to be
the norm. If you really need it, put the "last" statement last in
the loop.
- I don't see how "break" indicates the actual behavior any better than
"last" does.

Anno

gargoyle <> wrote in
news8bLd.3625$:

> On 2005-01-30, Anno Siegel <> wrote:
>> Not about bad choices. The real problem with brace-less statements
>> under "if" is an different one. It happens with nested "if"s and a
>> following "else":
>>
>> if ( $alive ) if ( $well ) get_up() else stay_put();
>>
>> is essentially ambiguous. You can't indicate if "else" is an
>> alternative to the first condition:
>
> In C, the else would get parsed as belonging to the innermost if.

That is what Anno was trying to explain to you. C resolves the ambiguity
by force. There is no a priori reason one interpretation is more logical
than the other.

> I think that's fairly logical,

That is because you have grown used to it.

> especially if one indents their code appropriately, eg:

But there is a language that depends on indentation to figure out what's
going on. It is Python.

> personally I wouldn't use ambiguous syntax like that. Even in the
> first case, my code would be like this:

But your coding preferences are not at issue here.

Sinan.

Jeremy Morton wrote:
> Bear with me on this - it seems
> semantically more accurate to say 'break' - you're immediately breaking out
> of the loop. 'last' makes it sound like the current loop will be the last,

The semantics of 'break' or 'last' are defined by the language (in this
case Perl), not by you.

Why not think of 'last' as "this is the last statement to run for the
loop".

It's always struck me as odd that the 'continue' statement in 'C'
starts the next pass of a loop. This is definitely a strange use of the
concept of "continue". But it is the semantics of 'C', so I accept it.
By trying to map particular programming concepts into single English words
with exisiting meaning there is always going to be some sort of mismatching
oddity.


--
Just because I've written it doesn't mean that
either you or I have to believe it.

On 2005-01-30, Abigail <> wrote:
> elsif? elsif? In C? I don't think so.

Well it's got 'else if' which is the same thing, no?
But anyway that's all academic. I was talking Perl code (that's why
the vars have a $ in front of them :-}), and how sometimes a ?: can
be used to omit braces. Because the if/elsif/else don't work w/o them.

On 2005-01-30, A. Sinan Unur <> wrote:
>> I think that's fairly logical,
>
> That is because you have grown used to it.

I grew used to it because the C book told me that's how it works. It's
true that's arbitrary, and they could have gone either way.

I think they chose the most convenient path though. Makes it easy to
write simple one-line statments and omit braces. Stuff like that comes
up all the time in my code, but in Perl I'm bound to the { and } keys.
Ouch, did you hear my pinky scream out in pain? It's in agony from all
those keypresses.

> But there is a language that depends on indentation to figure out what's
> going on. It is Python.

I do not wish to convert to a bondage/S&M language.

> But your coding preferences are not at issue here.

I know it's about language design and all that. So I'll not critisize
Larry's decision, whatever he goes with is probably for the best.

Abigail <> wrote in comp.lang.perl.misc:
> Anno Siegel () wrote on MMMMCLXX
> September MCMXCIII in <URL:news:ctjbm6$h4n$>:
> ??
> ?? Early compiler designs (Pascal, C, Algol) tended to ignore this ambiguity.
> ?? Later ones (Modula2, Perl, not sure about Algol6 decided to enforce
> ?? delimiters for this very reason. That was progress, there's no reason
> ?? to go back behind it.
>
>
> Algol 68 didn't use delimiters around then/else blocks. Algol 68 uses
> if ... then ... else ... fi which solves the problem in a different way.

Oh, right, thanks for reminding me.

od;
fi;
fi;

Maybe that's why the language never took off

It does show that the designers of Algol68, unlike those of Algol60, were
concerned about the ambiguity.

Anno