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

[Julien Fischer]

Hi Zoltan,

On Wed, 12 May 2021, Zoltan Somogyi wrote:

> While looking into test case failures during a Java bootcheck,
> I found error messages from list_class_files_for_jar saying
> "file not found or I/O error". These came from calls to dir.recursive_foldl2,
> which of course processes *many* files, but the error message
> cannot say *which* of these files wasn't found, because the
> return type of recursive_fold2 (and foldl2 itself) is a type
> that is intended to return an error for a file operation
> in which the name of the file the operation is done on
> is one of the input arguments of the operation itself.
>
> The right thing to do here would be to change the type
> of the output argument that returns either success or failure,
> so that on failure, it includes the name of the file on which
> an operation failed, and (if there is more than one) the kind
> of operation that failed, as well as the error message from
> the failure itself. We would keep the "partial data computed
> so far" part.
>
> The above would of course break backward compatibility,
> so the next best thing, which I propose to do, is to
>
> - modify the internals along the lines above,
>
> - provide new versions of foldl2 and recursive_foldl2
>  that return this extra info in the case of failure, but
>
> - put code into foldl2 and recursive_foldl2 to throw
>  away this extra info in case of failure, so that they can
>  keep their existing signature.
>
> Any objections? And if not, any proposals for the names
> of the new predicates?

No objections from me. I assume we would eventually deprecate the
originals anyway?

> The other thing that we should discuss is why the
> list_class_files_for_jar needs to do a complete traversal
> of a directory.

Because compilation of a single Java source file may result in multiple
class files being generated (and definitely will with what the Mercury
compiler generates).

Nested classes in Java are placed in their own .class files.  For
example.

     class Foo {
         class Bar {}
     }

will result in the generation of the class files Foo.class and
Foo$Bar.java.  For things like anonymous nested classes the naming
will involve a "non-empty sequence of digits" (to quote the JLS).

There are two reasons why we just search for all the .class files:

    1. The Mercury compiler isn't (currently) aware of what class files
    the Java compiler will generate for a given generated Java source file**
    and ...

    2. ... there doesn't seem to be a specific enough naming scheme on
    the Java side of things that the Mercury compiler could know.
    (The closest I could find is in section 13.1, "The Form of a Binary",
    of version 16 of the JLS.)

(** beyond the one for the top-level class; I think mmc --make is aware
of that for timestamping purposes.)

Julien.