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

[Zoltan Somogyi]

2021-05-15 21:26 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> However parlous the state of CS education may be, I think using the term
> "preoder" in the standard library documentation is reaonsable.
> The standard library docuemntation already assumes that the reader knows
> what things like an inorder traversal or topological sort are.

OK, will do.

>> This actually reminds me of another issue. The code in module_cmds.m
>> wants to accumulate a set of *file*names, not *dir*names, so calling Pred
>> on directories, as far as it is concerned, is both unnecessary work, and
>> potentially an unnecessary complication. As in: we need to filter out
>> directory names as they cannot be the .class files we are looking for,
>> but a malicious actor *could* in theory put a subdirectory whose name
>> ends in ".class" and has one of the prefixes we are looking for into the
>> directory we are searching. This is very unlikely, but I would prefer
>> this code working by design, and not by accident.
>>
>> It occurs to me that enter_subdirs could have another field, with a value
>> that is one of (say) call_pred_on_dir and do_not_call_pred_on_dir,
>> and we would call Pred on the directory only with the former value.
>> Do you object?
> 
> I have no objections.

Actually, I have realised that this flag is not needed. When we call Pred,
one of the arguments we pass to it is the file type, so that Pred itself
can decide whether to do anything with not just directories, but also
symbolic links, named pipes etc.

Instead, I made module_cmds look for .class files only among
regular files and symlinks.

>>>> +            % XXX The message is too verbose for use in a full file_error.
>>>
>>> I'm not sure what you mean by that one.
>>
>> There is an inherent tension between foldl2 and recursive_foldl2 on the
>> one hand, and general_foldl2 on the other hand. The general version
>> returns error info in a structured form, with the name of the file and
>> the identity of the failed operation separate from the I/O error.
>> For this use case, including the file name or the name of the op
>> in the string inside the I/O error would be bad, since it would prevent
>> users from formatting an error message as they liked. On the other hand,
>> for the original two versions, whose existing interface can return
>> no other info for an error than the I/O error itself, *not* including
>> the filename and the op in the I/O error is what is bad, since they
>> leave the user with no useful info to track down the error.
>>
>> We could solve this problem by including the filename and the op
>> in the message string only if a new field in the params says that
>> the top level call will return full file_errors, and not just I/O errors.
> 
> Given that foldl2 and recursive_foldl2 (in their current form) will be
> going away in the longer term anyway, I think that XXX can be resolved
> once that happens.

OK, I will leave the XXX.

Zoltan.