3 ms·

Yup. Oz follows the concurrent constraint paradigm developed by Saraswat. His "cc"-family of languages inspires a lot of this kind of development. His doctora

Yup. Oz follows the concurrent constraint paradigm developed by Saraswat. His "cc"-family of languages inspires a lot of this kind of development. His doctoral thesis was published: http://books.google.com/books/about/Concurrent_constraint_programming.html?id=8LKGpv3OCKcC http://books.google.com/books/about/Concurrent_constraint_pr... The first time I understood this fairly ubiquitous kernel-like language was from his papers, which I think spell it out more clearly than the usual lambda-calculus papers do. I do wish that more languages took after this style as the existing ones rarely take advantage of the quality that you can get from complex compilation analysis. I have not, for example, found one that is not dynamic, although many of them tend to be little more than a prettier and slower Erlang or, for the really good ones, a prettier, slower and less-safe Esterel. Instead, they are more Lisp-like, which is also technically declarative but are far harder to reason about temporally and therefore more complex to write and optimize.

mrbbk 13y ago
Double yep! I plan on covering how this stuff relates to concurrency next.
- handymanne 13y ago
  Cool. I, for one, will also be keeping an eye out for more real-time garbage collection articles. I'm specifically interested in real-world implementations that have actually been helpful. I'm sold on the value but I don't think that most languages provide the kind of guarantees that you need for RTGC. Again, its the problem with proving temporal properties, which is hard in functional programming. But I don't know any real languages for which RTGC should be easily integrated... maybe Mercury? TLA+/PlusCal feels closer to the right direction but is focused on specification instead of compilation (a distinction that we have turned into a difference). But I don't see how a traditional imperative language could handle RTGC without time-consuming and error-prone manual instrumentation. (I'm hoping I'm wrong about that.)
  - mrbbk 13y ago
    I think whichever way you slice it, program analysis is an essential aspect of true hard RTGC.

mrbbk 13y ago

Double yep! I plan on covering how this stuff relates to concurrency next.

handymanne 13y ago
Cool. I, for one, will also be keeping an eye out for more real-time garbage collection articles. I'm specifically interested in real-world implementations that have actually been helpful. I'm sold on the value but I don't think that most languages provide the kind of guarantees that you need for RTGC. Again, its the problem with proving temporal properties, which is hard in functional programming. But I don't know any real languages for which RTGC should be easily integrated... maybe Mercury? TLA+/PlusCal feels closer to the right direction but is focused on specification instead of compilation (a distinction that we have turned into a difference). But I don't see how a traditional imperative language could handle RTGC without time-consuming and error-prone manual instrumentation. (I'm hoping I'm wrong about that.)
- mrbbk 13y ago
  I think whichever way you slice it, program analysis is an essential aspect of true hard RTGC.