Atomic ets

[Ulf Wiger]

Den 2005-12-14 20:29:03 skrev Thomas Lindgren <thomasl_erlang@REDACTED>:

> 5. Introduce a magical new API more suited for
> concurrent/atomic ets. Drawback: it doesn't exist yet
> :-)

You'd think that with a functional language, there
should be a way to write code that is verifiably
'shallow' (no loops, no side effects - or, in this
case, only allowed side effects). This is essentially,
what we want for the match specifications (replacing
the ms_transform module), for mnesia transactions
(where the manual kindly asks us to write pure code)
and perhaps for atomic ets. If a function could be
tagged as (conditionally) safe, one could offer an
'atomic' construct and have it execute only such
code.

/Uffe (who volunteers _not_ to be the one implementing it.)