Chibi does not provide linux/linux-gnu/posix cond-expand feature

[a2379]

The R7RS (features) specification suggests that linux-gnu can be used as a cond-expand feature identifier. Appendix B specifies posix as well. But neither are provided by chibi.

I think the the linux feature should be set if running on Linux, linux-gnu only if _GNU_SOURCE is set, and posix for all POSIX systems (and maybe Plan 9?).

[a2379]

Also does not seem to expand CPU architecture features either, like x86-64.

[mnieper]

What is the precise semantic meaning of the identifiers? This question needs to be answered first before one can decide whether is certain feature flag should be set or not.

[ashinn]

Agree with @mnieper, the list in the appendix is just suggestions and not formally specified. Was there a SRFI for this?

Not sure why we'd want linux-gnu instead of linux. Plan9 is not posix.

Anyway, added the missing architecture feature for now.

[lassik]

https://github.com/cpredef/predef is a great resource for this stuff. But underscores the point that it's not an exact science.

[a2379]

It doesn't need to be precise to be useful. If I have a Scheme script that needs to change its behavior based on the OS it's running on, having a general identifier like openbsd or linux is sufficient.

I agree that linux-gnu is not necessary, I guess they just wrote that in the spec to avoid the GNU/Linux debate.

[mnieper]

It doesn't need to be precise to be useful. If I have a Scheme script that needs to change its behavior based on the OS it's running on, having a general identifier like openbsd or linux is sufficient.

I agree that linux-gnu is not necessary, I guess they just wrote that in the spec to avoid the GNU/Linux debate.

There is a huge difference between a GNU/Linux system and, say, an Android system with a Linux kernel. Thus, it makes a lot of sense to differentiate further. For example, when the Scheme system offers an exec-like command, the feature flags (if sufficiently specified) could tell the applications which typical programs are available to execute. A generic linux wouldn't help much here.

[a2379]

There is a huge difference between a GNU/Linux system and, say, an Android system with a Linux kernel.

The OS is the feature identifier, not the kernel. Android would have its own feature identifier, not linux IMO.

It may be helpful to differentiate a Linux system with GNU userland/glibc vs busybox/musl, but I think the broader feature identifiers are a good starting point.

[lassik]

Binaries are built for CPU + kernel + libc. The only GNU piece here is glibc.

[lassik]

At runtime, there's uname() and /etc/os-release. I imagine there are gotchas for both.

[a2379]

Binaries are built for CPU + kernel + libc. The only GNU piece here is glibc.

Yes, but a Scheme scripts may interact with userland through subprocesses, and GNU tools have a number of extensions that incompatible with POSIX tools.

At runtime, there's uname() and /etc/os-release. I imagine there are gotchas for both.

Yes but having an abstraction would be helpful, especially in a language like Scheme where OS details are usually abstracted over.

[lassik]

cond-expand is the wrong tool for finding your way around the userland. If you need GNU tar, try tar --version.

[lassik]

The underlying principle is that cond-expand can be used for both compiled and interpreted Scheme code. The concerns that apply to compiled Scheme programs (across the full range of available of Scheme implementations) are pretty much the same ones that apply to compiled C programs.

For example, a built program can be copied to another computer with compatible kernel and libc but a different userland. Or a program built on Windows 7 can be run on Wine/Linux or Wine/MacOS.

[ashinn]

If you need tar, use (chibi tar)! :wink:

Yes, there are limitations to cond-expand (especially when it comes to cross compiling) but it's better than nothing. System interfaces should be abstracted into portable libraries, but until these are available you often have no other choice than to use cond-expand.

That said, Chibi has all of these features except posix and the gnu- linux variant because I'm unclear as to both the motivation and semantics of those. If there are developments in that area we can reconsider, but in the meantime am closing this.