Re: [m-users.] Impurity needed?

Mark Brown <[email protected]>
Newsgroups gmane.comp.lang.mercury.general
Message-ID <CAM4AczBR7FCOvD=Da3sTbf9K_0kG3h2UpzpxdcbksRi8D3L4Zw@mail.gmail.com>
On Wed, Feb 22, 2023 at 4:36 PM Volker Wysk <[email protected]> wrote:
>
> Am Mittwoch, dem 22.02.2023 um 03:23 +1100 schrieb Mark Brown:
> > On Wed, Feb 22, 2023 at 12:23 AM Volker Wysk <[email protected]> wrote:
> > > So you think it would be okay to add the IO state to transactions in the
> > > ODBC library? Such that IO in a transaction would be allowed? Of course the
> > > programmer needs to be pointed to the fact that his IO actions can't be
> > > backtracked.
> > >
> > > Zoltan said this was a very bad idea...
> >
> > Right, it would be unsafe in much the same way as unsafe_{get,set}_io,
> > except the user's code wouldn't need to mention "unsafe" anywhere.  A
> > better solution would be to use those as needed, which would at least
> > alert people to the issue even if it can't be checked.
>
> Maybe make two predicates: called "transaction" and "unsafe_transaction".
> With only the latter allowing IO.

I wouldn't object.  It's much the same decision as whether to
advertise unsafe_{get,set}_io, though we often aren't as strict with
these sorts of things when it's not the std library.

Would it be possible to specify a small set of I/O operations that can
be guaranteed safe?  E.g., reading from a file seems ok.  If so it may
be possible to define a safe transaction that allows this, by
providing an abstract odbc_io type that is passed to the user code and
can forward file reads, or whatever, to the io module.  Do you think
that would make sense (or are there holes I haven't thought of)?

Cheers,
Mark

>
>
> Cheers, Volker
>
> _______________________________________________
> users mailing list
> [email protected]
> https://lists.mercurylang.org/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.