[m-rev.] for review: specialise file copying in the compiler

[Julien Fischer]

On Sat, 23 Apr 2022, Zoltan Somogyi wrote:

> 2022-04-23 22:38 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:

>> 3. We should add some sort of copy_file predicate to the standard
>> library.  This is slightly iffy since file copy operations in most
>> programming language standard libraries are really "copy the file and
>> preserve relevant metadata where possible".
>
> In at least some cases, preserving the modification time is something
> that we want to *avoid*, though I am not sure you include that in "metadata".

Certainly for this use case "metadata" does not include the file
modification time.  What metadata a standard library copy_file predicate,
preserves and what level of control the user has over that is one of the
"slightly iffy" things I referred to above -- it unfortuantely tends to
get very OS and file system specific.

>> On balance, I think it would
>> be a worthwhile addition and we can make it work well enough on the
>> platforms we support.
>
> If you say so; I don't know about non-Unix platforms to say yes or no.
>
>> There was the small matter of the 22.01 release between then and now ;-)
>
> Of course. I was just surprised that you seemed to abandon the agreed-on
> approach.

I had other things I needed to work on and haven't had time to circle
back to it yet.  (It will happen since I need those types for some things
at Opturion.)

...

>> Another question: should the stream foldls in the stream module be
>> modified to reduce stack usage in debug grades (as some of the ones
>> in the io module have been)?
>
> I don't think they should be modified; I think there should be separate
> versions of the relevant predicates that do chunking, with an extra
> chunk size parameter, since that does vary with expected max iteration length.

Ok.

Julien.