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'.


> On Feb 24, 2014, at 6:22 PM, Alexander Burger <> 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
> -- 

Reply via email to