typer and tree mutation

Regarding comment found here: https://github.com/scalamacros/kepler/commit/f617469164

+       *  To the moment I know only one such situation: typedAnnotations does not typecheck the annotation in-place, but rather creates new trees and typechecks them, so the original remains symless.
+       *  This is laboriously worked around in the code below. I hope this will be the only workaround in this department.
Does this imply you are depending on trees being typed in place everywhere else? Because that is a huge departure from the way things are supposed to work.  If the typer were by design mutating the incoming tree in place, then all the typing methods should return Unit (for clarity) or tree.type (for convenience, now that we can do such cool dependent things) but they all return either Tree or a tree of the same type, because you're supposed to always use the returned tree.
I realize that is less than universally done, but as far as I know, none of the places where it happens now are explicitly depending on it for correctness.
Enshrining  what is supposed to be only an optimization into reification will make it very difficult to get to somewhere we should be heading, albeit slowly: the typer as functional, parallelizable component, in principle a function from Tree => Tree (or Tree => Type or Tree => (Tree, Type) depending on how much one thinks the typer ought to do.)

Speaking of robustness of the reifier, I passionately hate the fact
that we cannot reify Types. This makes reifier very brittle.

Before annotations I managed to contain it. For annotations I had to
prohibit reification of annotations that refer to symbols that are
declared inside the quasiquote. Same story for classOf, and who knows
what else will manifest itself in the upcoming days.

Any ideas about dealing with this are very welcome.

On Feb 15, 5:49 pm, Eugene Burmako wrote:
> No, I don't actually rely on typechecking being performed in-place. The
> only thing I need is having symful originals, which can be achieved in
> multiple ways.
>
> So the phrase "[we have a problem]: typedAnnotations does not typecheck the
> annotation in-place" means "we have a problem with annotated originals
> being symless, which happens because typedAnnotations does not typecheck
> the annotation in-place", but not "we have a problem that should be solved
> by typedAnnotations working in-place". Sorry for the confusion.
>
> On 15 February 2012 17:01, Paul Phillips wrote:
>
>
>
> > Regarding comment found here:
> >https://github.com/scalamacros/kepler/commit/f617469164
>
> > +       *  To the moment I know only one such situation: typedAnnotations does not typecheck the annotation in-place, but rather creates new trees and typechecks them, so the original remains symless.
>
> > +       *  This is laboriously worked around in the code below. I hope this will be the only workaround in this department.
>
> > Does this imply you are depending on trees being typed in place everywhere
> > else? Because that is a huge departure from the way things are supposed to
> > work.  If the typer were by design mutating the incoming tree in place,
> > then all the typing methods should return Unit (for clarity) or tree.type
> > (for convenience, now that we can do such cool dependent things) but they
> > all return either Tree or a tree of the same type, because you're supposed
> > to always use the returned tree.
>
> > I realize that is less than universally done, but as far as I know, none
> > of the places where it happens now are explicitly depending on it for
> > correctness.
>
> > Enshrining  what is supposed to be only an optimization into reification
> > will make it very difficult to get to somewhere we should be heading,
> > albeit slowly: the typer as functional, parallelizable component, in
> > principle a function from Tree => Tree (or Tree => Type or Tree => (Tree,
> > Type) depending on how much one thinks the typer ought to do.)

Speaking of robustness of the reifier, I passionately hate the fact
that we cannot reify Types. 

Any ideas about dealing with this are very welcome.

No, I don't actually rely on typechecking being performed in-place. The only thing I need is having symful originals, which can be achieved in multiple ways.

On Wed, Feb 15, 2012 at 8:54 AM, Eugene Burmako <eugene.burmako@epfl.ch> wrote:

Speaking of robustness of the reifier, I passionately hate the fact
that we cannot reify Types. 

Any ideas about dealing with this are very welcome.

We'd have to start with, why can't we reify types? 

We'd have to start with, why can't we reify types?