Immutable GAPInfo.PackagesInfo records: Problems for JuliaInterface and float

[fingolfin]

When I merged hpcgap/lib/package.gi into lib/package.gi, see 42789e6, I accidentally broke the float package, which modifies its package record after it has been set. It does that to modify its banner string, to indicate which parts of it where actually compiled and loaded. That is indeed quite useful information, and it makes sense to display that as part of the banner string.

One way to fix this is to stop making the package records immutable, at least in GAP. But they'll stay immutable in HPC-GAP, so float would be broken there, unless we can stop making the package record immutable there, too... or perhaps we can delay doing so until the package was fully loaded (i.e. both init.g and read.g have been read)?

So my preferred solution would be to work together with @laurentbartholdi to change float to not modify the package record during a late stage anymore. But right now, I have not yet made my mind up on what I think would be a good solution; also, perhaps changing the immutability of the package info record at a later stage can be implemented, then no change to float would be necessary.

This must be resolved before GAP 4.10.

[olexandr-konovalov]

Why can't we make them atomic records in HPC-GAP instead of being immutable?

[fingolfin]

Well, then the content of the records (i.e. strings, lists, other records) still would not be accessible from all threads. Of course that may not be a major problem in the end -- I did not extensively test this, I just copied changes that others applied there in the past (e.g. @ChrisJefferson it seems, based on my reading of git log, which may flawed, though).

[olexandr-konovalov]

If you do atomic list of immutable things, then Float can simply replace one immutable banner by another immutable banner.

Or, maybe Float should simply change the way it modifies its record? Make a copy, modify it, make it immutable and replace the old record. Needs some experimenting.

[laurentbartholdi]

Well, I get punished for hacking, and that's only fair. What if we rather change the format of PackageInfo, and say that BannerString can be either a string or a function with 0 arguments and returning a string? That would avoid all problems, be clean and backwards-compatible. It's a single-line change to the package loading code.

[fingolfin]

While I like the idea of allowing a banner string function, setting it as the value for BannerString then also means that package won't work with older versions of GAP, so it's not really backwards compatible. But we could instead add a new field BannerFunction. Then old GAP versions will just keep printing the (default) BannerString, while new GAP versions will use the result of BannerFunction.

As an alternative (which is not mutually exclusive, i.e., we could do both), one could offer a way to add additional information into the output of DefaultPackageBannerString, to be printed at the end of that: Say a new field BannerExtras, which can be either a string or a zero-arg function returning a string; and that string is inserted into the default banner, right before the trailing separator.

[fingolfin]

Or perhaps it should be functions taking one argument, namely the info record?