Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used

[Dirk Herrmann]

Marius Vollmer wrote:

>  Kevin Ryde <address@hidden> writes:
>
> > Ah, no, I see this is still not right. scm_m_generalized_set_x is
> > using scm_macroexp, but it's not defined at all under
> > --disable-deprecated.
> >
> > Looks like this was a change by Marius not so long ago. Dunno if
> > it should be using scm_macroexp, or something else now.
>
>  I don't know either. Dirk, what would be The Right Thing here?

The goal is, to make the following possible:

(set! (@ some-module some-variable) value)

The current solution goes beyond that, by allowing any macro at the
place of the target of the set! macro. My assumption is, that this is
not intended, but just accepted as a side effect.

I don't think I have a good solution yet. However, here's at least some
suggestions:

1) Quick, and dirty: Re-surrect scm_macroexp _statically_ in eval.c.
The best would be to rename it to macroexp, to document clearly that it
shall not part of the API. It will not cause too many problems to make it
fit to the separate memoizer, since my local copy of guile provides
something similar to scm_macroexp: It provides a static function
memoize_expression, which not only expands the macros, but also
memoizes the resulting expression.

The problem with this approach would be, that it introduces a feature
that is not intended to be provided as such: As of now it provides
the expansion of arbitrary macros at the position of the target of
set!. If later we simply switch to memoize_expression, then we go
even beyond this, since memoize_expression will allow even further
transformations than scm_macroexp did.

2) Cleaner: Change the set! macro to check the target explicitly for
being (@ some-module some-variable) and modify the expander of
set! to set the variable within some-module directly.

This has the advantage, that set! really only accepts variables and
not arbitrary macros / expressions that expand to variables. It has
the disadvantage that the set! macro becomes more complex.

3) Different: Leave set! as it was before, and provide something
like address@hidden in addition to set!.

I am not sure that I like this one at all.

4) Undo the change to the set! macro and just don't provide the
possibility to (set! (@ ...) ...) until the new expansion works and
is ready for integration. (I hope that this is not too far away any
more - I fixed some major issues lately. Only goops is still bothering
me now...)

Best regards
Dirk