This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> Suppose you want to evaluate it and then freeze the heap. You can't, > unless you can guarantee that the SMOB tag of `thingie''s type will be > exactly the same when you load the frozen heap. So you have to > calculate `thingie' and `what-became-of-thingie' everytime you load > it, instead of just binding the pre-evaled values. Hmm. I still think it's okay. Every heap-freezing method either has a way to resolve references to objects outside of the heap at load time (for example, from primitives' procedure objects to the C functions that implement them), or it assumes that external objects are at fixed locations. - If it has some load-time patching method, you can use that to get the SMOB's tags. - If it has no resolution method, you're assuming the outside world is quite static, so you might as well also assume that your SMOB registration happens in the same order. > > > BTW is there any "static" (oops :) way to register functions, at > > > least theoretically? > > Not at present. Maybe in the future. > Mind telling how? Or where can I read about this? Just academically > curious. "Maybe in the future" means "I haven't thought about it yet, but it sounds like it might be a good idea." :) If we had plans written up, then I would have said something like "We've talked about it, but it isn't done yet."