Purity of methods in C#, evaulation and custom compiler?

Question

Have you ever been frustrated by Visual Studio not re-evaluating certain watch expressions when stepping through code with the debugger?

I have and does anyone here care about pure methods? Methods with no side-effects? There's so many great things about C# that I love, but I can't write pure functions, that is, static methods with no side-effects.

What if you were to build your own C# compiler where you could write something like this.

function int func(readonly SomeRefType a, int x, int y) { return /*...*/; }

Not only is the above a free function, alas, I don't call it a method, the function is assured to not have any side-effects. The C# keyword readonly could here be used to indicate just that, and provide a contract for pure functions. These kind of functions can always be evulated, without causing side effects. This being a way for Visual Studio to always evaulate my functions in the watch, despite the faulty assumpation that all method calls and user operators have side effects. A method where all the parameters are copy by value can never have side effects, yet, Visual Studio fails to recognize this.

I love C++ for what you can do at compile-time and I miss these things in C#, I think C# is dumbing down on the user a bit and basically not allowing certain expressiveness, hurting programmers. Many things which actually relate what you can do at compile time, I'd like to actually see more meta programs which are programs run by the compiler to compiler your original program.

e.g. While C# has booleans and don't allow things like if (var a = obj as MyRefType), it doesn't generate the approriate code. I did some digging around and noticed how C# fails to generate approriate IL for branchless conditionals, for example x > y ? 1 : 0, there's an IL instruction for just that which the C# compiler dosen't use.

Would you want, or be instrested in an open-source .NET compiler? Which looks like C# but is something entierly different, more expressive, and more flexible, and totally whaack, in terms what you can do with it?

Answer 1

Not really. If I want different language options I've already got:

• F# for a functional bent
• Boo for a DSL helper with custom compilation stages

The chances of a "design by committee" (or even "design by single amateur language designer") language ending up as well thought out as C# are pretty slim, IMO.

Would it be nice to be able to express a few more things? Absolutely.

Is it rather handy having hundreds of thousands of people who understand the same language, built-in Visual Studio integration from the people who really know it, etc? Absolutely!

For me, "looks like C# but is something entirely different" sounds like a problem, not a solution.

Answer 2

Why bother with writing a different compiler? You can achieve at least some of what you describe here by, e.g., writing a PostSharp weaver to alter the method (umm, function) at compile-time.

Answer 3

Just follow this simple convention: If it's not void, don't touch the parameters.

Answer 4

If you really want a mix of purity but you can still go with imperative aspect of OOP, go with F#. It's from Microsoft and it'll be productized and integrated into VS 2010.

If you really want a real pure functional programming that you can be sure that you have pure functions in your programming constructs and clearly differentiate side effects including IOs, Exceptions, you can go with Haskell.

For starter, you can download GHC, an open source Haskell compiler from Simon Peyton Jones, a researcher from Microsoft. You can also download Visual Haskell, a plugin for VS 2005 that functions as IDE for Haskell.

For more info:

• http://haskell.org/ghc/
• http://www.haskell.org/visualhaskell/

Answer 5

Implementing a language these days is a lot more than implementing a compiler. I'm personally addicted to Resharper, and even the more limited forms of syntax highlighting, hinting, auto-completion and in-editor compilation offered by plain Visual Studio is pretty sophisticated and helpful. All that UI stuff would have to be reimplemented as well.

A good case study in this area is the Spec# language. Rather than throwing more features into C#, Microsoft has instead turned it into a library that provides a way of decorating your code and then performing static checking on it, after the normal compilation step. So it is "bolted on" to whatever language you are already using.

This would probably be the most practical way to add more sophisticated verification to .NET languages.

Also, note that even though the language compiler generates IL with apparently redundant instructions, you aren't seeing what the JIT does when it produces more optimised native code.