Re: [m-users.] Impurity needed?

Volker Wysk <[email protected]> Tue, 21 Feb 2023 14:23:43 +0100
Newsgroups	gmane.comp.lang.mercury.general
Message-ID	<[email protected]>
Am Dienstag, dem 21.02.2023 um 21:45 +1100 schrieb Mark Brown:
> 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.

Sounds advanced...

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...

Cheers, 
Volker

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