[erlang-questions] New draft of frames proposal (was Re: Frames proposal)
Fri May 4 10:03:56 CEST 2012
Anyone on the OTP team wish to comment on whether or not this is part of the roadmap for R16/17?
On 4 May 2012, at 02:54, "Richard O'Keefe" <ok@REDACTED> wrote:
> 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.
> erlang-questions mailing list
More information about the erlang-questions