3 ms·

1. There's really no main stack, there's just the current stack and the enclosing stack (and the stack enclosing that, etc). It seems to work well in practice,

1. There's really no main stack, there's just the current stack and the enclosing stack (and the stack enclosing that, etc). It seems to work well in practice, but there might be some subtleties that I've missed, which is a major part of why I'm backing up to formalize it in the next post. 2. Yes, they're statically known. 3. It should ultimately be possible to compile Dawn to concurrent nets and therefore to evaluate concurrent sections concurrently, but I've spent very little time thinking about that. I definitely want to support traditional explicit multithreading and something like async/await M:N threading, but the details are unclear. It should be no less ergonomic or safe than Rust. 4. In Dawn it will be a type error. In the untyped calculus it's a runtime error.

Twisol 5y ago
> There's really no main stack Excellent! > It should ultimately be possible to compile Dawn to concurrent nets and therefore to evaluate concurrent sections concurrently I'm thinking more along the lines of Multicore OCaml's approach to concurrency, which uses effect handlers to support userland scheduling without requiring explicit support from the OS. In particular, I'm not asking for different parts of a program to execute truly in parallel. From my standpoint, concurrency has more to do with how you structure your programs -- I think of it as another view on modularity. In particular, to "evaluate concurrent sections concurrently" is something a user program would do, not something the compiler has to implement in terms of lower-level primitives.
- smaddox 5y ago
  Yes, that is definitely a possibility I hope to explore. Linearity has some interesting consequences for co-routines or async/await style code that I don't fully understand.
smaddox 5y ago
> It should ultimately be possible to compile Dawn to concurrent nets and therefore to evaluate concurrent sections concurrently Correction: to interaction nets: https://en.wikipedia.org/wiki/Interaction_nets https://en.wikipedia.org/wiki/Interaction_nets

Twisol 5y ago

> There's really no main stack Excellent! > It should ultimately be possible to compile Dawn to concurrent nets and therefore to evaluate concurrent sections concurrently I'm thinking more along the lines of Multicore OCaml's approach to concurrency, which uses effect handlers to support userland scheduling without requiring explicit support from the OS. In particular, I'm not asking for different parts of a program to execute truly in parallel. From my standpoint, concurrency has more to do with how you structure your programs -- I think of it as another view on modularity. In particular, to "evaluate concurrent sections concurrently" is something a user program would do, not something the compiler has to implement in terms of lower-level primitives.

smaddox 5y ago
Yes, that is definitely a possibility I hope to explore. Linearity has some interesting consequences for co-routines or async/await style code that I don't fully understand.

smaddox 5y ago

> It should ultimately be possible to compile Dawn to concurrent nets and therefore to evaluate concurrent sections concurrently Correction: to interaction nets: https://en.wikipedia.org/wiki/Interaction_nets https://en.wikipedia.org/wiki/Interaction_nets