Re: Idle musings on doing E over again

On Oct 15, 2012, at 3:46, Thomas Leonard wrote:

> Is the type of a record visible to E?

Yes.

> If the type of a record is visible to E (e.g. a User behaves differently to a NewUser), then sending a record to a remote vat must also send its type information. Again, that will be tricky with user-specified guards, since they can't travel in general.

This is a particular case of the general distributed programming problem. It should be possible that if you have two instances of the same 'application' in two vats, then a record delivered between them preserves its type; on the other hand, it should be possible to not have 'the same application' on the other end and get an untyped record.

Here is one possible strategy, described in terms of current E:

Let us assume that CapTP uses Data-E serialization, with one customization: on the receiving end, if any given *call* (i.e. object construction/lookup) fail, then instead of aborting the unserialization, a broken reference is substituted. (This is probably a good idea for robustness, anyway: you would like to be able to make use of the parts of the message you understand.)

Then, suppose that the Portrayal of a typed record is a call to

 toTypedRecord(type :RecordGuard, values :UntypedRecord)

which has this behavior: if the _type_ argument is a broken reference, then it returns an untyped record. (It would otherwise be identical to "values :type".)

This gives us DWIM behavior: if the type survives the trip, then the record is typed, else it is not.

> How are you planning to implement them?

However is efficient, of course.

I'm figuring to design them such that a record *can* be implemented in a packed format; e.g. a type pointer and value field pointers, where the type object contains the layout information including field names. This is an implementation detail, and non-machine-level implementations can't do it this way (explicitly).

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