return, continue, break -> ans = 1

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

return, continue, break -> ans = 1

John W. Eaton-6
On 29-Nov-2002, Miroslaw Kwasniak <[hidden email]> wrote:

| To: [hidden email]
| Cc: mirek
| Subject: return, continue, break -> ans = 1
|
| Bug report for Octave 2.1.40 configured for i386-pc-linux-gnu
|
| Description:
| -----------
|
| Hi,
|
|   Control statements: return, continue, break
|
|   If they are last statements in a line (not followed by semicolon)
|   octave displays: ans = 1

This is happening because of some changes I made in response to
http://www.octave.org/mailing-lists/bug-octave/2002/154.  The idea was
to make Octave's break, continue, and return statements behave more
like they do in Perl.  For example, make

  some_expression || break;

work as it would in Perl.  To implement this within the current
parser/interpreter, break must be an expression that returns a value.
But as people have pointed out, that causes a few other surprises for
existing Octave code.

My changes were simple.  They just made break, continue, and return do
what did before, but also behave as functions that returned 1 so they
would be valid in logical contexts.  But a simple change is not good
enough, and I don't see a way to allow the Perl-like behavior and also
be backward compatible without making some major changes to the way
Octave's parser and interpreter work.  I don't think it is worth the
effort and I've undone the changes I made earlier.  The CVS archive
should be updated within a few minutes.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: return, continue, break -> ans = 1

Etienne Grossmann-4

  Hello,

On Tue, Dec 03, 2002 at 11:36:52AM -0600, John W. Eaton wrote:
# On 29-Nov-2002, Miroslaw Kwasniak <[hidden email]> wrote:
#
# | To: [hidden email]
# | Cc: mirek
# | Subject: return, continue, break -> ans = 1
# |
# | Bug report for Octave 2.1.40 configured for i386-pc-linux-gnu
# |
# | Description:
# | -----------
# |
# | Hi,
# |
# |   Control statements: return, continue, break
# |
# |   If they are last statements in a line (not followed by semicolon)
# |   octave displays: ans = 1
#
# This is happening because of some changes I made in response to
# http://www.octave.org/mailing-lists/bug-octave/2002/154.  The idea was
# to make Octave's break, continue, and return statements behave more
# like they do in Perl.  For example, make
#
#   some_expression || break;
#
# work as it would in Perl.  To implement this within the current
# parser/interpreter, break must be an expression that returns a value.
# But as people have pointed out, that causes a few other surprises for
# existing Octave code.
#
# My changes were simple.  They just made break, continue, and return do
# what did before, but also behave as functions that returned 1 so they
# would be valid in logical contexts.  But a simple change is not good
# enough, and I don't see a way to allow the Perl-like behavior and also
# be backward compatible without making some major changes to the way
# Octave's parser and interpreter work.  I don't think it is worth the
# effort and I've undone the changes I made earlier.  The CVS archive
# should be updated within a few minutes.

  I only sent the report because I was unaware of the change and
thought it may be the result of some underlying problem. I only
noticed that when some of my functions started printing '1' (the value
of break) wherever I use it w/out a ';' after it. Otherwise, the
perlier, the better. Biased, me?

  Cheers,

  Etienne

 

--
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne


Reply | Threaded
Open this post in threaded view
|

Re: return, continue, break -> ans = 1

John W. Eaton-6
On  3-Dec-2002, Etienne Grossmann <[hidden email]> wrote:

|   I only sent the report because I was unaware of the change and
| thought it may be the result of some underlying problem. I only
| noticed that when some of my functions started printing '1' (the value
| of break) wherever I use it w/out a ';' after it. Otherwise, the
| perlier, the better. Biased, me?

I would be happy to have the Perl-like behavior, but not with all the
other bad side effects that happened with my simple-minded patch.  To
make it work correctly, I think we would have to have a completely
different way of interpreting expressions that involved break,
continue, and return.  Doing that is likely to complicate the parser
and interpreter a lot, and I don't think it is really worth it.  If
you (or someone else) can provide a nice clean set of patches that do
the right thing, I'd take a look at them.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: return, continue, break -> ans = 1

Pascal A. Dupuis-4
In reply to this post by John W. Eaton-6
On Tue, 3 Dec 2002, John W. Eaton wrote:

> My changes were simple.  They just made break, continue, and return do
> what did before, but also behave as functions that returned 1 so they
> would be valid in logical contexts.  But a simple change is not good
> enough, and I don't see a way to allow the Perl-like behavior and also
> be backward compatible without making some major changes to the way
> Octave's parser and interpreter work.  I don't think it is worth the
> effort and I've undone the changes I made earlier.  The CVS archive
> should be updated within a few minutes.
>

Hello John,

In fact, the || and && construct with a second member of return, break, or
continue is a sh mechanism (roughly speaking, Perl is a glue logic system
which supersedes sh). It is available in bash. May I suggest to ask to the
peoples maintaining bash how this is accomplished there, and eventually
transpose it to octave ?  Just a 2 eurocent suggestion...

Regards

Pascal Dupuis

--
Dr. ir. Pascal Dupuis
K. U. Leuven, ESAT/ELECTA (formerly ELEN):  http://www.esat.kuleuven.ac.be/
Kasteelpark Arenberg, 10; B-3001 Leuven-Heverlee, Belgium
Tel. +32-16-32 10 12 -- Fax +32-16-32 19 85


Reply | Threaded
Open this post in threaded view
|

Re: return, continue, break -> ans = 1

John W. Eaton-6
[I've removed all bug octave-maintainers, since I don't think this is
as much about a bug in Octave as something that should be discussed as
a possible new feature.  --jwe]

On  4-Dec-2002, Pascal A. Dupuis <[hidden email]> wrote:

| On Tue, 3 Dec 2002, John W. Eaton wrote:
|
| > My changes were simple.  They just made break, continue, and return do
| > what did before, but also behave as functions that returned 1 so they
| > would be valid in logical contexts.  But a simple change is not good
| > enough, and I don't see a way to allow the Perl-like behavior and also
| > be backward compatible without making some major changes to the way
| > Octave's parser and interpreter work.  I don't think it is worth the
| > effort and I've undone the changes I made earlier.  The CVS archive
| > should be updated within a few minutes.
| >
|
| Hello John,
|
| In fact, the || and && construct with a second member of return, break, or
| continue is a sh mechanism (roughly speaking, Perl is a glue logic system
| which supersedes sh). It is available in bash. May I suggest to ask to the
| peoples maintaining bash how this is accomplished there, and eventually
| transpose it to octave ?  Just a 2 eurocent suggestion...

I'm well aware that these kinds of operations are also possible in
Unix shells.

I'm also not opposed to this feature, but what I was trying to tell
you in my previous message is that it simply does not fit in with
Octave's current implementation.  I think I know how it is implemented
in bash, and although it is similar to the way Octave works, there are
some significant differences.

So I think to implement this feature properly would require more than
a few minutes of work.  I only attempted to do it because I thought I
saw a simple way, but it turned out to have more bad features than
good, so I had to remove it.  Now I'd rather spend time working on
things that I (and the person who signs my paycheck) think are more
important.

If you really want this feature in Octave, then I suggest you provide
a patch, or consider providing funding to someone who can implement it.

jwe