[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should guile-3.0 cond-expand guile-2 and guile-2.2?

From: Rob Browning
Subject: Re: Should guile-3.0 cond-expand guile-2 and guile-2.2?
Date: Tue, 10 Mar 2020 21:52:11 -0500

Ludovic Courtès <address@hidden> writes:

> Rob Browning <address@hidden> 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)
       (module-re-export! (current-module) names #:replace? #t))
       (module-re-export! (current-module) names))
       (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?

Rob Browning
rlb and
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]