[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
your note on Function Cells.
- To: JonL.pa @ PARC-MAXC
- Subject: your note on Function Cells.
- From: George J. Carrette <GJC @ MIT-MC>
- Date: Tue ,27 Sep 83 20:10:00 EDT
- Cc: LISP-FORUM @ MIT-MC, Padget @ UTAH-20
- In-reply-to: Msg of Tue 27 Sep 83 16:16 PDT from JonL.pa at PARC-MAXC.ARPA
A loaded VAX-NIL MACSYMA has about 14 thousand of what you
call slink cells allocated, mostly for function cells. So if
you had implemented them as a slot in the symbol it would have
indeed been a loser. Actually, another thing the indirection
buys us is to make it possible to relocate symbols without putting
a lot of work into looking at compiled code or its support structures.
Another kind of function cell we see a lot of now is a
flavor-method-table entry. These also get a regular function
cell too now, for the purpose of "book-keeping" in the assembler/loader,
so the figure of 14 thousand is more than slightly bloated by this
and by procedures on property lists. The garbage collector can
clean up this garbage though if the loader did a MAKFUNBOUND.
As you pointed out, the multiple-namespace concept is a very useful
one, and one that programmers have to be able deal with.
People should know that real Scheme programmers can make use of the
multiple-namespace idea too. In Yale T or MIT "6.001 " scheme one
might do a few different things:
(putprop 'foo (lambda (...) ...) 'bar)
and then write
((get'foo'bar) ...)
or define something that looks cleaner and runs faster such as:
(define-namespace foo)
(define-in-namespace (foo bar) (lambda (...) ...))
and then write
((foo bar) ...)
The *hack* is that languages that are implemented efficiently enough
in *general* allow the user to add his own namespace concepts which will
run as fast as if the implementor had wired them into the system and
wrote about them in the manual himself.
I have observed that T, MIT SCHEME, VAX-NIL, and Lispmachine(s)
live up to this *hack*, requiring slightly different amounts of
kludgery on the part of the user in some cases, but with nothing at
the level of LAP or MICROCODE being required.
This puts the arguments on a totally different level, at least for
people with practical access to these kinds of languages/machines.
You can do an excelent implementation of maclisp namespacing in T,
and vice-versa (for the maclisp descendants such as lispm and nil).
On the other hand, architectural optimizations in hardware and/or
software can make it a real bitch (to use the techical term) to implement
tail-calling in some implementations.
-gjc