I'm using CodeDom compiler to dynamically compile user defined scripts. We're working with C# scripts as standard, but I was wondering if there was a way how to support all CLI languages. To do that I'd have to detect used CLI language that was used in this particular source code.
Is there some elegant way how to detect only CLI languages from the source code?
Thanks
There are only 3 languages for which the framework provides a CodeDomProvider: C#, JScript and VB. Therefore, if the framework provides any direct method to parse "any language", it can only support these 3 languages. I don't think it does.
You may want to try to parse your code with all three implementations of CodeDomProvider, and keep the first that succeeds. It will take a dozen of lines of code.
I think it might be your best try.
Documentation for CodeDomProvider: http://msdn.microsoft.com/en-us/library/ds075xdx.aspx
Documentation for CodeDomProvider.Parse: http://msdn.microsoft.com/en-us/library/system.codedom.compiler.codedomprovider.parse%28v=vs.110%29.aspx
Related
Is there a way to run F# code in C#? I have written an app in C# - I'd like to provide it the ability to execute F#, read Record objects, enumerate lists from F#. What is the current solution for this? I know in the future there will be probably be a way to do this via an update to Roslyn. Also, curious how to run F# code in F#, currently. Is there a way to do that easily?
Currently, you have to make the F# a library, and then call it from C#. Since F# is just .NET, using the F# library is (mostly) just like using any other C# library. You might want to look into FSharpX for this portion, however, as it provides some utilities to ease calling F# from C# and vice versa.
If you want to compile the F# dynamically from C#, you'll need to use the F# CodeDom implementation from the F# Power Pack. This will let you use CodeDom to compile F# on the fly, and then execute it from C#.
Note that Roslyn will not help here, even when it's released, as it won't support F# as a code model, only C# and VB.Net. It would potentially be possible to use Roslyn to manipulate and compile C# from within F#, but not the other way around.
In addition to the options that Reed already mentioned, there are a two other alternatives based on using the F# Interactive - you can either run it as a separate process or you could use the open-source release to reference it and call it directly (which is quite challenging, though).
So in summary, you have three options:
You can start the fsi.exe process and evaluate F# code in the F# Interactive environment (by sending F# code to the process by standard input). The F# binding for MonoDevelop is a good example how to do this (see InteractiveSession.fs).
The only difficulty is communication between the two processes, but I think this should be doable using a .NET remoting (or WCF) channel between the two. You can also just read the standard output from F# Interactive, but that might be a bit too simple.
You could use the open-source release of F# compiler & tools to reference relevant parts of the F# compiler and call them (as a library) to evaluate F# code. This would be the best option and it would give you pretty much the same options you get with interactive C# from Roslyn.
Sadly, this is not quite an easy task - I was playing with the idea of doing this and I made some progress (I can share that), but it is not done yet. The idea is to take the source code of fsi.exe (here), remove all UI and turn it into a library.
Using CodeDOM, you can invoke the F# compiler (fsc.exe) to compile F# code into a stand-alone application (or library), load it dynamically and run it. A disadvantage is that this will start a new instance of the compiler each time you use it and so it may be a bit slow (depends on your scenario)
Since the question has been asked, there has been a lot of exciting development :-)
You can now do this really easily using the F# Compiler Services project:
The F# compiler services package is a component derived from the F# compiler source code that exposes additional functionality for implementing F# language bindings, additional tools based on the compiler or refactoring tools. The package also includes F# interactive service that can be used for embedding F# scripting into your applications.
I am currently involved in some interesting programming language research which has, up until now, centred around extending the upcoming Java 7.0 compiler with some very powerful programmer-productivity-based features. The work should be equally applicable to related programming languages such as C#.
I'm currently scoping out the options for prototyping a C# port of the functionality. I would prefer open-source options so that the fruits of this work can be shared with the broadest-possible audience. Thus the Mono C# compiler seems to be the most obvious starting point. I'm an experienced C# developer so writing the code isn't the problem. I'm mainly concerned about extending the compiler in a maintainable and supported fashion. In the Mono FAQ on the subject (link) it is stated that "Mono has already been used as a foundation for trying out new ideas for the C# language (there are three or four compilers derived from Mono's C# compiler)". Unfortunately, there are no further pointers than this and, so far, Google searches have not turned anything up.
I'm wondering if anybody out there has any information on this. Do mcs/gmcs/dmcs have a standard extensibility model? Specifically, I will be performing some interesting transformations on a program's abstract syntax tree. Is there a standard mechanism for inserting functionality into the compiler chain between abstract syntax tree generation and the type checker and then code generation?
Up until now I've written some ad-hoc extensions to the code (primarily in the code generator) but this doesn't seem to be a maintainable solution especially given that I intend to keep my extensions up to date with the Git trunk of Mono as much as possible. Furthermore it would be nice to be able to make updates to my extensions without having to recompile the whole compiler every time I make a change. I would like to be able to wrap all my AST manipulations into a single .NET assembly that could be dynamically loaded by mcs/gmcs/dmcs without having to hack at the core compiler code directly.
Any thoughts or pointers on extending the Mono C# compiler would be gratefully received!
UPDATES (23 October 2010)
In response to the responses to my question, I decided that I would start working on a branch of Mono in order to create a simple extensibility model for the compiler. It's in its very early stages, but here it is at GitHub:
http://github.com/rcook/mono-extensibility
And the main commit is: http://github.com/rcook/mono-extensibility/commit/a0456c852e48f6822e6bdad7b4d12a357ade0d01
If anybody would be interested in collaborating on this project, please let me know!
Unfortunately, I cannot adequately answer your question, but if you look at the examples of C# extensions on Miguel de Icaza's blog, you will notice that all of them take the form of patches to the compiler, not plugins or extensions. This seems to indicate that there is no such API.
Note that all of these examples are of much smaller scope than what you seem to be working on:
Parameterless Anonymous Methods (this post actually explicitly mentions concerns about the maintainability of such language extensions)
String Interpolation
Destructuring Assignment for Tuples
Syntactic Sugar for IEnumerable
These are mostly localized syntactic sugar, with no "interesting" behavior. The fourth patch, for example, implements Cω's syntactic sugar for IEnumerables, but without any of Cω's semantics that make this syntax interesting. If you look at the patch you can see that it literally does stupid syntactical expansion of ~T → IEnumerable<T>, as opposed to Cω, where member access and method invocation are properly lifted over streams.
Microsoft Research's Phoenix Compiler Pipeline was once explicitly touted as the solution to such extensibility problems, but it seems that it now focuses mostly on optimizations and analysis on the IR level in a code generation backend. In fact, I'm not even sure if the project is even still alive.
The mono C# compiler is a bit of a hack. I spent around a week figuring out how to use information from the parse tree. The compiler does not produce any intermediate representation and code generation may break parts of the parse tree.
Still, the parser and tokenizer might prove useful to you and you just take it from there.
SharpDevelop also provides a C# parser.
The SharpDevelop parser is easier to use than the mono C# parser.
If F# also works for you, I would recommended. The source much cleaner than mono and available under open source license.
I've already tried to develop languages using C and C++, but how can I create a interpreted language using C#? Thanks.
PS: I want to build it to run in Windows Mobile devices.
Well... what have you tried in C and C++?
Developing a language isn't exactly childs play. Do you understand lexical analysis? Do you understand different types of parsers? Where an LR parser might be more appropriate than an LALR parser? Or vice-versa? Do you understand context free grammars? Regular expressions?
That doesn't even begin to cover code generation, optimization, etc... (which may not all apply for an interpreted language, but you're still going to want to know a thing or two about them before you dive in).
You seem to be familiar with compiler construction, so I'll just point to the tools:
MPLEX and MPPG are respectively scanner and parser generators that generate a lot of what you need to build a compiler or interpreter using the C# language.
It seems that more documentation can be found in the .NET SDK, but I don't have it at hand so I'll just leave a pointer to MSDN.
If you want an interpreteded language developing it for C# is no different than developing it in C or C++.
If you want to compile to a (.Net) compiled language then .Net offers lots of possibilities through System.Reflection.Emit.
I've been jumping from C# to Java an awful lot and the "differences" between the two are a bit of an annoyance.
Would it be possible to write a set of extentions/plugins that would merge the two languages syntaxes.
I'm talking about adding either IDE support or using language constructs that would for example:
treat these two lines equivalently:
System.out.println("Blah");
Console.out.writeline("Blah");
Automatically notice that when you type in string you mean String
Recognise common API calls and translate them in the background.
The end goal being to be able to write a java/C# program and to pick at compile time which VM/Runtime you are targeting.
If you could do this would it be a good idea?
If not why not?
The two languages are so similar it's painful in some aspects but in other aspects they are really different.
I've seen Code that will translate a C# project into Java and I'm assuming there is probably the reverse, what I am proposing is a middle ground, so we can all just "get along".
No, absolutely not. Certainly not in the languages themselves (as implied by the title) and preferably (IMO) not in the IDEs (as requested in the body).
They are different languages. The idioms and conventions are subtly different. I don't want to be thinking in Java when I'm writing C# or vice versa. I believe developers should be actively encouraged to separate their thinking. It's not too hard to switch between the two, but that switch should be present, IMO.
While I totally agree with Jon Skeet, if you must have this why not create your own library of Java API so you can create System.out namespace which has a method call printLn which calls Console.Writeline()?
That gets you close to what you want.
Just because Java and C# share some similar syntax you need to see past this and think in terms of Java Platform and .NET Platform. The two are distinctly different, so my answer is definitely not.
There actually already is a Java language for the .NET framework, developed by microsoft: J#
This way you get the java-syntax but you are still developing with the .NET framework.
But i am not recommending anyone to use it.
I knew Java before i knew C# so i tried out J# because i thought it would be an easier transition. At first I liked it but after I tried C# I'm never going back. First of all, nobody uses J# so it's kinda hard to find examples and tutorials. Second, C# has (IMO) much more convenient syntax, specially for events, properties, lambda, anonymus methods and alot of other things, it's also being updated every now and then with even more syntax sugar which i don't think J# is.
Maybe if you often write Java and sometimes have to write a .net app it might be a good option.
I think no. I also switch from java to c#. But if the syntax is identical was is to stop someone from trying to compile c# in a Java compiler, or vice-versa.
Visual Studio actually ships with a Java to C# converter, which tries to do some of the things you mention. Unfortunately it fails miserably (1) for anything beyond the simple hello world application.
Despite being very similar on the surface, there are many significant differences between Java and C#, so you would achieve very little by doing what you suggest imo.
(1) To be fair, it actually does a fairly good job if you consider the limitations given for such a task, but in practice the resulting code is of limited use and you have to do a lot of clean up after the conversion.
Firstly what you are describing is not a difference in language syntax but a differences in class libraries. Both languages are relatively simple in terms of keywords and features but understanding or knowing the libraries and how they operate requires considerable learning.
The mistakes you are describing are things that the developer should not be making to begin with - the IDE should not be guessing. There are going to be many cases where you can't easily / trivially translate between java or dotnet. In the end a skilled developer learns and knows when and which class libraries to use.
Actually in the beginning there was no dotnet - microsoft was behind java. They however proceeded to change java in ways not compatible with the java plstform standard. To paraphrase sun sued microsoft and won I'm court. Following that ms proceeded to create dotnet and particularly c# which became microsofts VM platform. Of course along the way a whole stack of things got changed. Microsoft introduced many things which broke Javas run anywhere etc. They have done the same thing with dotnet which have cause problems for the mono team to be able to faithfully reimplemwnt everything for other non windows platforms.
• String vs string.
• lowercase method names (java) v uppercase method names(dotnet).
• Giving java keywords new names - "package".
In the end dotnet was microsoft response so they can control the platform and do their own thing instead of following a standar
I'm porting a Java library to C#. I'm using Visual Studio 2008, so I don't have the discontinued Microsoft Java Language Conversion Assistant program (JLCA).
My approach is to create a new solution with a similar project structure to the Java library, and to then copy the java code into a c# file and convert it to valid c# line-by-line. Considering that I find Java easy to read, the subtle differences in the two languages have surprised me.
Some things are easy to port (namespaces, inheritance etc.) but some things have been unexpectedly different, such as visibility of private members in nested classes, overriding virtual methods and the behaviour of built-in types. I don't fully understand these things and I'm sure there are lots of other differences I haven't seen yet.
I've got a long way to go on this project. What rules-of-thumb I can apply during this conversion to manage the language differences correctly?
Your doing it in the only sane way you can...the biggest help will be this document from Dare Obasanjo that lists the differences between the two languages:
http://www.25hoursaday.com/CsharpVsJava.html
BTW, change all getter and setter methods into properties...No need to have the C# library function just the same as the java library unless you are going for perfect interface compatibility.
Couple other options worth noting:
J# is Microsoft's Java language
implementation on .NET. You can
access Java libraries (up to version
1.4*, anyways).
*actually Java 1.1.4 for java.io/lang,
and 1.2 for java.util + keep in mind that J# end of
life is ~ 2015-2017 for J# 2.0 redist
Mono's IKVM also runs Java on
the CLR, with access to other .NET
programs.
Microsoft Visual Studio 2005 comes
with a "Java language conversion
assistant" that converts Java
programs to C# programs
automatically for you.
One more quick-and-dirty idea: you could use IKVM to convert the Java jar to a .NET assembly, then use Reflector--combined with the FileDisassembler Add-in--to disassemble it into a Visual C# project.
(By the way, I haven't actually used IKVM--anyone care to vouch that this process would work?)
If you have a small amount of code then a line by line conversion is probably the most efficient.
If you have a large amount of code I would consider:
Looking for a product that does the conversation for you.
Writing a script (Ruby or Perl might be a good candidate) to do the conversion for you - at least the monotonous stuff! It could be a simple search/replace for keyword differences and renaming of files. Gives you more time/fingers to concentrate on the harder stuff.
I'm not sure if it is really the best way to convert the code line by line especially if the obstacles become overwhelming. Of course the Java code gives you a guideline and the basic structure but I think at the end the most important thing is that the library does provide the same functionality like it does in Java.