[nem-en] Integration issues
Igor Tkachev
it at rsdn.ru
Thu Aug 31 21:39:26 CEST 2006
Hello Michal,
> While we can produce typed tree without function inlining (because
> this is what you're talking about, right?),
Right. Another example are constants and static variables. The
compiler replaces them by their values.
> it cannot be used for code generation, because for example blocks
> (including break and return) will stop to work.
For the integration we don't need it to be executable. However, the
debugging might be an issue in this case. But I prefer to solve
problems in order they come.
>> 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.
As Vlad made it more exact, we have more places that need to be
changed and we need one consistent approach. I think SetLocation could
be the one.
>> 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
That's a good idea.
Actually, most of integration tasks start from discovering what object
we have under the current location. After that the task itself is
performed. If you look at the Nemerle.Compiler.Utils project at the
CodeModel\Project.n file, you will find a little monster of 600+ line
length named FindLocatedExpr. The purpose of this method is to find an
object located at the provided line and col.
All we need from locations is something like that. Location stack can
simplify this method a lot.
> (or maybe turning this Location
> stack into Located-object stack and saving a reference to a Located in
> TExpr).
In this case we have to scan Typedtree anyway.
> I'm affraid about performance (no GC-ing PExprs) but maybe I
> shouldn't...
You should not. For integration we don't parse the whole project, just
current method. When the compiler (as separated process) compiles the
project, it does not matter. Also Parsetree much smaller than
Typedtree.
--
Best regards,
Igor mailto:it at rsdn.ru
More information about the devel-en
mailing list