Re: [clisp-list] stacking init-functions in saveinitmem

[Bruno H. <br...@cl...>]

Sam Steingold wrote:
> The historical behavior of CLISP wrt repeated (SAVEINITMEM
> :INIT-FUNCTION) has been to stack :INIT-FUNCTIONs:
> 
> $ ./clisp -q -norc -x '(saveinitmem "1" :init-function (lambda () (print 1)))'
> $ ./clisp -M 1.mem -q -norc -x '(saveinitmem "2" :init-function (lambda () (print 2)))'
> $ ./clisp -M 2.mem -q -norc
> 
> 2
> 1
> [1]>
> 
> I.e., successively saved images invoke all the INIT-FUNCTIONs from the
> previous images.

This is not wrong, is it? The idea of the :init-function is that
 1) When you specify it, it takes control regardless what the :init-function
    of the previous image was.
 2) When you don't specify it, the previous :init-function takes control.

What you are observing is the behaviour when the init-function terminates
after doing some initializations, without taking control. It is indeed a
bit surprising then that the initializations are being done in "opposite"
order of what one would expect. But this is not the main use-case. The
main case is 1) above.

> I find that this feature makes it hard to recover the original CLISP
> REPL without accessing the internal SYS package:
> (saveinitmem "orig" :init-function #'sys::main-loop)

You're right. The default value of a public API should be public. It'd be
good to make #'sys::main-loop public (either as a function, or as a constant,
I don't mind.)

Bruno