Re: macros, procedure->macro

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> > > Removing these would change the interface.  According to our
> > > standard procedure, this would mean going through a phase of
> > > deprecating the corresponding functions.  However, this would mean,
> > > we could not actually proceed with working on the evaluator, since
> > > as long as those functions exist (even if deprecated) it is not
> > > possible to split up the evaluator.
> > 
> > Is it really impossible?  I'd say it can be done, as long as we have
> > 'local-eval'.
> 
> Could you explain how you think it should be done?  Especially how you
> think one should obtain the local environment during execution.

The local environment is just there during execution, isn't it?  We
need to keep using our current data structure for it that can be
searched for local variables.  We could not immediately switch to a
more streamlined data structure for environments that omits these
names.

Actually, we need only keep the old data structure for code that uses
"acros" or "macros".  This can be determined at memoization time.  So
if we are really want to switch to a different environment
representation, we can do that while still providing "acros" and
"macros", but it would probably too much work.

Then, when we have a 'traditional' environment, we can pass this
environment to the "acro" and "macro" transformers and use it to
memoize and execute the code returned by the "macro".

> In any case, I think it should be a temporary solution to be able to
> go through a phase of deprecation of acros and macros.

Yes.