* 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).