program exit code
Leopold Toetsch
communicate an exit-status to the shell.
We could do:
1) REG_INT(5) ...has exit code
2) end Ix ... end opcode has exit code
3) exit_code Ix .. set exit code
1) breaks existing programs but fits calling conventions
2) could break tools, which assume C<end> is opcode #0
so probably 3) or ...
Comments welcome
leo
Jos Visser
My EUR 0,02 is:
- I think that we (parrot) are currently in a state that we
should not be too concerned about backward compatibility
and breaking existing programs. There will be an infinite
amount of time when we will need to worry about it, so
let's not start too soon. Whilst we (mostly: you :-) are
developing parrot and have not declared anything "stable",
let's go for the best solutions within the defined
architecture...
- Because of that, I like option 1). Adding a new "exit_code"
op seems ugly to me. What would happen if I use "exit_code"
halfway through the program? (I can imagine, but still it
could make it hard to debug where in Jupiter's name the
exit code has been set. If this is the way to go, I would
be happier with a PMC type that abstracts the interpreter
and use an "exit-code" attribute...
- I like 2) too, since it matches the patterns in a lot of
languages that can set the return code in the exit/return/end
statement.
++Jos.nl
--
La vida no es la que uno vivió, sino la que
recuerda y cómo la recuerda para contarla...
~ Gabriel García Márquez
Nicholas Clark
> On Sun, Aug 24, 2003 at 12:09:21PM +0200 it came to pass that Leopold Toetsch wrote:
> > Parrot programs have commandline info in P0 but there is no means to
> > communicate an exit-status to the shell.
> > We could do:
> >
> > 1) REG_INT(5) ...has exit code
> > 2) end Ix ... end opcode has exit code
> > 3) exit_code Ix .. set exit code
> > 1) breaks existing programs but fits calling conventions
> - Because of that, I like option 1). Adding a new "exit_code"
> op seems ugly to me. What would happen if I use "exit_code"
> halfway through the program? (I can imagine, but still it
> could make it hard to debug where in Jupiter's name the
> exit code has been set. If this is the way to go, I would
> be happier with a PMC type that abstracts the interpreter
> and use an "exit-code" attribute...
>
> - I like 2) too, since it matches the patterns in a lot of
> languages that can set the return code in the exit/return/end
> statement.
I like the idea of (1), but I'm used to C. It seems quite clean if the
top level subroutine just "returns" to its caller, which happens to be
the shell. C (and perl) can both call exit midway through any routine.
(in a controlled fashion)
IIRC someone said that in python to exit (in what sounds like this fashion)
you just raise a system.exit exception. By default it gets caught by the
caller of your main routine, and your program exits. But you can trap the
exception, and do whatever you want. That feels powerful, more flexible
than an exit() library function à la C.
Nicholas Clark
Gordon Henriksen
> IIRC someone said that in python to exit (in what sounds like this
> fashion) you just raise a system.exit exception. By default it gets
> caught by the caller of your main routine, and your program exits. But
> you can trap the exception, and do whatever you want. That feels
> powerful, more flexible than an exit() library function à la C.
Sweet! Good for forcing Don't Panic! philosophy upon code you didn't
don't want to rewrite, or don't have the source for.
—
Gordon Henriksen
mali...@mac.com
Jos Visser
> > > 1) REG_INT(5) ...has exit code
>
> top level subroutine just "returns" to its caller, which happens to be
> the shell. C (and perl) can both call exit midway through any routine.
> (in a controlled fashion)
So, a language designer could generate something like:
set I5,1
end
> IIRC someone said that in python to exit (in what sounds like this fashion)
> you just raise a system.exit exception. By default it gets caught by the
> caller of your main routine, and your program exits. But you can trap the
> exception, and do whatever you want. That feels powerful, more flexible
> than an exit() library function à la C.
It is (I think), and the language designer can implement his/her "end"
or "exit" statement in this way... What I am trying to say is that
Parrot need not prescribe this...
Dan Sugalski
Since exiting may not really be exiting (don't forget, you could be
exiting back to the calling embedding program, or back to parrot if
you've been called recursively) I think we'd be better off returning
a status PMC, which would make me think that option 4, "exit Px" is
the way to go, or throwing an exit exception. (Which seems much less
nice, but I can see the advantages of being able to trap exit
requests from inner methods)
We can leave end with no params as op 0,the plain "I've fallen off
the end of the world, figure it out" last-gasp op to catch code that
just trots off the end of a bytecode segment as zero-padding is
cheap. We can use an alternate op that provides more information as
the normal exiting op.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk