[nem-en] Integration issues

[Kamil Skalski]

On 8/30/06, Michal Moskal <michal.moskal at gmail.com> wrote:
> 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.

Maybe we should create a subtype of Typer, like  CompletionTyper,
which could do the "different" stuff for various parts of
implementation. Manager could have a "factory" method to create Typer
/ CompletionTyper depending on the actual engine being used.
I guess completion runs only on Typer (or maybe also Typer2), so for
the pure completion purpose this will be ok.

>
> >
> > 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.

In case of MemberBuilder we have an exception:
http://nemerle.org/svn/nemerle/trunk/ncc/hierarchy/ClassMembers.n

I guess we should make MemberInfo / TypeInfo inherit from Located,
this will allow all of them to have modifiable location, which isn't
bad, because usually locations should be possible to correct them.

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

Agreed.

>
> >
> > 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.

I don't like the idea... This will make things more complicated in
many places (keeping track of these objects and their changes), cause
addition of quite unreadable code in many places, etc.
I think we should rather try to set the locations of TExpr more
correctly - this is similar problem btw, because to track the original
PExpr you would need to write all the code which would now be enough
to correct locations. And in case of locations we have something to
begin with.

>
> 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...

Probably we already leak them, but this might hit performance somewhat.


-- 
Kamil Skalski
http://nazgul.omega.pl