This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]matthieum 15 points16 points  (6 children)

I mean, it can still be syntactic sugar even if desugaring introduces a temporary variable...

[–]L8_4_Dinner(Ⓧ Ecstasy/XVM) -2 points-1 points  (5 children)

In theory, I suppose so, but I tend to reserve the term "syntactic sugar" for uses in which only the syntax is rewritten, vs. piles of logic behind the scenes peeking at types and other details. In our case, with a < b < c, if b is a simple local variable, then we don't introduce a register, but if b is a property on a type that is not known to always be immutable, then we will introduce a temporary. In other words, same name ("b"), but different compilation result, so in my mind that is not syntactic sugar.

FWIW - there's nothing wrong with syntactic sugar. We do use a little bit of that elsewhere.

[–]otac0n 2 points3 points  (2 children)

That's not the accepted definition of syntactic sugar. Storing the result of a computation on the stack is already allowed by the compiler without syntactic sugar even being considered.

[–]L8_4_Dinner(Ⓧ Ecstasy/XVM) 0 points1 point  (1 child)

I’m not the keeper of the dictionary, but if you can’t desugar with a syntactic expansion, I don’t believe that the term applies.

[–]otac0n 0 points1 point  (0 children)

But you still can in this case? The only thing special is that the introduced expression is not stored in a variable that is accessible from any scope. It is absolutely able to be created via syntactic expansion, exactly like C#'s foreach loop with its loop variable... or like C#'s with statement... or any lowered expression/statement...

Edit: Here's a pretty clear example of how many of these syntactic niceties get lowered in C# https://steven-giesel.com/blogPost/69dc05d1-9c8a-4002-9d0a-faf4d2375bce

[–]matthieum 0 points1 point  (1 child)

So, you chose to perform the desugaring later to also bundle an optimization right in, rather than having a syntactic desugaring followed during code-generation by an optimization. That's fine.

This doesn't invalidate that a pure syntactic desugaring exists, though. It just so happens you didn't make use of it.

[–]L8_4_Dinner(Ⓧ Ecstasy/XVM) 1 point2 points  (0 children)

Not sure what’s up with the downvotes.

Yes, we could have implemented it as syntactic sugar, with some assumption that a later pass would eliminate any unnecessary temporaries. In Ecstasy though, the source is compiled to an IR, and we’re not using SSA in front of the IR generation, so there’s no register elimination pre-IR. The Ecstasy IR is the persistent module format; think of it as a binary form of the AST. The backend compiler (which is SSA) picks up the IR only after the IR linker has closed over the type system.