Re: scheme-script organization created Lassi Kortela 26 Jun 2021 14:16 UTC
> It's not broken because you can use it distribute executable R6RS > programs, which are portable by design. You also have to distribute > accompanying libraries, of course, but this is no different to typical C > programs. That's using an academic and largely impractical definition of the term "portable". The first problem is that R6RS doesn't specify how the implementation finds libraries in the file system. And the problems grow from there. Are we really pretending that there are a large number of substantial R6RS programs that don't depend on a particular Scheme implementation, and don't depend on particular libraries, FFI, packages, etc.? It just doesn't seem like we would be causing practical problems to many people. Anyone who wants to ship a Chez Scheme program using chez-srfi and some FFI stuff, should just call `chezscheme --program` instead of `scheme-script`, and it doesn't seem sensible to compile that a `scheme-script` breaks a program like that. > Because of the same reason that you would rather call "cc" or "c99" > instead of "gcc". If we can work out a scheme-script that does something reasonable when there are no declarations present in the file, that's a good thing. "cc" (with no knowledge of which compiler it is) lets you compile something akin to ISO C90 ("ANSI C"), using only the standard library, with high confidence that your program works. The Scheme equivalent would be if scheme-script is guaranteed to be roughly R5RS compatible. To get C99 or GNU C, you have to call "gcc -std=c99" or "gcc -std=gnu99", things like that. You can no longer rely on "cc". > Why is everyone in the Scheme community so eager to repeat the same > mistakes that have led to so many splits in the community? R6RS > introduces gratitious incompatibilities to prior SRFIs; R7RS introduced > gratitious incompatibilities to R6RS. R6RS is normative, and is far more central, widely used, and irreplaceable than scheme-script. R6RS was also reasonably specified to begin with, whereas the whole idea of a scheme-script tied to an RnRS is dodgy, irrespective of the details of the spec. There are facilities in POSIX that are standard (normative, even), but widely considered broken as designed (e.g. file locking, definition of leap years). It doesn't pay to adhere strictly to a standard in every detail (especially given that scheme-script is not normative). > That argument would only be correct if `scheme-script' were the only > possible name that isn't misleading. The point is not to look at one name in isolation, but the collection of all our command names taken together. That collection is confusing, and will become more confusing if we add new names. That's what bothers me.