[m-users.] Impurity needed?

[Volker Wysk]

Am Donnerstag, dem 23.02.2023 um 12:26 +1100 schrieb Mark Brown:
> On Wed, Feb 22, 2023 at 4:36 PM Volker Wysk <post at volker-wysk.de> 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 <post at volker-wysk.de> 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)?

I'm not sure how small such a set would be, to be useful. Just
forwarding odbc_io operations to io operations shouldn't be hard to
implement. Still, in the end, it might amount to making stubs for much of
the io library... And there also might be predicates in the io library which
do or don't alter the state of the world, depending on the arguments.

Granted, there are cases (like mine), where it's just reading a file, and a
limited set of IO actions will do.

And, I think, there might be cases where it would be desirable to do IO
operations inside a transaction, which *do* change the state of the world.
For instance, writing data to a log file while in a transaction. This might
be data about trying something, and it would be desirable to keep it, even
when the transaction is rolled back.

I think your idea would make sense, but it probably can't cover all cases of
desirable non-world-changing io inside a transaction.

I'm a little reluctant about such a limited odbc_io state. I don't like the
idea of being restricted...

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20230223/361d4755/attachment.sig>