This sounds like the right solution to me, Alex. Using @@ would be analogous to the C interface to system calls storing the error code in 'errno'.
Rand > On Feb 24, 2014, at 6:22 PM, Alexander Burger <a...@software-lab.de> wrote: > > 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:email@example.com?subject=Unsubscribe -- UNSUBSCRIBE: mailto:firstname.lastname@example.org?subject=Unsubscribe