unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* 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).