From: "Ludovic Courtès" <ludo@gnu.org>
To: Rob Browning <rlb@defaultvalue.org>
Cc: Andy Wingo <wingo@igalia.com>, Guile Devel <guile-devel@gnu.org>
Subject: Re: Should guile-3.0 cond-expand guile-2 and guile-2.2?
Date: Wed, 11 Mar 2020 14:59:48 +0100 [thread overview]
Message-ID: <87ftefj8kr.fsf@gnu.org> (raw)
In-Reply-To: <87lfo7mwmc.fsf@trouble.defaultvalue.org> (Rob Browning's message of "Tue, 10 Mar 2020 21:52:11 -0500")
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’.
prev parent reply other threads:[~2020-03-11 13:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftefj8kr.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
--cc=rlb@defaultvalue.org \
--cc=wingo@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).