[m-users.] io.error type

[Peter Wang]

On Sat, 05 Feb 2022 13:51:58 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi Peter,
> 
> On Sat, 5 Feb 2022, Peter Wang wrote:
> 
> > On Fri, 04 Feb 2022 15:52:38 +0100 Volker Wysk <post at volker-wysk.de> wrote:
> >> Am Freitag, dem 04.02.2022 um 12:54 +0100 schrieb Fabrice Nicol:
> >> > So yes, errno codes could have been returned, if is_error had been 
> >> > publicly visible, but design decisions went against this.
> >> 
> >> How are the chances that this will be changed? Not being able to determine
> >> which error occured, is kind of grave.
> >
> > I agree it would sometimes be useful to get a machine-usable reason for
> > an error. I think we should add something like:
> >
> >        % Get a system-specific error code associated with an error,
> >        % if any. On C backends, the error code should be an errno
> >        % value.
> >        %
> >    :- pred system_error_code(io.error::in, int::out) is semidet.
> 
> My inclination would be to just to store the system_error value in the
> io.error type, rather than turning into an int.  If we document
> what the target language representation of a system_error value is,
> then it will be "helpful" for the C# and Java backends as well.
> 
> (The io.error type would continue to contain its current string field,
> since removing it would break code that calls io.error_message.)

Yes, that seems better. So we have:

    % implementation
    :- type io.error
        --->    io_error(system_error, string).

    :- func make_io_error(system_error, string) = io.error.

    :- pred get_system_error(io.error::in, system_error::out)
        is semidet.

An io.error value constructed by make_io_error/1 will have a dummy
system_error in the first argument; it can be -1 or null.

Peter