Skip to content

Ensure every constraint to wild has its own PSL and remove the AtomSourceMap? #612

Open
@mattmccutchen-cci

Description

@mattmccutchen-cci

Currently, when 3C adds a constraint (including a constraint to wild), it can specify a PSL, which is supposed to identify the code that resulted in the constraint between the two atoms. When 3C reports a root cause of wildness, it uses the PSL of the constraint to wild if one is specified, otherwise it falls back to the AtomSourceMap, which is supposed to give the PSL of the definition of the program element that was constrained to wild. This fallback has pros and cons, though they each have caveats:

  • Pro: In many cases (e.g., an element defined in unwritable code), we don't have a PSL other than the element definition anyway, so relying on the AtomSourceMap could save us some duplicate code at call sites that add constraints. However, using the AtomSourceMap may not be the best way to solve this problem: we might prefer to factor out the logic that determines the PSL for the element definition and use it at each call site. Then we could make the PSL parameter required to force ourselves to think about what PSL makes sense in each case.
  • Con: The automatic fallback can make bugs in the determination of the PSL associated with the constraint more confusing to track down. However, this could be addressed by adding more debug output to 3C that is conditional on a flag, which is probably a useful thing to have in general.

Mike said at yesterday's meeting that as we increasingly prioritize user-friendliess of 3C, we should commit to specifying a good PSL for every constraint to wildness and drop the AtomSourceMap fallback. I'm not completely convinced, but I'm going ahead and filing an issue for it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions