|Static type-checking with dynamic scoping firstname.lastname@example.org (1991-01-14)|
|Static type-checking with dynamic scoping email@example.com (1991-01-15)|
|Re: Static type-checking with dynamic scoping Chuck_Lins.SIAC_QMAIL@gateway.qm.apple.com (Chuck Lins) (1991-01-15)|
|Re: Static type-checking with dynamic scoping brm@Neon.Stanford.EDU (Brian R. Murphy) (1991-01-15)|
|Re: Static type-checking with dynamic scoping firstname.lastname@example.org (1991-01-16)|
|Re: Static type-checking with dynamic scoping brm@Neon.Stanford.EDU (Brian R. Murphy) (1991-01-17)|
|Re: Static type-checking with dynamic scoping email@example.com (1991-01-21)|
|From:||Brian R. Murphy <brm@Neon.Stanford.EDU>|
|Organization:||Computer Science Department, Stanford University|
|Date:||Tue, 15 Jan 91 16:42:07 -0800|
It seems to me that one could consider (dynamically bound) free
variables in a procedure to simply be additional parameters to the
procedure. Then standard ML-like type inference could be done.
Not being fluent with ML syntax, I give an example in (dynamically
(defun f (x)
(y x)) ;; y free, bound dynamically
Here f might taken to have type:
([y: a->b], a) -> b
that is, it takes an argument of type a, a binding of y with type a->b,
and returns a value of type b.
A place where f is used might look like:
(let ((y sub1))
where y has type
int -> int
and f is applied to ([y:int->int], int) which may be unified with the
above, yielding a result of int as well.
Keeping track of all of the current bindings and determining which
onese were relevant in a particular application would certainly
clutter up the type inference, but it shouldn't make it terribly
Return to the
Search the comp.compilers archives again.