Re: Data-E: Removing fixed literal type set

On Jun 3, 2009, at 1:03, Kevin Reid wrote:

> The buildLiteral/1 message to Data-E builders is renamed buildAtom/1.
>
> A Data-E builder specifies the kinds of objects it will accept as
> atoms, by a guard which can be retrieved from it. (We need to choose
> the verb for this.)

I thought I had posted this before, but apparently not: we have chosen  
atomType/0, by analogy with collections' keyType and valueType.

> This does not introduce a large compatibility problem (from
> differences in what is considered an atom) because: In most builder/
> recognizer compositions, either the recognizer or the builder is
> deSubgraphKit.  ...
>
> deSubgraphKit's recognizer only invokes the builder's buildAtom if the
> object under consideration is Data (i.e. authorityless), and
> deSubgraphKit's builder only accepts Data as atoms. This ensures that
> Data-E does not carry authority other than that explicitly described
> by uses of the defined exits.

I have implemented this scheme in Caja-CapTP, and I just realized a  
certain bug resulted from the fact that I did not implement the  
abovementioned Data requirement: under that condition, if a  
deSubgraphKit recognizer is connected to a deSubgraphKit builder, _it  
always just passes the root object through_!

This is not good, as joined deSubgraphKits are useful for deep-copying  
and translation.

Implementing the Data restriction would work for this particular case,  
but I am thinking that, in general, the deSubgraphKit should have its  
recognizers _parameterized_ with a guard restricting what it will pass  
to buildAtom. This way the recognizer's client (the emitter of a Data- 
E stream) can control exactly what literal objects may be sent to the  
builder.

Does this seem reasonable? Should the subgraph builder also be  
parameterized with the atom guard?

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>