Unintuitive semantics for library context arguments

[sjdv1982]

Contexts that are arguments to library instances can easily do the wrong thing. The following problems exist:

• You can't mount or share cells in a library context. Solution: When copied over, mounts and shares must be removed. Do this also for normal ctx.subcontext = othercontext assignment.

• Incoming connections are currently destroyed, which is fine for normal subcontext assignment, but this is unintuitive for context arguments:

  • ~For one, a lingering structured cell auth value may suddenly become relevant upon connection destruction, which is very unintuitive. This is a generic problem of Seamless graphs. Solution: destroy all lingering auth values (auth values in combinarion with a null-subpath incoming connection) upon graph save.~
  • For another, the incoming connection current values can easily be "baked" into the graph. (See "quick and dirty" section in the RRM/main-HISTORY script for a manual baking). This is typically what you want for library context arguments (although not for normal subcontext assignment). Ergo, baking should happen automatically upon library context copying and library context copying must happen automatically upon incoming connections (is already the case?). Together, this making library instances properly reactive to incoming connection updates to their context arguments, which is what one expects from Seamless.

• Libraries should be able to mark some cells as "sanitize". For stdlib.map, this is essentially the .inp cell. Sanitizing means that upon library context copying, all checksums of sanitized cells must be cleared by a cancel that propagates to downstream connections. Without this sanitation, the mapping context may contain leftover checksums from testing, which leads to erroneous elision.

[sjdv1982]

The lingering auth relic is an issue of its own, see #162