This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
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