Hi Rob, (+ Cc: Andy.)
Rob Browning <r...@defaultvalue.org> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Rob Browning <r...@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’.