<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 2, 2013 at 1:42 PM, Joshua Cranmer 🐧 <span dir="ltr"><<a href="mailto:Pidgeot18@gmail.com" target="_blank">Pidgeot18@gmail.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="im">On 11/1/2013 12:15 PM, Daniel Jasper 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">
Start with JavaScript. Syntactically, it is very close to C++ and there are already different efforts going on to combine JavaScript and LLVM. Add an additional LanguageStandard (this flag already supports C++03 and C++11) in clang-format’s configuration and gate JavaScript specific formatting decisions (e.g. indentation of JavaScript’s namespace-equivalent on it).<br>

</blockquote>
<br></div>
JavaScript has some extremely different syntax that is likely to play havoc with a straight C/C++ lexer. It also depends on exactly which variant of JavaScript you want to support--ES5? ES6? Mozilla's JS extensions? Support E4X as well?<br>

1. Regular expressions. I don't recall off the top of my head, but I believe it boils down to "/ starts a regular expression if you're expecting an operand and is a division operator if you're not"--you'll need to do at least enough parsing to distinguish those two cases.<br>
</blockquote><div><br></div><div>For reference, the entire syntax is split down the middle between "/ means division" vs "/ means regex". Spec reference is <<a href="http://es5.github.io/#x7">http://es5.github.io/#x7</a>>; the two goal tokens of the grammar are InputElementDiv and InputElementRegExp.</div>
<div> </div><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">
2. Array comprehensions (ES 6/Mozilla JS 1.8.5 enhancements): [x for (x in obj)], [x for each (x in obj)], [x for (x of obj)]. The middle is not in ES 6 (it's actually a holdover from E4X that sticks around because it was introduced well before the for-of statement was, and found relatively widespread use in Mozilla which made the JS people keep it around when we killed E4X), and I don't recall if the generator form (without enclosing brackets) is in ES 6 or not.<br>

3. Generators: function*() { yield y; yield* x; }. I don't even know recommended style guides for the star-variant, as I only just retrofitted my code to have them two or three days ago.<br>
4. Object literals:<br>
var x = {<br>
  get y() { return z; },<br>
  x: 13,<br>
  q: function () { return this.x; }<br>
};<br></blockquote><div><br></div><div>This is the kind of feature that I'm least concerned with, since it is lexically identical to C++ (modulo a few keywords that will be interpreted as identifiers).</div><div> </div>
<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">
5. Semicolon insertion. Newlines can become semicolons in the right circumstances (the worst misfeature in JS, IMHO).<br></blockquote><div><br></div><div>This isn't a big deal. Basically there's a fixed set of lookahead tokens and if the next token is one of them, then the statement continues, otherwise it ends ("semicolon is inserted"). (Of course, open parentheses override this but I'm sure clang-format already handles that case just fine).</div>
<div> </div><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">
6. Reading the ES6 draft, it supports \u in IdentifierNames just like Java does.<br>
7. Some other operators are in play. === and !== have been brought up/ there is also >>> and >>>= (like Java's operators), and ... (array spread operator).<br>
8. Some ES6 features I haven't played with that may or may not have been added to some libraries yet: template strings, and there's also a =>-like notation for functions IIRC.<br>
<br>
Regular expression literal support will definitely need different lexing paths than C/C++, although (excluding template strings and some E4X literals--the former of which is too new to be widely supported and the latter of which has already been ripped out from the only major engine that it) I think it is otherwise close enough to reuse a lot of the lexing capabilities of C-family languages. Just be forewarned that the shallow parsing that needs to be done for JS is likely to be rather different from that down for C/C++, even if their lexing streams look more or less similar.</blockquote>
<div><br></div><div>If this goes through, I would expect clang-format's lambda formatting to be top-notch, since about half of all javascript code basically consists of lambdas :)</div><div><br></div><div>-- Sean Silva</div>
<div> </div><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"><span class=""><font color="#888888"><br>
<br>
-- <br>
Joshua Cranmer<br>
Thunderbird and DXR developer<br>
Source code archæologist</font></span><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>