[nem-en] [Integration] Locations

[Igor Tkachev]

Hi All,

As I mentioned before, Location is one of the major issues we have to
deal with when working on the integration. Here are a couple of
examples which help to describe the problem:

_ = typeof(string);

Here '(string)' part is not included at any TExpr location.

using (fs = FileStream(…))

In this example we have a problem with the ‘fs’ local variable. It’s
also out of any TExpr location.

Another example related to the location is the following:

def (ii, ll) = Foo(…)

In this case, the typer creates two TExpr objects with the same
location: the first one is the wildcard ('_'), the second one is the
'ii' variable.

I see a few ways I would like to discuss how we can handle this.

1. In some cases it seems to be just a default implementation as any
other behavior has never been required. It can be fixed if it does not
break anything else.

2. We can hardcode specific logic for every single scenario. I like
this one least of all in spite of the fact that in some cases we will
have to.

3. We can try to keep relations between PExpr and TExpr objects. 

Let me explain that one. For example, in order to implement quick tips
for a macro to show how the compiler opens it, I scan Parsedtree
first. If I find a PExpr.CallMacro object, I store its location and
then I scan Typedtree until I find an object with location exactly
matched to the macro location. So far this works, but looks like a
dirty hack.

However, it would look like a legal way if the typer could save a
reference to original PExpr object when it creates a TExpr object. I
understand that it’s not always possible, but in most scenarios it is.

I think this solution could be the best as we would 100% know where
TExpr objects come from and we do not have to correct their current
locations. Especially, I guess we will need TExpr location later when
we start implementing debugging support.

What do you think, guys?

-- 
Best regards,
Igor
mailto:it at rsdn.ru