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

[Zoltan Somogyi]

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?

The other thing that we should discuss is why the
list_class_files_for_jar needs to do a complete traversal
of a directory. When doing a bootcheck, I normally do it
with -j6, since my laptop has six cores.  When doing the tests
in e.g. hard_coded, a significant fraction of those traversals will fail,
because between (1) dir.m reading the list of file names
in a directory, and (2) dir.m trying to open the named files,
some other test case will finish, and as part of finishing,
it will delete the files it put into that directory.
In other words, this issue generates Heisenbugs
(or Heisen-test-failures, if you prefer).

I know almost nothing about the management of .class
and .jar files, since the only real Java coding I have done
was when I was teaching a "computing 101" type class
for our masters students, where the programs were all tiny.
Can anyone answer the question at the start of the
previous paragraph, or point me to a relevant resource
that would help me learn myself?

Zoltan.