Re: Idle musings on doing E over again

On 1 October 2012 16:44, Kevin Reid <[email protected]> wrote:
> On Oct 1, 2012, at 5:42, Thomas Leonard wrote:
[...]
>> 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?

For example, if I'm writing a Python server (e.g. in Django), I get a
database layer that will load objects from the database as needed. In
Java I get the same kind of thing with e.g. Hibernate. In both cases,
I can easily write services which manage collections of objects too
large to fit in memory.

In E, I could provide a single server object and do the database
access myself (or using one of the Java libraries), but then I lose
the security benefits of e.g. passing users SturdyRefs.

I made a custom system which revives E objects lazily from a database,
but there should be something provided by the standard library (my
system doesn't evict objects from memory either, so it only helps
start-up time; it doesn't stop the server running out of memory).
Probably not a language issue, except that E provides timeMachine in
privilegedScope.

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

E's problem here is that it defines many things as runtime errors,
rather than compile-time. Warnings are good, but errors are better, if
possible. Also, there's a difference between:

- "This will certainly fail", and
- "This could fail in some situations"

e.g.

def foo(a, b) { return a + b }

is OK for E, but a staticly checked language would require you to
prove that "a" would have an "add" method which could accept "b" in
all cases. Of course, these compile-time errors can also become
run-time when running over a network against untrusted remote code (or
link-time, with out-of-date compiled code).

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

No idea. Haskell is nice. ATS is a bit over-the-top ;-) Java would be
OK if it handled nulls and generics better.

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

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.

> 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

Sounds good.

Cheers,


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang