<div dir="ltr">Hi!<div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 15, 2014 at 12:17 PM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="">> starts_with([$  | _]) -> space;<br>
> starts_with([$         | _]) -> tab;<br>
> starts_with([$<br>>  |_]) -> newline.<br>
><br>> Vlad here recommends deprecating the former case, <br>
><br><br>
</div>I can understand the argument about it being confusing, otoh, special casing<br>
something in the language implementation (the whitespace literals VS every<br>
other literal) to explicitly disallow them when there is a text-readable way<br>
of expressing this already (the escape characters) seems like step in the<br>
wrong direction.<br>
<br>
The current implementation is entirely consistent, is not confusing in<br>
editors/highlight modes which are trained to point out literal whitespace, and<br>
the readability issue really boils down to clean coding conventions VS trying<br>
to make the language implementation force a clean coding convention which may<br>
not fit all cases/editors/communities. If emacs/vi/fooedit evolve in the future<br>
to the point our conception of "whitespace" changes even a little, this will<br>
be seen as an awkward wart lingering in the language. I can't think of a case<br>
of coding convention VS implementation-imposed discipline where "imposed<br>
discipline" was a good idea unless it was central to the design of the<br>
language to begin with.<br></blockquote><div><br></div><div>The problem is that  file diffs usually don't have this feature. (Not to mention paper printouts, if anyone still use those :-). Also, most editors can show spaces, tabs and newlines in a "visible" way, but the syntax allows any control character and I'm not sure all editors will display for example $^C. Also, "cat f.erl" might behave strangely if there are control characters (I remember a long time ago all OTP files had ^L between function definitions...)<br>

</div><div><br></div><div>Also, one must not use editor features/plugins that automatically replace tabs with spaces or the other way around. Some editors do that everywhere, not just at the beginning of the line.</div><div>

<br></div><div>regards,<br></div><div>Vlad</div><div> </div></div></div></div>