0

Not quite a duplicate: this appears to be very similar to the situation described in an existing question. But my question is not "why does it happen", but rather "is there any way to keep using uninterned symbols".

Let's say certain macro generates an expansion that is an invocation of a private, runtime-generated function. This function has an "uninterned" name (or, rather, interned in a non-default obarray). When evaluated directly, this works fine.

However, byte-compiled code using said macro and, in effect, the function, won't work, because after write-to-.elc-and-read-back function name symbol becomes truly uninterned, i.e. is not identical to what I have in my internal obarray.

Is there any way to keep function names out of the default obarray, yet still have them work when invoked from .elc files? (I did make some investigations of Emacs source code and haven't found any, but still ask in case I've missed something obvious.)

Improve this question
2
  • 1
    I would think that your macro expansion needs to take care of the necessary interning to your non-default obarray, but the question would be a lot clearer if you showed some code.
    – phils
    Dec 23, 2018 at 21:34
  • What @phils said - please show some code. The question is currently not too clear, and so it risks being deleted. In general, the more specific/concrete the question, the clearer it is, and the better a candidate it is for emacs.SE.
    – Drew
    Dec 23, 2018 at 23:36

1 Answer 1

Reset to default
0

I believe the answer is "no": writing a symbol which is not interned in the main obarray leads inevitably (if you use the normal print&read code) to an external representation that lost its connection to your obarray, I'm afraid.

Of course, you can try and workaround this problem by printing code like

(defalias (intern "foo" such-and-such-obarray)
          ...)

i.e. don't print the symbol but instead print code which will compute the symbol when evaluated. How to do that (and whether it's practical) will depend on the details of what you do.

Improve this answer
4
  • Interesting idea, but unfortunately requires post-processing .elc, which I don't want to require. It also leaves the problem of calling that function unresolved. I'll leave the question open for a while, maybe someone comes up with another trick. But I suspect "no" is correct.
    – user8782
    Dec 24, 2018 at 10:08
  • @doublep: I don't think it necessarily requires post-processing the .elc. As for function calls, you can generate (funcall (intern "foo" such-and-such-obarray) ...).
    – Stefan
    Dec 24, 2018 at 13:47
  • Calling with such a construct will incur performance penalties on each function invocation, even if it is only one hashtable lookup. Also, I can indeed use defalias the way you proposed, but at least defun really does expect a symbol as name, not e.g. (intern ...) form.
    – user8782
    Dec 24, 2018 at 14:04
  • @doublep: Indeed. You can pre-compute the lookup and store it in a variable, but if you want to do it globally, that var probably needs to be interned, so you're back to square 1.
    – Stefan
    Dec 24, 2018 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.