`SetUserPreference` does not honor `check` or `values`

[fingolfin]

DeclareUserPreference explicit documents that one specify a function check, i.e.

a function that takes a value as its argument and returns either true or false, depending on whether the given value is admissible for this preference; if several preferences are declared together then the number of arguments of the function must equal the length of the name list,

But in practice, as far as I can tell nothing in the GAP library ever calls this.

Likewise, values,

the list of admissible values, or a function without arguments that returns this list,

does not seem to be checked.

AFAIK the user preference code was written by @frankluebeck and @ThomasBreuer, so maybe they can shed some light on this.

[ThomasBreuer]

The function BrowseUserPreferences from the Browse package turns a given list of admissible values (for example in the case of Boolean valued preferences such as ReadObsolete, ReproducibleBehaviour, UseColorPrompt) into a menu to choose from, and also calls the check function if this is available.

[fingolfin]

Yes but SetUserPreference performs no checks which I found very surprising and means that I can't rely on the preference values to be valid. So I need to introduce additional verification and checks.

I think at the very least the manual should warn about this, both developers and users)

[ThomasBreuer]

With the current setup, SetUserPreference itself can in general not perform these checks.

• The file gap.ini that contains the initializations of user preferences is read very early, in particular it is read before the packages get loaded which contain the declarations of the user preferences. Thus we do not have the information about the validity at the time when SetUserPreference gets called.
• At the time when the declaration becomes available, it may still be too early for calling the functions that are involved, they may be available only after the package that declares the preference is completely loaded.
• Some user preferences may refer to packages which are not loaded at all in the current session.

We could add a function that can be called in a GAP session and then checks the validity of those user preferences that belong to the actually loaded packages.
Such a check could then be called automatically after starting GAP and after LoadPackage calls.

[fingolfin]

OK, that all makes sense.

I still think that the documentation should state explicitly when check is used and when not.