Announcment: MutableRoslyn

[YaakovDavis]

I've released the 1st version of MutableRoslyn; a library for easy mutation of Roslyn syntax trees: https://github.com/YaakovDavis/MutableRoslyn

The mutable classes are auto-generated from the same XML that's used to generate Roslyn's red nodes, those reducing the risk for implementation errors.

The lib supports Immutable <-> mutable conversion.

A typical workflow would be:

1. Convert to mutable
2. Modify
3. Convert back to immutable.

The lib doesn't preserve (unstructured) trivia.

[agocke]

I just have to ask -- why?

[YaakovDavis]

I believe anyone who tried to do any decent amount of tree manipulation already knows the answer.

Working with the immutable tree is just pain. On Jun 23, 2015 7:55 AM, "Andy Gocke" notifications@github.com wrote:

I just have to ask -- why?

— Reply to this email directly or view it on GitHub https://github.com/dotnet/roslyn/issues/3607#issuecomment-114356022.

[agocke]

@YaakovDavis So, first, almost all functional programming languages use immutable trees as their natural data structure because they're highly amenable to functional manipulation, so immutability is often a natural fit for trees.

But second, you can't use this in most of the places people use roslyn today -- like in VS or analyzers. So what's the use case?

[YaakovDavis]

First, it supports conversion from, and to, Roslyn, so it can be used anywhere Roslyn is used.

I use it for code-generation and transformation purposes; I have an abstract code that I transform to a concrete implementation by AST mutation.

I can see it useful for similar scenarios.

Think meta-programming.

[sharwell]

I believe anyone who tried to do any decent amount of tree manipulation already knows the answer.

Working with the immutable tree is just pain.

I have not found this to be the case at all. I have run into a few issues like the inability of the syntax factory to handle XML documentation comments (#218), but that isn't a problem with the trees being immutable and it's also something we worked around by creating a new factory.

[YaakovDavis]

The problem with immutable tree manipulation is that any node "update" requires regenerating all its ancestors. This means you have to avoid holding references to ancestor nodes, or keep updating them manually. This is verbose and error prone.

The Immutable Tree design restricts the user to visitors and rewriters, which can consider only one node at a time, in a depth-first order.

While this works for some scenarios, it certainly doesn't for others.

If Roslyn's tree is workable for your needs, have fun. This lib is for the other cases.

[gafter]

@YaakovDavis Congrats on your project.

[jawilliam]

Hi, @YaakovDavis:

I have the urgent necessity to use a mutable tree versions of Roslyn. If is needed I can detail my scenario to support your claims that there are cases where are really important. I tried to follow the reference you put here but is broken.

Can you enable that solution for me?

Regards

[YaakovDavis]

The repository is now available.

I'm not sure about its level of functioning at the moment, hope you find it useful. The child file of Ast.cs is auto-generated, and will contain the AST classes after a successful compilation.