Re: Idle musings on doing E over again

On Oct 10, 2012, at 2:04, Thomas Leonard wrote:
> On 2012-10-07 17:43, Kevin Reid wrote:
>> On Oct 2, 2012, at 4:24, Thomas Leonard wrote:
> [...]
>>> 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.

That very much does not fit into my scheme. Could you outline some use cases?

> Also, optional fields (i.e. fields with default values) would be useful for backwards compatibility.

Defaulted-optional fields will certainly exist, as these are meant to provide useful semantics for keyword-arguments (as Maps are used in current E, but more expressively and thus better for rough analyses).

> I guess :User would coerce the fields? So after:
> 
>   def user :User := raw
> 
> user.email() might not equal raw['email']?

Yes, but only if you have something that coerces in that field, of course. This is basically the same as you had written

  def User := Tuple[String, Email]

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

I'm afraid you'll be disappointed; my current thinking is directed towards a Smalltalk-style minimal language: keep everything out of the language that can be expressed in terms of calls and closures. Such depends, of course, on having a syntax which makes it pleasant to express those calls and closures, so I will certainly attempt to avoid outcomes which are a mess of punctuation to express simple things.

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