Annotating LNodes with comments

[qwertie]

Annotating LNodes with comments

[qwertie]

Hi. Sorry, I've been unproductive since before I went to the Philippines (to meet my wife), and now it's worse. The heat drives me nuts, we don't have reliable internet access at home yet, and I don't have a desk. With regard to Loyc, I wanted to implement a small change to the EC# parser in order to add a pattern-matching macro to EC#, but that small change intersected with a serious slug in LLLPG so that the grammar takes about two minutes to compile. And I just haven't been able to decide what to do about it.

Adding a comment is easy enough. Just add a single-line comment #trivia attribute:

var commented = LesLanguageService.Value.ParseSingle("foo(25);")
    .PlusAttr(LNode.Trivia(CodeSymbols.TriviaSLCommentBefore, "Call foo!"));
var text = LesLanguageService.Value.Print(commented);
System.Console.WriteLine(text);

Output:

//Call foo!
foo(25);

[jonathanvdc]

Thanks! That was just what I needed. I've integrated the technique in the IR builder, and figuring out what's going on in the generated IR is a whole lot easier now.

Oh, in the meanwhile, I think I kind of uncovered a tiny bug in the LES printer/parser while I was experimenting with (textual) IR: the printer converts LNode.Literal(float.PositiveInfinity) to ∞f; (at least on my machine), and the parser doesn't recognize that as a valid float literal. In fact, all infinity literals behave like this. I think the fancy infinity signs are created by the ToString call in this method (in LesNodePrinter).

void PrintValueToString(object value, string suffix)
{
    _out.Write(value.ToString(), false);
    _out.Write(suffix, true);
}

This is not exactly a showstopper for me because the IR back-end defaults to a binary encoding anyway. I could also just circumvent this particular edge case by teaching the IR handler to use special symbols for infinity constants. Besides, I did encounter this thing by accident, so I guess it can't be all that rare.

I'm willing to fix this problem, add a test to verify, and submit a PR. I'm just not sure how you'd like to solve this particular problem, though. I feel like mandating Unicode infinity signs sounds like a bad idea in general. Someone might corrupt a file by saving or opening it as ASCII instead of UTF-8, and this Unicode bling doesn't match the look and feel of LES (or at least, my experience with it) in general. I was thinking more along the lines of introducing a number of special symbols, much like @null, for infinity literals. @inf_pos_float, @inf_neg_float, @inf_pos_double, @inf_neg_double, perhaps? I'm a little concerned about overlap with pre-existing identifiers, though. Do you know of any real-life projects this proposal could break?

Hope your setup improves soon over there.

[qwertie]

Ahh, well, the LES lexer includes a negative sign as part of literals - i.e. 5-4 is a syntax error because - is considered to be part of an integer literal -4 - it feels like this should be changed, but I don't know what to do instead. Anyway, following that pattern we need only define, say, @inf and @inf_f (using f as a suffix, similar to normal float literals) and use -@inf for negative infinity. Of course there should also be @NaN or @nan (which one? I have no particular preference, but if we used @NaN, admitting capitals, then I think @INFf might be better for infinity, to avoid the underscore which is not present on normal float literals).

You need not worry about breaking anything, since the number of known uses of LES in production is currently zero.

I do not have time to implement these changes myself immediately, do feel free to make a pull request that includes the necessary changes to the lexer (IIRC literals like @false and @true are recognized in the lexer, not the parser) and the printer.

[jonathanvdc]

I submitted a pull request (#16) that introduces @inf_f, -@inf_f, @nan_f, @inf_d, -@inf_d, @nan_d. I settled on this naming scheme because:

1. An all lower-case precedent was set by @void, @null, @true and @false.
2. Explicit type suffixes are easier to reason about type-wise, and this design is more regular than having both @inf_f and @inf.
3. Having both @inf and @inf_d would have been plain confusing, and I didn't feel comfortable with introducing two magic identifiers that do the exact same thing.
4. @inf_d may not be as quite terse as @inf, but encoding infinitely large doubles is probably not something people do all that often. Besides, @inf_d is pretty concise as-is.

But if you're absolutely not okay with these literals, I'd be happy to change them.

Sorry it took me a while to get this done. I've been kind of busy lately, so I didn't have a lot of free time on my hands.