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

[Steve Davis]

fixed typo of missed "when" to avoid the distraction from my real question!

On Dec 29, 2012, at 6:39 AM, Steve Davis <steven.cha...@gmail.com> wrote:

> 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) when is_frame(F) -> etc
> ?
>
> regs,
> /s

[Joe Armstrong]

On Sat, Dec 29, 2012 at 1:42 PM, Steve Davis <steven.cha...@gmail.com> wrote:

fixed typo of missed "when" to avoid the distraction from my real question!

On Dec 29, 2012, at 6:39 AM, Steve Davis <steven.cha...@gmail.com> wrote:

> 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) when is_frame(F) -> etc
> ?

I think they might be called maps in the future...

maps can have any ground term as a key. 

If you want the equivalent of the above you'd have to reserve a 

specific key to emulate the record name. So you'd have something like this:

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

foo(R = #another_record{}) -> ...

would be (with maps) (using the key 'type' to name the record)

foo(#{type=record}=R) -> ...

foo(#{type=another_record}=R) -> ...

/Joe

[Steve Davis]

Ah yes... it also leaves the flexibility in place for frame/map processing without *having* to specify it being of a particular named type.

That would work great.

....R16 anyone?

best,
/s

On Dec 29, 2012, at 7:51 AM, Joe Armstrong <erl...@gmail.com> wrote:
>
> would be (with maps) (using the key 'type' to name the record)
>
> foo(#{type=record}=R) -> ...
> foo(#{type=another_record}=R) -> ...

[Thomas Lindgren]

>________________________________
> From: Steve Davis <steven.cha...@gmail.com>
...

>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.

Regarding atom garbage collection, I'd also recommend OTP to check if there's anything useful in my old paper, inventively named "Atom Garbage Collection", Erlang Workshop 2005. Give me a call if it's too obscure (as I recall, it didn't really set the world on fire). 

Two comments on EEP 20 (I looked at this one: http://www.erlang.org/eeps/eep-0020.html ):

1. EEP 20 doesn't mention handling of message passing or similar scenarios as far as I can see. Perhaps there should be an implementation study where someone could figure out what's the best policy. E.g., should local atoms be globalized when sent? Or should there be translation at sender and/or receiver? Or something else? 

2. Towards the end, leaking global atoms is mentioned. This can in principle happen not only maliciously or by error, but also by upgrading your code sufficiently many times or in other situations where valid external data containing atoms arrives. So while using local atoms reduces the problem of running out of atom table, some way of collecting the global atoms would still be useful. The paper above is one proposal for this.

Best,
Thomas

[Max Lapshin]

What is the idea to make atoms collectable?

They are designed as a limited number of domain specific words. You cannot deal with endless amount of domain language, it is always finite. So atoms are also finite.

[Loïc Hoguin]

On 12/29/2012 05:52 PM, Thomas Lindgren wrote:
>
>
>> ________________________________
>> From: Steve Davis <steven.cha...@gmail.com>
> ...
>> 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.
>
>
> Regarding atom garbage collection, I'd also recommend OTP to check if there's anything useful in my old paper, inventively named "Atom Garbage Collection", Erlang Workshop 2005. Give me a call if it's too obscure (as I recall, it didn't really set the world on fire).
>
> Two comments on EEP 20 (I looked at this one: http://www.erlang.org/eeps/eep-0020.html ):
>
> 1. EEP 20 doesn't mention handling of message passing or similar scenarios as far as I can see. Perhaps there should be an implementation study where someone could figure out what's the best policy. E.g., should local atoms be globalized when sent? Or should there be translation at sender and/or receiver? Or something else?
>
> 2. Towards the end, leaking global atoms is mentioned. This can in principle happen not only maliciously or by error, but also by upgrading your code sufficiently many times or in other situations where valid external data containing atoms arrives. So while using local atoms reduces the problem of running out of atom table, some way of collecting the global atoms would still be useful. The paper above is one proposal for this.

Anthony Ramine has done some work on local atoms which would be garbage
collected. AFAIK it needs a few other patches to get in before that can
happen though, and these weren't accepted for R16. :(

https://github.com/nox/otp/tree/eep20

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Thomas Lindgren]

>________________________________
> From: Max Lapshin <max.l...@gmail.com>

>
>What is the idea to make atoms collectable?
>
>They are designed as a limited number of domain specific words. You cannot deal with endless amount of domain language, it is always finite. So atoms are also finite.

Hi Max, I'm not sure what you mean? As far as I know, atoms can be used for many purposes (and have been, in Erlang as well as its ancestors Prolog and Lisp). However, due to the implementation limitations in Erlang/OTP some of these uses are considered bad practice, particularly for long-running servers. 

For example, Yaws used to represent HTTP header names as atoms, which is nice since comparison is fast and O(1) and atoms are represented once, unlike binaries, which saves memory. This approach was replaced by using binaries for header names once it was realized incoming HTTP requests could cause ERTS to run out of atoms, by accident or on purpose. It would have been simple, easy, fast and compact to use atoms, except that atoms leaked due to not having a GC.

With that said, it is of course possible to work around this. Use binaries, use list_to_existing_atom/1, use coding standards, etc.

Best regards,

[Anthony Ramine]

You should read Richard O'Keefe's post "EEP20: Split the atoms!" on his blog:

http://www.erlang.org/eeps/eep-0020.html

--
Anthony Ramine

Le 29 déc. 2012 à 18:30, Max Lapshin a écrit :

> What is the idea to make atoms collectable?
>
> They are designed as a limited number of domain specific words. You cannot deal with endless amount of domain language, it is always finite. So atoms are also finite.