Volta and You
Yesterday, Volta was made publicly available for the first time. It is an experimental project in the early stages of development. The team decided to release an early technology preview so that developers everywhere can help guide the project through experience and feedback. We want your feedback.
The first release provides the basic feature set that will be improved upon with time. It has some obvious shortcomings that we are aware of and are actively addressing. But really, at this stage, the preview is more concerned with sparking your imagination about what is possible than ironing out all of the details.
Perhaps you disagree. Maybe the most important feature to you is the completeness of a final product. If that is the case, then say so and we will seriously consider making it a higher priority for the upcoming early experimental releases.
At some point, Volta may become, feed into, or inform a product, but that is a little way off yet. So let's enjoy the unique opportunity of working together to make something great.
In the coming months, I will alternate between three types of posts:
1. Volta focused posts: explaining the motivation, features, and technical details
2. C#: this includes both 3.0 and eventually 4.0 features
3. Random thoughts: like it says; two that will be discussed soon are programmer tests and continuations
I hope you enjoy the posts and I look forward to engaging with you in discussion.
Comments
Anonymous
December 06, 2007
Wes, When it comes to possible C# 4.0 features, along with the co/contravariance that Eric Lippert has been hinting at in his recent blogs, it would be very helpful if partial generic specialization could be added by way of the existing constraint mechanism. The main pain point scenario that I see today is that certain classes might want to do one thing for a reference type and another for a struct. For example the return type might be T for a class or T? for a struct. There's no easy way to do this w/o creating a separate class for each. What would be better is if I could specify two classes with the same name, but different where constraints. The overload resoltuion would pick out the most restrictive type. This could also work method overloading where there are two generic methods with the same name/parameters but different where constraints. The most specific would win. This kind of feature would eliminate the need for different classes to handle classes and structs in a generic way. Of course, there'd be other uses too, but this is one major one. Any thoughts? Thanks!Anonymous
December 06, 2007
Are you open/interested in feedback about what we would like to see in c# 4.0 as well? Or should we address those concerns to someone else?Anonymous
December 06, 2007
It's great to see previews and be able to provide feedback. However, try not to follow the Acropolis path, where fun was sometimes favored instead of useful features. If you want people to believe in your project, the main focus should be kept on key features.Anonymous
December 06, 2007
Well,I tried to run this, but it requires us to install the visual studio 2008. However, Volta/Linq itself is a rather interesting idea. I will try this after my exams a week later. It takes sometime to download all of these software first.Anonymous
December 06, 2007
onovotny: Yes, I understand where you are coming from. That is very interesting and duly noted. rob: As a member of the C# language design team, I am very interested to hear any input that you may have. fabrice: Good point. I love having fun, but I love solving problems even more. Do you have a particular useful feature in mind? wu: Awesome. Definitely check it out when you can. You can use either VS 2008 or VS 2008 beta 2. If you don't have either then try getting the n-day trial (for some n that I can't recall).Anonymous
December 07, 2007
The comment has been removedAnonymous
December 08, 2007
Wes, Please please pretty-please tell us that we're going to get macros with C# 4.0.Anonymous
December 08, 2007
Cool, Wes. My initial impression of Volta is that it's a project that tries to do the impossible. :-) That's a cool project to tackle in any case! Really looking forward to C# 4 posts and Volta posts. Those are both intriguing and will keep me subscribed. Wes, as a suggestion for C# 4, I really just want things that help us write code with less bugs. Whether that's design by contract, or the full Spec# stuff, or STM, whatever: that's what I really want, better, more reliable software.Anonymous
December 08, 2007
I am happy you're back, and waiting for your posts Wes.Anonymous
December 10, 2007
Ziv: I can't make any promises there but there has been a lot of discussion about metaprogramming. Judah: We regularly evaluate the stuff Spec# and other MSR projects do with contracts to see if they fit into the C# plans. Btw, both my wife and I love your blog.Anonymous
December 14, 2007
Looking forward to hearing about new C# features! :) Type classes, maybe? Implementing interfaces using extension methods (changing the typing of the class) maybe? Something we could really use over here, although I do understand it has some scary consequences in reflection.Anonymous
December 14, 2007
Type classes are one of my favorite things from Haskell, but I don't think we will see them in C# anytime soon. Extension classes on the other hand may make an appearance in some .NET language but no promises. It is just that extension classes are a great way to model relationships between objects as well as keep role based state around. As a side note, what do you think about the "like" and "wrap" operators proposed in EcmaScript 4? If something similar were implemented in C# then a programmer could have a structurally compatible instance implement an interface. This would actually remove much of the need for duck typing and many cases where dynamic invocation is needed.Anonymous
December 17, 2007
One of the reasons I like Haskell so much is its type system. You can probably imagine why I'm a bit disappointed to hear type classes won't make it anytime soon. I haven't heard of extension classes before. Are they classes that have extension methods that can implement interfaces? Isn't adding state to such a concept faking (or implementing) multiple inheritance? What about mixins? public class SomeClass<T> : T I can see problems implementing this, because the fact for each different T a version needs to be compuled to have the BaseType property of the Type of SomeClass<T> point to T. (and all the implications for the runtime). It would be a nice feature however. I had a quick look at some resources about ES4 containing some information about like and wrap. Is it basically something like an anonymous interface? Because if it is anonymous, it can't be specified in the class signature, so it should be based on public or extension method signatures, instead of type constraints. I would like to have static checking on this (O(1)?), as to eliminate the reason for runtime checking (O(#methods)?). This type of constraint for an object is of course already implemented with the foreach construct needing an object having a statically resolvable GetEnumerator() method. Could I take some type, implement a GetEnumerator extension method, and use it in a foreach loop? Well that's about it, for now... :)Anonymous
December 17, 2007
I will be missing the flexibility of type classes as well. No, it isn't multiple inheritance. It is something more like role-based inheritance since the class would only implement that interface when the extension class is in scope. You can already do something related to this. Make a static class with a bunch of extension methods for type T. Now add a static member of type Dictionary<T,ExtendedStateForT>. Bingo! The class now appears to have extra state. We can even do some things to implement an interface with extension methods. This is all nice but it remains just a bunch of fine hackery. It would be a lot better if languages or the runtime support such a thing. I can't tell you how many times I've wanted to write C<T> : T. At this point, I wouldn't plan on that either. But, you can use monads to get some of what you want. In fact, my next series of posts will eventually go into the latter approach. Yes, you are right that a pattern based constraint is already used in foreach loops. The checks don't have to be O(#methods) because a particular type doesn't have to be checked multiple times. Most likely it would be O(#methods/number of times that type&interface are checked).Anonymous
December 17, 2007
Off-topic: Wes, I'm honored that you and your wife read my blog. Thanks man! Take care.Anonymous
December 17, 2007
The comment has been removedAnonymous
December 18, 2007
I think I'' rephrase my question. The most obvious answer is of course: typeof(object).GetMethod("GetHashCode", BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly).Invoke(obj,null); But is there a way without using reflection?Anonymous
January 02, 2008
Can you post any updates to type inference that is being considered for 4.0? In particular as it relates to infering generic parameters. Hopefully something that will make creating lists of unnamable types (i.e. Anonymous Types) a bit less awkward.Anonymous
April 11, 2008
Good idea! P.S. A U realy girl?