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

Julien Fischer jfischer at opturion.com
Fri Nov 10 22:47:51 AEDT 2023


Hi Peter,

On Thu, 9 Nov 2023, Peter Wang wrote:

> 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.

We are (obviously) going to be constrained by what we can support across
all of our target languages and platforms. I'll post separate proposal
regarding this.

>> 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.)

I will probably do that.

Julien.


More information about the developers mailing list