On Mon, Feb 13, 2012 at 8:46 AM, Ludovic Courtès <l...@gnu.org> wrote: > Hi Alex, > > Thanks for your feedback. > > Alex Shinn <alexsh...@gmail.com> skribis: > >> On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <l...@gnu.org> 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 pathnames library. -- Alex
