On Mon, Feb 13, 2012 at 8:46 AM, Ludovic Courtès <ludo@gnu....> wrote:
> Hi Alex,
> Thanks for your feedback.
> Alex Shinn <alexshinn@gmai...> skribis:
>> On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <ludo@gnu....> 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.
Wouldn't the feature be better named "hurd" then?
How can a system be both Hurd and Linux?
>>> 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.
Yes, but you're talking about C features, when we
only have to worry about Scheme features, so I need
more relevant examples to be able to give explanations
or take corrective action.
> 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.
Presumably this would be part of the R7RS large