General proposal for sealec context processing

Hi all,

before I try myself on the API document, I would rather submit to you the
general ideas I have about how we can achieve what I described in the
Syntax document. Let me know if that makes sense.

The general idea is to assign a unique *seal ID* to each sealed context.
This seal ID will be included, in the active context, on every term
definition created by the sealed context. Also, the active context will
have an additional attribute, 'effective seals', which is a list of seal
IDs.

The context processing algorithms will have an optional 'current seal'
input parameter. The rationale of this parameter is to remember that we are
"inside" a given sealed context, and as such should be able to override its
own term definitions.

More precisely, when we are about to override a term definition, we will
fail if :
* the previous term definition has a seal ID AND
* that seal ID is in the `effective seals` list AND
* that seal ID is different from the `current seal`

In other words, a term definition can be overriden if
* it is not sealed (it has no seal ID) OR
* its seal is not active OR
* the overriding originates in the same sealed context

The `effective seals` list is managed that way;
- when building the active context, we add to the list the seal ID of every
sealed context we encountered.
- During expansion, when we traverse a property, we check its term
definition and only keep in the list of `effective seals` the seal ID of
this property, if any. Otherwise, the list is emptied.

What do you think?

Received on Thursday, 31 January 2019 07:54:38 UTC