[nem-en] Integration issues

[Kamil Skalski]

On 8/31/06, Igor Tkachev <it at rsdn.ru> wrote:
> 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.

The places to look at are calls to ConstantFolder:

typing/OverloadPossibility.n:111:                  match
(ConstantFolder.FieldValueAsLiteral (fld)) {
typing/TypedTree.n:134:        match (ConstantFolder.FoldConstants
(par.GlobalEnv, e)) {
typing/Typer-PatternTyper.n:434:                    def val =
ConstantFolder.FieldValueAsPureLiteral (fld);
typing/Typer-PatternTyper.n:747:          | PT.PExpr.Call
(PT.PExpr.Ref (n), _) when ConstantFolder.is_known_operator (n.Id) =>
typing/Typer-PatternTyper.n:748:            def folded =
ConstantFolder.FoldConstants (typer.env, pattern);
typing/Typer.n:2832:            def folded = ConstantFolder.FoldTyped
(name.Id, parm1.expr,
typing/Typer.n:2856:            def folded = ConstantFolder.FoldTyped
(name.Id, parm1.expr, local_context.IsChecked);

Maybe this could be fixed by disabling actions from ConstantFolder or
replacing it with some dummy class in completion flow...

I'm not entirely sure if disabling constant folding won't hurt some
type inference actions / operator usage / implicit conversions, but I
guess it should be ok.

>
> > 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
>
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


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