This is in the hope that people will join in a discussion! SO anybody who had views please add your thoughts...
At present Reduce is arranged as a number of chunks of code that are loaded when the system starts, plus a further selection of modules that are not loaded automatically but where the main entrypoints to them load the code on first use. Finally there are packages that are only available when the user explictly does a load_package operation. The selection of what is in each category is probably really not rational but has been a consequence of history. Eg for compelling reasons based in Reduce's origin the high energy physics stuff is in the central core.
So TWO questions:
(1) Should we over time move to a fresh choice about what is always loaded and what is loaded on need - and how do we decide what goes where?
(2) At present merely loading some packages alters behaviour and there is then no way to go back to the previous situation. What are the prospects or desirabilities of saying that LOADINg a package has no effect beyond making capabilities available, and ALL optional behavious should be controlled by on/off switches?
Neither of the above is something to be done overnight, but both could be part of a dircetion to aim towards. Arthur
In answer to question 2, just on general principles, for me, the desirability of loading a package having no effect beyond making the capabilities available is very high. Considering the alternative - load a package, exit the program, restart the program, re-enter all the data needed to recreate state - then, yes, ALL optional behaviours should be controlled by switches.
As an aside to question 1, I notice that in my version of Reduce, reduce-i686-pc-ubuntu8.10-20090414, there is a Load Package drop-down menu in which package names are "greyed-out", rather than "checked" after loading. This is odd behaviour in the sense that "greyed-out" usually means "unavailable", not "already installed and active".
In answer to question 1, I would prefer that everything load on demand. The user should not have to think about this. Any potential side-effects should be configurable, as in question 2. I suppose there should also be a notice that some package has loaded automatically, and a listing of the state of any changes in behaviour that would be configured.
Re loading a module having effect. I agree!! But I also know that at present that MANY modules are not like that are not like that so there is a big project for some group of volunteers to chase that down and change it! There is eg an issue that some modules add new or extra syntax - if module-loading must not change anything that syntax has to migrate to the core.
re making more things autoload, that is probably easier. Very nearly all autoloading is specified in the file packages/support/entry.red and any proposed additions to that that PROMISED that the functions triggering autoloading where only defined in just one package and so could NEVER cause confusion seems tidy and simple and safe to me. So somebody doing a systematic job to identify package entrypoints that way might be useful.
Re the CSL-version menus for package loading, that will be my code. I do not count myself as either an expert in or enthusiast for GUI coding, and having that menu at all was quite enough work! You are probably right but I am not about to be very energetic about altering it!
Log in to post a comment.