Re: [m-users.] Impurity needed?

On Tue, Feb 14, 2023 at 5:24 AM Volker Wysk <[email protected]> wrote:
>
> Am Dienstag, dem 14.02.2023 um 03:11 +1100 schrieb Zoltan Somogyi:
> > 2023-02-14 02:13 GMT+11:00 "Volker Wysk" <[email protected]>:
> > > > It would be trivial to change the signature as you ask. It would also be
> > > > a very bad idea to do so. The point of making an operation a transaction
> > > > is to ensure that only two things can happen:
> > > >
> > > > - the transaction succeeds, and ALL of its effects happen, or
> > > > - the transaction fails, and NONE of its effects happen.
> > >
> > > In my understanding, this applies only to the effects on the database...
> >
> > Consider this sequence modelling an automatic teller machine:
> >
> > 1. Start a transaction.
> > 2. User specifies the account and the amount to withdraw.
> > 3. Teller machine program commands cash dispenser
> >     to give out the requested cash.
> > 4. The program subtracts the amount from the account,
> >     and discovers that the result is negative.
> > 5. Because of this, the program aborts the transaction.
> >
> > Disregard the fact that the test should have been done before
> > giving out the requested cash. The point I am making is that
> > giving out the cash should happen IF AND ONLY IF the same
> > amount could be deducted from the account. Any violation
> > of that rule either creates or destroys money. Creating money
> > is illegal in most countries unless you are the central bank,
> > and if you are anyone other than the central bank, you probably
> > don't want to pointlessly destroy money either.
> >
> > > > If you allowed I/O in the middle of a transaction, and then later
> > > > it turned out that the transaction cannot succeed, then neither
> > > > of those end states would be reachable.
> > >
> > > So someone using a vanilla imperative language is forbidden to do IO when
> > > being inside a transaction, too -?
> >
> > In imperative language interfaces to DBMSs, there is no practical way to forbid
> > the program to do I/O during a transaction, and, as your use case demonstrates,
> > there are *some* kinds of I/O that you do want to permit. However, saying that
> > database programmers should feel free to do ANY kind of I/O inside transactions
> > is like saying that those programmers should feel free to point ANY device at the
> > users of the database and pull the trigger, whether the device is a water pistol
> > or a flame thrower.
>
> I'm not saying that any kind of IO should be allowed inside transactions.
> But how could a programming language restrict it to the right kinds of
> IO?That isn't possible. It's the responsibility of the programmer to do it
> right. In your example, he has the responsibility to first check the balance
> of the account, before giving out the cash. You have to enable all kinds of
> IO, so the correct ones are possible.

There's research being done in "coeffects" which I think includes
things such as only allowing certain types of I/O.  Mercury's I/O
mechanism can be thought of as a rudimentary coeffect system, and
that's how it's being used in the library, but I think people are also
interested in systems that allow more fine-grained control for
situations like this.  As to what's currently possible I'm not sure,
but I take your point about there being a need for at least some kinds
of I/O.

Cheers,
Mark

>
> That's what I think.
>
> Cheers,
> Volker
> _______________________________________________
> users mailing list
> [email protected]
> https://lists.mercurylang.org/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users