exit doesn't match its documentation

[p5pRT]

Migrated from rt.perl.org#100364 (status was 'rejected')

Searchable as RT100364$

[p5pRT]

From @nwc10

Created by @nwc10

I don't think that I'm being stupid here.

The docs say​:

=item exit

Evaluates EXPR and exits immediately with that value. Example​:

  $ans = \;   exit 0 if $ans =~ /^[Xx]/;

And C\<1 == 1> is an expression? Right?

$ perl -wle 'exit 1 == 1'; echo $? Useless use of numeric eq (==) in void context at -e line 1. 1 $ perl -wle 'exit 1 == 0'; echo $? Useless use of numeric eq (==) in void context at -e line 1. 1

adding parentheses forces the issue;

$ perl -wle 'exit(1 == 1)'; echo $? 1 $ perl -wle 'exit(1 == 0)'; echo $? 0

I'm aware of the Advice from Klortho. Particularly​:

#11943 Ah yes\, and you are the first person to have noticed this bug since 1987. Sure.

But it does seem to be an inconsistency between the documentation and the implementation. I assume that the implementation trumps the documentation here\, given that it's been constant as far back as I can test​:

$ ~/Sandpit/5000/bin/perl -lwe 'exit 1 == 1'; echo $? Useless use of numeric eq in void context at -e line 1. 1 $ ~/Sandpit/5000/bin/perl -lwe 'exit 1 == 0'; echo $? Useless use of numeric eq in void context at -e line 1. 1

and

$ /usr/local/perl4/bin/perl4.036 -wle 'exit 1 == 1'; echo $? 1 $ /usr/local/perl4/bin/perl4.036 -wle 'exit 1 == 0'; echo $? 1 $ /usr/local/perl4/bin/perl4.036 -wle 'exit(1 == 1)'; echo $? 1 $ /usr/local/perl4/bin/perl4.036 -wle 'exit(1 == 0)'; echo $? 0

I'm not sure what 'EXPR' should be replaced with\, in the documentation.

Nicholas Clark

Perl Info

``` Flags: category=core severity=low Site configuration information for perl 5.15.3: Configured by nick at Thu Sep 22 20:40:09 BST 2011. Summary of my perl5 (revision 5 version 15 subversion 3) configuration: Commit id: 9100e0355b96ae40c9800b9facaa6f990da38cb3 Platform: osname=freebsd, osvers=7.0-stable, archname=i386-freebsd-64int uname='freebsd plum.flirble.org 7.0-stable freebsd 7.0-stable #7: sat jul 26 20:39:26 bst 2008 root@plum.flirble.org:usrobjusrsrcsysplum i386 ' config_args='-Dusedevel=y -Dcc=ccache gcc -Dld=gcc -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@ccl4.org -Dperladmin=nick@ccl4.org -Dinc_version_list= -Dinc_version_list_init=0 -Doptimize=-g -Uusethreads -Duse64bitint -Accflags=-DNO_MATHOMS -Uusemymalloc -Duseperlio -Dprefix=~/Sandpit/snap5.9.x-v5.15.3-17-g9100e03 -Dinstallman1dir=none -Dinstallman3dir=none -Uuserelocatableinc -de' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='ccache gcc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DNO_MATHOMS -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-g', cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DNO_MATHOMS -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 20070719 [FreeBSD]', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags ='-Wl,-E -fstack-protector -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -lm -lcrypt -lutil -lc perllibs=-lm -lcrypt -lutil -lc libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector' Locally applied patches: @INC for perl 5.15.3: lib /home/nick/Sandpit/snap5.9.x-v5.15.3-17-g9100e03/lib/perl5/site_perl/5.15.3/i386-freebsd-64int /home/nick/Sandpit/snap5.9.x-v5.15.3-17-g9100e03/lib/perl5/site_perl/5.15.3 /home/nick/Sandpit/snap5.9.x-v5.15.3-17-g9100e03/lib/perl5/5.15.3/i386-freebsd-64int /home/nick/Sandpit/snap5.9.x-v5.15.3-17-g9100e03/lib/perl5/5.15.3 . Environment for perl 5.15.3: HOME=/home/nick LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/nick/bin:/usr/flirble/admin/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/home/nick/bin:/usr/local/sbin:/sbin:/usr/sbin PERL_BADLANG (unset) SHELL=/usr/local/bin/bash ```

[p5pRT]

From zefram@fysh.org

Nicholas Clark wrote​:

And C\<1 == 1> is an expression? Right?

$ perl -wle 'exit 1 == 1'; echo $?

1 == 1 certainly is an expression\, but this parses as exit(1) == 1\, so your code doesn't actually contain 1 == 1 as a subexpression. This is perfectly consistent behaviour​: unary functions (with unparenthesised argument lists) bind tighter than infix comparison ops. It's documented in perlop. You can see the same effect here​:

$ perl -wle 'print int 10.5 == 10'
1

-zefram

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @nwc10

On Thu\, Sep 29\, 2011 at 02​:50​:58PM +0100\, Zefram wrote​:

Nicholas Clark wrote​:

And C\<1 == 1> is an expression? Right?

$ perl -wle 'exit 1 == 1'; echo $?

1 == 1 certainly is an expression\, but this parses as exit(1) == 1\, so your code doesn't actually contain 1 == 1 as a subexpression. This is perfectly consistent behaviour​: unary functions (with unparenthesised argument lists) bind tighter than infix comparison ops. It's documented in perlop. You can see the same effect here​:

$ perl -wle 'print int 10.5 == 10'
1

I assumed that that was the reason. Thanks for the clarification.

I'm still not sure what 'EXPR' should be replaced with\, in the documentation.

[same for int\,

=item int EXPR X\ X\ X\ X\ X\

=item int

Returns the integer portion of EXPR. If EXPR is omitted\, uses C\<$_>.

and presumably this is the same for all unary functions.]

I find perlfunc unhelpful if it uses EXPR as the mnemonic for something described as "Keywords related to the control flow of your Perl program"\, which for all practical purposes is a statement\, given that it can't return and hence isn't meaningful as part of a larger expression.

(I think that goto is the only other "Keyword related to the control flow of your Perl program" which can take an EXPR. But it does bug me that meaningless expressions such as C\ are accepted without warning)

Nicholas Clark

[p5pRT]

From tchrist@perl.com

Zefram \zefram@&#8203;fysh\.org wrote   on Thu\, 29 Sep 2011 14​:50​:58 BST​:

Nicholas Clark wrote​:

And C\<1 == 1> is an expression? Right?

$ perl -wle 'exit 1 == 1'; echo $?

1 == 1 certainly is an expression\, but this parses as exit(1) == 1\, so your code doesn't actually contain 1 == 1 as a subexpression. This is perfectly consistent behaviour​: unary functions (with unparenthesised argument lists) bind tighter than infix comparison ops. It's documented in perlop. You can see the same effect here​:

$ perl -wle 'print int 10.5 == 10'
1

Yup\, that's the same example as I was about to provide.

Another related example where things aren't what you might think they are is this​:

  print (3+5)*8;   return (3+5)*8;

Those aren't anything like the same.

--tom

[p5pRT]

From tchrist@perl.com

Nicholas Clark \nick@&#8203;ccl4\.org wrote   on Thu\, 29 Sep 2011 15​:21​:36 BST​:

(I think that goto is the only other "Keyword related to the control flow of your Perl program" which can take an EXPR. But it does bug me that meaningless expressions such as C\ are accepted without warning)

This is kinda what my

  print (3+5)*8;   return (3+5)*8;

example is about. return is a keyword related to the control flow of your Perl program that takes an expression. The EXPR given to int\, print\, and return all three act different(ly) to/from one another.

--tom

[p5pRT]

From @tux

On Thu\, 29 Sep 2011 08​:25​:39 -0600\, Tom Christiansen \tchrist@&#8203;perl\.com wrote​:

Zefram \zefram@&#8203;fysh\.org wrote on Thu\, 29 Sep 2011 14​:50​:58 BST​:

Nicholas Clark wrote​:

And C\<1 == 1> is an expression? Right?

$ perl -wle 'exit 1 == 1'; echo $?

1 == 1 certainly is an expression\, but this parses as exit(1) == 1\, so your code doesn't actually contain 1 == 1 as a subexpression. This is perfectly consistent behaviour​: unary functions (with unparenthesised argument lists) bind tighter than infix comparison ops. It's documented in perlop. You can see the same effect here​:

$ perl -wle 'print int 10.5 == 10'
1

Yup\, that's the same example as I was about to provide.

Another related example where things aren't what you might think they are is this​:

print  \(3\+5\)\*8;

If I read this I read it as '( print (3 + 5) ) * 8;' unambiguously

return \(3\+5\)\*8;

useless use of '*8' in statement at line ...

Those aren't anything like the same.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20\, 11.00\, 11.11\, 11.23 and 11.31\, OpenSuSE 10.1\, 11.0 .. 11.4 and AIX 5.2 and 5.3. http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From zefram@fysh.org

Nicholas Clark wrote​:

I'm still not sure what 'EXPR' should be replaced with\, in the documentation.

That part of the documentation doesn't distinguish between parenthesised and unparenthesised argument lists\, which it would have to to correctly describe the parsing there. I think it shouldn't be replaced at all​: it's (mostly) documenting semantics rather than syntax\, and the =item line is a stylised representation of the parameter list rather than a real exposition of the grammar. perlop accurately indicates how unary functions are parsed.

-zefram

[p5pRT]

From tchrist@perl.com

"H.Merijn Brand" \h\.m\.brand@&#8203;xs4all\.nl wrote   on Thu\, 29 Sep 2011 16​:39​:02 +0200​:

If I read this I read it as '( print (3 + 5) ) * 8;' unambiguously

return \(3\+5\)\*8;

useless use of '*8' in statement at line ...

Nope. It's surprising how many people misunderstand that!

Witness​:

  % perl -le 'sub trick { return (3+5)*8 } print trick()'   64

It is parsed completely differently!!

--tom

[p5pRT]

From zefram@fysh.org

Tom Christiansen wrote​:

% perl -le 'sub trick { return (3+5)*8 } print trick()' 64

It is parsed completely differently!!

Because it's a list function\, because you can return a list.

-zefram

[p5pRT]

From Mark@Overmeer.net

Deja vu. Remember the discussion about the prototypes in POSIX.pm? To add a few​:

* Nicholas Clark (perlbug-followup@​perl.org) [110929 13​:38]​:

# \<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=100364 >

$ ~/Sandpit/5000/bin/perl -lwe 'exit 1 == 1'; echo $? Useless use of numeric eq in void context at -e line 1. 1 $ ~/Sandpit/5000/bin/perl -lwe 'exit 1 == 0'; echo $? Useless use of numeric eq in void context at -e line 1. 1

perl -MPOSIX=exit -wle 'exit 1 == 1'; echo $? 1

perl -MPOSIX=exit -wle 'exit 1 == 0'; echo $? 0

My suggestion was to add a prototype to POSIX​::exit because CORE​::exit($) has prefix-operator priority caused by its ($) prototype and POSIX​::exit is simply a list operator. Adding a simple name to the include list of POSIX changes the syntax of the whole file! Not only for exit.

But most people voted for the backward compatibility of POSIX​::exit(@​x) to return $x[0]\, over consequent behavior. -- Regards\,

  MarkOv

---

  Mark Overmeer MSc MARKOV Solutions   Mark@​Overmeer.net solutions@​overmeer.net http​://Mark.Overmeer.net http​://solutions.overmeer.net

[p5pRT]

From tchrist@perl.com

Zefram \zefram@&#8203;fysh\.org wrote   on Thu\, 29 Sep 2011 16​:12​:30 BST​:

Tom Christiansen wrote​:

% perl -le 'sub trick { return (3+5)*8 } print trick()' 64

It is parsed completely differently!!

Because it's a list function\, because you can return a list.

Ahem​:

  % perl -le 'print reverse (6+10)*8'   488

--tom

[p5pRT]

From @cpansprout

On Thu Sep 29 06​:38​:22 2011\, nicholas wrote​:

This is a bug report for perl from nick@​ccl4.org\, generated with the help of perlbug 1.39 running under perl 5.15.3.

----------------------------------------------------------------- [Please describe your issue here]

I don't think that I'm being stupid here.

Well.... :-)

The docs say​:

=item exit

Evaluates EXPR and exits immediately with that value. Example​:

$ans = \<STDIN>;
exit 0 if $ans =~ /^\[Xx\]/;

And C\<1 == 1> is an expression? Right?

Just as much as C\<1) == 1>.

$ perl -wle 'exit 1 == 1'; echo $? Useless use of numeric eq (==) in void context at -e line 1. 1 $ perl -wle 'exit 1 == 0'; echo $? Useless use of numeric eq (==) in void context at -e line 1. 1

adding parentheses forces the issue;

$ perl -wle 'exit(1 == 1)'; echo $? 1 $ perl -wle 'exit(1 == 0)'; echo $? 0

I'm aware of the Advice from Klortho. Particularly​:

#11943 Ah yes\, and you are the first person to have noticed this bug since 1987. Sure.

Someone else once reported the same problem with print $a xor $b.

$ perl -MO=Deparse\,-p -e 'exit 1 == 1'; (exit(1) == 1); -e syntax OK

But it does seem to be an inconsistency between the documentation and the implementation.

perlfunc - Perl builtin functions

=head1 DESCRIPTION

The functions in this section can serve as terms in an expression. They fall into two major categories​: list operators and named unary operators. These differ in their precedence relationship with a following comma. (See the precedence table in L\.)

[p5pRT]

@cpansprout - Status changed from 'open' to 'rejected'

[p5pRT]

From @cpansprout

On Thu Sep 29 07​:22​:07 2011\, nicholas wrote​:

On Thu\, Sep 29\, 2011 at 02​:50​:58PM +0100\, Zefram wrote​:

Nicholas Clark wrote​:

And C\<1 == 1> is an expression? Right?

$ perl -wle 'exit 1 == 1'; echo $?

1 == 1 certainly is an expression\, but this parses as exit(1) == 1\, so your code doesn't actually contain 1 == 1 as a subexpression. This is perfectly consistent behaviour​: unary functions (with unparenthesised argument lists) bind tighter than infix comparison ops. It's documented in perlop. You can see the same effect here​:

$ perl -wle 'print int 10.5 == 10' 1

I assumed that that was the reason. Thanks for the clarification.

I'm still not sure what 'EXPR' should be replaced with\, in the documentation.

[same for int\,

=item int EXPR X\ X\ X\ X\ X\

=item int

Returns the integer portion of EXPR. If EXPR is omitted\, uses C\<$_>.

and presumably this is the same for all unary functions.]

I find perlfunc unhelpful if it uses EXPR as the mnemonic for something described as "Keywords related to the control flow of your Perl program"\, which for all practical purposes is a statement\, given that it can't return and hence isn't meaningful as part of a larger expression.

$success or exit;

[p5pRT]

From @abigail

On Thu\, Sep 29\, 2011 at 06​:38​:22AM -0700\, Nicholas Clark wrote​:

# New Ticket Created by Nicholas Clark # Please include the string​: [perl #100364] # in the subject line of all future correspondence about this issue. # \<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=100364 >

This is a bug report for perl from nick@​ccl4.org\, generated with the help of perlbug 1.39 running under perl 5.15.3.

----------------------------------------------------------------- [Please describe your issue here]

I don't think that I'm being stupid here.

The docs say​:

=item exit

Evaluates EXPR and exits immediately with that value. Example​:

$ans = \<STDIN>;
exit 0 if $ans =~ /^\[Xx\]/;

And C\<1 == 1> is an expression? Right?

$ perl -wle 'exit 1 == 1'; echo $? Useless use of numeric eq (==) in void context at -e line 1. 1 $ perl -wle 'exit 1 == 0'; echo $? Useless use of numeric eq (==) in void context at -e line 1. 1

adding parentheses forces the issue;

$ perl -wle 'exit(1 == 1)'; echo $? 1 $ perl -wle 'exit(1 == 0)'; echo $? 0

I'm aware of the Advice from Klortho. Particularly​:

#11943 Ah yes\, and you are the first person to have noticed this bug since 1987. Sure.

But it does seem to be an inconsistency between the documentation and the implementation. I assume that the implementation trumps the documentation here\, given that it's been constant as far back as I can test​:

$ ~/Sandpit/5000/bin/perl -lwe 'exit 1 == 1'; echo $? Useless use of numeric eq in void context at -e line 1. 1 $ ~/Sandpit/5000/bin/perl -lwe 'exit 1 == 0'; echo $? Useless use of numeric eq in void context at -e line 1. 1

and

$ /usr/local/perl4/bin/perl4.036 -wle 'exit 1 == 1'; echo $? 1 $ /usr/local/perl4/bin/perl4.036 -wle 'exit 1 == 0'; echo $? 1 $ /usr/local/perl4/bin/perl4.036 -wle 'exit(1 == 1)'; echo $? 1 $ /usr/local/perl4/bin/perl4.036 -wle 'exit(1 == 0)'; echo $? 0

Doesn't it have to do with prototypes? Note the difference between​:

  $ perl -wE 'sub f {say $_ [0]} f 2 == 2'   1   $ perl -wE 'sub f ($) {say $_ [0]} f 2 == 2'   Useless use of numeric eq (==) in void context at -e line 1.   2   $

However\,

  $ perl -wE 'say prototype "CORE​::exit"'   ;$   $ perl -wE 'sub f (;$) {say $_ [0]} f 2 == 2'   1   $

I'm not sure what 'EXPR' should be replaced with\, in the documentation.

I don't have much a problem with the current documentation. For me\, it's clear if someone writes​:

  EXPR1 * EXPR2

that if I were to replace 'EXPR1' with '1 + 2'\, and 'EXPR2' with '3 + 4'\, the result won't be 21.

I guess one could do a s/\bEXPR\b/(EXPR)/g over perlfunc. I don't favour it; IMO\, it's already kind of implied.

Abigail

[p5pRT]

From zefram@fysh.org

Abigail wrote​:

However\, ... $ perl -wE 'sub f (;$) {say $_ [0]} f 2 == 2' 1

That was a bug\, fixed in 5.14.

-zefram

[p5pRT]

From @xdg

On Thu\, Sep 29\, 2011 at 9​:38 AM\, Nicholas Clark \perlbug\-followup@&#8203;perl\.org wrote​:

I'm not sure what 'EXPR' should be replaced with\, in the documentation.

While "perldoc -f XXXX" doesn't show it\, a full "perldoc perlfunc" has a lengthy opening section that discusses the issues.

Unfortunately\, like much of Perl documentation\, it's far to verbose while still being incomplete. For example\, it defines the term "LIST" but doesn't define any of the other terms except to imply that they are not in list context.

Possibly\, EXPR should be replaced throughout with terms that are descriptive of use. E.g. "exit VALUE". This would be consistent with the use of "FILEHANDLE"\, "DIRHANDLE"\, "VARIABLE"\, "REF"\, "BLOCK"\, etc.

-- David

[p5pRT]

From @ap

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2011-09-29 17​:45]​:

On Thu Sep 29 07​:22​:07 2011\, nicholas wrote​:

I find perlfunc unhelpful if it uses EXPR as the mnemonic for something described as "Keywords related to the control flow of your Perl program"\, which for all practical purposes is a statement\, given that it can't return and hence isn't meaningful as part of a larger expression.

$success or exit;

Or perhaps a lot more commonly\,

  my $head = shift // return;

[p5pRT]

From @abigail

On Thu\, Sep 29\, 2011 at 03​:40​:14PM -0400\, David Golden wrote​:

On Thu\, Sep 29\, 2011 at 9​:38 AM\, Nicholas Clark \perlbug\-followup@&#8203;perl\.org wrote​:

I'm not sure what 'EXPR' should be replaced with\, in the documentation.

While "perldoc -f XXXX" doesn't show it\, a full "perldoc perlfunc" has a lengthy opening section that discusses the issues.

Unfortunately\, like much of Perl documentation\, it's far to verbose while still being incomplete. For example\, it defines the term "LIST" but doesn't define any of the other terms except to imply that they are not in list context.

Possibly\, EXPR should be replaced throughout with terms that are descriptive of use. E.g. "exit VALUE". This would be consistent with the use of "FILEHANDLE"\, "DIRHANDLE"\, "VARIABLE"\, "REF"\, "BLOCK"\, etc.

I dunno.

Is '1 == 0' a value? If so\, it doesn't solve the ambiguity of 'exit 1 == 0'. But if '1 == 0' isn't a value\, it doesn't explain why 'exit(1 == 0)' is valid.

Abigail

[p5pRT]

From @xdg

On Thu\, Sep 29\, 2011 at 7​:25 PM\, Abigail \abigail@&#8203;abigail\.be wrote​:

Possibly\, EXPR should be replaced throughout with terms that are descriptive of use.  E.g. "exit VALUE".  This would be consistent with the use of "FILEHANDLE"\, "DIRHANDLE"\, "VARIABLE"\, "REF"\, "BLOCK"\, etc.

Is '1 == 0' a value? If so\, it doesn't solve the ambiguity of 'exit 1 == 0'. But if '1 == 0' isn't a value\, it doesn't explain why 'exit(1 == 0)' is valid.

I said 'VALUE' because that is what is in the text​:

  Evaluates EXPR and exits immediately with that value.

(This is extra confusing because the word "evaluates" implies that EXPR could be more than a scalar value -- which it can be\, but only if you parenthesize it to avoid operator precedence issues)

One could say 'exit EXITCODE' or something\, I suppose.

Short of rewriting perlfunc to use 'exit(EXPR)' or having an explicit statement of how things are prototyped\, I don't see any easy answers to make documentation clearer. How about this ultra redundant form​:

  exit EXITCODE   exit( EXPR )

-- David

[p5pRT]

From zefram@fysh.org

David Golden wrote​:

How about this ultra redundant form​:

exit EXITCODE exit( EXPR )

If you're trying to be that clear\, the "EXPR" is still wrong. "1\,2" is an expression\, but​:

  $ perl -lwe 'exit(1\,2)'   Too many arguments for exit at -e line 1\, at end of line   Execution of -e aborted due to compilation errors.

You could accurately say​:

  exit ARITHEXPR   exit(TERMEXPR)

except with the understanding that an arithmetic expression beginning with a paren will be treated as the latter form. And with some exception for expressions involving the low-precedence logic operators\, but I think we ought to be making that bit of the grammar sane rather than documenting the insanity. Since the grammar behaves the same way for most builtins\, I think it ought to be documented in one place\, not separately for each function\, possibly not in perlfunc at all.

-zefram

[p5pRT]

From @ikegami

On Fri\, Sep 30\, 2011 at 5​:58 AM\, Zefram \zefram@&#8203;fysh\.org wrote​:

You could accurately say​:

exit ARITHEXPR exit(TERMEXPR)

except with the understanding that an arithmetic expression beginning with a paren will be treated as the latter form.

I don't see how that helps. \<\<1\,2>> was given as an example of a problematic expression and it is neither arithemtic nor a term.

That and arithmetic expressions don't necessarilly start with parens. Isn't the syntax simply the following​:

  exit TERM

A TERM is a simple value or an expression in parenthesis.

- Eric

[p5pRT]

From zefram@fysh.org

Eric Brine wrote​:

I don't see how that helps. \<\<1\,2>> was given as an example of a problematic expression and it is neither arithemtic nor a term.

That's precisely how it helps. "exit 1\,2" doesn't match either of the forms that I listed\, for exactly that reason\, and indeed it's not parsed with "1\,2" as the argument. "1"\, however\, *is* an arithmetic expression\, and so in "exit 1\,2" the argument to exit is the "1".

That and arithmetic expressions don't necessarilly start with parens.

Yes\, precisely. The only arithmetic expressions that you can use with the "exit ARITHEXPR" form are the ones that don't start with parens.

the syntax simply the following​:

exit TERM

A TERM is a simple value or an expression in parenthesis.

That's not what "term" means in the Perl grammar.

-zefram

[p5pRT]

From @ikegami

On Fri\, Sep 30\, 2011 at 4​:42 PM\, Zefram \zefram@&#8203;fysh\.org wrote​:

Eric Brine wrote​:

I don't see how that helps. \<\<1\,2>> was given as an example of a problematic expression and it is neither arithemtic nor a term.

That's precisely how it helps. "exit 1\,2" doesn't match either of the forms that I listed\, for exactly that reason\, and indeed it's not parsed with "1\,2" as the argument. "1"\, however\, *is* an arithmetic expression\, and so in "exit 1\,2" the argument to exit is the "1".

Sorry if I wasn't clear\, but you missed my point. I was saying that your syntaxes don't allow for C\<exit(1\,2)>\, which is allowed. C\<1\,2> is not a term\, which is what you allowed in parens.

Yes\, precisely. The only arithmetic expressions that you can use with

the "exit ARITHEXPR" form are the ones that don't start with parens.

ok\, I was wrong there exit 1 + 2 is not what I thought it was.

the syntax simply the following​:

exit TERM

A TERM is a simple value or an expression in parenthesis.

That's not what "term" means in the Perl grammar.

Ya\, I thought exit 1 + 2 was ( exit 1 ) +2. That's wrong.

-zefram

[p5pRT]

From zefram@fysh.org

Eric Brine wrote​:

Sorry if I wasn't clear\, but you missed my point. I was saying that your syntaxes don't allow for C\<exit(1\,2)>\, which is allowed.

No\, it's not​:

$ perl -lwe 'exit(1\,2)' Too many arguments for exit at -e line 1\, near "2) " Execution of -e aborted due to compilation errors.

-zefram

[p5pRT]

From @ikegami

On Sat\, Oct 1\, 2011 at 2​:26 AM\, Zefram \zefram@&#8203;fysh\.org wrote​:

Eric Brine wrote​:

Sorry if I wasn't clear\, but you missed my point. I was saying that your syntaxes don't allow for C\<exit(1\,2)>\, which is allowed.

No\, it's not​:

$ perl -lwe 'exit(1\,2)' Too many arguments for exit at -e line 1\, near "2) " Execution of -e aborted due to compilation errors.

-zefram

Ack\, I thought the list was executed in scalar context. Don't know what I was thinking. Anyway\, 3+4 and 5 || 6 aren't terms\, but exit(3+4) and exit(5 || 60) are allowed. Tested this time​:

perl -we"exit(3+4)"

echo %ERRORLEVEL% 7

perl -we"exit(5||6)"

echo %ERRORLEVEL% 5

[p5pRT]

From zefram@fysh.org

Eric Brine wrote​:

Anyway\, 3+4 and 5 || 6 aren't terms\,

They are in the sense in which "term" is meant in the Perl grammar. It refers to a term of a list. See "term" and "listexpr" in perly.y\, and "parse_termexpr" in perlapi.

-zefram

[p5pRT]

From @ikegami

On Sat\, Oct 1\, 2011 at 5​:04 AM\, Zefram \zefram@&#8203;fysh\.org wrote​:

Eric Brine wrote​:

Anyway\, 3+4 and 5 || 6 aren't terms\,

They are in the sense in which "term" is meant in the Perl grammar. It refers to a term of a list. See "term" and "listexpr" in perly.y\, and "parse_termexpr" in perlapi.

In my experience\, term refers to an expression in parens or a value literal. I shouldn't be expected to read perly.y to understand how to use exit.

[p5pRT]

From @abigail

On Sat\, Oct 01\, 2011 at 05​:59​:40AM -0400\, Eric Brine wrote​:

On Sat\, Oct 1\, 2011 at 5​:04 AM\, Zefram \zefram@&#8203;fysh\.org wrote​:

Eric Brine wrote​:

Anyway\, 3+4 and 5 || 6 aren't terms\,

They are in the sense in which "term" is meant in the Perl grammar. It refers to a term of a list. See "term" and "listexpr" in perly.y\, and "parse_termexpr" in perlapi.

In my experience\, term refers to an expression in parens or a value literal. I shouldn't be expected to read perly.y to understand how to use exit.

It doesn't matter what it means.

The majority of the people reading the documentation will not know what it means.

Documentation that is only understandable if you have more than a passing knowledge of the implementation has little use to the average programmer.

I think it's far more important to have documentation that's understandable by the general programmer\, than have documentation that cannot be nitpicked by someone with a deep knowledge of both Perl and perl.

I strongly suggest to keep 'exit EXPR' in.

Abigail