-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plan: get rid of hidden implications #2336
Comments
One suggestion by @ThomasBreuer was that there could be an optional argument to In either case, we could then keep track of this explicitly, and issue a warning or even error if a property of this kind gets redefined. Also, one may consider a similar for the tester of an attribute: e.g. |
It is fine to have two functions for the two purposes of property declarations. |
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes a "hidden" implication created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
Some time ago we added the command line option -N to disable hidden methods (see also gap-system#2336). This causes many InstallMethod invocations in packages to print warnings. Improve these warnings to make it easier to resolve them.
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes various "hidden" implications created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This makes a "hidden" implication created by DeclareProperty explicit, thus fixing a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
Some time ago we added the command line option -N to disable hidden methods (see also #2336). This causes many InstallMethod invocations in packages to print warnings. Improve these warnings to make it easier to resolve them.
This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This seems correct, as there were no real methods to compute it. Also, it is very similar to IsIntegers, which is also a category. This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This seems correct, as there were no real methods to compute it. Also, it is very similar to IsIntegers, which is also a category. This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This seems correct, as there were no real methods to compute it. Also, it is very similar to IsIntegers, which is also a category. This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This seems correct, as there were no real methods to compute it. Also, it is very similar to IsIntegers, which is also a category. This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This seems correct, as there were no real methods to compute it. Also, it is very similar to IsIntegers, which is also a category. This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This seems correct, as there were no real methods to compute it. Also, it is very similar to IsIntegers, which is also a category. This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This seems correct, as there were no real methods to compute it. Also, it is very similar to IsIntegers, which is also a category. This makes a so-called "hidden" implication created by DeclareProperty explicit, thereby resolving a bunch of warnings that show up if one starts the upcoming GAP 4.11 with the `-N` command line option, and then loads this package. For some information on the background of this, see also <gap-system/gap#1649> and <gap-system/gap#2336>
This fixes warnings when starting GAP with the -N option. For more information, see gap-system/gap#2336
Sadly things got worse since I last touched this, as lots packages added new code relying (accidentally) on hidden implications. At the same time, we keep encountering problems caused by hidden implications (see e.g. https://github.com/gap-system/gap/pull/4935/files#r940054140). Ideally we'd come up with a plan to migrate incrementally to a world without hidden implications.... Perhaps we could add an optional argument for Or perhaps we just need to make the switch, hard:
|
Short summary
I would like to get rid of hidden implications in GAP completely. They can lead to counterintuitive problems, like the order in which packages were loaded can affect ranking; and other problems, see e.g. issue #1649 (and esp. this comment by @frankluebeck which already sketches the plan here, and gives additional useful information)
Background: What are hidden implications?
Currently, GAP's method ranking relies on both implications, and so-called "hidden implications". An implication is when a filter
IsFOO
implies another filterIsBAR
(e.g. viaInstallTrueMethod
). In that case, the rank ofIsFOO
should be larger than that ofIsBAR
, reflecting the idea that the more "properties" (used in a non-technical sense here) a filter implies, the higher it should be ranked.This is all good and fine, but apparently was/is not quite good enough to get a good ranking system (?). Thus GAP also uses so-called "hidden" implications: A "hidden" implication from a filter
IsFOO
to a filterIsBAR
has the same effect on the relative ranking of the two filters, but without a mathematical implication between the two.These typical are created indirectly when you declare a property or attribute. Example:
DeclareProperty( "IsNilpotentGroup", IsGroup );
This creates a hidden implication from
IsNilpotentGroup
toIsGroup
, but not a mathematical one. Meaning that the rank ofIsNilpotentGroup
is larger than that ofIsGroup
; but in principle at least, something could be in the filterIsNilpotentGroup
without being also in the filterIsGroup
. Now, in this particular case, one "obviously" also intended an actual proper implication -- but none exists! One has to manually establish it, e.g. via this:The reason for this is clearer if you consider this example: in polycyclic, we have this:
DeclareProperty( "IsTorsionFree", IsGroup );
Now, this installs a hidden implication
IsTorsionFree
toIsGroup
. But now perhaps you are writing a package in which you deal with torsion free monoids. So you add this:DeclareProperty( "IsTorsionFree", IsMonoid );
Both can happily coexist, but now we are glad that GAP did not erroneously install an actual implication from
IsTorsionFree
toIsGroup
, as our most beloved torsion free monoid, the setN
of natural numbers, isn't a group.But GAP only installs a hidden implication the first time a property is declared... Thus now the ranking of the filter
IsTorsionFree
depends on the order in which packages are loaded: if the polycyclic package is loaded first, then the rank will be higher than as if your new package is loaded, asIsGroup
has a higher rank thanIsMonoid
.This kind of example is not made up, it occurs in practice that people want to define properties for different kind of objects.
Proposed solution
Get rid of hidden implications, gradually, as sketched above.
TODO: add more details later on?
The text was updated successfully, but these errors were encountered: