[m-dev.] proposed additions: file copying in stdlib and compiler

[Peter Wang]

On Tue, 07 Nov 2023 16:32:16 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> 
> 1. Add copy_file and copy_directory to the standard library.
> 
> Many programming languages provide some form of file copying operation as part
> of their standard libraries (Files.copy() in Java, File.Copy() in C#,
> std.filesystem::copy in C++17, std::fs::copy in Rust etc).  While file copying
> is in general is an intrinsically filesystem-specific thing, I think it is
> possible to provide a version that is sufficiently useful to warrant its
> inclusion standard library.
> 
> I propose we add the predicates io.file.copy_file and io.file.copy_directory to
> the standard library.  The actual semantics of these operations (e.g. how they
> deal with existing files, symbolic links etc) will need to be decided, but I'm
> intending to replicate what "cp" and "cp" -R do respectively.  (See the second
> half of this proposal below for why.)
> 
> For copy_file, I propose to shift the do_copy_file predicate from
> compiler/module_cmds.m into library/io.file.m and use that as the fall-back
> implementation. If the target platform provides a more efficient mechanism (e.g
> CopyFile() and friends from the Windows API), we would use that in preference.
> 

It sounds okay. For a copy_file operation in the standard library,
I think you'd want a range of options, as seen in some of the operations
in other languages.

> I propose to add a new flag to the Mercury compiler, --install-method.
> This option will accept two values: external and internal.
> 
> With a value of "external", the compiler will use the values of
> --install-command and --install-command-dir to copy files and directories
> (just as it does now).

That's fine. There's no need to add anything to the standard library
first, though. (I mean that the problem in the compiler can be fixed
before we hammer out the design of copy_file in the standard library.)

Peter