4 ms·

This looks really awesome. A few questions: 1. Is the "main stack" (the unnamed one, the one your program begins with focus on) specially identifiable in some

by Twisol 5y ago

This looks really awesome. A few questions: 1. Is the "main stack" (the unnamed one, the one your program begins with focus on) specially identifiable in some way? I note further down this comment tree that, if the "main stack" is simply whichever one happens to be in focus, there are some exciting possibilities for coroutines that are simply resumed in focus of the stack that they treat as their main. 2. Are stack names always statically known in Dawn? Put differently, can you generate fresh stack names at runtime? If so, what does that look like, and how does that impact a theoretical reduction from multi-stack Dawn to single-stack Dawn? If not, can you envision additional intrinsics for supporting coroutines without requiring the user program to virtualize stacks manually? 3. Do you have any thoughts on concurrency in general in Dawn? I'm a big fan of the mental model offered by concurrent logic paradigms (especially Saraswat's concurrent constraint programming), where concurrent systems interact monotonically over shared logical variables. I think there's a subtle and exciting alignment between that concept and your named stacks. Does this line up with any of your thoughts? 4. (A bonus) What happens when an operation is attempted on an empty stack? I assume some form of exceptional case occurs, but in the face of concurrency, would it make sense to yield execution until something else puts an element onto the stack? (Probably not, because of FIFO semantics, but it's a fun question!)

smaddox 5y ago
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

by Twisol 5y ago

smaddox 5y ago

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