Concatenating atoms

[Joe Armstrong (AL/EAB)]

Neat - great idea

I hadn't thought of that

I'm not sure that bigints is a good idea though - it might cause internal
problems but binaries would be garbed and binary comparisons are presumably
faster than list comparisions. So the variable Abc on line 23 of my program
could be represented as {var,23,<<"abc">>}

Yes - I will immediately change my XML parser to this representation :-)

(and a potential compiler bug can be fixed !!!!)

/Joe

> -----Original Message-----
> From: Thomas Johnsson XA (LN/EAB) 
> Sent: den 3 februari 2005 17:28
> To: erlang-questions@REDACTED
> Subject: RE: Concatenating atoms
> 
> 
> .. And this might be a good time to suggest an alternative in 
> applications like these:
> use integers/bignums instead of atoms. Like:
> 
> string_to_integer([]) -> 0;
> string_to_integer([C|S]) -> C bor (string_to_integer(S) bsl 8).
> 
> integer_to_string(0) -> [];
> integer_to_string(I) -> [I band 16#ff | integer_to_string(I bsr 8)].
> 
> 30> A = stringinteger:string_to_integer("hej hopp i lingonskogen!"). 
> 819731492177739986812987346725244519542754012099320112488
> 31> stringinteger:integer_to_string(A).                             
> "hej hopp i lingonskogen!"
> 
> 
> Hopefully bignums are "represented sensibly" ie in one chunk, 
> or at least 
> more compactly than strings ... are they?
> 
> -- Thomas
> 
> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]
> Sent: den 3 februari 2005 16:57
> To: erlang-questions@REDACTED
> Subject: RE: Concatenating atoms
> 
> 
> 
> Joe wrote:
> 
> > *Every* parser which accepts inputs from a communication 
> > channel suffers from this
> > problem is the set of atoms that it can create is unbounded.
> 
> 
> >   This gives us a number of design choices.
> > 
> > 	1) Accept that I have incorrect implementation that 
> > will one day crash
> > 	2) Prove that the atom table cannot overflow because 
> > the alphabet is
> > 	   finite and will not overflow the atom table
> > 	3) Uses strings instead of atoms
> 
> 
> This might be a good time to point out that xmerl
> converts element and attribute names to atoms.
> 
> I've seen complaints on the list that xmerl is slow.
> All other things being equal, switching over to using
> strings instead would slow it down considerably
> (not that I've measured this).
> 
> /Uffe
>