From: Hal Fulton Date: 2012-07-03T05:39:45+09:00 Subject: Another random idea -- "break" at toplevel --f46d042ef67337f59304c3decce3 Content-Type: text/plain; charset=ISO-8859-1 There have been times that I wanted to just skip to the bottom of the current file. For one example, consider this idiom (not as popular as it used to be): if $0 == __FILE__ # Possibly many lines end I'd like to write this as: break if $0 != __FILE__ But of course, that doesn't work. And of course, exit would be appropriate if your program itself is in the current file. Has anyone else ever thought along these lines? I grant that the usefulness is very limited. A part of me thought: Well, should "break" just jump to the bottom of the innermost enclosing context? And a part of me likes this, but a part feels there are excellent reasons not to do it. For example: If you're inside a method but not inside a loop, break would act the same as return. It might confuse you if you think your break is inside a loop but isn't -- it would return instead of giving an error. (But if you can't tell the inside of a loop from the outside, your code needs to be made prettier.) Break inside a block, of course, is like a "return" from/for the block. That, I suppose, is the only time break takes a value -- but I don't think it would break anything (inside a method) if it *always* took a value. In that case, loops and class definitions could have (meaningful) return values. The only time I envision this "break " being truly useless is breaking from inside a required file -- we don't want to harm the semantics of require() returning true/false, and I can't think where else the value would go. Unless we made "break" at toplevel of a require return true by default -- but that seems even uglier. On a side note, the "$0 == __FILE__" expression is ugly to me. What I really would like if something like: break if __REQUIRED__ or simply __MAIN__ But this is just me rambling. Comment or ignore as you wish. Cheers, Hal --f46d042ef67337f59304c3decce3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There have been times that I wanted to just skip to the bottom of
the cu= rrent file.

For one example, consider this idiom (not as popular as = it used
to be):

=A0=A0=A0 if $0 =3D=3D __FILE__
=A0=A0=A0=A0= =A0=A0 # Possibly many lines
=A0=A0=A0 end

I'd like to write this as:

=A0=A0=A0 break = if $0 !=3D __FILE__

But of course, that doesn't work. And of cou= rse, exit would be
appropriate if your program itself is in the current= file.

Has anyone else ever thought along these lines? I grant that the
us= efulness is very limited.

A part of me thought: Well, should "b= reak" just jump to the bottom
of the innermost enclosing context? A= nd a part of me likes this, but
a part feels there are excellent reasons not to do it.

For example: = If you're inside a method but not inside a loop, break
would act the= same as return. It might confuse you if you think your
break is inside = a loop but isn't -- it would return instead of giving an
error. (But if you can't tell the inside of a loop from the outside, yo= ur
code needs to be made prettier.)

Break inside a block, of cour= se, is like a "return" from/for the block.
That, I suppose, is= the only time break takes a value -- but I don't
think it would break anything (inside a method) if it *always* took a
v= alue.

In that case, loops and class definitions could have (meaning= ful)
return values.

The only time I envision this "break <= ;value>" being truly useless is
breaking from inside a required file -- we don't want to harm the
s= emantics of require() returning true/false, and I can't think where
= else the value would go.

Unless we made "break" at toplev= el of a require return true by default --
but that seems even uglier.

On a side note, the "$0 =3D=3D __FI= LE__" expression is ugly to me. What
I really would like if somethi= ng like:

=A0=A0=A0 break if __REQUIRED__

or simply

=A0= =A0=A0 __MAIN__

But this is just me rambling. Comment or ignore as you wish.

Che= ers,
Hal

--f46d042ef67337f59304c3decce3--