fix: work-around malformed all field in definitions

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.

[ammkrn]

Some attributes like to_additive and to_dual create declarations which do not preserve the property that their all list is "a List of all (including this one) declarations in the same mutual block." The current theorem/def/opaque export logic relied on this being the case for all declarations.

This fix ensures that the current "base" declaration is included in the list of names exported, and tries to ensure declarations are not re-exported by the appearance of malformed declarations, for example if:

• properly formed declaration x has an all list [x], and;
• improperly formed declaration y has an all list of [x]

then the old/current logic would export x twice if the x declaration was found first; once for the x declaration, and again when exporting y.

Ideally there would be an upstream change to try and ensure that this invariant is preserved, but the exporter should probably be made robust against this either way.

[nomeata]

There was some private discussion on zulip, but we should probably continue it here for visibility, and to involve @hargoniX.

I since learned that the all field is ignored by the kernel, and not set appropriately by some tactics like to_additive. With that in mind, I am unsure if it's even a good idea to rely on it in the exporter.

Consider

import Lean
mutual
def f : Nat → Nat := fun x => g x
def g : Nat → Nat | 0 => 0 | .succ n => f n
end
open Lean
/-- info: [`f, `g] -/
#guard_msgs in
#eval do return (← getConstInfoDefn ``f).all
/--
info: @[irreducible] def f : Nat → Nat :=
fun a => f._mutual (PSum.inl a)
-/
#guard_msgs in
#print f

It would be strange IMHO if f and g were grouped in the output format.

The only grouping of definitions that I see as useful here is that of mutual partial or unsafe declaration. Unfortunately, the environment doesn't keep track of the original mutual declaration passed to the kernel.

Given how muddy these waters are, I wonder if we should backtrack and remove the grouping of definitions again. It has no use on safe declarations anyways, and we could leave it to the replay code to reconstruct the mutualDefns for unsafe declarations if they are of interest.

@hargoniX, what do you think?

[nomeata]

(If we do merge the proposed workaround it definitely needs an explanation that we can make sense of in a year :-))

[hargoniX]

Given that they get elaborated into non-mutual things just dropping the all field seems sensible to me if it is not to be trusted anyways yes.

[nomeata]

The question is more whether the exporter should group definitions. It could

• group them based on all, for convenience of having definitions that were mutual before elaboration near each other, or
• only group them when they were sent to the kernel together using .mutualDefn. more principled, but requires heuristics and is only relevant for unsafe definitions, or
• don't group definitions at all

[nomeata]

I chatted some more with Hendrik on this, and we came to the conclusion that we should simply removing the grouping of definitions from the format. Justification:

• In the safe fragment of the lean logic, there is no concept of mutual definition. (Pre-elaboration mutual shouldn’t play a role here).
• The only meaningful mutual-ness we have is with unsafe definitions that were part of a .mutualDefnDecl. But the information which unsafe definitions were mutual is lost, and has to be reconstructed in a non-trivial way.
• Reconstruction could peek at the all field (but we saw that this field is unreliable) or by analysing the dependency graph.
• We could make lean4export do that analysis and somehow represent .mutualDefnDecl in the format. But not much is gained: We expect that most applications of the export format, and most checkers, only care about the safe fragment anyways, and would now have to deal with that in the format for no good reason. So it seems nicer to let those checkers that actually do care about unsafe definitions to decide how to deal with that, while making it a complete non-issue for everyone else.

This way, the all field becomes irrelevant for export purposes, which is good.

I’ll prepare a PR that updates the format.

[nomeata]

Closing in favor of #16.