12

I was exploring ways how to implement a general-purpose/DSL language for .NET platform. From what I saw, there are several tools that make language implementation (parsing source code) relatively easy. Irony, Yacc, ANTLR… the problems with these projects are that some are not evolving, some generate slow parsers, some cannot run on .NET Core CLR etc. There is always some obstacle that pushes me towards solution “write your own parser”.

So I was wondering… is it possible to write my own parser and connect/integrate it with Roslyn? Are there any books, tutorials or examples how it can be done?

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
user1498611
  • 324
  • 4
  • 15
  • Of course you can write you own code and call Roslyn elements with the results. You'll discover that you have to do a lot of work specific to your langauge (Rosyln won't) and likely that integrating with Roslyn amounts to building a translator from your language to whatever Roslyn offers as an intermediate form (AST, MSIL, ...). See http://stackoverflow.com/a/3460977/120163 for an extended discussion of what it takes to do this, especially the bit about *life after parsing* – Ira Baxter Jan 13 '16 at 20:44

3 Answers3

7

Roslyn is not meant for this.

The best you'll be able to do with Roslyn is generate a C# (or VB) SyntaxTree & Compilation after you parse your language by hand, letting Roslyn take care of the type system & codegen.

And this will only work at all if your language can be completely translated to C# (or VB) syntax.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • 1
    "only (if)...can be completely translated to C#" this note pretend to mean that there are languages that can't be translated to C# what is sort of fallacy (author can't point such language)... See Church–Turing thesis. – Roman Pokrovskij Jul 10 '16 at 14:19
  • 1
    @RomanPokrovskij: If your language is too dissimilar from C# (eg, a much stronger type system), Roslyn won't help you; you'd essentially be writing a compiler that treats C# as assembly. This is only useful if you can do a syntactic-level transformation. – SLaks Jul 10 '16 at 14:32
  • @RomanPokrovskij The fallacy is yours. The CT thesis would apply if the goal was to compute in C# any function that can be computed in one's chosen language, but that's a very different goal from `translating` one's chosen language into C#. If all we cared about is computing functions, then we wouldn't care about Roslyn or C# at all. Suppose, for instance, that your language allows overriding access modifiers, or has function overloading on return type. You won't be able to translate that to C#. Writing an interpreter in C# for your language isn't "translation". – Jim Balter Jan 02 '17 at 05:49
  • 1
    Everybody could wrote a language that "allows overriding access modifiers" this is checked on compilation level when to save the "original information" for referencing - use attributes. The same is about "overloading on return type" - encode name with "fancy name" as generic functions do it, add additional info to attributes. – Roman Pokrovskij Jan 02 '17 at 09:15
  • 1
    @RomanPokrovskij: No; the CLR doesn't allow that either, so you'd have to write everything from scratch, at which point Roslyn won't be at all useful. – SLaks Jan 02 '17 at 16:14
  • @SLaks not only CLR doesn't allow, also there are no CPU instructions for that, but it is still VERY EASY to check "overriding access modifiers" of custom language during this language parsing or even in runtime. – Roman Pokrovskij Jan 02 '17 at 21:03
  • @RomanPokrovskij Ok, someone just wants to argue even though they are clearly wrong and are missing the point. Even if there are ways to encode these things, that has nothing to do with the Church-Turing thesis. Over and out. – Jim Balter Jan 03 '17 at 04:02
  • 1
    @Jim Balter, you are right, I do not see any sense and points in that: "And this (generate SyntaxTree after parsing) will only work (???) at all if YOUR LANGUAGE can be completely translated to C# ". – Roman Pokrovskij Jan 03 '17 at 10:04
  • @RomanPokrovskij: If your language cannot be completely translated to C#, you can't meaningfully express it as a C# syntax tree and get any benefit from that. If you treat C# as an assembly language and build everything yourself, you'll just create lots of headache for no purpose. – SLaks Jan 03 '17 at 15:06
  • 1
    @SLaks For me is important to remove this "rule", because I would like to encourage developers to create DSL (and of course meaningful DSL is declarative language when IL/cli is imperative so of course they not match on instructions level but at the same time the calculation of any DSL expression can be expressed in Roslyn as well as in C#). For you is important to state the "rule" and I do not understand why? Roslyn is just a way to dynamically create CLR execution units. – Roman Pokrovskij Jan 03 '17 at 18:03
  • @RomanPokrovskij: No; a DSL would typically generate imperative code that declares the desired result. DSLs can usually be translated into C# code (and can frequently be designed as valid C# code in the first place) – SLaks Jan 03 '17 at 18:08
  • @RomanPokrovskij Roman is correct. I am defining a new language, which is a subset of C#. I have a very good reason to do this. How do I get Roslyn analyzers restricted to my custom Item / Language type? – Frank Nov 06 '21 at 16:57
4

Roslyn does not allow to do it.

Look at this project: Nitra. It's under active development.

Memoizer
  • 2,231
  • 1
  • 14
  • 14
  • 2
    And just some context: it was an intentional non-goal of Roslyn to be a generic framework for building compilers. Although that would have been cool, we also had to, well, actually ship something. :-) – Jason Malinowski Jan 15 '16 at 21:15
  • @JasonMalinowski is it likely that the 'non-goal' might change in the future? Is there a place to discuss? – Rossco Feb 09 '16 at 03:04
  • For building new compilers for languages, it's still a non-goal. – Jason Malinowski Feb 09 '16 at 06:15
  • 1
    @JasonMalinowski Can I use Roslyn to parse c# code and emit some code in different language, for example Java? I guess this should be anyway possible traversing the syntax tree, but does roslyn offers itself some facilities to plug some custom code generation? – ceztko Oct 12 '18 at 13:51
  • Extending our emit isn't a direct goal, but with the latest stuff you can ask for [operations](https://learn.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.semanticmodel.getoperation?view=roslyn-dotnet#Microsoft_CodeAnalysis_SemanticModel_GetOperation_Microsoft_CodeAnalysis_SyntaxNode_System_Threading_CancellationToken_) which get you some of information we have in our binding structures. You could _try_ to emit from that, but it might still be easier to just fork and modify directly. We are open source! – Jason Malinowski Oct 13 '18 at 01:12
  • 4
    Not so active "today" it seems; the most recent updates are 2 years ago at the time of this response. – mwpowellhtx Apr 14 '19 at 15:21
1

I know this is an old thread, but your best bet (in visual studio at least) is to create an IVsSingleFileGenerator that converts your code into c# or other Roslyn language.

quelbe
  • 41
  • 4