Re: Idle musings on doing E over again

On Oct 1, 2012, at 5:42, Thomas Leonard wrote:

> Hi Kevin,
> 
> If you want feedback from users, these were the main problems for us:
> 
> 1. VatTP not using standard TLS libraries -> security risk due to lack of
> updates.

As far as I know, The Plan Always Has Been to move to standard SSL/TLS/whichever-it-is-HTTPS-uses plus key checking; it's just that nobody has gotten around to implementing this in all these years. Certainly a new from-scratch implementation would take advantage of the latest libraries.

> 2. CapTP "ping-of-death" vulnerabilities due to pipelining: e.g.
> server<-getVersion()<-pow(2147483647).

E has always intended to support mobile code, which by definition may hang the target vat. However, I have considered the possibility of locking down unserialization by defining a subset of all messages, which is those which are processed in time linear in the input size. Such a subset, plus application-specific messages, might well solve this problem, but I have not yet tried to actually implement it.

(Tricky part of defining such a condition coherently is reference cycles in the input.)

> 3. Lack of a framework for persisting and reviving database resources
> (timeMachine not useful; had to build our own).

This strikes me as the sort of thing which would necessarily be application-specific. Can you describe what you think would be generalizable?

> 4. Lack of static type-checking (Java developers are used to the compiler
> checking things for them).

I would hope to have a compiler smart enough to do inlining and allocation-elimination optimizations. There'll probably be enough information to issue "this will necessarily crash at runtime" warnings -- but this is an implementation feature, not a language feature, and I'm currently largely thinking about language features.

What type of static type system do you have in mind?

> Lack of a proper record type is related.

Ah, I am very much in favor of including a record type. However, I'd just like to check — what is a “record type” to you?

This are the features I am thinking of for the “record type”:
• like a Map, but exposes its keys as methods/accessors, not subscripts
• optimized for many records of the same shape (key set) with few entries
• can express a subtype which is “records with exactly these keys”
• can be pattern-matched
• automatically provides mutable and immutable variants, 'with' copy-and-mutator operations, and zippers

These are the use cases I want it to serve:
• algebraic data types
• named parameters
• multiple return values
• possibly syntax trees

> 5. Performance (especially start-up time). Static type checking would help a
> lot here, I think.

Startup time is certainly something I intend to keep in mind. It is relevant to two use cases I am particularly interested in supporting better than current E does:
• code in web pages (the common form of distributed computing)
• command-line utilities and other programs following the launch, do something, exit pattern.

I believe most of the startup time in current E implementations is in loading code (improvable by precompilation, if you have a place to stash the compile output) and in creating the objects in a vat (improvable by keeping the core code smaller and improving execution speed).

Could you explain how you expect static type checking to help startup time?

> People complained a bit about the syntax, but I don't think anything else
> would have been better. If it had been pure Java, they'd have had to learn
> the same concepts. Personally, I think it's very good.

I'll keep that in mind. For what it's worth, most of my wilder syntactic ideas have so far produced terrible results when I try to write down a program in them :-)

> Integration with Java was very easy and useful, though very hard to explain to managers.


I do not see Java as the right target for the primary implementation, but certainly host-platform integration should be a priority, whatever the host is.

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