Andre van Tonder wrote:
 > I would like to point out that, with a primitive procedural
 > interface, static type inference becomes hard. Indeed, if
 > record types are values constructed at runtime, it is hard to
 > see how much useful type inference can be done without some
 > kind of partial evaluation.

I would like to understand this argument.  Part of my problem,
I think, is that I have implemented interprocedural static type
inference in a Scheme compiler, relying on properties of known
procedures; I suspect this is what you mean by "partial
evaluation".  Had I relied on properties of syntactic forms,
then the compiler (including the type inferencer, but not just
the type inferencer) would have been more complicated, because
the compiler would have had to know about more special forms,
and still would have had to know about properties of known
procedures.

I can imagine special forms that are capable of expressing
things that cannot be expressed by any procedural interface.
SRFI-76 seems to allow for that, but doesn't require it so
far as I can tell.  If there is some connection between this
and type inference, I'd like to understand the connection.

I am aware that a procedural interface can be used in ways
that would defeat type inference, but programmers seldom try
to do things like that.  With SRFI-76, where we would expect
most uses of the procedural interface to arise via macro
expansion of the special forms, the implementors can arrange
for the special forms to expand into procedural code that is
easy for their compiler's type inference to handle.

Will