Foreign Function Interface

[aartaka]

Would be nice to have. There’s %system for shell invocations (and it won’t hurt to actually export it as system or something,) but having C available is even better.

[dermagen]

That would be an entirely separate piece of code (and a big one if one wants to be portable between systems).
I am working on the full numerical tower at the moment, and would consider something like FFI only when I am done with it.

[aartaka]

@dermagen in the meanwhile, can %system be exported?

[dermagen]

People don't like it in the open, tell that it is a security problem. It still can be imported from (skint hidden), but I don't want to advertise it; its name is also problematic for those who are not familiar with libc.

[aartaka]

@dermagen sure, it’s dangerous, but so is importing (skint hidden) in SRFIs. And Lisps are always about not hand-holding the user. So I consider system exporting to be an ideologically consistent move.

Regarding naming: Guile has system and system*, so a precedent is established.

[dermagen]

Didn't know that about Guile, thanks. Will look into it.

By the way, if 'system' is public, wouldn't it require a lot of system-dependent file name and other system-dependent hacks to operate correctly in a portable code? It was not easy to organize tests execution on top of it -- Windows and Unix command lines are different in many respects

[aartaka]

By the way, if 'system' is public, wouldn't it require a lot of system-dependent file name and other system-dependent hacks to operate correctly in a portable code?

Dunno about that. It might! But even providing only system and dispatching on features might be a possible approach 🤔

[pipebyte]

Following up on the "can %system be exported?" question earlier in this thread.

I tested the smallest possible public version. %system already works through (skint hidden); the change is simply to make the existing primitive public and documented.

Concretely, the change is one added line in i.h:

declare_instruction(system, "Z6", 0, "%system", '1', AUTOGL)   /* existing */
declare_integrable(NULL,   "Z6", 0, "system",  '1', AUTOGL)    /* added */

The added line is an alias bound to the existing Z6 encoding: no new VM instruction, no new C implementation, no new dependency, and %system itself is unchanged. One entry in the export table of pre/t.scm, (system . process) — the dotted form is this table's convention for (skint NAME) libraries — makes the name reachable as (import (skint process)); (scheme process-context) is not touched. t.c is regenerated from pre/t.scm as usual.

The primitive already runs the command through the C library's system() and translates the returned wait status; the implementation already has a _WIN32 case. Measured behaviour:

(system "echo hi")          ; prints "hi", returns 0
(system "sh -c 'exit 7'")   ; returns 7

The procedure does not capture output; the caller can redirect it when needed.

The difference from simply telling users to import the hidden library is that (skint hidden) is undocumented and explicitly not advertised, and currently makes 391 bindings available unless narrowed with only ((only (skint hidden) %system) gives exactly one); (import (skint process)) imports one.

The practical consequence is that command-level control flow can stay in Scheme instead of moving into a shell script. I tested a deterministic loop in which the command — driven by a counter file — fails twice and succeeds on the third call; retry, inspection, and accumulation all remained in Scheme:

("FAIL 1" "FAIL 2" "OK 3")

A second run, with the counter already past the threshold, produced ("OK 4"): the loop exits on the first success. This is a mechanism test, not a reliability test.

On the concerns mentioned earlier:

Naming: system is consistent with the terminology used by other Scheme implementations such as Guile. It also gives the existing functionality a documented entry point instead of requiring (skint hidden).

Portability: system() is already used by the implementation, with existing _WIN32 handling for the returned status. The platform-specific part is the command syntax itself, which depends on the caller.

Not proposed here: pipes (open-input-pipe / open-output-pipe) and FFI.

— pipe byte came for pipes, left with system found.