Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hi Alex,

Thanks for your feedback.

Alex Shinn <address@hidden> skribis:

> On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <address@hidden> wrote:
>>
>>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>>>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>>>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>>>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>>
>> I wonder how these are specified.  Does a *-kfreebsd-gnu build have
>> ‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
>> isn’t used?  Does Cygwin have ‘unix’?
>
> First note the list of feature identifiers is one of the
> things most likely to be trimmed in the next draft.

Good.  :-)

> There is no "gnu" feature proposed in R7RS,

That would be for GNU, aka. GNU/Hurd.

> The point about the "unix" feature being vague is well
> taken.

It’s not just ‘unix’, see the above examples.

>> And above all: are people going to write #ifdef __linux__ish code when
>> what they mean is #ifdef __GLIBC__ or even something different?
>
> This particular analogy doesn't apply.

IMO it applies in the sense that, as with C code, people will check for
‘linux’ when what they really care about is what the libc provides, or
whether the core utilities support --color, etc.

The libc/kernel confusion has been causing a lot of troubles to people
porting C applications from GNU/Linux to GNU/kFreeBSD and GNU/Hurd.
This class of problem should be avoided as much as possible.

[...]

> Regardless, we're likely to add a disclaimer that you
> should only resort to cond-expanded code as a last
> resort.

Yes, definitely.

I haven’t checked whether R7RS has something like that, but I think it
would be nice to provide well-defined, fine-grain indicators instead.
For instance, a ‘file-separator’ variable, which would be ‘/’ on Unices
and Cygwin, and ‘\’ on raw Windows.

Thanks,
Ludo’.