[e-lang] Data-E: Removing fixed literal type set
kpreid at mac.com
Mon Aug 17 12:55:44 EDT 2009
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
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
Does this seem reasonable? Should the subgraph builder also be
parameterized with the atom guard?
Kevin Reid <http://switchb.org/kpreid/>
More information about the e-lang