

Declarative Computation, Syntactic Sugar, and the Abstract Machine - mrbbk
http://michaelrbernste.in/2013/06/17/declarative-computation-and-the-abstract-machine.html

======
mrbbk
Also part of a series.

Chapter 01: [http://michaelrbernste.in/2013/02/19/CTM-
chapter-01.html](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-...](http://michaelrbernste.in/2013/02/23/notes-on-teaching-with-the-
kernel-language-approach.html)

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

~~~
handymanne
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...](http://books.google.com/books/about/Concurrent_constraint_programming.html?id=8LKGpv3OCKcC)

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
Double yep! I plan on covering how this stuff relates to concurrency next.

~~~
handymanne
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
I think whichever way you slice it, program analysis is an essential aspect of
true hard RTGC.

