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

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

   : (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

Reply via email to