Prepend "Gambit" to gsc -v output

[fare]

To easily distinguish Gambit Scheme from GhostScript, could the output of gsc -v be prepended with "Gambit ", "Gambit Scheme ", or "Gambit Scheme Compiler "? That would help a lot.

For reference, my current output is:

v4.9.3 20180930122740 x86_64-pc-linux-gnu "./configure '--prefix=/nix/store/66n5065r41jwbrng159xn19b12mwmw66-gambit-unstable-2019-09-07' '--enable-single-host' '--enable-c-opt=-O2' '--enable-gcc-opts' '--enable-shared' '--enable-absolute-shared-libs' '--enable-poll' '--enable-openssl' '--enable-default-runtime-options=f8,-8,t8' 'CC=gcc' 'CXX=g++'"

[lassik]

Note: Gambit's gsc -v can already be distinguished from GhostScript's gsc -v since the latter command's output starts with GPL Ghostscript. But if starting gsc -v output with Gambit doesn't present a backward-compatibility problem, it's nice as well.

[feeley]

Changing the output of the -v option should happen rarely because it breaks backwards compatibility, and the -v option is exactly for situations when a script needs to know the version of Gambit. It has always been the case that the first word of the output is the version number vX.X.X:

> (read (open-process (list path: "gsc" arguments: '("-v"))))  
v4.9.3

It seems the original problem can be solved much more directly by calling up the gsc-script program, which is the same as gsc but doesn't clash with ghostscript.

[lassik]

It seems the original problem can be solved much more directly by calling up the gsc-script program, which is the same as gsc but doesn't clash with ghostscript.

That seems right. Can gsc-script be relied on to be installed whenever gsc is?

Changing the output of the -v option should happen rarely because it breaks backwards compatibility, and the -v option is exactly for situations when a script needs to know the version of Gambit. It has always been the case that the first word of the output is the version number vX.X.X:

That's fair enough. If it has always been that way, some scripts probably depend on it.

Would you be interested in an S-expression output format for the version flag? I thought about how to do that for a while and came up with a solution that is backward-compatible with the existing version output of all Scheme implementations I could get my hands on and can also be parsed with line-oriented Unix tools like grep and awk. The trick is for the S-expression parsing to start at the first output line with a parenthesis in the leftmost column. The preceding text can be in arbitrary format: no other output format besides S-expressions tends to begin lines with parentheses.

I also surveyed the version flags of all those Scheme implementations. Many of them have -v (lower-case) and -V (upper-case) and many also have --version and -version. I think -V (upper-case) is the strongest tradition for a version flag in Unix programs, and very rarely has any other meaning (lower-case -v is used as a verbose flag by many programs, including some Scheme implementations). The Art of Unix Programming recommends it.

[lassik]

I'll submit a SRFI about that version flag thing in any case. It's a bit of a culture shock to output S-expressions from a Unix program, but after staring at output sketches for a while it didn't feel less natural than alternative syntaxes like Keyword: Value. And the regularity of S-expressions makes them much easier to parse: there few if any ambiguous situations.

[feeley]

The output of -v is already in S-expression syntax... a sequence of S-expressions:

> (read-all (open-process (list path: "gsc" arguments: '("-v"))))
(v4.9.3 20180930122740
        x86_64-apple-darwin18.6.0
        "./configure '--enable-single-host' 'CC=gcc-8'")

[lassik]

Very nice! I didn't realize you were using Scheme read in the above example.

I went through all the usage messages I collected, and Gambit's is the only one already in S-expression format. IMHO it'd be useful to have key-value pairs in the output like:

(version v4.9.3)
(build-date 20180930122740)

Many Schemes have the usual information (different subsets of about a dozen common items; there is not a lot of variety) so the keys could be standardized somewhat, and since arbitrary keys are allowed it'd be easy to add new info while being backward compatible.

As one application, I'm preparing a very lightweight #! launcher written in C with the ability to find and start any Scheme (and Lisp) implementation and run a script; having version info in a standard format would make its job a lot easier.

[feeley]

Using this format for Gambit would break backward compatibility...

[lassik]

SRFI 176 (Version flag) is going final over the weekend. Feedback still welcome. It's a full development of the above S-expression key-value idea, backward-compatible with every Scheme implementation I could find. The SRFI hooks into the upper-case -V flag which Gambit is not currently using for anything. Would you be interested in implementing it?