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

[Tim Watson]

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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions