Declarative Computation, Syntactic Sugar, and the Abstract Machine | Hacker News Reader

Declarative Computation, Syntactic Sugar, and the Abstract Machine

michaelrbernste.in

31 pointsmrbbk6 comments

Also part of a series.

Chapter 01: http://michaelrbernste.in/2013/02/19/CTM-chapter-01.html

On the paper that sums up the pedagogy: http://michaelrbernste.in/2013/02/23/notes-on-teaching-with-...

Oz (the language presented in this article) is a language worth learning also for the unique way it formulates concurrency. Concurrent processes are coordinated through variables being realized - i.e. a process that requires a variable to be bound will block at the point it is required and when another process causes the variable to become bound, it will proceed. Its constraint programming facilities can be expressed very nicely using these constructs.

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

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

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

I think whichever way you slice it, program analysis is an essential aspect of true hard RTGC.

Reply on news.ycombinator.com