Re: Package: symbol reading woes

On Jan 20, 8:30 pm, Kent M Pitman <pit...@xxxxxxxxxxx> wrote:
szergling <senatorZergl...@xxxxxxxxx> writes:
I have gradually evolved my thinking, trying out various method (shown
below) with various degrees of flexibility/robustness until I gave up
and settled on delayed-eval, completely inelegant, and hard to edit,
since the code passed to it is not a sexp, but raw text.

;; funcall a symbol
(funcall
(eval
'(intern "MCOMMAND" :matlab-ffi-extensions))
"1 + 1")

(defun dfuncall (package name &rest args)
"Delayed symbol interning funcall. Useful for calling symbols whose
package hasn't been loaded at read time."
(apply (intern name package) args))

(defun delayed-eval (code)
(eval (read-from-string code)))

;; Example usage
(lisp-fork
:sexp
'(progn
(blah blah)

(use-package :matlab-ffi-extensions)

(blah blah)

(dfuncall
:matlab-ffi-extensions "MCOMMAND"
"~{addpath('~a');~}" *matlab-paths*)

(blah blah)

(delayed-eval
"(progn
(matlab-ffi-extensions:close-matlab-engine *matlab-engine*)
(setf *matlab-engine* nil)
)")

(ext:saveinitmem "default.mem")))

I don't want to return to bash scripts to create Lisp images. Any
ideas? Maybe I'll need to settle for eval?

I don't know if I understand your question. Does this last not work?
You're asking for ideas about how to get it to work or how to do it
better?

Given the constraints of what you're describing, if it all has to work
in one form, then this may be what you have to do.

Your problem, it looks to me (I didn't execute your code and don't
have whatever Lisp version you're using, I suspect), is caused by
wanting to load a package definition in the same expression as you use
the symbols you'll get back. The Lisp package system is not directly
intended to do this and you have to do a kind of dance like this to
protect the expression long enough to be able to read it and execute
the first forms.

The problem would vanish if you could send several forms. [Or evaluate
them before the fork, if that's what's going on. Are you trying not to
pollute your pre-fork environment?]

I'm not sure by what means you're getting dfuncall loaded; you show it
in a separate form in the example above [although it would work to
have it in the progn, too]. So apparently you can tolerate some pollution
of the pre-fork environment. If so, maybe you can just load the library.

Or maybe you're trying to get the latest version of the indicated
package when you start up. In that case, maybe you can load a
compatible dummy version that just has enough symbols to get you
going.

So if you can execute forms before the lisp-fork that will fix a lot of
things. If you can't, then I bet you can also do this, though I didn't
test it:

(lisp-fork :sexp '(eval (read-from-string "...")))

For something like this I don't see any issue with using eval. This is
the kind of gluish thing for which eval is needed. (The only reason for
not using EVAL here would be if doing so was going to cause Lisp somehow
cause your lisp to think eval was now "in play" and could not be "gc'd out"
from some situation where it wanted to do that. That's quite an
implementation-specific issue, and might or might not come up, but I think
it's likely that it won't.)

You're almost surely using eval implicitly anyway to execute the
lisp-fork command anyway. (You're not compiling the above code and then
executing it as a fasl file, are you? Or if you are, you don't have to,
do you? I'd be surprised if so.)

Does any of this help?

.

Relevant Pages