Hi Konstantin, > > Right, the exit status is not stored anywhere. Maybe this is a design > > error, i.e. returning 'NIL' or a number from 'call' might have been a > > better choice. But changing this now would break existing programs. > > That what I did to fix such design problem: > - I renamed internal function "call" to "exe", > - I made "exe" to return exit code instead to T or Nil, > - in lib.l I made function "call" which behaves like old "call". > > Do you see some problems in this patch?
Yes, indeed. For one thing, 'exe' is not a good name for this. "exe" has a special meaning in PicoLisp: It is used to denote a list as an executable expression, which can be passed to 'eval' (as opposed to a 'prg', which is suitable for 'run' etc.). Then, such function wrapping introduces additional runtime overhead, but its purpose (the numeric exit code) is needed only in rare situations. An application program is typically not interested in the return code if 'call' fails, but will log the called process's standard error messages instead. I'm also not happy with the previously discussed solution, using a new global like *ExitStatus, as it clobbers the internal symbol space. > If no, what is your vision of fixing such problem? I think what we need is a general paradigm for handling such situations. There may be more functions where we will want to return additional information in certain cases. So what I would do is store this exit code in the '@@' symbol. We can recommend '@@' for general "secondary" results, and also '@@@' for "tertiary" results. A kind of optional second and third return value. This goes along the line of '@', which is already similar to this, as it keeps the results of conditional expressions in a well-defined manner. So if 'call' (and possibly other functions) return some optional value in '@@' (and perhaps '@@@'), it will not interfere with '@', and won't need a new global variable every time. The symbols '@', '@@' and '@@@' can thus be seen as volatile, being overwritten with auxiliary values whenever needed. This is already the case in the REPL, where they are overwritten each time a result is printed. To obtain the exit code in the REPL, you would do something like: : (or (call "command" "arg") (quit "command exit code" @@)) Does anybody have objections against this? If not, I'll put it tomorrow into pil64, pil32 and Ersatz. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
