[erlang-questions] Did Erlang's grammar change in R16A?

Björn-Egil Dahlberg wallentin.dahlberg@REDACTED
Fri Feb 15 01:02:31 CET 2013


2013/2/15 Anthony Ramine <n.oxyde@REDACTED>

> Hi Björn,
>
> While a local atom may take more space than a heap binary, the
> amortized cost of comparing a local atom to another local atom
> with a different name is O(1) because their hash aren't the
> same.
>

Ok, how does this perform against linear scan Eterm data array? The
tradeoff being one word memory saved on the heap also? Keep in mind that
most atoms are pretty short.


> Furthermore, two different local atoms with the same name will
> become the very same term on the heap when gc happens after
> a comparison between the two of them.
>

You are forcing me to look at the EEP again.

.. first thought you were messing with the arity thing meaning .. perhaps i
should sleep. putting more stuff in the header .. seems good

.. wait a minute .. are you proposing an immediate with a payload? so it's
really a thing instead? and if it is a thing should you really be messing
with the header meaning?

Seems like it's a one pass gc strategy in unifying the atoms .. ok. I need
to take a look at the proposal when all my neurons are firing ok. I can't
possibly be reading that EEP correctly.


These two things won't ever happen with heap binaries.
>
> On an unrelated subject, I hope some at least some of the OTP
> team do look hard at EEPs.
>

Sure but my sleepy brain does not remember it all =)

I gather your worried that your implementing something that will not be
accepted. I can't answer that. I can say that a reference implementation
for an EEP goes a long way though.

I think there are many ways to skin this particular cat and I think it
should debated what the most effective atom gc could be.



>
> Regards,
>
> --
> Anthony Ramine
>
> Le 14 févr. 2013 à 23:42, Björn-Egil Dahlberg a écrit :
>
> > (I might be wrong about the size though .. didn't look that hard).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130215/6deb493a/attachment.htm>


More information about the erlang-questions mailing list