[erlang-questions] A bug? - bloom filters - and loadable BIFs

[Mikael Pettersson]

Steve Kirsch writes:
 > is there a way to do a destructive setelement?
 > 
 > This is in the VM, but the compiler rarely generates it.
 > 
 > Is there a way to force this?

Not really. Destructive setelement/3 is not trivial.

First there's the general avoidance of mutable data structures in
Erlang, and destructive setelement/3 in that setting is a step in
the wrong direction.

Second, having destructive updates of general collection-like objects
(cons cells, tuples) in any system with a generational garbage collector,
such as Erlang/OTP, _requires_ specific support from the garbage collector
(for handling so-called wrong-way pointers). Since the Erlang language
doesn't support mutable general collection-like objects, the Erlang/OTP VM
garbage collector doesn't either.

The BEAM Erlang compiler is able to identify certain kinds of
setelement/3 operations which can safely use destructive updates
(mainly record initialisations as I recall), and for those it uses
the VM's destructive setelement/3 operation.

However, giving programmers direct access to destructive setelement/3
is both unsafe and against the spirit of Erlang, so it's not going to
happen any time soon.

 > -----Original Message-----
 > From: Steve Kirsch 
 > 
 > Wow. That is very cool. And if the bitarray is large enough, it is
 > passed by reference in a message. Awesome.
 > 
 > So is there a way to set a byte or word at a time??
 > 
 > -----Original Message-----
 > 
 > hipe_bifs:bitarray(NrArrayBits, InitialBitValue) -> BitArray
 > hipe_bifs:bitarray_sub(BitArray, BitNr) -> BitValue
 > hipe_bifs:bitarray_update(BitArray, BitNr, BitValue) -> BitArray
 > 
 > Bit values are the booleans true and false.
 > Array indexing is 0-based (1-based indexing is just sooo wrong).
 > The update operation returns the updated array.
 > 
 > The number of elements in a bit array is limited to what can be
 > described by non-negative fixnums (immediate "small" integers), which is
 > something like 2^27 - 1 on 32-bit machines. Larger bitarrays than that
 > must be emulated using a chunked representation.
 > See lib/hipe/regalloc/hipe_ig.erl for an example (look for the
 > USE_NEW_BITARRAY_BIFS define and the adjset code following it).
 > 
 > /Mikael
 >