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

Richard O'Keefe ok@REDACTED
Fri May 4 03:54:46 CEST 2012

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

And it is LONG past time for that to happen.

More information about the erlang-questions mailing list