salog <alesmaer@[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:
1. Haskell-style Monads, which are (roughly speaking) programming
constructs that locally enforce sequentiality even in a language
where evaluation order is unspecified.
2. Clean-style uniqueness types, which are linear types that ensure
that a value is only used once, so it is safe to have side effects
associated with reading the value and which allow overwriting the
old value (which is never used again) destructively. For example,
a file handle can be treated as a linearly typed value such that
every operation on the file takes the handle as an argument and
conceptually returns a new handle (which is the same as the old).
Opening a file returns a handle and closing a file takes a handle
but returns nothing (except, perhaps, an indication of
success/failure).
3. Effect types. These are used in langauges that allow unlimited
side-effects, but let the type of a function include a description
of its visible side effects (including reads of mutable
variables). A function can, through a type specification,
prevents its own arguments form having specified effects. This
allows, for example, a memoizing function to be restricted to pure
functions.
4. Continuation-based i/o. When the program want to do a side
effect, it terminates and returns a description of the side effect
and a continuation (similar to a call-back) that the environment
should call when the side-effect is performed (passing results
from the side effect as arguments to the continuation).
5. No restrictions. Languages like Standard ML or O'Caml allow
unrestricted side effects and it is mainly a matter of style that
keep programmers from using them all over the place.
Torben
|
