salog <alesmaer@[EMAIL PROTECTED]
> writes:
> On 29 апр, 18:51, torb...@[EMAIL PROTECTED]
(Torben Ægidius Mogensen)
> wrote:
>> salog <alesm...@[EMAIL PROTECTED]
> 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
|
