Repository navigation
Printing indices instead of generated heap type names? #3627
Description
As we move on from working exclusively with tiny GC test programs, I'm not sure the code for generating heap type names is pulling its own weight in terms of the value it brings against its complexity. For real programs, the heap types are so large and complex that the generated names fail to be useful for basic things like identifying at a glance whether two places use the same or different heap types. Printing simple indices into the type section, while providing less local information about type structure, would make for better readability overall IMO. This would also eliminate current bugs with type name clashes.
Would anyone object to me removing the name generation code?
Activity
tlively commentedon Feb 27, 2021
cc @kripken
tlively commentedon Feb 28, 2021
Thinking about this more, one problematic case would be when heap types need to be printed as part of individual expressions without the context of a full module. In that situation, printing type indices would be meaningless. I propose that we print the full type inline in those cases rather than trying to give it a name. Separately, we should add a mechanism for globally configuring the default print depth of expressions and types to avoid information overload in that and other situations. I got a an error message that printed a type with 1.8MB of text the other day and it was not too useful 😅
kripken commentedon Mar 1, 2021
I agree with the above. When printing the full module, we may as well index them. When there is no module (printing just an expression) then printing in the old way makes sense.
If it's not hard, then having both an index and a shortened full name might be nice, e.g.
tlively commentedon Mar 1, 2021
I'm proposing that we not give types names at all (besides names present in the input, of course), so there wouldn't be a need for short or long names.
kripken commentedon Mar 1, 2021
Are you opposed to also adding a short name after the index? If so, why?
(Seems like the name could help readability in some cases at least. And having the index up front in the name would avoid current name issues.)
tlively commentedon Mar 1, 2021
I'm just not sure a short name with structural rather than semantic information would ever be useful for real world programs because there will be a very large number of types that all look very similar from a 10,000 foot view. It will simplify our code a lot if we can just print
123instead of a name, even a name like$123, because then we won't need to worry about name clashes with user-defined names at all.kripken commentedon Mar 1, 2021
Fair enough. I'm thinking not just of large real-world programs but also smaller things, like maybe a reduced testcase from one of them. But we can consider adding more than just indexes later if it seems useful, I agree your direction is good.
tlively commentedon Jan 15, 2025
This is done. There are still some issues about printing meaningless type indices in error messages, but those can be addressed separately.