[erlang-questions] Frames proposal

[Steve Davis]

Looking at the age of the last entry in this thread, it seems that the discussion about frames has rather tailed off again. A pity.

I'd like to add support for both the introduction of frames (and for the EEP 20 on "splitting atoms"). They appear to me to solve fairly pressing issues.

Personally, I _strongly_ prefer the proposed "erlson form" of notation for frames above the suggested <{}> and ~.

I do have a question (re: section 8.2 "What we've lost...")... I frequently use pattern matching to constrain arguments to type, e.g.:

foo(R = #record{}) -> etc

In frames, are we limited to: 
foo(F) is_frame(F) -> etc
?

regs,
/s

On Thursday, May 3, 2012 8:54:46 PM UTC-5, Richard O'Keefe 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-q...@REDACTED 
http://erlang.org/mailman/listinfo/erlang-questions 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121229/f827270e/attachment.htm>