Related articles |
---|
Static type-checking with dynamic scoping roberto@cernvax.cern.ch (1991-01-14) |
Static type-checking with dynamic scoping gateley@rice.edu (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 barmar@think.com (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 mac@eleazar.dartmouth.edu (1991-01-21) |
Newsgroups: | comp.compilers |
From: | Brian R. Murphy <brm@Neon.Stanford.EDU> |
Keywords: | types, design |
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
scoped) Lisp:
(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))
(f 3))
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
more difficult.
-Brian Murphy
brm@cs.stanford.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.