Re: Basic Design Questions: function cells

[Martin <GRISS%HP-HULK@HPLABS>]

Return-Path: <@SU-AI.ARPA:berman@isi-vaxa.ARPA>
Received: from hplabs.ARPA by HP-HULK with TCP; Wed 19 Feb 86 13:15:15-PST
Received: from SU-AI.ARPA by hplabs.ARPA ; Wed, 19 Feb 86 13:16:12 pst
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86  12:41:30 PST
Received: by isi-vaxa.ARPA (4.12/4.7)
	id AA04673; Wed, 19 Feb 86 12:43:16 pst
From: berman@isi-vaxa.ARPA (Richard Berman)
Message-Id: <8602192043.AA04673@isi-vaxa.ARPA>
Date: Wed, 19 Feb 1986 16:43:00 -0000
Cc: Alan Snyder <snyder@hplsny.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@su-ai.ARPA

    I believe these arguments were comparing storing function definitions in
    dedicated cells to storing them in property lists.  As far as I know no
    one has argued that having functions and variables in separate name spaces
    leads to a more or less efficient implementation than having them in the
    same name space.
    
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function).  Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------

The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.

RB

Actually, in our CL implementation, and in PSL before it, there is a
compiled LAMBDA handler function (or "thunk") to which you JSR; it
finds the associated S-expression wherever it is (or reconstructs, or
whatever).

Martin Griss
-------