[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: gls@AQUINAS.THINK.COM
- Subject: Function cells
- From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
- Date: Thu, 20 Feb 86 19:53:37 EST
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of Thu 20 Feb 86 18:27 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
I lied of course when I said I didnt understand the efficiency arguments
for function cells and their irregular binding semantics. I do understand,
and I think they are hogwash. First, the dynamic binding case might
not really be the most important. It is true that in most code written
*now* a form (<F> <A> <B> <C>) the <F> is 98% evaluated "dynamic"
(or at least it uses a shallow bound global cell, which is not the
same thing really) and the rest of <A> <B> <C> are 90% local or lexical.
But one need not equate global cell with fluid binding. Also one
need not equate multiprocessing fluid binding with DEAP BINDING.
There are easy ways of implementing fluid binding in a multiprocessing
or multiprocessor context without arbitrarily costly table lookups.
(Example, a LMI-LAMBDA 2-processor model running ... to be published...)
The argument DCP mentions that goes like "what if I BIND #'CAR" is
also hogwash. What if I (defun car (x) ...)??? You have the same
problem. A good answer starts off with, "well, when you compiled the function F
you did it in a lexical scope where CAR was bound to a CONSTANT."
Unfortunately to users of common-lisp that isnt a good answer because
common-lisp does not admit of such a *model* of binding and evaluation.
What you want is a model where fluid, local, lexical, all fall out
as the same mechanism with slightly different parameters. I claim that
even MIT freshman get exposed to such models.