Re: How to avoid side effects following functional style, when you need to write adn read data to/from database.

salog <alesmaer@xxxxxxxxxx> writes:

On 29 апр, 18:51, torb...@xxxxxxxxxxxxx (Torben Ægidius Mogensen)
wrote:
salog <alesm...@xxxxxxxxxx> writes:
One of the functional programming feature is absence of variables
assignments, than allows to avoid side effects. But writing and
reading data is alike set and get external variables, so we again come
to a risk get side effects working with databases.
Are there any ideas how to walk around this risk, excluding 'human
element' from the process.

Several answers to this have been used: ...

How would you comment a such way (take into account that I have not
read about Monads yet):

every side-effect function should have a fake argument - a functions,
that destined to indicate what another side-effect function this
function depend on.

?

For example, function a0() writes to a database, function b0() reads
from the database.
But, the idea is that a0() has to read data that b0() has written
earler.
Accordingly, we khow that a0() and b0() are side-effect functions. So,
we can arrange a functional compiler in a such way, that a0() and b0()
can't be declare as is. Our compliler should demand that each of these
function should have one (or more) additional argument-function, just
to indicate mental dependence one function from another one.

I'm not exactly sure what you mean. Do you mean that a0 takes b0 as
an extra argument and vice versa? I don't see what this would
accomplish, except as a kind of comment reminding readers that they
are linked. And the important linkage isn't really in the functions
you use, but in the objects they access. For example, a function that
reads from a file may be used on many different files, and what the
write-to-file function needs is not knowing that a read-from-file
function exists (or the identity of this), but what files are
currently open for reading.

Besides, making a function require a specific other function as
argument requires some trickery with types, essentially inventing a
type unique to that specific function. Also, this becomes more
complicated if you have more than two functions that interact with the
same stateful object. For example, to interact with a file, you need
functions to open, close, read from and write to the file and,
possibly, move the read or write focus.

It sounds like linear types (like Clean's uniqueness types) are closer
to what you want.

Torben
.

Relevant Pages