Hacker News new | past | comments | ask | show | jobs | submit login

> One of the examples in the repository is an implementation of malloc.

Right. And (imho) malloc is quite possibly an "old fashioned" way of looking at things:

   function malloc(num_bytes: nat): @byte
A reference to a byte block obtained from specifying the number of bytes! I would like to see the modern memory manger be type aware, have a very rich memory model, and allow for the propagation of application level semantics to OS (so they can cooperate in dealing with the current issue: memory access latencies and concurrency).

> I don't think that there can be an established definition of [a] modern systems language

Key word is "modern" so here is an attempt to box that a bit: There are 2 possible dimensions to the notion of modern:

1 - it addresses new hardware realities

2 - it enables "progress" in dealing with matter rendered difficult by existing paradigms of system programming.

The realities of a modern system surely include: multi-core SMP; strong likelihood to be employed as distributed nodes; virtualization. So "modern" platforms and deployment patterns are not addressed.

Second, Deca, I gather, would delegate dealing with all this to some higher level (user level) framework built on top of the language. I don't see any progress in that critical front, either.




Deca does deal with SMP and concurrency in one way: module-level variables are tagged thread-local in the bitcode by default, at least if they're mutable.

Once the "newsig" branch (it's a rewrite from scratch after the original code had troubles with multi-module compilation) with the new signature system (region, effect, type, mutability) can compile some example code again, I'm merging it back into the main branch.


> I would like to see the modern memory manger be type aware

Because these are system languages, that would happen when hardware is type aware.


It is not necessary. With software replacement for MMU possible (see Singularity OS), hardly any hardware safety support is a requirement nowadays. TAL is the way to go - AFAIK it is possible to make plain x86 assembly dependently typable by attaching proof witnesses to EXE.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: