[erlang-questions] Did Erlang's grammar change in R16A?
Thu Feb 14 23:18:44 CET 2013
2013/2/14 Evan Miller <emmiller@REDACTED>
> On Thu, Feb 14, 2013 at 1:08 PM, Richard Carlsson
> <carlsson.richard@REDACTED> wrote:
> > On 2013-02-14 20:03, Evan Miller wrote:
> >> As I understood it, dots are legal in unquoted atom names. This
> >> appears not to be the case in R16A. Is this intentional?
> >> Erlang R15B03 (erts-220.127.116.11) [source] [smp:8:8] [async-threads:0]
> >> [hipe] [kernel-poll:false]
> >> Eshell V18.104.22.168 (abort with ^G)
> >> 1> a.b.
> >> 'a.b'
> >> 2>
Btw, note that a.b actually becomes quoted in output.
> >> Erlang R16A (erts-5.10) [source] [smp:8:8] [async-threads:10] [hipe]
> >> [kernel-poll:false]
> >> Eshell V5.10 (abort with ^G)
> >> 1> a.b.
> >> * 1: syntax error before: '.'
> >> 1>
> >> Kai Janson noticed this because the "mongodb" package fails to compile
> >> under R16A due to a syntax error on an atom with a dot in it.
> >> https://github.com/mongodb/mongodb-erlang
> >> I couldn't find any mention of changing the grammar in the README. Is
> >> this a bug?
> > The automatic concatenation of atoms separated by dots was originally
> > introduced with the experimental "packages" system, and was probably lost
> > again when this feature was dropped from the codebase.
> > /Richard
> Ah, I see. This is alluded to in the Bible, Chapter 2, Section 8, Footnote
> "You might find that a period (.) can also be use in atoms--this is an
> unsupported extension to Erlang."
You don't miss an opportunity to be entertaining. =)
It's an unfortunate consequence of removing packages. Dots were part of
package paths and I guess it didn't need quoting out of convenience. Also I
think it was a concatenated on a completely different level in the
The mistake wasn't to remove unquoted dots but to never fix the *bug* with
quoting in the first place.
Anyhow, it's gone now I hope it will never see the light of day again.
On a side note, I also have an issue with:
* Creating atoms in runtime. It should only have been allowed in code and
never by list_to_atom/1 or binary_to_atom/1,2 (binary_to_term would still
be a thing though)
* Using atoms as filenames and node-names, i.e. using atoms as strings.
Atoms are atoms, NOT strings. If using atoms as strings were an performance
issue, strings (lists) should have been fixed to remedy this.
2 cents poorer,
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions