On Sun, Aug 24, 2003 at 01:07:48PM +0200, Jos Visser wrote: > 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
