[m-dev.] foldl2 and recursive_fold2 in dir.m have the wrong result type

[Zoltan Somogyi]

2021-05-12 21:36 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> In that case you can call them something like foldl2_maybe_error etc.
> The names won't be permanent since we'll go back to the original ones
> after a few releases anyway.

The existing predicates return a type that maybe contains an error,
so I think a "_maybe_error" suffix would be misleading.

>> Are you saying that there is a possibility that two independent test cases
>> could be compiled into an *overlapping* set of class files? So if those
>> two test cases are executed at the same time,
>>
>> - test case 1 could create e.g. x.class,
>> - test case 1 could then use x.class,
>> - test case 2 could overwrite x.class,
>> - test case 1 could finish and delete x.class,
>> - test case 2 could fail because it cannot find x.class?
>>
>> Is this theoretically possible?
> 
> It could be the case for those test cases that share a module whose
> source code is in the tests directory.  It shouldn't occur for
> genuinely independent test cases however.

I was asking about *independent* test cases, i.e. test cases that
do not share a module. But never mind, the rest of your reply
told me what I wanted to know.
 
> It doesn't.  For each program, the Mercury compiler knows what all of
> the top-level class files will be called.  For each top-level class,
> Foo, we know that any other classes related to that class (e.g. nested
> classes etc) will have a class file name beginning with the prefix Foo$.
> The Mercury compiler constructs the set of such prefixes and then includes
> all files beginning with those prefixes in the JAR.

So, basically what we want is NOT "the full list of files in this directory", but
"the full list of files in this directory whose name starts with one of this list
of prefixes". That means that errors when opening files whose names
do NOT start with such a prefix should NOT be considered errors.

>> And a last question: is there any reason for why list_class_files_for_jar
>> uses dir.recursive_foldl2 instead of variant that ignores errors caused
>> by entries in directories that disappear between being read and being opened,
>> other than "recursive_foldl2 exists, and it is close enough"?
> 
> I'm not sure.  Where is the other version?

That's my point: it does not exist (yet), while recursive_foldl2 did and does exist.
The right thing to do there would have been to write that version, instead of using
existing code that did not do *quite* what needed to be done.

Zoltan.