Re: Requests for API changes

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> I have not yet deprecated SCM_SYMBOL_FUNC and friends.  The question
> is, how these should be cleanly replaced?

Hmm, the function slot of symbols is meant to implement the two name
spaces for functions and variables of most Lisps.  Variable values
would be looked up in the normal way via the module system and
function values would be gotten directly from the symbol.

Maybe we could just look up the function values via the module system
as well, by having two environments instead of just one for looking up
variable values.  The evaluator look into one of these environment for
identifiers in the car of a form, and in the other for the rest.

One way to do this would be to have a new special form, say `(lookup
ENV SYM)' where ENV must evaluate to an environment and SYM must be a
symbol.  This form would cause SYM to be looked up in ENV and
memoized.  Care must be taken so that ENV is evaluated in the right
context.  Maybe it is better not to do any evaluation in this special
form and just enable it to select from a previously installed set of
environments.  This set of environments would be attached with the
code like the lookup-procedure is now.

For example, we could have

    (set-extra-eval-environments `((funcs . ,FENV)))

    ((lookup funcs foo) ...)

That would give us a super general way to lookup in multiple name
spaces in Scheme code.  But I'm sure there are some problems with this
approach that I don't yet see.

As an alternative, we could just hard wire function and variable
environments into the evaluator.  Scheme code would have the same
environment for both function and variable lookup and Lisp code can
have two separate ones.

I think the latter alternative is simpler and should be good enough.