* Should guile-3.0 cond-expand guile-2 and guile-2.2? @ 2020-02-27 7:30 Rob Browning 2020-03-07 15:17 ` Ludovic Courtès 0 siblings, 1 reply; 4+ messages in thread From: Rob Browning @ 2020-02-27 7:30 UTC (permalink / raw) To: guile-devel $ guile-3.0 -c '(display (cond-expand (guile-2.2 "?\n"))) ? Is that intentional? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Should guile-3.0 cond-expand guile-2 and guile-2.2? 2020-02-27 7:30 Should guile-3.0 cond-expand guile-2 and guile-2.2? Rob Browning @ 2020-03-07 15:17 ` Ludovic Courtès 2020-03-11 2:52 ` Rob Browning 0 siblings, 1 reply; 4+ messages in thread From: Ludovic Courtès @ 2020-03-07 15:17 UTC (permalink / raw) To: Rob Browning; +Cc: Guile Devel Hi, Rob Browning <rlb@defaultvalue.org> skribis: > $ guile-3.0 -c '(display (cond-expand (guile-2.2 "?\n"))) > ? > > Is that intentional? I think so, though I don’t think this was discussed here. The way I see it, it means that guile-3 is a superset of 2.2. Ludo’. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Should guile-3.0 cond-expand guile-2 and guile-2.2? 2020-03-07 15:17 ` Ludovic Courtès @ 2020-03-11 2:52 ` Rob Browning 2020-03-11 13:59 ` Ludovic Courtès 0 siblings, 1 reply; 4+ messages in thread From: Rob Browning @ 2020-03-11 2:52 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guile Devel Ludovic Courtès <ludo@gnu.org> writes: > Rob Browning <rlb@defaultvalue.org> skribis: > >> $ guile-3.0 -c '(display (cond-expand (guile-2.2 "?\n"))) >> ? >> >> Is that intentional? > > I think so, though I don’t think this was discussed here. > > The way I see it, it means that guile-3 is a superset of 2.2. OK, though that wasn't true for guile-2.2 with respect to 2.0? In any case, it'd be nice to have the policy documented, perhaps on the srfi-0 info page. At the moment, I just needed a way to write code that behaved differently with 3.0+ as compared to 2.2, because 2.2 doesn't support define-module #:re-export-and-replace, and there's no functional equivalent yet. For now I did this (I don't currently care about older than 2.2): (define (re-export-and-replace! . names) (cond-expand (guile-3.0 (module-re-export! (current-module) names #:replace? #t)) (guile-2.2 (module-re-export! (current-module) names)) (else (module-re-export! (current-module) names #:replace? #t)))) And migrated all the relevant symbols out of the define-module form. Do we think that the norm will be for releases to cond-expand the symbols for all their ancestors (up to some point)? i.e. guile 4 will likely cond expand guile-3, guile-3.0, guile-3.1, ... and guile-2, guile-2.2, and so on? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Should guile-3.0 cond-expand guile-2 and guile-2.2? 2020-03-11 2:52 ` Rob Browning @ 2020-03-11 13:59 ` Ludovic Courtès 0 siblings, 0 replies; 4+ messages in thread From: Ludovic Courtès @ 2020-03-11 13:59 UTC (permalink / raw) To: Rob Browning; +Cc: Andy Wingo, Guile Devel Hi Rob, (+ Cc: Andy.) Rob Browning <rlb@defaultvalue.org> skribis: > Ludovic Courtès <ludo@gnu.org> writes: > >> Rob Browning <rlb@defaultvalue.org> skribis: >> >>> $ guile-3.0 -c '(display (cond-expand (guile-2.2 "?\n"))) >>> ? >>> >>> Is that intentional? >> >> I think so, though I don’t think this was discussed here. >> >> The way I see it, it means that guile-3 is a superset of 2.2. > > OK, though that wasn't true for guile-2.2 with respect to 2.0? Oh, but there was not ‘guile-2.0’ symbol, right? > In any case, it'd be nice to have the policy documented, perhaps on > the srfi-0 info page. Agreed. > At the moment, I just needed a way to write code that behaved > differently with 3.0+ as compared to 2.2, because 2.2 doesn't support > define-module #:re-export-and-replace, and there's no functional > equivalent yet. > > For now I did this (I don't currently care about older than 2.2): > > (define (re-export-and-replace! . names) > (cond-expand > (guile-3.0 > (module-re-export! (current-module) names #:replace? #t)) > (guile-2.2 > (module-re-export! (current-module) names)) > (else > (module-re-export! (current-module) names #:replace? #t)))) > > And migrated all the relevant symbols out of the define-module form. > > Do we think that the norm will be for releases to cond-expand the > symbols for all their ancestors (up to some point)? i.e. guile 4 will > likely cond expand guile-3, guile-3.0, guile-3.1, ... and guile-2, > guile-2.2, and so on? My interpretation is that ‘guile-2.2’ is to be interpreted as “2.2 or any later backwards-compatible version [at a language level]”. Thus, what ‘guile-4’ will mean will depend on the compatibility story of 4.0 wrt. to 3.x. Ideally I guess we’d want to express things in terms of minor/major version (in)equalities rather than plain symbol matches. One can actually do that with a ‘syntax-case’ macro looking at ‘minor-version’ etc., but that’s inconvenient. Ludo’. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-11 13:59 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-27 7:30 Should guile-3.0 cond-expand guile-2 and guile-2.2? Rob Browning 2020-03-07 15:17 ` Ludovic Courtès 2020-03-11 2:52 ` Rob Browning 2020-03-11 13:59 ` Ludovic Courtès
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).