.NET 5 future support ?

[Guevara-chan]

https://devblogs.microsoft.com/dotnet/introducing-net-5/ - so, it happens.
Any plans to start updating compiler for upcoming Core/Framework merge, since 5.0 will probably become a standard very soon ?

[masonwheeler]

That's definitely on the to-do list. The tricky thing is, .NET 5 is an evolution of .NET Core, and it's missing a handful of things that the Boo compiler relies on; to get it to work requires rearchitecting both the system for reading external assemblies and the system for outputting the finished compilation product.

[Guevara-chan]

Did you ever thought about re-implementing compiler as Boo-to-C# transpiler ? It will be something akin of what CoffeeScript is to JS then, with MUCH less headache involved in doing... like... anything.

[masonwheeler]

I have, but a lot of things wouldn't work, particularly the metaprogramming. Macros and attributes might work OK, assuming they don't try and do anything with the type system, but meta methods are processed in the middle of ProcessMethodBodies, which requires full type information. (Which requires access to external assemblies.)

[Guevara-chan]

So, it's all about Reflection and dynamic analysis, right ?

[popcatalin81]

Did you ever thought about re-implementing compiler as Boo-to-C# transpiler

I was thinking about using Roslyn as a backend for the Boo compiler. The Parser is replaceable (Used by both VB and C#). The rest of the Roslyn compiler pipeline needs to be modified slightly for metamethods and macros.

There would be a list of benefits going this route:

• Roslyn Red-Green AST would be a great addition for macro implementation, as they are immutable and provide non-desctructive modification of AST, macro safety would be greatly improved.
• IL generation and Assembly binary format handling would practically be free (Inherited from Roslyn)
• Type information & dynamic analysis is also free (Provided by Roslyn services)
• IDE & Autocompletion services infrastructure provided by Roslyn (actual semantics by Boo compiler)
• DLR reused for duck typing (Eliminating the need for current duck type implementation)
• Roslyn State Machine for Iterators and Async (eliminating the need for Boo iterator implementation)
• (And probably others)

Cons:

• This is basically a compiler rewrite. A tremendous amount of effort is required to accomplish this.
• Roslyn will probably need to be Forked. And the fork maintained with down-merges. This will not be a simple task.

[masonwheeler]

@popcatalin81 That would be nice, and maybe not as huge as you might think. If we could get past the ResolveExpressions compilation stage as-is, all of the metaprogramming would be finished at that point. (Assuming that you're not using a custom compiler pipeline that messes around with stuff at a later point, or doing various tricks to attach OnAfterStep event handlers to later stages, or other things that are currently possible.) At that point, it would be possible to translate the Boo AST to a Roslyn AST.

Before that point, it would be entirely infeasible. It would completely break metaprogramming, which is strongly tied to the design of the existing Boo AST. The Roslyn AST is very, very different in many ways, and metaprogramming is such an integral part of Boo that this wouldn't be just "a compiler rewrite"; at that point it becomes a whole new language.

[popcatalin81]

If we could get past the ResolveExpressions compilation stage as-is, all of the metaprogramming would be finished at that point.

This could certainly be a good starting point. An quite possibly the best option to implement this.

Before that point, it would be entirely infeasible. It would completely break metaprogramming, which is strongly tied to the design of the existing Boo AST

Yes, they are rather different currently in implementation. But the Roslyn Ast can be used for sytnax rewriting See http://source.roslyn.io/#Microsoft.CodeAnalysis.CSharp/Syntax/CSharpSyntaxRewriter.cs which is used by refactorings currently, but could potentially be used by a macro system as well. (In the end they accomplish very similar things).

The Roslyn AST is very, very different in many ways, and metaprogramming is such an integral part of Boo that this wouldn't be just "a compiler rewrite"; at that point it becomes a whole new language.

The core aspects of Rolsyn and Boo AST are sufficiently similar to be interchangeable in my opinion. There are Boo specific concepts for which a Roslyn based boo compiler will have to extent the Roslyn AST in the same way VB and C# extend the "Core" AST with specific tokens, which are then onverted to more general Roslyn tokens quite early in the pipeline. Boo could take a similar approach. http://source.roslyn.io/#Microsoft.CodeAnalysis.CSharp/Syntax/SyntaxKind.cs

[masonwheeler]

The core aspects of Rolsyn and Boo AST are sufficiently similar to be interchangeable in my opinion.

I got a very different impression, porting the Roslyn code for async/await to Boo:

• Roslyn ASTs are immutable; Boo macros often mutate existing AST nodes
• Boo ASTs are conceptually a syntax tree with semantic Entity values attached, while Roslyn AST is the exact opposite: a semantic tree with syntax nodes attached.
• Many of the things that are handled with macros in Boo are their own semantic node types in Roslyn. For example, there's code in the async rewriter that specifically checks to see if you're inside a lock statement block by checking for the lock statement node type, which doesn't exist in Boo.

[popcatalin81]

Roslyn ASTs are immutable; Boo macros often mutate existing AST nodes

Roslyn AST Nodex are made to be replaced not mutated directly. This adds safety to the AST mutation operations. Example where a property declaration is changed to autoproperty and the field declaration is removed.

Very different models to operate on the AST that's true and the Macro system will definitely need to be rewritten to account for this, which makes porting to Roslyn AST quite allot harder.

Boo ASTs are conceptually a syntax tree with semantic Entity values attached, while Roslyn AST is the exact opposite: a semantic tree with syntax nodes attached.

Yes a bit of a mismatch here.

Many of the things that are handled with macros in Boo are their own semantic node types in Roslyn. For example, there's code in the async rewriter that specifically checks to see if you're inside a lock statement block by checking for the lock statement node type, which doesn't exist in Boo.

Boo does not need to implement the lock statement, the async rewriter handles try catch blocks as well, so boo lock macro will still work fine with async rewriter.

[ricardok1]

Hi guys, any update on this? .NET 5 is the future... ;-)

[altbodhi]

Hi guys, any update on this? .NET 5 is the future... ;-)

Why Do you not use Ne ? It is support dotnet core. see my experiments https://github.com/altbodhi/NugetNemerleCore