So I guess you don’t need to emulate wrap around integers,
if you would provide more GNU support. And the analogue to
a library(file_system) for SICStus prolog compatibility like here:
Would possibly also not be a full emulation. Only the file
system predicates from GNU would land in some SWI-Prolog library.
But I didn’t yet manage to compile GNU 1.6.0 so that it has
same speed as GNU 1.5.0 or GNU 1.4.5. So I am using still
GNU 1.5.0 or GNU 1.4.5 whenever I am refering to GNU. Not
yet the new GNU 1.6.0, which I am too stupid to compile correctly
AFAIK, it is not part of POSIX. The POSIX primitive is mkdir(), which takes a path name (and mode) and adds a single directory to the filesystem. It fails with EEXIST if there is something there (either a directory or some other entry) or ENOENT if the parent inferred from the given pathname does not exist and ENOTDIR if the inferred parent is not a directory (and a bunch of permission, representation, resource, etc. errors).
So, at least on POSIX, the way to ensure a directory is
[optionally] check it exists. If so, done
Create it. If no error, done. If error, check that it exists. If so, done.
The first could be omitted. The error-checking create is required as even if the directory did not exist, it may be created between the two calls. The second could only check for existence in the EEXIST error. That is precisely what the SWI-Prolog library does.
The more interesting question is what should a high level language that attempts to be as OS neutral as possible provide. It would be a great topic for the PIP initiative started at the ICLP in London. Might turn out to be hard. Luckily the number of fundamentally different file systems that are still relevant have decreased a bit and we can learn from many other languages.
That is surely a good starting point. Would be nice to have agreement between at least a number of important Prolog systems … Many systems seem to have something that is pretty usable, but no two systems agree on even the basic names, basic semantics and error handling. As acting on errors is not uncommon, some agreement would be desirable. Possibly even better is to define more high level primitives that do not require acting on errors (such as ensuring a directory exists).
The reason I suggested this is that Python has a pretty good process for proposing designs and reviewing the (PEPs, etc.), so typically a lot of thought has gone into the various APIs. (os.makedirs and os.mkdir are fairly old, so they might not have had as much review)
Agreed that higher-level APIs would be good, such as ensure_directory/1, but even there, some kind of error handling needs to be defined (e.g. ensure_dictionary('/foo/bar) would typically be an error), and details of the access modes would also need to be defined. (AFAICT, ensure_directory(foo, 0o777) would be the same as Python’s os.makedirs('foo', mode=0o777, exist_ok=True), so we could use the usual SWI-Prolog conventions for options, e.g. `makedirs(“foo”, [mode(0o777), exist_ok(true)]).