Hi Waldek, > It seems to be problem of adding runtime support.
Certainly. But since probably *you* must do the work, I don't think that is going to be supported any time soon. > In Axiom/FriCAS there is extra difficulty: > > )lib INT > > is supposed to wipe old version of INT and replace it by a new > version. Obviously, 'extend' is difficult to manage in a "session". In fact, although in the rest of your mail you spoke about "unloading", I think that this is a very dangerous thing, even now. Maybe, it's a non-issue, because nobody will do the following anyway, but suppose I modify integer.spad in such a way that it does not export Ring anymore. I can compile such Integer domain and it will be auto )lib'ed into my session and, of course, breaks everything. You might see this as a feature (maybe it is for development), but I don't (at least not for ordinary users) and would rather forbid ')lib' to destroy my session if it is recognized that the new (reloaded) code is in some way contradicting the values (including the category and domain hierarchy) that is currently in my session. I guess, it is even impossible to recognize whether the new code is compatible with my current session. So, although my first reaction to your idea of unloadable "extends" was like "Wow, that would be cool!", a second thought dismissed it as unnecessary. Why do we have )lib? It allows to extend the system with newly written user SPAD code. For my taste, I wouldn't want to modify existing (FriCAS-released) code (because that's that task of the FriCAS developers/maintainers). For newly written user code, one could have something like )mark foo1 )lib blah1 )mark foo2 )lib blah2 )sweep foo2 and would be at the situation of )mark foo2 with all of blah2 unloaded. It's perhaps a bit questionable what will happen with user values that were assigned after foo2... Anyway, maybe the easiest solution is to wipe only the last version in the chain of extends of a domain by the )lib command and replace it with the new code. Then one could end up with a chain like orig-INT --> extend-INT which would become orig-INT --> orig-INT after compiling the original integer.spad. Then two identical versions of INT would be in memory, but the first would never be used, because it's shadowed by the second. Maybe all of this is not well thought through, but I just wanted to share my ideas. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
