Date: 19 Jun 2006 12:22:29 -0700
paul c wrote:
> Marshall wrote:
> > ...
> > TTM is extremely well developed in the RT part. Indeed, it
> > is the most thorough treatment of the topic I know of, and
> > probably the only one to give it its due importance. But it is
> > fairly uninspired in the PLT part. There is no mention of
> > closures (in the PLT sense,) lambda, higher-order functions,
> > recursion or tail-call optimization, process calculi or even
> > message passing, type inference, parametric polymorphism
> > (outside of its built-in use with relations) or metaprogramming
> > anywhere in the book that I can find. (Although I only have
> > the 2nd ed.; haven't gotten to the 3rd ed. yet.)
> > ...
> (at the risk of exposing my feeble grasp of modern plt lingo):
> 1. closures - don't views give the same notion of postponement?
I don't think so, but I'm not certain I see where you're going. Closures are functions which have access to variables defined outside of the body of the function; they "close" over them. This makes them equivalent to objects, but more general. You can simulate fields with closures, and you can simulate things like C's local-static variables.
Yes, views do give a notion of postponement, which is one of the many things that makes them so cool.
That's actually a fairly profound statement. There is some relationship between messaging and assignment that I've been pondering for some time, but I don't grok it fully yet. I want to read more about process calculi.
Yes, they have recursive querying with TCLOSE. A solution to an important problem, but I'm not sure how I feel about it. It seems a bit ad hoc. Dunno. But I was more referring to recursive functions.
> 4. type inference - i thought the larger part of TTM was about this
> (even though typing theory is a bit over my head).
There's a lot about types but nothing about type inference per se that I can find. Not in the Hindley-Milner sense.
> These few seem like kind of parallel notions to me and I'm usually
> wondering whether there are others.
> I guess another thing I'm saying is that once a "context" as you put it,
> is established then we need to realize the terms in that context, e.g.,
> if the context is both of plt and rt, the way one of them realizes a
> particular notion may look crazy in terms of the other context. Maybe
> it is foolish to even entertain the marrying of these particular contexts.
Well, certainly not every two programming paradigms will fit well
It's another aspect of design: choosing parts based not only on how good they are but how well they work together.
I happen to think that RT and functional programming will go great together, synergistically great in fact. They are two areas of CS that are paying attention to foundations, and the foundations are quite compatible, in that function is a kind of relation.
Marshall Received on Mon Jun 19 2006 - 21:22:29 CEST