Data-E: Removing fixed literal type set

[Kevin Reid-2]

Data-E currently defines a fixed set of literal types: String,  
Integer, Float64, Character. This is less flexible than it could be.

Uses for generalizing the definition of literals:

   * I am borrowing Data-E for use on the JavaScript platform, where  
there are no native integers or characters; it would be convenient not  
to have to define handling for these types, yet not deviate from the  
Data-E 'standard'.

   * It would be nice for serialization formats such as deBytecodeKit  
to be able to define compact representations for e.g. byte arrays.

   * If we introduce more literal types to E in the future due to some  
change in What a Programming Language Ought To Have, it won't be a  
protocol change.

   * An intra-address-space comm system using Data-E for proxy  
handling would like to share between vats any object which is Data  
(deeply immutable and authorityless) and thread-safe.

                                ---      ---

I have proposed and MarkM has approved and refined this plan:

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.)

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. Since the subgraph builder deals in real objects, it  
can accept anything as an atom (and just return it). Since the  
subgraph recognizer deals in real objects, if the builder's atom guard  
rejects an object, the recognizer can proceed by using the uncall  
mechanism instead.

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 said this in discussion and MarkM wanted me to save it:

"There are objects you agree exist, there are objects you write down,  
and there are objects you take apart."

(Those being exits, atoms/literals, and calls, respectively.)

(Hm, analogy with mathematical notation: a number can be written as a  
well-known name like π and i, as digit data like 1.324, or as a  
formula like sqrt(2)/2.)

--
Kevin Reid                            <http://homepage.mac.com/kpreid/>


_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

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 hereby choose the verb atomType/0.

Precedent: Collections' keyType/0 and valueType/0.

In Caja-CapTP, the result will be a predicate function rather than a  
guard, until such time as Cajita has an idiomatic guard facility  
(particularly, ejectors are currently missing).

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




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller-2]

On Sun, Aug 9, 2009 at 7:25 AM, Kevin Reid <kpreid@...> wrote:

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 hereby choose the verb atomType/0.

Precedent: Collections' keyType/0 and valueType/0.

Good.
 

In Caja-CapTP, the result will be a predicate function rather than a
guard, until such time as Cajita has an idiomatic guard facility
(particularly, ejectors are currently missing).

Draft guards and ejectors in T-cajita.js at <http://codereview.appspot.com/105065/show>.

 

--
   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller-2]

On Sun, Aug 9, 2009 at 10:54 AM, Mark S. Miller <erights@...> wrote:

In Caja-CapTP, the result will be a predicate function rather than a
guard, until such time as Cajita has an idiomatic guard facility
(particularly, ejectors are currently missing).

Draft guards and ejectors in T-cajita.js at <http://codereview.appspot.com/105065/show>.

Very similar of course to the pattern you compile to in the visitEscapeExpr() method of E-on-JavaScript's lib-host/org/erights/eojs/compiler.emaker

Given this helper function, could visitEscapeExpr() compile to more compact code by using it? Should it?

--
   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

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/>




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang