Re: Idle musings on doing E over again

On 2012-10-07 17:43, Kevin Reid wrote:
> On Oct 2, 2012, at 4:24, Thomas Leonard wrote:
[...]
>> So I can say e.g.:
>>
>> struct User { name :String, email :Email }
>>
>> def register(u :User) { ... }
>>
>> If "u" is received over the network then the system should verify its
>> structure and reject it if it's wrong. But when passing between
>> functions within a vat, it shouldn't keep rechecking it.
>
> Yes, this is what I have in mind. In particular, what I am currently
> thinking is: records have an optional "type" reference. When the User
> guard gets an untyped (or wrong-typed?) record, it checks the record
> against the declared structure and produces a new record with the
> matching type. Thus, if the type already matches we have an O(1) check
> after the conversion.

Sounds reasonable.

What about extra fields? It would be useful to accept a record with at least 
the two fields above, but still preserve any other fields. Also, optional 
fields (i.e. fields with default values) would be useful for backwards 
compatibility.

I guess :User would coerce the fields? So after:

   def user :User := raw

user.email() might not equal raw['email']?

> Thus we can have records with just as much type information as real
> objects, but not require the creator of a record to have a reference to
> the type object (or, for network cases, to have a reference to the *same*
> type object). This is particularly relevant because (given sufficiently
> nice syntax) I want to use records as the standard solution to keyword
> arguments.
>
> On the grounds of keeping the language small, what do you think of a
> quasi, i.e. def makeUser := struct` name :$String email :$Email ` ?

I think I'd rather have some specific syntax (though no extensions to Kernel-E).

> On the other hand, another potentially valuable facility would be some
> way to avoid rerunning guards on an object even if they are purely
> structural guards. I've thought about providing a generalized cache for
> this purpose; I don't know whether doing so will turn out to be feasible
> (i.e. provide more performance benefit than cost).


-- 
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK


tel: +44 23 8059 8866

mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk/