* GCC 3.4 fails to build eval.c when --disable-deprecated is used
@ 2004-04-25 11:13 Andreas Vögele
2004-05-01 21:50 ` Kevin Ryde
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Vögele @ 2004-04-25 11:13 UTC (permalink / raw)
[Sorry, it seems that my new MUA doesn't complain when sending a
message without subject.]
If Guile CVS is built with --disable-deprecated GCC 3.4 fails to build
eval.c. The problem is that the function scm_macroexp(), which is used
in line 1941 of eval.c, is not declared. The prototype is not declared
in eval.h if deprecated functions are disabled and the function
definition starts further below in line 2131. I solved this problem
locally by adding a forward declaration to eval.c.
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used
2004-04-25 11:13 GCC 3.4 fails to build eval.c when --disable-deprecated is used Andreas Vögele
@ 2004-05-01 21:50 ` Kevin Ryde
2004-05-01 22:00 ` Kevin Ryde
0 siblings, 1 reply; 6+ messages in thread
From: Kevin Ryde @ 2004-05-01 21:50 UTC (permalink / raw)
Andreas Vögele <voegelas@gmx.net> writes:
>
> If Guile CVS is built with --disable-deprecated GCC 3.4 fails to build
> eval.c. The problem is that the function scm_macroexp(), which is
> used in line 1941 of eval.c, is not declared. The prototype is not
> declared in eval.h if deprecated functions are disabled and the
> function definition starts further below in line 2131. I solved this
> problem locally by adding a forward declaration to eval.c.
Thanks, I added that.
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used
2004-05-01 21:50 ` Kevin Ryde
@ 2004-05-01 22:00 ` Kevin Ryde
2004-05-18 21:33 ` Marius Vollmer
0 siblings, 1 reply; 6+ messages in thread
From: Kevin Ryde @ 2004-05-01 22:00 UTC (permalink / raw)
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.
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used
2004-05-01 22:00 ` Kevin Ryde
@ 2004-05-18 21:33 ` Marius Vollmer
2004-05-21 18:41 ` Dirk Herrmann
0 siblings, 1 reply; 6+ messages in thread
From: Marius Vollmer @ 2004-05-18 21:33 UTC (permalink / raw)
Cc: bug-guile, Kevin Ryde
Kevin Ryde <user42@zip.com.au> 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?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used
2004-05-18 21:33 ` Marius Vollmer
@ 2004-05-21 18:41 ` Dirk Herrmann
2004-05-24 20:03 ` Marius Vollmer
0 siblings, 1 reply; 6+ messages in thread
From: Dirk Herrmann @ 2004-05-21 18:41 UTC (permalink / raw)
Cc: bug-guile, Kevin Ryde
Marius Vollmer wrote:
> Kevin Ryde <user42@zip.com.au> 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 set@! 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
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.4 fails to build eval.c when --disable-deprecated is used
2004-05-21 18:41 ` Dirk Herrmann
@ 2004-05-24 20:03 ` Marius Vollmer
0 siblings, 0 replies; 6+ messages in thread
From: Marius Vollmer @ 2004-05-24 20:03 UTC (permalink / raw)
Cc: bug-guile, Kevin Ryde
Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
> Marius Vollmer wrote:
>
>> Kevin Ryde <user42@zip.com.au> 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.
Hmm, the desire to make (set! (@ ...) ...) work was the inspiration
for doing macro expansion of the target of 'set!', but that macro
expansion is intended to be a real feature, not just a side effect.
I actually wasn't asking about fixing the specification of 'set!',
only about fixing its implementation. You say that there is no good
replacement for scm_macroexp yet, so I'll go with your suggestion 1:
making scm_macroexp static in eval.c.
Whether a macro-expandin 'set!' is a good idea or not is a different
question...
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-05-24 20:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-25 11:13 GCC 3.4 fails to build eval.c when --disable-deprecated is used Andreas Vögele
2004-05-01 21:50 ` Kevin Ryde
2004-05-01 22:00 ` Kevin Ryde
2004-05-18 21:33 ` Marius Vollmer
2004-05-21 18:41 ` Dirk Herrmann
2004-05-24 20:03 ` Marius Vollmer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).