<div dir="ltr">Hi!<div><br></div><div>Of course there should be a proper deprecation cycle, it's a braking change. </div><div><br></div><div>I've been looking very briefly at where would these checks be made and I'd say that it probably should be in the preprocessor. However, the scanner already interprets the literals and the only way to know how the value was specified in the source is by having the scanner return the text and it's not a very good idea to always do that (memory usage could increase dramatically). </div>

<div><br></div><div>A solution would be to let the character tokens always include the text, but this potentially breaks code that assumes there is no text attribute if it wasn't requested. On the other hand, the attributes are specified as an opaque data type and should be accessed with attribute_info and token_info, so maybe we could get away with that? If yes, I will start working on it. If not, I welcome other suggestions.</div>

<div><br></div><div>regards,</div><div>Vlad</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 14, 2014 at 4:32 PM, Björn-Egil Dahlberg <span dir="ltr"><<a href="mailto:egil@erlang.org" target="_blank">egil@erlang.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 2014-05-14 16:15, Fred Hebert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the argument here is specifically about whitespace characters.<br>
<br>
For example, using:<br>
<br>
starts_with([$  | _]) -> space;<br>
starts_with([$   | _]) -> tab;<br>
starts_with([$<br>
  |_]) -> newline.<br>
<br>
Is currently allowed, but it is arguably clearer to use:<br>
<br>
starts_with([$\s | _]) -> space;<br>
starts_with([$\t | _]) -> tab.<br>
starts_with([$\n | _]) -> newline.<br>
<br>
Vlad here recommends deprecating the former case, while recommending the<br>
latter form.<br>
<br>
I would tend to agree for the sake of readability, but would like a<br>
regular deprecation cycle with warnings explaining the recommended<br>
changes ("The $<space> form is being deprecated, replace with $\s" or<br>
something).<br>
</blockquote></div>
I like this proposal.<br>
<br>
I don't know how fast we could remove $ , $    , etc (earliest 19?) but we could certainly emit irritating deprecation warnings that make people want to fix their code.<span class="HOEnZb"><font color="#888888"><br>
<br>
// Björn-Egil</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Fred.<br>
<br>
On 05/14, Sean Cribbs wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
They are incredibly useful in pattern-matching simple string arguments. e.g.<br>
<br>
case erlang:system_info(version) of<br>
     [$5, $., $1, $0 | _ ] -> ok;<br>
     _ -> fail<br>
end<br>
<br>
<br>
On Wed, May 14, 2014 at 4:28 AM, Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
I would like to make a suggestion regarding the accepted literal<br>
characters syntax. At the moment, any character following a $ is accepted<br>
as itself. I find it very confusing when these characters are whitespace or<br>
control chars and my suggestion is to refuse these literals. Most of them<br>
have escaped representations and the others should be written as integers<br>
anyway.<br>
<br>
What do you think? Is anyone using these in a meaningful way?<br>
<br>
best regards,<br>
Vlad<br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
</blockquote>
<br>
-- <br>
Sean Cribbs <<a href="mailto:sean@basho.com" target="_blank">sean@basho.com</a>><br>
Software Engineer<br>
Basho Technologies, Inc.<br>
<a href="http://basho.com/" target="_blank">http://basho.com/</a><br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>