Re: [m-users.] Impurity needed?

Volker Wysk <[email protected]> Mon, 13 Feb 2023 19:24:12 +0100
Newsgroups	gmane.comp.lang.mercury.general
Message-ID	<[email protected]>
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. 

That's what I think.

Cheers,
Volker

_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users
signature.asc (application/pgp-signature, 833 B)