[nem-en] Integration issues

[Michal Moskal]

On 8/30/06, Igor Tkachev <it at rsdn.ru> wrote:
> Hi All,
>
> We are facing a few issues working on the integration project which can
> not be solved by ourselves. Here they are:
>
> 1. When the compiler creates the typed tree, it also optimizes result
>    and we lose some information we need for completion, tips,
>    navigation, etc. In this mode we need compiler to create the typed
>    tree only.
>
>    I think we will need the same for debugging.

While we can produce typed tree without function inlining (because
this is what you're talking about, right?), it cannot be used for code
generation, because for example blocks (including break and return)
will stop to work.

I will look into this more later today.

>
> 2. While the user is changing a method body, locations of methods
>    below are being changed as well. Those changes are made most
>    frequently and if we call compile every time, it will kill
>    performance.
>
>    We could optimize this if we corrected locations of the methods
>    bellow the current position. But, unfortunately, locations are
>    read-only.
>
>    So, the question is - can we make it mutable?

They are, actually the field "loc" in the Located class is mutable, so
you assign new location whenever you wish (just create a new location
object, which doesn't cost anything anyway). Maybe adding some
SetLocation method wouldn't hurt.

Locations are structs, therefore making the Location.token field
mutable doesn't seem like a good idea (there are always problems with
mutable structs).

>
> 3. I wrote about this issue a couple of weeks ago, but I did get any
>    answer. I guess, I was not clear enough.
>
>    The idea is to keep relations between PExpr and TExpr objects.
>    Every time a TExpr object is created, it should get a reference to
>    a PExpr object which was a cause of the TExpr object creation.
>
>    This will let us get precise location for the TExpr objects and
>    optimize some algorithms.

How precise do you need this information to be? I could think of using
something similar to Location stack (or maybe turning this Location
stack into Located-object stack and saving a reference to a Located in
TExpr). I'm affraid about performance (no GC-ing PExprs) but maybe I
shouldn't...

-- 
   Michał