Re: Package: symbol reading woes

Oopsies, please ignore previous post, it was posted in error.

On Jan 20, 8:30 pm, Kent M Pitman <pit...@xxxxxxxxxxx> wrote:
szergling <senatorZergl...@xxxxxxxxx> writes:

[[ ... ]]

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?

Apologies again for how vague the question was. It was more a
brainstorm request. Yes, it works, I just want something better. Eg,
can we arrange for

(package1:fun 1 2 3)

to read into a list of (forward-referenced-symbol number number
number), so that if package1 exists, the forward-reference works out
fine at evaluation time. Otherwise, an error is thrown. I guess it
could be called a "late-binding symbol-intern".

Maybe I am thinking about a macro to do:

(with-late-intern
("USE-PACKAGE" :package1)
("USE-PACKAGE" ":PACKAGE2") ;; can also do keywords
("PACKAGE1:FUN" 1 2 3)
("+" 1 "PACKAGE1:*VAR*"))

(may need to escape string data separately)

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.

Yes, that is exactly the problem. Don't some Schemes 'solve' this
'transparently' with their module systems? I don't know.

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 too worried about pollution. I don't think I can send several
forms successively -- the only way to do that might be to use LOAD.

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.

I can use load, but if you imagine what I was trying to do, compare
typing everything at the REPL vs saving into file then LOAD. I was
looking for the least effort when typing out code. However, there
certainly is room to play with loading files, which currently looks to
be the most promising avenue to try.

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.

Don't know, this sounds too involved for REPL work. The sexp sent to
lisp-fork is a way to document how an image was created, so I can make
new slightly different images when required. Ultimately, I was trying
to run code on a cluster at some useful level of abstraction. Eg, the
cluster can be pretty congested, so some way to have fine grained
job-submission is useful. I thought some generic way to deal with
multiple Lisps and module dependency tracking would be nice here.

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 "...")))

Don't think I can do a single, whole, read-then-eval like this. It has
to contain multiple selectively-delayed eval-reads. Otherwise, it's no
different from the problem with "wanting to load a package definition
in the same expression as you use the symbols" (above).

Eg:

'(eval
(read-from-string
"(progn
(use-package :package1)
(package1:fun1 2 3))"))

won't work.

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

Is this a tree-shaking issue? I'm not too worried about
executable/image size.

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

In case it wasn't clear, lisp-fork is a "run-shell-command" hack, with
"shell arguments" passed in -- one of which is an input sexp to be
evaluated. I think you mean that eval is used implicitly in that the
forms are evaluated in a REPL: sbcl --eval, or clisp -x, etc.

Does any of this help?

I'll try them, keep exploring, and see what's nicest. I'll probably
not have too much time to work my way out of this mess this time. It
will have to stay messy.

Thank you for trying :)

.

Relevant Pages

  • Re: Package: symbol reading woes
    ... The Lisp package system is not ... different from the problem with "wanting to load a package definition ...
    (comp.lang.lisp)
  • Re: How to organize source files
    ... I usually put one package per file, and usually one class per file, ... functions too so it won't be as simple to resolve the dependencies at ... Lisp programs are functions. ... program, you'll just have to tell it to load the image, and depending ...
    (comp.lang.lisp)
  • Re: Loading packages
    ... I just want to put (use-package "lexer") at the top of my source file and let the lexer package load what it needs. ... Package definitions are normal Lisp code. ...
    (comp.lang.lisp)
  • Re: Loading packages
    ... Where do the package files go? ... where do I put the lexer files? ... your point of view it's just important to load them in the right order ... Probably you should change the current directory in lisp to the lexer ...
    (comp.lang.lisp)
  • Re: fasl and lisp image
    ... fundamental difference between the lisp image and the set of .fasl ... need anything more than a remembered set of fasl to load (both ... When I work with a Lisp machine, ... When I later restart the Lisp, ...
    (comp.lang.lisp)