[erlang-questions] New draft of frames proposal (was Re: Frames proposal)

[Richard O'Keefe]

On 3/05/2012, at 10:55 PM, Max Lapshin wrote:

>>  - They have no default value
>>  - Only atoms may be keys
> 
> These two poins are very interesting to discuss.
> 
> 
> Problem is with handling external data.

Response 1:

   Frames are very explicitly a replacement for RECORDS.
   You cannot currently use records in external data.
   

Response 2:

   EEP 20 (http://www.erlang.org/eeps/eep-0020.html)
   has now been around for nearly four years.  It offers
   a permanent fix to the limited size of the atom table,
   a fix which has been used before in another concurrent
   programming language.

   That's not the only way to fix the atom table problem.
   SWI Prolog offers true multicore concurrency AND a
   garbage collected atom table.  That's been around for
   a few years now too.

   By any engineering standard I can think of, fixing this
   vulnerability in Erlang should have very high priority.
   The frames proposal presupposed that this flaw has been
   fixed somehow.  We *cannot* let this flaw warp Erlang
   programming for the rest of our lives.

> 
> We will not be able to use frames for handling user data if only atoms
> can be keys, but if we allow to store atoms, binaries and strings as
> keys, we will get a mess with different ways to introduce keys.

We *WILL* be able to use frames for handling user data
WHEN THE ATOM TABLE BUG IS FIXED.

And it is LONG past time for that to happen.