The best implementation of Position

[civp]

Hello, I'm working on (my branch) adding position information (span) to trees. I've tried three implementations. Which implementation do you think is the best?

• Add span as a field of Tree like tpe
• Add span as the second parameter list of constructors. E.g., Ident(x)(span)
• Add span to the first parameter list of constructors. E.g., Ident(x, span)

The first implementation is not good enough because we must call setSpan for every Tree. If we forget it, span will be the default value NoSpan.

The second implementation uses currying. But there's not a good reason for using currying.

The last implementation may be the most reasonable, and I'm using it. The problem is it changes the number of parameters. I have to modify every occurance of them. It was a disaster to modify the ReadTreeSuite, which had over 1,700 lines of code. I used scalameta to do so but the beautiful formats of cases were lost. I think you won't be happy with that.

If you have better ways of implementing the position, please let me know!

[sjrd]

• Add span as the second parameter list of constructors. E.g., Ident(x)(span)

That's the one you want.

The second implementation uses currying. But there's not a good reason for using currying.

There is a good reason. You showed very clearly that 1. and 3. are not acceptable. There's your reason for using currying.

---

There is precedent for this design in the Scala.js IR, by the way.

[julienrf]

I personally find this solution confusing because it also has an impact on equality, meaning that two Ident trees referring to the same identifier but at different positions in the program will be equal.

I see this consequence of currying as an important drawback. I don’t really see the problem with updating the places where pattern matching is used (and maybe we should use less pattern matching in the first place?).

[sjrd]

The ability to pattern-match on Trees is one of the most fundamental things anyone will want to do if they work with Trees at all. Making pattern matching less than ideal is a significant drawback.

If Trees are equal with different positions, that's probably fine. In fact, in all the cases where I have relied on Tree equality in the past, I would have been bitten by differences caused by positions only.

[julienrf]

OK, then it makes even more sense to exclude them from equality comparisons! Thank you for your feedback.