For Reference

• The Future of C#
• C# Future
• C# Team Technical Achievement Award

Tuple Syntax 
a la (precise parenthesization not so important here)

(1,2,3)

Tuple Enumeration

Not a language feature but allow tuple to be enumerated (IEnumerable<T>) for both homogeneous and heterogeneous tuples, meaning these two cases would both be legal

foreach (var x in (1,2,3))
  Console.WriteLine(x);

foreach (var x in (1,"WTF",3))
  Console.WriteLine(x);

Where in the first case the tuple would be IEnumerable<int> and in the second case the tuple would be either IEnumerable<IDynamic> or IEnumerable<Object>.

exoteric said:

I'll start out -

 

Tuple Syntax 
a la (precise parenthesization not so important here)

(1,2,3)

Tuple Enumeration

Not a language feature but allow tuple to be enumerated (IEnumerable<T>) for both homogeneous and heterogeneous tuples, meaning these two cases would both be legal

foreach (var x in (1,2,3))
  Console.WriteLine(x);

foreach (var x in (1,"WTF",3))
  Console.WriteLine(x);

Where in the first case the tuple would be IEnumerable<int> and in the second case the tuple would be either IEnumerable<IDynamic> or IEnumerable<Object>.

BigInt literals

var bigint = 349438474346346348348346734634634892390139328234746546348349349347237236465483932948565623893832932932737;

Bass said:

exoteric said:

*snip*

BigInt literals

 

var bigint = 349438474346346348348346734634634892390139328234746546348349349347237236465483932948565623893832932932737;

Not sure that would make the cut without a suffix literal.  But something like a "B" suffix would seem to fit.

Bass said:

exoteric said:

*snip*

BigInt literals

 

var bigint = 349438474346346348348346734634634892390139328234746546348349349347237236465483932948565623893832932932737;

I cannot tell if this is sarcasm...

exoteric said:

I'll start out -

 

Tuple Syntax 
a la (precise parenthesization not so important here)

(1,2,3)

Tuple Enumeration

Not a language feature but allow tuple to be enumerated (IEnumerable<T>) for both homogeneous and heterogeneous tuples, meaning these two cases would both be legal

foreach (var x in (1,2,3))
  Console.WriteLine(x);

foreach (var x in (1,"WTF",3))
  Console.WriteLine(x);

Where in the first case the tuple would be IEnumerable<int> and in the second case the tuple would be either IEnumerable<IDynamic> or IEnumerable<Object>.

I would be against tuple enumeration. A tuple is not a collection and should not be considered as such. If you really want that feature, you could build it yourself:

public static class TupleExtensions
{
  public static IEnumerable<T> ToCollection<T>(this Tuple<T, T> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
  }
  
  public static IEnumerable<object> ToCollection<T1, T2>(this Tuple<T1, T2> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
  }

  public static IEnumerable<T> ToCollection<T>(this Tuple<T, T, T> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
    yield return tuple.Item3;
  }
  
  public static IEnumerable<object> ToCollection<T1, T2, T3>(this Tuple<T1, T2, T3> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
    yield return tuple.Item3;
  }
  
  ...
}

TommyCarlier said:

exoteric said:

*snip*

I would be against tuple enumeration. A tuple is not a collection and should not be considered as such. If you really want that feature, you could build it yourself:

public static class TupleExtensions
{
  public static IEnumerable<T> ToCollection<T>(this Tuple<T, T> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
  }
  
  public static IEnumerable<object> ToCollection<T1, T2>(this Tuple<T1, T2> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
  }

  public static IEnumerable<T> ToCollection<T>(this Tuple<T, T, T> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
    yield return tuple.Item3;
  }
  
  public static IEnumerable<object> ToCollection<T1, T2, T3>(this Tuple<T1, T2, T3> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
    yield return tuple.Item3;
  }
  
  ...
}

A tuple is a collection. It's just a heterogeneous collection where elements do not always have the same type. That said, using extension methods for tuple enumeration could be a pretty good midpoint between no support and built-in support.

Not sure about enumeration, a tuple is only a sequence in a syntactic sense, theres plenty of contexts for how you can iterate something, and I think there needs to be proper thought into what should be considered a native sequence to the language.. best bet is, does it really add anything? no, then its not worth introducing additional behavior.

exoteric said:

I'll start out -

 

Tuple Syntax 
a la (precise parenthesization not so important here)

(1,2,3)

Tuple Enumeration

Not a language feature but allow tuple to be enumerated (IEnumerable<T>) for both homogeneous and heterogeneous tuples, meaning these two cases would both be legal

foreach (var x in (1,2,3))
  Console.WriteLine(x);

foreach (var x in (1,"WTF",3))
  Console.WriteLine(x);

Where in the first case the tuple would be IEnumerable<int> and in the second case the tuple would be either IEnumerable<IDynamic> or IEnumerable<Object>.

I'll agree with tuple syntax, but the (1, 2, 3) stuff isn't the important part. What's much more important is tuple assignment.

int a, b, c;

(a, b, c) = TupleReturningMethod();

wkempf said:

exoteric said:

*snip*

I'll agree with tuple syntax, but the (1, 2, 3) stuff isn't the important part. What's much more important is tuple assignment.

 

int a, b, c;

(a, b, c) = TupleReturningMethod();

I'll buy that for a dollar. I really liked that way of "decomposing" a tuple when using SML. Both are ways to make programs shorter because ultimately you don't need it, just as you don't need foreach.

TechChaser said:

I Would love to have partial publishing facility in website model applications, if there is an ASP.Net release

I think this thread is specifically about language features, in terms of .net features, I'd love to see some work put into making compilation more extensible (like postsharp for example)..

stevo_ said:

TechChaser said:

*snip*

I think this thread is specifically about language features, in terms of .net features, I'd love to see some work put into making compilation more extensible (like postsharp for example)..

Yeah, it would be interesting to see an application go through some programatic transform before compilation.  Something a bit more powerful than the simple #if(DEBUG) ugliness.  Maybe along the lines of a Linq to Parse Tree, or Linq to Assembly, or Linq to Attributes.  ie, you could have your precompiler set up with a set of Linq expressions, and if you wanted to do a core compile, you would choose the one that removed all the [UI]-decorated classes and methods.

That would also allow a lot more flexibility for encapsulation and information hiding than the current five access specifiers, and would enable things like friend classes without explicitly adding friend classes.  ie, the Linq code could specify that classes decorated with [Tester] would have access to all methods decorated [Testable], but that no other classes would be able to see it.  That would allow the "architects" to create the attributes and write the Linq code to determine what is visible to what, while the application programmers simply create classes to work within those boundaries.

Something like a formal, compilable version of a standards document.

Another nice thing about doing things this way is that you gain the power of doing macro-type stuff, but since everything is just a Linq-to-Parse-Tree, it would be analyzable realtime to the editor and intellisense (just like the #if(DEBUG) is now).

staceyw said:

Bass said:

*snip*

Not sure that would make the cut without a suffix literal.  But something like a "B" suffix would seem to fit.

There is no suffix literal for Int32 and Int64, try doing a var on a literal over 3 billion in value, the compiler will automatically define it as an Int64.

Bass said:

staceyw said:

*snip*

There is no suffix literal for Int32 and Int64, try doing a var on a literal over 3 billion in value, the compiler will automatically define it as an Int64.

var i = 123L; // the type of i is long/Int64

Minh said:

I want to have "endif"

Is this a serious suggestion?

TommyCarlier said:

Bass said:

*snip*

var i = 123L; // the type of i is long/Int64

I ment to say that the compiler can figure out if a literal should be an Int32 or Int64 based on it's size. My bad.

stevo_ said:

I think first class tuples would be useful, I would imagine extension properties make it in as its been noted that they actually agreed on a specification for how to do it, just had to cut it for 4.0 in order to shipit.

 

Not sure about enumeration, a tuple is only a sequence in a syntactic sense, theres plenty of contexts for how you can iterate something, and I think there needs to be proper thought into what should be considered a native sequence to the language.. best bet is, does it really add anything? no, then its not worth introducing additional behavior.

IIRC they decided the specification was the wrong thing and to go back to the drawing board.

stevo_ said:

I think first class tuples would be useful, I would imagine extension properties make it in as its been noted that they actually agreed on a specification for how to do it, just had to cut it for 4.0 in order to shipit.

 

Not sure about enumeration, a tuple is only a sequence in a syntactic sense, theres plenty of contexts for how you can iterate something, and I think there needs to be proper thought into what should be considered a native sequence to the language.. best bet is, does it really add anything? no, then its not worth introducing additional behavior.

It adds composability (direct use of tuples for LINQ) - but you're right, it needs to be thought out if there are costs involved, conflict cases - and whether to only allow it for homogeneous tuples: for this case what would be wrong, I don't see anything.

Maddus Mattus said:

More complex data structures, such as R-Tree's

As a language feature?

stevo_ said:

Maddus Mattus said:

*snip*

As a language feature?

yeah, you are right. It would make it a .Net 5.0 feature not a language feature.

But I would still like it

public dependency class Person
{
	public dependency string Name 
	{ 
		get;
		set; 
		default { return "John Doe"; }
		change { Console.WriteLine("Old: {0}, New: {1}", oldvalue, newvalue); }
	}
}

instead of

public class Person: DependencyObject
{
	public static readonly DependencyProperty NameProperty = DependencyProperty.Register(
		"Name", typeof(string), typeof(Person), new PropertyMetadata("John Doe", OnNameChanged));
	
	private static void OnNameChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args)
	{
		((Person)sender).OnNameChanged((string)args.OldValue, (string)args.NewValue);
	}
 
	public string Name
	{
		get { return (string)GetValue(NameProperty); }
		set { SetValue(NameProperty, value); }
	}
	private void OnNameChanged(string oldvalue, string newvalue)
	{
		Console.WriteLine("Old: {0}, New {1}", oldvalue, newvalue);
	}
}

Would be nice if something like this could also work with INotifyPropertyChanged, IDataErrorInfo and IEditableObject.

Vriff Polo said:

First class dependency objects and properties;

 

 

public dependency class Person
{
	public dependency string Name 
	{ 
		get;
		set; 
		default { return "John Doe"; }
		change { Console.WriteLine("Old: {0}, New: {1}", oldvalue, newvalue); }
	}
}

 

 

instead of

 

 

public class Person: DependencyObject
{
	public static readonly DependencyProperty NameProperty = DependencyProperty.Register(
		"Name", typeof(string), typeof(Person), new PropertyMetadata("John Doe", OnNameChanged));
	
	private static void OnNameChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args)
	{
		((Person)sender).OnNameChanged((string)args.OldValue, (string)args.NewValue);
	}
 
	public string Name
	{
		get { return (string)GetValue(NameProperty); }
		set { SetValue(NameProperty, value); }
	}
	private void OnNameChanged(string oldvalue, string newvalue)
	{
		Console.WriteLine("Old: {0}, New {1}", oldvalue, newvalue);
	}
}

 

Would be nice if something like this could also work with INotifyPropertyChanged, IDataErrorInfo and IEditableObject.

 

There is a lot of activity around dependency injection, dependency properties etc. I wonder if they really constitute the way of the future especially with Rx on the horizon. Hmm...

I think this is something too specific for a language feature personally, but its something that could be implemented by a library if we had a standard way to do post compilation weaving like postsharp does.

A progression of signal amplifications vis-à-vis noise reductions

// absolute noise
Tuple<int, int> Abs(int x, int y)
{
    return Tuple.Create(Math.Abs(x), Math.Abs(y));
}
// less noise
(int, int) Abs(int x, int y)
{
    return (Math.Abs(x), Math.Abs(y));
}
// less noise still
(int, int) Abs (int x, int y)
{
    return Math.Abs(x), Math.Abs(y);
}
void test()
{
    // full noise
    Abs Tuple.Create(1, -1)
    // less noise
    Abs (1, -1)
}

In particular, this

void test()
{
    Abs (1, -1)
}

should also match up with this

Tuple<int, int> Abs(Tuple<int, int> p)
{
    return Tuple.Create(Math.Abs(p.Item1), Math.Abs(p.Item2));
}

... what about saying "you know, we did a really good job on c# 4.0, so lets leave it for a while and instead of adding new features right away, lets see if we can look to adding stuff in five years time."

silverfrost said:

Clearly this is nver going to happen but....

 

... what about saying "you know, we did a really good job on c# 4.0, so lets leave it for a while and instead of adding new features right away, lets see if we can look to adding stuff in five years time."

 

Problem is, the world doesn't stand still just because you do. Witness Java-land and the great Scala. Not evolving is loosing.

    public struct Unnullable<T> where T : class
    {
        public Unnullable(T x)
        {
            if (x == null)
                throw new NullReferenceException();
            item = x;
        }
        public T Item
        {
            get
            {
                return item;
            }
        }
        private readonly T item;
    }

and used as such

    class Foo
    {
        int Bar = 3;
    }
    class Program
    {
        static void Main(string[] args)
        {
            var ufoo = new Unnullable<Foo>(new Foo());
            Console.WriteLine(ufoo.Item);
            Unnullable<Foo> baz; // error
            Unnullable<Foo> bax = null; // error
            Unnullable<Foo> box = (Foo)null; // error
            Console.ReadKey();
        }
    }

with built-in compiler support so we can simply write

var ufoo = new Foo!(); // type of ufoo is Foo! => Unnullable<Foo> 
Console.WriteLine(ufoo.bar);

Even without compiler support it will help catch nullness errors because in this case the compiler just translates ! to Unnullable - a kind of dual of ? which translates to Nullable. And with compiler support you may not even need to explicitly implement as Unnullable<T> although it will probably make the implementation easier.

And of course unnullable classes - where by default the class is unnullable.

while ((int bytesRead = stream.Read (buffer, 0, buffer.Length)) > 0) {

   outStream.Write (buffer, 0, bytesRead);

}

if ((IDisposable d = someObject as IDisposable) != null) {

  d.Dispose ();

} else {

  Console.WriteLine("Cannot dispose objects of type {0}", d.GetType().Name);

}

switch (char c = charReader.ReadChar()) {

  case 'a':

  case 'b': {

     return c;

  }

  ...

}

It would prevent some name pollution and make porting code from C/C++ easier.

Blue Ink said:

It may seem a not very ambitious request, but what I would like to see in C# is the ability to declare variables in the guard expression of some statements. Some usage examples:

 

while ((int bytesRead = stream.Read (buffer, 0, buffer.Length)) > 0) {

   outStream.Write (buffer, 0, bytesRead);

}

 

if ((IDisposable d = someObject as IDisposable) != null) {

  d.Dispose ();

} else {

  Console.WriteLine("Cannot dispose objects of type {0}", d.GetType().Name);

}

 

switch (char c = charReader.ReadChar()) {

  case 'a':

  case 'b': {

     return c;

  }

 

  ...

}

 

It would prevent some name pollution and make porting code from C/C++ easier.

 

Doesn't seem too bad although I'd be cautious about importing C++ coding practices into C#.

exoteric said:

Unnullability a la

    public struct Unnullable<T> where T : class
    {
        public Unnullable(T x)
        {
            if (x == null)
                throw new NullReferenceException();
            item = x;
        }
        public T Item
        {
            get
            {
                return item;
            }
        }
        private readonly T item;
    }

and used as such

    class Foo
    {
        int Bar = 3;
    }
    class Program
    {
        static void Main(string[] args)
        {
            var ufoo = new Unnullable<Foo>(new Foo());
            Console.WriteLine(ufoo.Item);
            Unnullable<Foo> baz; // error
            Unnullable<Foo> bax = null; // error
            Unnullable<Foo> box = (Foo)null; // error
            Console.ReadKey();
        }
    }

with built-in compiler support so we can simply write

var ufoo = new Foo!(); // type of ufoo is Foo! => Unnullable<Foo> 
Console.WriteLine(ufoo.bar);

Even without compiler support it will help catch nullness errors because in this case the compiler just translates ! to Unnullable - a kind of dual of ? which translates to Nullable. And with compiler support you may not even need to explicitly implement as Unnullable<T> although it will probably make the implementation easier.

 

And of course unnullable classes - where by default the class is unnullable.

The real performance benefits from this [null checks] come in at the MSIL level, unfortunately, so spec# etc. is the only way to go. None of this namby-pamby, prittle-pattle, tittle-tattle type nonesense.

With regard to dependency injection, I think Prism is leading the way here, and from a library point of view, it makes sense and the team has really done a fantastic job. If you gave me the cash and the staff to build a high-class, modern application, Prism would be at the top of my list.

With regard to extension methods, you could pick a handful of your favorite static libraries, MessageBox.Show, Regex even Code Contracts and add them to your list. This will widen the scope for method name clashes, so i'm sure the BCL team will resist this somewhat.

Thats not to say there isn't some perspicacious thinking going on here, because there is.

vesuvius said:

exoteric said:

*snip*

The real performance benefits from this [null checks] come in at the MSIL level, unfortunately, so spec# etc. is the only way to go. None of this namby-pamby, prittle-pattle, tittle-tattle type nonesense.

 

With regard to dependency injection, I think Prism is leading the way here, and from a library point of view, it makes sense and the team has really done a fantastic job. If you gave me the cash and the staff to build a high-class, modern application, Prism would be at the top of my list.

 

With regard to extension methods, you could pick a handful of your favorite static libraries, MessageBox.Show, Regex even Code Contracts and add them to your list. This will widen the scope for method name clashes, so i'm sure the BCL team will resist this somewhat.

 

Thats not to say there isn't some perspicacious thinking going on here, because there is.

I'm quite curious as to how you'd create a more efficient representation than a struct wrapping a reference type, please elaborate.

Actually this is not about performance at all, it is about correctness.

I'm not very familiar with Spec# but believe it has syntax support for non-nullability. Does Spec# not use the off-the-shelf CLR?

As to extension methods, that's a different thread, this is about C# 5.0 ideas (but would welcome any discussion about anti-patterns there; I don't think Contract makes sense as an extension method cluster at all; it does make sense, however, to lift the methods out to be accessible without name qualification; MessageBox.Show, I don't know about that one; - but let's have that discussion in the other thread).

vesuvius said:

exoteric said:

*snip*

The real performance benefits from this [null checks] come in at the MSIL level, unfortunately, so spec# etc. is the only way to go. None of this namby-pamby, prittle-pattle, tittle-tattle type nonesense.

 

With regard to dependency injection, I think Prism is leading the way here, and from a library point of view, it makes sense and the team has really done a fantastic job. If you gave me the cash and the staff to build a high-class, modern application, Prism would be at the top of my list.

 

With regard to extension methods, you could pick a handful of your favorite static libraries, MessageBox.Show, Regex even Code Contracts and add them to your list. This will widen the scope for method name clashes, so i'm sure the BCL team will resist this somewhat.

 

Thats not to say there isn't some perspicacious thinking going on here, because there is.

By prism you mean unity? unity is ok but its really an entry level ioc.. in terms of pure di I think windsor and MEF are worth looking at.

Windsor is a much more mature and capable ioc, and mef is more focused on different types of di.

exoteric said:

vesuvius said:

*snip*

I'm quite curious as to how you'd create a more efficient representation than a struct wrapping a reference type, please elaborate.

 

Actually this is not about performance at all, it is about correctness.

 

I'm not very familiar with Spec# but believe it has syntax support for non-nullability. Does Spec# not use the off-the-shelf CLR?

 

As to extension methods, that's a different thread, this is about C# 5.0 ideas (but would welcome any discussion about anti-patterns there; I don't think Contract makes sense as an extension method cluster at all; it does make sense, however, to lift the methods out to be accessible without name qualification; MessageBox.Show, I don't know about that one; - but let's have that discussion in the other thread).

I like your idea. I'd extend it to say I think .NET should have used non-nullable types by default. But it's probably too late for that.

Bass said:

exoteric said:

*snip*

I like your idea. I'd extend it to say I think .NET should have used non-nullable types by default. But it's probably too late for that.

It's the same with mutable vs immutable - we're finding that the defaults are wrong

- mutable vs immutable by default

- nullable vs unnullable by default

- imperative vs declarative by default

really, all these choices steer you toward the functional paradigm but not necessarily without object-orientation (Scala, and less so, F#)

but it's actually not too late to reverse the situation in C# - consider this

val x = 3; // immutable by default - type-inferred; doesn't imply out-lawing "var" but does begin a movement towards a saner default (well, actually, within a single method, if side-effects are constrained to it, supposedly it doesn't matter for purity; still, val would be nice; and this doesn't mean transitively immutable - each type would still need to be implemented as immutable)

immutable unnullable class Person ... // self-evident, if bloated - but bloat at definition site is better than bloat at use site

or -

invariant class Person ... // as above

or -

immutable class Person! ... // as above

Strip away some paths of expression (implicit nullability, implicit mutability, implicit side-effects) and you give the compiler greater (or at least easier access to) freedom to do radical program transformation. I'd like to think that's where we're going...

One thing is reversing the present. Another is reversing the (sins of the) past - also known as the .Net Framework... But that reversal probably begins with a more principled C#.

stevo_ said:

vesuvius said:

*snip*

By prism you mean unity? unity is ok but its really an entry level ioc.. in terms of pure di I think windsor and MEF are worth looking at.

 

Windsor is a much more mature and capable ioc, and mef is more focused on different types of di.

Is there no one DI/F to rule them all? If we have several DI/Fs will they compose? Is this a sustainable path?

exoteric said:

stevo_ said:

*snip*

Is there no one DI/F to rule them all? If we have several DI/Fs will they compose? Is this a sustainable path?

Like anything I think its probably a good and realistic thing that there isn't a single great one, windsor is pretty solid though.. but it focuses more on the ioc aspects.. in terms of raw dependency injection.. ie- I have a service A, which requires service B.. then MEF is offers more choices of resolution aspects.

You could well today use both mef and something like windsor but I don't think they would align exactly.. I think that MEF may gain more ioc like features in upcoming releases, and become something close to a 'fantastic all rounder' for awhile.

These days I use windsor, but I don't really think any ioc frameworks are really meeting a modern requirement.. mef has stable composition which I think should be something iocs should look into providing as an option.

exoteric said:

Bass said:

*snip*

It's the same with mutable vs immutable - we're finding that the defaults are wrong

 

- mutable vs immutable by default

- nullable vs unnullable by default

- imperative vs declarative by default

 

really, all these choices steer you toward the functional paradigm but not necessarily without object-orientation (Scala, and less so, F#)

 

but it's actually not too late to reverse the situation in C# - consider this

 

val x = 3; // immutable by default - type-inferred; doesn't imply out-lawing "var" but does begin a movement towards a saner default (well, actually, within a single method, if side-effects are constrained to it, supposedly it doesn't matter for purity; still, val would be nice; and this doesn't mean transitively immutable - each type would still need to be implemented as immutable)

 

immutable unnullable class Person ... // self-evident, if bloated - but bloat at definition site is better than bloat at use site

 

or -

 

invariant class Person ... // as above

 

or -

 

immutable class Person! ... // as above

 

Strip away some paths of expression (implicit nullability, implicit mutability, implicit side-effects) and you give the compiler greater (or at least easier access to) freedom to do radical program transformation. I'd like to think that's where we're going...

 

One thing is reversing the present. Another is reversing the (sins of the) past - also known as the .Net Framework... But that reversal probably begins with a more principled C#.

Is there any actual compilers against functional language that can do analytical optimizations?

Bass said:

exoteric said:

*snip*

Is there any actual compilers against functional language that can do analytical optimizations?

Not quite sure what you mean but this work impresses me

http://www.cse.unsw.edu.au/~dons/papers/CLS07.html 

This paper presents an automatic fusion system, stream fusion, based on equational transformations, that fuses a wider range of functions than existing short-cut fusion systems. In particular, stream fusion is able to fuse zips, left folds and functions over nested lists, including list comprehensions. A distinguishing feature of the stream fusion framework is its simplicity: by transforming list functions to expose their structure, intermediate values are eliminated by general purpose compiler optimisations.

We have reimplemented the entire Haskell standard list library on top of our framework, providing stream fusion for Haskell lists. By allowing a wider range of functions to fuse, we see an increase in the number of occurrences of fusion in typical Haskell programs. We present benchmarks documenting time and space improvements.

exoteric said:

Bass said:

*snip*

Not quite sure what you mean but this work impresses me

 

http://www.cse.unsw.edu.au/~dons/papers/CLS07.html 

This paper presents an automatic fusion system, stream fusion, based on equational transformations, that fuses a wider range of functions than existing short-cut fusion systems. In particular, stream fusion is able to fuse zips, left folds and functions over nested lists, including list comprehensions. A distinguishing feature of the stream fusion framework is its simplicity: by transforming list functions to expose their structure, intermediate values are eliminated by general purpose compiler optimisations.

We have reimplemented the entire Haskell standard list library on top of our framework, providing stream fusion for Haskell lists. By allowing a wider range of functions to fuse, we see an increase in the number of occurrences of fusion in typical Haskell programs. We present benchmarks documenting time and space improvements.

I'd like to propose an === operator, or "is identical to" operator, unlike == it isn't overridable (so it's good for ensuring reference equality when working with types that override == without manually calling Object.ReferenceEquals). It'd also work on structs where == is a value comparison and not a reference comparion by default.

Switching from a class to a struct, or vice versa, is painful, for no reason.

I should not have to choose between class or struct in order to be able to choose between heap or stack allocation. Heap or stack allocation should be a decision of the user of a data type, not the implementation of the data type. That is a more extreme and probably not possible without breaking c#, because we need syntax to indicate what is a reference, and what is a value, as in C++.

We need the notion of const-ness and const-correctness that can carry through, so we know what is immutable at a deep level. Basically, we need a more mathematically oriented language.

I would like to see a JIT compiler that can perform as well as Java's hot-spot compiler on high performance computing applications.

exoteric said:

Bass said:

*snip*

Not quite sure what you mean but this work impresses me

 

http://www.cse.unsw.edu.au/~dons/papers/CLS07.html 

This paper presents an automatic fusion system, stream fusion, based on equational transformations, that fuses a wider range of functions than existing short-cut fusion systems. In particular, stream fusion is able to fuse zips, left folds and functions over nested lists, including list comprehensions. A distinguishing feature of the stream fusion framework is its simplicity: by transforming list functions to expose their structure, intermediate values are eliminated by general purpose compiler optimisations.

We have reimplemented the entire Haskell standard list library on top of our framework, providing stream fusion for Haskell lists. By allowing a wider range of functions to fuse, we see an increase in the number of occurrences of fusion in typical Haskell programs. We present benchmarks documenting time and space improvements.

Vala is a language inspired by C# which does not allow null reference types without explictly idenitfying them as nullable.

eg:

string foo()
{
   return null;
}

   

won't compile

string? foo()
{
   return null;
}

   

would.

This will alert the caller on the possibility that function can return null, and thus the programmer can take the needed precautions.

C# could use similar syntax. Hopefully one day we can get rid of NullReferenceExceptions for good. They do not belong in an managed language IMO.

Frank Hileman said:

I would like to see features to make it easier to create data types with value semantics. This includes both classes (reference types) and structs. Currently there is a lot of unnecessary work between Equals, IEquatable, IClonable, GetHashCode, operator==, etc, with most of the work simple stuff that could be automated. For example, by default, you probably want equality and assignment to be defined as equality and assignment of fields, so there should be a way to get that automatically, and declaratively handle exceptions via attributes.

 

Switching from a class to a struct, or vice versa, is painful, for no reason.

 

I should not have to choose between class or struct in order to be able to choose between heap or stack allocation. Heap or stack allocation should be a decision of the user of a data type, not the implementation of the data type. That is a more extreme and probably not possible without breaking c#, because we need syntax to indicate what is a reference, and what is a value, as in C++.

 

We need the notion of const-ness and const-correctness that can carry through, so we know what is immutable at a deep level. Basically, we need a more mathematically oriented language.

 

I would like to see a JIT compiler that can perform as well as Java's hot-spot compiler on high performance computing applications.

Actually the language D has very sophisticated (transitive) const semantics.

In many cases I think defining const-ness or immutability is a definition-site problem. If a type is inherently mutable, I'm not so sure it makes sense to force a new immutable version of it. Types should be designed to work as immutable or mutable and the type-system should maybe help you track if you let an impure object flow through a method call (e.g. by forcing you to mark the return type as Impure<T>.

For example, if you let in an impure object in an otherwise pure method and you then compute some result based on it - but accessing properties of the object changes the object itself (let's just say it's an evil object), then this means that the method is still pure in a way but if you then call the same method again with the same object, it will break - because technically it's not the same object anymore. So the method is no longer reflexively pure.

public struct STuple<a>
{
    private readonly a x;
    public a Item
    {
        get { return x; }
    }
    public STuple(a a)
    {
        x = a;
    }
}
public struct STuple<a, b>
{
    private readonly a x;
    private readonly STuple<b> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b)
    {
        x = a;
        s = new STuple<b>(b);
    }
}
public struct STuple<a, b, c>
{
    private readonly a x;
    private readonly STuple<b, c> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b, c> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b, c c)
    {
        x = a;
        s = new STuple<b, c>(b, c);
    }
}
public struct STuple<a, b, c, d>
{
    private readonly a x;
    private readonly STuple<b, c, d> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b, c, d> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b, c c, d d)
    {
        x = a;
        s = new STuple<b, c, d>(b, c, d);
    }
}
public struct STuple<a, b, c, d, e>
{
    private readonly a x;
    private readonly STuple<b, c, d, e> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b, c, d, e> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b, c c, d d, e e)
    {
        x = a;
        s = new STuple<b, c, d, e>(b, c, d, e);
    }
}

As you can see they are recursively constructed structs. Their definition is much like linked lists, only here defined statically as heterogeneous nested structs.

It looks quite elegant and I'd expect more efficient for what tuples will often be used for than a class based implementation. There is no interface compatibility because C# forbids it. Also in this form the code is not FxCop compatible (lower-case type parameters and sins like that).

Now how to make these semantics better? It would be cool if the following was possible

• an (s)tuple of a higher dimension extends an (s)tuple of a lower dimension (structural matching between lower- and higher-dimensional (s)tuples)
• an (s)tuple is an IEnumerable<dynamic> when heterogeneous
• an (s)tuple is an IEnumerable<T> when homogeneous

These ideas will require an extension of the generic type system for C#. For examples in C# there is no struct inheritance or  struct interface inheritance.

Thoughts?

[2nd revision]

exoteric said:

More about tuples. I see in .Net 4.0 beta 2 they are implemented as classes. How about this?

 

public struct STuple<a>
{
    private readonly a x;
    public a Item
    {
        get { return x; }
    }
    public STuple(a a)
    {
        x = a;
    }
}
public struct STuple<a, b>
{
    private readonly a x;
    private readonly STuple<b> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b)
    {
        x = a;
        s = new STuple<b>(b);
    }
}
public struct STuple<a, b, c>
{
    private readonly a x;
    private readonly STuple<b, c> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b, c> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b, c c)
    {
        x = a;
        s = new STuple<b, c>(b, c);
    }
}
public struct STuple<a, b, c, d>
{
    private readonly a x;
    private readonly STuple<b, c, d> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b, c, d> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b, c c, d d)
    {
        x = a;
        s = new STuple<b, c, d>(b, c, d);
    }
}
public struct STuple<a, b, c, d, e>
{
    private readonly a x;
    private readonly STuple<b, c, d, e> s;
    public a Item
    {
        get { return x; }
    }
    public STuple<b, c, d, e> Rest
    {
        get { return s; }
    }
    public STuple(a a, b b, c c, d d, e e)
    {
        x = a;
        s = new STuple<b, c, d, e>(b, c, d, e);
    }
}

 

As you can see they are recursively constructed structs. Their definition is much like linked lists, only here defined statically as heterogeneous nested structs.

 

It looks quite elegant and I'd expect more efficient for what tuples will often be used for than a class based implementation. There is no interface compatibility because C# forbids it. Also in this form the code is not FxCop compatible (lower-case type parameters and sins like that).

 

Now how to make these semantics better? It would be cool if the following was possible

• an (s)tuple of a higher dimension extends an (s)tuple of a lower dimension (structural matching between lower- and higher-dimensional (s)tuples)
• an (s)tuple is an IEnumerable<dynamic> when heterogeneous
• an (s)tuple is an IEnumerable<T> when homogeneous

These ideas will require an extension of the generic type system for C#. For examples in C# there is no struct inheritance or  struct interface inheritance.

 

Thoughts?

 

[2nd revision]

how is a.Rest.Rest.Rest.Rest.Item more readable than a.Item4?

Ion Todirel said:

exoteric said:

*snip*

how is a.Rest.Rest.Rest.Rest.Item more readable than a.Item4?

That's just a way to structure the definition in a "compositional" way. One should not normally access the items in this way (given syntax support for tuples as mentioned earlier in wkempf). Although if you want to, it'd be easy to create getters that did this traversal. You could define properties such as Length and indexers such as Item ([]).

Ion Todirel said:

exoteric said:

*snip*

how is a.Rest.Rest.Rest.Rest.Item more readable than a.Item4?

To illustrate

public struct STuple<a>
{
    private readonly a x;
    public a Some
    {
        get { return x; }
    }
    public a this[int index]
    {
        get
        {
            if (index != 0)
                throw new IndexOutOfRangeException();
            else
                return x;
        }
    }
    public IEnumerator<a> GetEnumerator()
    {
        yield return Some;
    }
    public static int Index
    {
        get { return 0; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a)
    {
        x = a;
    }
}
public struct STuple<a, b>
{
    private readonly a x;
    private readonly STuple<b> s;
    public a Some
    {
        get { return x; }
    }
    public STuple<b> Rest
    {
        get { return s; }
    }
    public dynamic this[int index]
    {
        get
        {
            if (index > Index || index < 0)
                throw new IndexOutOfRangeException();
            else
                return index == Index
                    ? Some as dynamic
                    : Rest.Some as dynamic;
        }
    }
    public IEnumerator<dynamic> GetEnumerator()
    {
        yield return Some;
        yield return Rest.Some;
    }
    public static int Index
    {
        // C# forbids: (Rest.Index + 1)
        get { return 1; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a, b b)
    {
        x = a;
        s = new STuple<b>(b);
    }
}

Example

var a = new STuple<int>(3);
var b = new STuple<int,int>(1,2);
foreach (var x in a)
    Console.WriteLine(x);
foreach (object x in b)
    Console.WriteLine(x);
Console.ReadKey();

If we could somehow express a version of GetEnumerator that only applies to a homogeneous (s)tuple, meaning (s)tuple where all type parameters are equal, then there would be no need for a dynamic formulation, esp. as this is statically known.

public static class STupleExtensions
{
    public static IEnumerator<a> GetEnumerator<a>(this STuple<a, a> s)
    {
        yield return s.Some;
        yield return s.Rest.Some;
    }
}

I realize though that this kind of trickery is probably not very high on any wishlist heh

C# isn't classically functional, so trying to treat it so is really pretty abusive and it shows with how you'd need to use it.. if you want to go nuts on functional style, why not just pick a language that is based on functional foundations like F#?

Your efforts would be much more rewarding there.

stevo_ said:

Is it even ON the wishlist? can you explain why somebody would want this vs the .net tuple class? regardless of source naming guidelines .. (having type arg a and paramter a is really needlessly complicated).. personally I think you have a over obsession with functional style code.

 

C# isn't classically functional, so trying to treat it so is really pretty abusive and it shows with how you'd need to use it.. if you want to go nuts on functional style, why not just pick a language that is based on functional foundations like F#?

 

Your efforts would be much more rewarding there.

There are several things to consider. (The why is explained previously but see the end of this post as well (the questions)).

Types are shared across languages, imperative or declarative. The discussion here is about the formulation of tuples in .Net, so it is really language agnostic in a sense, it just so happens that C# is quite close to the lingua franca of .Net, MSIL. It could've been VB too for that matter. F# has a succint syntax but I'm not very convinced its fundamentally more functional than C# for example, given that C# now has lambdas and "monadic syntax". Both F# and C# are hybrid imperative/declarative/object-oriented languages; and F# has had to adapt to this as the .Net Framework is object-oriented (one possible interpretation of the dot in dot net?). So I don't believe a resistance to functional style C# is that meaningful in the larger scheme of things.

The experimental code provided here is just to show how tuples could be defined in a more "compositional" way. There is disagreement as to whether this is a good thing. That's good  and certainly does not discourage me from experimenting - I find this both educational and fun. C# or F#, it really doesn't make that much difference to me. Types are shared - the fundamental means of expression also.

So you should refocus your attention to the semantics: are tuples as sequences helpful or harmful; are tuples as structs vs classes helpful or harmful; are a "recursive" definition of tuples more helpful than a flat definition?

exoteric said:

stevo_ said:

*snip*

There are several things to consider. (The why is explained previously but see the end of this post as well (the questions)).

 

Types are shared across languages, imperative or declarative. The discussion here is about the formulation of tuples in .Net, so it is really language agnostic in a sense, it just so happens that C# is quite close to the lingua franca of .Net, MSIL. It could've been VB too for that matter. F# has a succint syntax but I'm not very convinced its fundamentally more functional than C# for example, given that C# now has lambdas and "monadic syntax". Both F# and C# are hybrid imperative/declarative/object-oriented languages; and F# has had to adapt to this as the .Net Framework is object-oriented (one possible interpretation of the dot in dot net?). So I don't believe a resistance to functional style C# is that meaningful in the larger scheme of things.

 

The experimental code provided here is just to show how tuples could be defined in a more "compositional" way. There is disagreement as to whether this is a good thing. That's good  and certainly does not discourage me from experimenting - I find this both educational and fun. C# or F#, it really doesn't make that much difference to me. Types are shared - the fundamental means of expression also.

 

So you should refocus your attention to the semantics: are tuples as sequences helpful or harmful; are tuples as structs vs classes helpful or harmful; are a "recursive" definition of tuples more helpful than a flat definition?

So let me boil it down to its absolute undeniable essence

STuple pros

- structs; for performance reasons (makes sense for tuples as most tuples are less than 10 elements)

- recursion; for composition (tuple.Rest rather than new Tuple<A,B>(tuple.Item1, tuple.Item2); to be fair: representation bias)

- enumeration; for composition (use tuples directly as sequences which, intuitively they are)

Tuple pros

- classes; for nominal typing (: INominal<T>)

- flatness; for ease of comprehension and simplicity

- non-enumeration; unmistakeable distinctness, no accidental application of abstraction

The tension here is somewhat like structural vs nominal typing. Is it a duck if it looks, walks and quacks like a duck or is it only a duck if it has duck painted over it?

These are choices. Being aware that there are choices being made for you and what the trade-offs are, is useful. I'm sure there are good reasons for the current design - nevertheless it is interesting to examine other paths of expression

exoteric said:

exoteric said:

*snip*

So let me boil it down to its absolute undeniable essence

 

STuple pros

- structs; for performance reasons (makes sense for tuples as most tuples are less than 10 elements)

- recursion; for composition (tuple.Rest rather than new Tuple<A,B>(tuple.Item1, tuple.Item2); to be fair: representation bias)

- enumeration; for composition (use tuples directly as sequences which, intuitively they are)

 

Tuple pros

- classes; for nominal typing (: INominal<T>)

- flatness; for ease of comprehension and simplicity

- non-enumeration; unmistakeable distinctness, no accidental application of abstraction

 

The tension here is somewhat like structural vs nominal typing. Is it a duck if it looks, walks and quacks like a duck or is it only a duck if it has duck painted over it?

 

These are choices. Being aware that there are choices being made for you and what the trade-offs are, is useful. I'm sure there are good reasons for the current design - nevertheless it is interesting to examine other paths of expression

 

> recursion; for composition (tuple.Rest rather than new Tuple<A,B>(tuple.Item1, tuple.Item2); to be fair: representation bias)

I would call .Rest.Rest.Rest.* a bad design rather than a different representation, get a better name and I may change my mind

> enumeration; for composition (use tuples directly as sequences which, intuitively they are)

And how are you going to enumerate them, return a IEnumerable<object>? That surely ain't cool.

Ion Todirel said:

exoteric said:

*snip*

> recursion; for composition (tuple.Rest rather than new Tuple<A,B>(tuple.Item1, tuple.Item2); to be fair: representation bias)

I would call .Rest.Rest.Rest.* a bad design rather than a different representation, get a better name and I may change my mind

 

> enumeration; for composition (use tuples directly as sequences which, intuitively they are)

And how are you going to enumerate them, return a IEnumerable<object>? That surely ain't cool.

 

 

(1) homogeneous tuples: Tommy already showed how you can enumerate them using extension methods. These are fully typed so no problem there. The next step is to define GetEnumerator as part of tuple itself and define it only for homogenous tuples -or- : given a foreach which would accept type-parametric extension methods, you could just define it as GetEnumerator<T, ...> extension methods.

static where possible

- nominal too!

(2) heterogeneous tuples; as mentioned previously, you can simply use dynamic. In this case you want to be extremely careful of course but you will not have to insert casts; in fact you may want this to be defined as extension methods from a nested namespace (System.Dynamic[.Tuple] or System.Tuple.Dynamic) so it isn't automatically imported; or even be able to except some extension methods for a particular variable... well ok, that's extreme

dynamic when necessary

- structural too!

The name Rest is not so important, although I like it (and it rhymes with Best - beat that!). Of course Rest could also be defined for tuples as they are defined today (Tuple<T, ...>), it just so happens it isn't. I wouldn't call a design bad because of a name but of course names are important in the final design; I've not picked the names with respect to a broader audience; such "streamlining" is not really interesting in the initial design phase, more of a distraction.

Vriff Polo said:

First class dependency objects and properties;

 

 

public dependency class Person
{
	public dependency string Name 
	{ 
		get;
		set; 
		default { return "John Doe"; }
		change { Console.WriteLine("Old: {0}, New: {1}", oldvalue, newvalue); }
	}
}

 

 

instead of

 

 

public class Person: DependencyObject
{
	public static readonly DependencyProperty NameProperty = DependencyProperty.Register(
		"Name", typeof(string), typeof(Person), new PropertyMetadata("John Doe", OnNameChanged));
	
	private static void OnNameChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args)
	{
		((Person)sender).OnNameChanged((string)args.OldValue, (string)args.NewValue);
	}
 
	public string Name
	{
		get { return (string)GetValue(NameProperty); }
		set { SetValue(NameProperty, value); }
	}
	private void OnNameChanged(string oldvalue, string newvalue)
	{
		Console.WriteLine("Old: {0}, New {1}", oldvalue, newvalue);
	}
}

 

Would be nice if something like this could also work with INotifyPropertyChanged, IDataErrorInfo and IEditableObject.

 

I like tuple syntax, but I kinda feel it fails the -100 point test for C#.  re enumeration of tuple values, this seems more of a metaprogramming kind of feature and actually can't you do it with reflection even now?  actually, isn't this more or less equivalent to serialization?

 I would definitely like to see some kind of language feature that makes declarative dataflow and data binding less awkward.  It doesn't have to be direct support for the WPF dependency property system -- although I'd personally welcome that -- but maybe there's some more general feature that would still allow something like WPF dependency properties to be built on top of it and be syntactically nicer, though I can't think just what that would be at the moment.

I would of course also welcome better support for non-nullable and immutable values -- and pure functions -- but I suspect this may have to wait for a successor language to C# (which might still be called C# as with VB6 -> VB.NET).

contextfree said:

Vriff Polo said:

*snip*

I like tuple syntax, but I kinda feel it fails the -100 point test for C#.  re enumeration of tuple values, this seems more of a metaprogramming kind of feature and actually can't you do it with reflection even now?  actually, isn't this more or less equivalent to serialization?

 

 I would definitely like to see some kind of language feature that makes declarative dataflow and data binding less awkward.  It doesn't have to be direct support for the WPF dependency property system -- although I'd personally welcome that -- but maybe there's some more general feature that would still allow something like WPF dependency properties to be built on top of it and be syntactically nicer, though I can't think just what that would be at the moment.

 

I would of course also welcome better support for non-nullable and immutable values -- and pure functions -- but I suspect this may have to wait for a successor language to C# (which might still be called C# as with VB6 -> VB.NET).

Two questions for you contextfree

- what is the -100 point test for C# (and how does it relate to any tuple syntax)

- how is enumeration of tuples equivalent to serialization

exoteric said:

Frank Hileman said:

*snip*

Actually the language D has very sophisticated (transitive) const semantics.

 

In many cases I think defining const-ness or immutability is a definition-site problem. If a type is inherently mutable, I'm not so sure it makes sense to force a new immutable version of it. Types should be designed to work as immutable or mutable and the type-system should maybe help you track if you let an impure object flow through a method call (e.g. by forcing you to mark the return type as Impure<T>.

 

For example, if you let in an impure object in an otherwise pure method and you then compute some result based on it - but accessing properties of the object changes the object itself (let's just say it's an evil object), then this means that the method is still pure in a way but if you then call the same method again with the same object, it will break - because technically it's not the same object anymore. So the method is no longer reflexively pure.

I agree with you. I would like to be able to specify the semantics of a data type or method more easily: should it be treated as immutable, or not (const). Should an argument be considered deeply const, etc. The compiler can take advantage of that and we can be free to break the rules, to add diagnostic fields to data types, for example.

The main problem I have is the clumsiness of value semantics in c#. This is just language weirdness.

Frank Hileman said:

exoteric said:

*snip*

I agree with you. I would like to be able to specify the semantics of a data type or method more easily: should it be treated as immutable, or not (const). Should an argument be considered deeply const, etc. The compiler can take advantage of that and we can be free to break the rules, to add diagnostic fields to data types, for example.

 

The main problem I have is the clumsiness of value semantics in c#. This is just language weirdness.

There is some elegance as well: auto-boxing and unboxing of values. <edit:wrong>On the other hand it is strange[1] that it's not possible to express that a struct (such as Tuple) conforms to an interface (such as IComparable<T>). Being a struct offsets you to a second-class[2] citizenship, stripped of priviledges such as interface inheritance.</edit:wrong>

Constness is really about purity as immutable objects lead to purity. Structs render mutability a tiny bit better as you always pass around copies but if a struct is mutable then it's still fundamentally impure and assists in permeating impurity; at least in an impure setting; say you have a method that has a local variable that is a struct type, then mutating this should be no major issue but if, on the other hand, this struct is not local but ambient in the object, then mutating it will affect purity of the object.

I believe D is working towards supporting notions of purity and the same with C# or maybe generally .Net in that I saw some special contract attributes for this somewhere (maybe).

It's interesting to think about having types be pure but also having a special purity constraint on types which the type-checker can enforce. This is the inverse of what Haskell does: everything is pure unless it's not - and then you get trapped in the IO monad. It would be quite nice to have a similar formalism, if reversed, for .Net, where you could express Pure<T>.

This would of course be a very special type, requiring compiler magic, depending on the power of the language itself; e.g. C# with a step in a multi-step compilation process for doing expression tree verification of static invariants such as purity; well, that's an advanced topic: allowing the programmer to extend the type-system/checker with arbitrary invariants; in a way we can think of contracts in this way too (it's just that many invariants can't be statically verified; but using types with more associated meaning would seem more powerful; somewhat like dependent typing perhaps.)

[1] Not strange in a pragmatic sense (language evolution takes time) but weird in an idiological sense (absent a notion of time, one could argue about imperfections such as unnecessary non-uniformity between structs and classes; on the other hand[3])

[2] Not a pun

[3]Talk is cheap

exoteric said:

Frank Hileman said:

*snip*

There is some elegance as well: auto-boxing and unboxing of values. <edit:wrong>On the other hand it is strange[1] that it's not possible to express that a struct (such as Tuple) conforms to an interface (such as IComparable<T>). Being a struct offsets you to a second-class[2] citizenship, stripped of priviledges such as interface inheritance.</edit:wrong>

 

Constness is really about purity as immutable objects lead to purity. Structs render mutability a tiny bit better as you always pass around copies but if a struct is mutable then it's still fundamentally impure and assists in permeating impurity; at least in an impure setting; say you have a method that has a local variable that is a struct type, then mutating this should be no major issue but if, on the other hand, this struct is not local but ambient in the object, then mutating it will affect purity of the object.

 

I believe D is working towards supporting notions of purity and the same with C# or maybe generally .Net in that I saw some special contract attributes for this somewhere (maybe).

 

It's interesting to think about having types be pure but also having a special purity constraint on types which the type-checker can enforce. This is the inverse of what Haskell does: everything is pure unless it's not - and then you get trapped in the IO monad. It would be quite nice to have a similar formalism, if reversed, for .Net, where you could express Pure<T>.

 

This would of course be a very special type, requiring compiler magic, depending on the power of the language itself; e.g. C# with a step in a multi-step compilation process for doing expression tree verification of static invariants such as purity; well, that's an advanced topic: allowing the programmer to extend the type-system/checker with arbitrary invariants; in a way we can think of contracts in this way too (it's just that many invariants can't be statically verified; but using types with more associated meaning would seem more powerful; somewhat like dependent typing perhaps.)

 

[1] Not strange in a pragmatic sense (language evolution takes time) but weird in an idiological sense (absent a notion of time, one could argue about imperfections such as unnecessary non-uniformity between structs and classes; on the other hand[3])

[2] Not a pun

[3]Talk is cheap

On the other hand it is strange[1] that it's not possible to express that a struct (such as Tuple) conforms to an interface (such as IComparable<T>).

That's not true. Structs can implement interfaces just fine.

Sven Groot said:

exoteric said:

*snip*

That's not true. Structs can implement interfaces just fine.

Thanks! I tried this a couple of weeks ago but misread the compiler output.

I would kick my own behind for this mistake but anatomy forbids it.

exoteric said:

Ion Todirel said:

*snip*

To illustrate

public struct STuple<a>
{
    private readonly a x;
    public a Some
    {
        get { return x; }
    }
    public a this[int index]
    {
        get
        {
            if (index != 0)
                throw new IndexOutOfRangeException();
            else
                return x;
        }
    }
    public IEnumerator<a> GetEnumerator()
    {
        yield return Some;
    }
    public static int Index
    {
        get { return 0; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a)
    {
        x = a;
    }
}
public struct STuple<a, b>
{
    private readonly a x;
    private readonly STuple<b> s;
    public a Some
    {
        get { return x; }
    }
    public STuple<b> Rest
    {
        get { return s; }
    }
    public dynamic this[int index]
    {
        get
        {
            if (index > Index || index < 0)
                throw new IndexOutOfRangeException();
            else
                return index == Index
                    ? Some as dynamic
                    : Rest.Some as dynamic;
        }
    }
    public IEnumerator<dynamic> GetEnumerator()
    {
        yield return Some;
        yield return Rest.Some;
    }
    public static int Index
    {
        // C# forbids: (Rest.Index + 1)
        get { return 1; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a, b b)
    {
        x = a;
        s = new STuple<b>(b);
    }
}

Example

var a = new STuple<int>(3);
var b = new STuple<int,int>(1,2);
foreach (var x in a)
    Console.WriteLine(x);
foreach (object x in b)
    Console.WriteLine(x);
Console.ReadKey();

If we could somehow express a version of GetEnumerator that only applies to a homogeneous (s)tuple, meaning (s)tuple where all type parameters are equal, then there would be no need for a dynamic formulation, esp. as this is statically known.

public static class STupleExtensions
{
    public static IEnumerator<a> GetEnumerator<a>(this STuple<a, a> s)
    {
        yield return s.Some;
        yield return s.Rest.Some;
    }
}

I realize though that this kind of trickery is probably not very high on any wishlist heh

I'd want that, too.

Dodo said:

exoteric said:

*snip*

I'd want that, too.

Inspired by the XHTML thread, this idea popped up; not new by any means but very much missing in action. First importing the members of a static class (Java people know this as static import; SML people as open; VB.NET people as something else)

public double Ex(double x)
{
    using Math;
    var z = 1/Sinh(x);
    ...
    return z3;
}

Next: importing the members of an enum

public enum HtmlChar : ushort
{
    nbsp = '\u00A0'
    ...
}
...
public void Output()
{
    using HtmlChar;
    var e = new XElement("p", ..., nbsp, ...);
    ...
    e.Save(...);
}

So two very different and very common scenarios covered by this (double-) feature.

[edit:] ushort does not work for Unicode in general, so have to switch to strings, which rules out enums

exoteric said:

Frank Hileman said:

*snip*

There is some elegance as well: auto-boxing and unboxing of values. <edit:wrong>On the other hand it is strange[1] that it's not possible to express that a struct (such as Tuple) conforms to an interface (such as IComparable<T>). Being a struct offsets you to a second-class[2] citizenship, stripped of priviledges such as interface inheritance.</edit:wrong>

 

Constness is really about purity as immutable objects lead to purity. Structs render mutability a tiny bit better as you always pass around copies but if a struct is mutable then it's still fundamentally impure and assists in permeating impurity; at least in an impure setting; say you have a method that has a local variable that is a struct type, then mutating this should be no major issue but if, on the other hand, this struct is not local but ambient in the object, then mutating it will affect purity of the object.

 

I believe D is working towards supporting notions of purity and the same with C# or maybe generally .Net in that I saw some special contract attributes for this somewhere (maybe).

 

It's interesting to think about having types be pure but also having a special purity constraint on types which the type-checker can enforce. This is the inverse of what Haskell does: everything is pure unless it's not - and then you get trapped in the IO monad. It would be quite nice to have a similar formalism, if reversed, for .Net, where you could express Pure<T>.

 

This would of course be a very special type, requiring compiler magic, depending on the power of the language itself; e.g. C# with a step in a multi-step compilation process for doing expression tree verification of static invariants such as purity; well, that's an advanced topic: allowing the programmer to extend the type-system/checker with arbitrary invariants; in a way we can think of contracts in this way too (it's just that many invariants can't be statically verified; but using types with more associated meaning would seem more powerful; somewhat like dependent typing perhaps.)

 

[1] Not strange in a pragmatic sense (language evolution takes time) but weird in an idiological sense (absent a notion of time, one could argue about imperfections such as unnecessary non-uniformity between structs and classes; on the other hand[3])

[2] Not a pun

[3]Talk is cheap

Constness (knowing if an object can be modified by a method) might be about purity if you are thinking about functional languages and concurrency. I simply find value semantics easier to reason with and work with, whether or not I am using a functional language or concurrency. It feels natural.

If you make a heap allocated data type (class in C#) immutable, it starts to acquire value semantics. But you still need to implement a lot of boilerplate code (Equals, IEquatable, operator == !=, GetHashcode etc), this code is a waste of time, and it is different from the boilerplate code you need for a stack allocated data type (struct in C#). The choice of value semantics or reference semantics should be independent of the allocation technique. 

Ideally, we can change from heap to stack based allocation without changing the data type implementation or usage. C# is probably permanently broken. But anything to move in that direction, and reduce the amount of code bloat, would be helpful.

Companies should upgrade to it.

My .NET 3 - 4 skills are going to waste, except on my hobby projects. My previous job is just now starting to upgrade to .NET 2.0.

(1) Clojure like pure/persistent data structures and STM.

(2) Go like type equivalence.

(3) Erlang like lightweight processes, perhaps using heap allocated stack frames (c.f. Second Life marshalling).

GrantB said:

Not really sure about these but...

(1) Clojure like pure/persistent data structures and STM.

(2) Go like type equivalence.

(3) Erlang like lightweight processes, perhaps using heap allocated stack frames (c.f. Second Life marshalling).

 

There doesn't appear to be anything special about Go's notion of type equivalence beyond structural typing. C# has dynamic now, not sure the good folks want to go beyond that because dynamic allows you to apply the same programming pattern but in a less type-safe way. Another idea is to be able to coerce a type that structurally matches a different type into that type - a sort of structural cast.

Love the idea behind persistent data structures.

exoteric said:

Unnullability a la

    public struct Unnullable<T> where T : class
    {
        public Unnullable(T x)
        {
            if (x == null)
                throw new NullReferenceException();
            item = x;
        }
        public T Item
        {
            get
            {
                return item;
            }
        }
        private readonly T item;
    }

and used as such

    class Foo
    {
        int Bar = 3;
    }
    class Program
    {
        static void Main(string[] args)
        {
            var ufoo = new Unnullable<Foo>(new Foo());
            Console.WriteLine(ufoo.Item);
            Unnullable<Foo> baz; // error
            Unnullable<Foo> bax = null; // error
            Unnullable<Foo> box = (Foo)null; // error
            Console.ReadKey();
        }
    }

with built-in compiler support so we can simply write

var ufoo = new Foo!(); // type of ufoo is Foo! => Unnullable<Foo> 
Console.WriteLine(ufoo.bar);

Even without compiler support it will help catch nullness errors because in this case the compiler just translates ! to Unnullable - a kind of dual of ? which translates to Nullable. And with compiler support you may not even need to explicitly implement as Unnullable<T> although it will probably make the implementation easier.

 

And of course unnullable classes - where by default the class is unnullable.

mod up Unnullablfe<T> (although I'd prefer NonNullable<T>). It should be usable in all places types are usable today and the framework should make full use of it. This would obviously require a CLR rev. Languages that support it should mark their assemblies appropriately, those that don't have the implicit casts/expections added for them by the jit.

piersh said:

exoteric said:

*snip*

mod up Unnullablfe<T> (although I'd prefer NonNullable<T>). It should be usable in all places types are usable today and the framework should make full use of it. This would obviously require a CLR rev. Languages that support it should mark their assemblies appropriately, those that don't have the implicit casts/expections added for them by the jit.

Nonnullable<T> is not bad, it's close to the latin Nonnullus which looks and sounds beautiful. That said, personally speaking, there is an strange eerie funny attraction to Unnullable<T>. Anyway, that's naming...

Actually for non-nullability, we'd probably want two things

1. definition-site non-nullability annotation
2. use-site non-nullability annotation

And preferably we want these to be low-impact in terms of syntax.

Example 1: use-site non-nullability (ejecting null from the domain of Tuple<int,int>)

Tuple<int,int>! thouShaltNull = Tuple.Create(10,20);

Example 2: definition-site non-nullability (giving birth to a new type that is non-nullable)

public class Tuple<int,int>!
{
    ...
}

Example 3: use-site nullability of a reference type which is born non-nullable

UnnullableTuple<int,int>? thouMayNull = ...;

It will be forbidden to construct a combination such as

Unnullable<Nullable<Val>> ... // error
Nullable<Unnullable<Ref>> ... // error

where Val is some value-type (non-nullable) and Ref is some reference type (nullable); so that the inner type is born (un-)nullable and at use-site you create a double negation.

Same as

Val?! ... // error
Ref!? ... // error

It is also forbidden to create unnnullable+unnullable and nullable+nullable combinations.

exoteric said:

Ion Todirel said:

*snip*

To illustrate

public struct STuple<a>
{
    private readonly a x;
    public a Some
    {
        get { return x; }
    }
    public a this[int index]
    {
        get
        {
            if (index != 0)
                throw new IndexOutOfRangeException();
            else
                return x;
        }
    }
    public IEnumerator<a> GetEnumerator()
    {
        yield return Some;
    }
    public static int Index
    {
        get { return 0; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a)
    {
        x = a;
    }
}
public struct STuple<a, b>
{
    private readonly a x;
    private readonly STuple<b> s;
    public a Some
    {
        get { return x; }
    }
    public STuple<b> Rest
    {
        get { return s; }
    }
    public dynamic this[int index]
    {
        get
        {
            if (index > Index || index < 0)
                throw new IndexOutOfRangeException();
            else
                return index == Index
                    ? Some as dynamic
                    : Rest.Some as dynamic;
        }
    }
    public IEnumerator<dynamic> GetEnumerator()
    {
        yield return Some;
        yield return Rest.Some;
    }
    public static int Index
    {
        // C# forbids: (Rest.Index + 1)
        get { return 1; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a, b b)
    {
        x = a;
        s = new STuple<b>(b);
    }
}

Example

var a = new STuple<int>(3);
var b = new STuple<int,int>(1,2);
foreach (var x in a)
    Console.WriteLine(x);
foreach (object x in b)
    Console.WriteLine(x);
Console.ReadKey();

If we could somehow express a version of GetEnumerator that only applies to a homogeneous (s)tuple, meaning (s)tuple where all type parameters are equal, then there would be no need for a dynamic formulation, esp. as this is statically known.

public static class STupleExtensions
{
    public static IEnumerator<a> GetEnumerator<a>(this STuple<a, a> s)
    {
        yield return s.Some;
        yield return s.Rest.Some;
    }
}

I realize though that this kind of trickery is probably not very high on any wishlist heh

I would love to see a way to extend types beyond that awkward "first-parameter-with-this-modifier" trick.

For example this natural syntax would be awesome:

// 'class', 'struct', 'interface' or 'enum' keywords
// are useless here since the type already exists
public extension TypeToExtend
{	
     // 'public' modifier is useless here, as in any interface declaration
     void ExtensionMethod()
     {
          // the 'this' keyword is available here
          ...
     }

     static void StaticExtensionMethod()
     {
          // the 'this' keyword is NOT available here, as in any static method
          ...
     }

     void ExtensionProperty { get; set; }
}

As you can see it would allow "extension properties" and "extension static methods".

You could even have "extension constructors", "extension events" and so on...

Everything you could imagine to extend !

ramooon said:

exoteric said:

*snip*

I would love to see a way to extend types beyond that awkward "first-parameter-with-this-modifier" trick.

For example this natural syntax would be awesome:

 

// 'class', 'struct', 'interface' or 'enum' keywords
// are useless here since the type already exists
public extension TypeToExtend
{	
     // 'public' modifier is useless here, as in any interface declaration
     void ExtensionMethod()
     {
          // the 'this' keyword is available here
          ...
     }

     static void StaticExtensionMethod()
     {
          // the 'this' keyword is NOT available here, as in any static method
          ...
     }

     void ExtensionProperty { get; set; }
}

 

 

 

As you can see it would allow "extension properties" and "extension static methods".

You could even have "extension constructors", "extension events" and so on...

Everything you could imagine to extend !

 

Interesting idea. It looks like a more complete/holistic/uniform approach to type extension, kudos. It is reminiscent of partial classes, except not exclusive for classes. Now I wonder: if you have a partial class A and another partial class B in two distinct namespaces and say you have a simple console program and the console program imports partial class A; will partial class B then also implicitly be used or only if you explicitly import that namespace? In the latter case the partial class construct looks pretty darned close to what you want, except partial to classes, so to speak. Hindsight is great.

As for public/private, private is probably a sign of imperativeness because in an imperative setting you want to be careful about who's modifying your object using your special helper methods whereas when constructing new objects it's not really that big of an issue and this default looks wrong for a mostly-declarative world (or functional if you will). This will also save lots of code having to explicitly declare public all over. Well... too late for C#, that ship sailed long ago.

exoteric said:

ramooon said:

*snip*

Interesting idea. It looks like a more complete/holistic/uniform approach to type extension, kudos. It is reminiscent of partial classes, except not exclusive for classes. Now I wonder: if you have a partial class A and another partial class B in two distinct namespaces and say you have a simple console program and the console program imports partial class A; will partial class B then also implicitly be used or only if you explicitly import that namespace? In the latter case the partial class construct looks pretty darned close to what you want, except partial to classes, so to speak. Hindsight is great.

 

As for public/private, private is probably a sign of imperativeness because in an imperative setting you want to be careful about who's modifying your object using your special helper methods whereas when constructing new objects it's not really that big of an issue and this default looks wrong for a mostly-declarative world (or functional if you will). This will also save lots of code having to explicitly declare public all over. Well... too late for C#, that ship sailed long ago.

Well, I'm not sure to understand what you said but the extensions would be available only if you import the right namespaces (ie. exactly the same behavior as the current syntax). The main benefit over partial classes is that it does not require  the 'partial' keyword at the declaration site and it is not limited to classes therefore basically everything is extensible by default What I didn't realize is that the partial keyword would become totally useless o_O ... right ?

BTW Here's what I would like to see in future C# releases:

- Contracts: Spec# contracts built-in the language (with the bang non-null operator)

- Metaprogramming: a way to have user-defined keywords and syntax (ie.  a 'keyword' keyword and so on)

- Immutablilty and Purity keywords

- Some more declarative and lazy stuffs -- I absolutely love LINQ

Another idea, but IDE specific:

I wonder why although the IDE is now WPF based, it is still limited to classic characters ?

For example if I type something like "-->" I would like the IDE to replace it with a real arrow.

This would allow custom symbols to be used in modern languages...

ramooon said:

exoteric said:

*snip*

Well, I'm not sure to understand what you said but the extensions would be available only if you import the right namespaces (ie. exactly the same behavior as the current syntax). The main benefit over partial classes is that it does not require  the 'partial' keyword at the declaration site and it is not limited to classes therefore basically everything is extensible by default What I didn't realize is that the partial keyword would become totally useless o_O ... right ?

 

BTW Here's what I would like to see in future C# releases:

- Contracts: Spec# contracts built-in the language (with the bang non-null operator)

- Metaprogramming: a way to have user-defined keywords and syntax (ie.  a 'keyword' keyword and so on)

- Immutablilty and Purity keywords

- Some more declarative and lazy stuffs -- I absolutely love LINQ

 

Another idea, but IDE specific:

I wonder why although the IDE is now WPF based, it is still limited to classic characters ?

For example if I type something like "-->" I would like the IDE to replace it with a real arrow.

This would allow custom symbols to be used in modern languages...

 

I'm not sure but on the face of it, it looks like your type extension idea would basically generalize and unite both partial classes and extension methods. Thumbs up. There may be gotchas but on the face of it, it looks very compelling.

exoteric said:

GrantB said:

*snip*

There doesn't appear to be anything special about Go's notion of type equivalence beyond structural typing. C# has dynamic now, not sure the good folks want to go beyond that because dynamic allows you to apply the same programming pattern but in a less type-safe way. Another idea is to be able to coerce a type that structurally matches a different type into that type - a sort of structural cast.

 

Love the idea behind persistent data structures.

Would there be any value in this?

void f(dynamic IFoo arg)
{
	arg.foo();
}

Where

(1) arg is of type dynamic

(2) the compiler warns when arg is used in a way not compatible with IFoo

(3) the compiler warns when an actual parameter does not implement method signatures isomorphic with IFoo

(4) the IDE provide arg with IFoo intellisense

GrantB said:

exoteric said:

*snip*

Would there be any value in this?

 

void f(dynamic IFoo arg)
{
	arg.foo();
}

 

Where

(1) arg is of type dynamic

(2) the compiler warns when arg is used in a way not compatible with IFoo

(3) the compiler warns when an actual parameter does not implement method signatures isomorphic with IFoo

(4) the IDE provide arg with IFoo intellisense

generics?

Ion Todirel said:

GrantB said:

*snip*

generics?

No because that requires explicit association to IFoo whereas here we just need arg to match IFoo.

int Div(int n, int d) throws DivisionByZeroException { if (d == 0) throw new DivisionByZeroException(); else return n / d; }

Now if a function of Div does not catch DivisionByZeroException, then it must declare that it throws it. Se we can always see in the function type if it is exception safe; that is, responsibility is clearly defined.

exoteric said:

Exceptions as part of type-signatures

 

int Div(int n, int d) throws DivisionByZeroException { if (d == 0) throw new DivisionByZeroException(); else return n / d; }

 

Now if a function of Div does not catch DivisionByZeroException, then it must declare that it throws it. Se we can always see in the function type if it is exception safe; that is, responsibility is clearly defined.

I would argue that the compiler should just infer the potential exceptions vs java style manual decl.. plus code contracts go some way towards this, it would be nice to have more static analysis (including more 'bug be here' than just 'this won't compile') I'm sure the c# team would agree but of course its a lot easier to say it than make it happen.

exoteric said:

Exceptions as part of type-signatures

 

int Div(int n, int d) throws DivisionByZeroException { if (d == 0) throw new DivisionByZeroException(); else return n / d; }

 

Now if a function of Div does not catch DivisionByZeroException, then it must declare that it throws it. Se we can always see in the function type if it is exception safe; that is, responsibility is clearly defined.

That is something they deliberately decided not to do when designing .Net.

It's also impossible to add it now. Exception specifications only work if every single function uses them. If you allow interoperability with old code that doesn't have exception specifications, you'd need to have some way of dealing with situations where a method throws an exception which is not caught and not allowed by the specification of a method further up the chain. You'd get the same mess as in C++.

Sven Groot said:

exoteric said:

*snip*

That is something they deliberately decided not to do when designing .Net.

 

It's also impossible to add it now. Exception specifications only work if every single function uses them. If you allow interoperability with old code that doesn't have exception specifications, you'd need to have some way of dealing with situations where a method throws an exception which is not caught and not allowed by the specification of a method further up the chain. You'd get the same mess as in C++.

Yes, there'd had to be a strict and non-strict mode. You'd have to have your programs opt-in to it.

stevo_ said:

exoteric said:

*snip*

I would argue that the compiler should just infer the potential exceptions vs java style manual decl.. plus code contracts go some way towards this, it would be nice to have more static analysis (including more 'bug be here' than just 'this won't compile') I'm sure the c# team would agree but of course its a lot easier to say it than make it happen.

I agree we should have more help from VS with this. There's really zero help here: at least it should be easy to say: these exceptions are not caught in the function you call, consider catching these, and of course refactoring in exception-safety by right-clicking on a function call and having it automatically catch every uncaught case; where static analysis proves what is not caught.

On the other hand, there's probably also some benefits to expressing this explicitly. It may have been a deliberate choice to not have checked exceptions but maybe not the right choice.

exoteric said:

// deleted, wrong thread

It might have already been suggested, but I'd like to see base2 literals, which would be useful for writing Flags enums definitions without needing to think too much:

I also want to see VC-style documentation inference. In VC it gets the comments on the same line as #defines and uses that, but in C# you have to use XML comments, which take up too much space and hamper visiblity.

So this:

[Flags]

public enum Whatever {

    /// <summary>Foo Fighters</summary>

    Foo = 0x10,

    /// <summary>So a blonde walks into a bar...</summary>

    Bar = 0x11

}

Becomes:

[Flags]

public enum Whatever {

    Foo = 0b1010, // Foo fighters

    Bar = 0b1011 // So a blond walks into a bar...

}

public once int Total
{
    get { ... }
}

On the other hand, maybe its entirely possible to implement this with attributes

[Memoize]
public int Total
{
    get { ... }
}

Also, towards a more immutable world, is the current object construction syntax/semantics adequate? If you recursively initialize an object by setting properties, you have nice syntax a la JSon but the object is left open in a mutable state when you are done (or?). In a more immutable world one would then have to use very messy constructors, essentially with one parameter for every readonly/const member of a class that needs initialization. Even with named parameters this is not that nice; or maybe its good enough.

Also, how about auto-implemented properties and immutability. Is it good enough with private set and public get? Should you be able to set a hint that a property be readonly, i.e. that it is only settable at construction time? e.g.

public int Total
{
    get;
    set once;
}

Or should the compiler just infer this and apply any benefits yielded by analysis (e.g. class verifiably supports imutability post-construction, even if not explicitly so). Or should there be a keyword a la

public readonly class Person
{
    public string Name { get; set; } // settable, but only once, at construction time
    public uint Age { get; set; }
}

In some ways, just having readonly fields almost looks better

public class Person
{
    public static Person Parse(IEnumerable<byte> data)
    {
        return new Person()
        {
            Name = data.Take(20).ToAscii();
        }
    }
    public readonly string Name;
}

But that's not legal C#.

Some food for thought.

1 - Parameter-Level Interface Implementation; For example:

class Person
{
    public string Name { get; set; }
    public int Age { get; }
}
interface IPersonata
{
    string Name { get; }
    int Age { get; }
}
class SomeTasks
{
    // ...
    void Function(static IPersonata p) { /* ... */ }
    // ...
    void AnotherFunction(Person p)
    {
        // ...
        Function(p);
        // ...
    }
}

Should work; since Person satisfies IPersonata "statically". This is something like Google Go languages does. If we use dynamic instead of static; then it should generate necessary parts at runtime.

2 - Mixins (like Scala's Mixins); which in turn could lead to some statically typed meta-programming (well; It "could"; yet I am not sure how viable are these things in C#'s type system *).

3 - Templating generics themselves; at least as type parameters, in interfaces:

interface ITemplateBuilder<T><a>
{
     T<a> CreateInstance(a arg);
}

4 - Stronger type inferance (*).

5 - XAML everywhere! Yes! XAML could be a perfect replacement for macros in C#; and it's legal even for macro-hater C# folks (and some designers which I have not their eagle-eye view for sure; yet I like statically syntatic extension tools)! XAML provides a proper blending of aspects, services and data manipulation facilities.

I have successfully implemented a kd tree (in fact a 2d tree!) for solving a GIS nearest neighbor finding algorithm and enjoyed it a lot; and it is really performant.

But; the point that language designers should have in calculation more and more (as our problems get more complex and need quicker reactions):

A programming language for sure consums time to bend the programmer's mind to it's concept. At one point this "bending time" will be costy enough for being abandoned by industry.

One good job that Microsoft did; is releasing F#. Because if they intend to keep C# the way it is; they should leverage abstraction levels as new languages. F# is a wonderful language; yet a Scala blend (Maybe G# since G has one more angle than C!) could help more; since this "syntax" thing - and { } - really matters.

kaveh.shahbazian@gmail.com said:

I would like many features of Scala could be incorporated into C#. As that does not going to happen, I have my reduced wish list (with forgotten items, since I'm now somwhow dissapointed with C# road map - that's me).

 

1 - Parameter-Level Interface Implementation; For example:

class Person
{
    public string Name { get; set; }
    public int Age { get; }
}
interface IPersonata
{
    string Name { get; }
    int Age { get; }
}
class SomeTasks
{
    // ...
    void Function(static IPersonata p) { /* ... */ }
    // ...
    void AnotherFunction(Person p)
    {
        // ...
        Function(p);
        // ...
    }
}

Should work; since Person satisfies IPersonata "statically". This is something like Google Go languages does. If we use dynamic instead of static; then it should generate necessary parts at runtime.

 

2 - Mixins (like Scala's Mixins); which in turn could lead to some statically typed meta-programming (well; It "could"; yet I am not sure how viable are these things in C#'s type system *).

 

3 - Templating generics themselves; at least as type parameters, in interfaces:

interface ITemplateBuilder<T><a>
{
     T<a> CreateInstance(a arg);
}

 

4 - Stronger type inferance (*).

 

5 - XAML everywhere! Yes! XAML could be a perfect replacement for macros in C#; and it's legal even for macro-hater C# folks (and some designers which I have not their eagle-eye view for sure; yet I like statically syntatic extension tools)! XAML provides a proper blending of aspects, services and data manipulation facilities.

 

I have successfully implemented a kd tree (in fact a 2d tree!) for solving a GIS nearest neighbor finding algorithm and enjoyed it a lot; and it is really performant.

 

But; the point that language designers should have in calculation more and more (as our problems get more complex and need quicker reactions):

 

A programming language for sure consums time to bend the programmer's mind to it's concept. At one point this "bending time" will be costy enough for being abandoned by industry.

 

One good job that Microsoft did; is releasing F#. Because if they intend to keep C# the way it is; they should leverage abstraction levels as new languages. F# is a wonderful language; yet a Scala blend (Maybe G# since G has one more angle than C!) could help more; since this "syntax" thing - and { } - really matters.

Scala was designed from the ground up with an object-functional theory in mind; C# is evolving towards functional style (with LINQ in particular) but even if we want C# to evolve I don't see C# ever becomming as smooth as Scala in this regard; it simply wasn't designed from the outset with this philosophy in mind.

On the other hand it's probably not completely unreasonable to say that Microsoft wanted the equivalent of Java, fixing its inherent mistakes and improving it in various ways and then grew the idea further into an infrastructure for "poly-linguistic execution" although essentially founded on C# semantics (feel free to correct me.)

This "Parameter-Level Interface Implementation" sounds to me like structural typing. That is indeed very desirable in some cases although you can emulate it with C# 4.0 dynamics - but I imagine loosing a lot of efficiency along the way.

It would probably be more desirable to have a higher-kinded type system a la Haskell (higher-order generics or higher-order parametric polymorphism?)

http://en.wikipedia.org/wiki/Type_polymorphism

There has been some rumours that Microsoft is working on one more language. I believe Joe Duffy has been involved in this and maybe Erik Meijer as well. It's probably going to be pretty hard to beat Scala in generality and elegance but I remember a video with Joe Duffy and Erik Meijer discussing Linear Type Systems as a means to control effects within a concurrent world - or something to that effect. Maybe we can get an update some time on the current thinking within the company of what features are being thought of next.

And of course we still have C# 5.0 on the horizon (and C# 4.0 is still not quite out of its eggshell yet.) I'm surprised you are disappointed at the C# roadmap because I haven't seen any roadmap so maybe you can point me to it - please!

Still, functional programming has arrived in C# and its best realized in LINQ which is still evolving, at least on the library level. Rx is the latest and greatest example. So its power and impact is still unfolding.

exoteric said:

kaveh.shahbazian@gmail.com said:

*snip*

Scala was designed from the ground up with an object-functional theory in mind; C# is evolving towards functional style (with LINQ in particular) but even if we want C# to evolve I don't see C# ever becomming as smooth as Scala in this regard; it simply wasn't designed from the outset with this philosophy in mind.

 

On the other hand it's probably not completely unreasonable to say that Microsoft wanted the equivalent of Java, fixing its inherent mistakes and improving it in various ways and then grew the idea further into an infrastructure for "poly-linguistic execution" although essentially founded on C# semantics (feel free to correct me.)

 

This "Parameter-Level Interface Implementation" sounds to me like structural typing. That is indeed very desirable in some cases although you can emulate it with C# 4.0 dynamics - but I imagine loosing a lot of efficiency along the way.

 

It would probably be more desirable to have a higher-kinded type system a la Haskell (higher-order generics or higher-order parametric polymorphism?)

 

http://en.wikipedia.org/wiki/Type_polymorphism

 

There has been some rumours that Microsoft is working on one more language. I believe Joe Duffy has been involved in this and maybe Erik Meijer as well. It's probably going to be pretty hard to beat Scala in generality and elegance but I remember a video with Joe Duffy and Erik Meijer discussing Linear Type Systems as a means to control effects within a concurrent world - or something to that effect. Maybe we can get an update some time on the current thinking within the company of what features are being thought of next.

 

And of course we still have C# 5.0 on the horizon (and C# 4.0 is still not quite out of its eggshell yet.) I'm surprised you are disappointed at the C# roadmap because I haven't seen any roadmap so maybe you can point me to it - please!

 

Still, functional programming has arrived in C# and its best realized in LINQ which is still evolving, at least on the library level. Rx is the latest and greatest example. So its power and impact is still unfolding.

 

@exoteric  
Thanks for your time and your informative and precise reply.

i.
First on my disappointment about C# roadmap: I always look into ways not only to separate subsystems; but also abstracting bunch of aspects among all layers. First tool I like it here is syntactic extension mechanism and meta-programming and the second one - which I enjoy it's presence at XAML (especially WPF) - is a neat and clean (I am not sure if this name is descriptive enough) "aspect oriented" programming model. In XAML you can think of providers, services that are presented through providers, (I did not see this anywhere else, so maybe I am wrong) a very well tailored and tailor-able implementation of prototype-based OO model, templating every “thing/aspect” even up to the sky, binding/plumbing/validating state and much more; and why I think it should be more than handy in a programming language? An example could be a common task: Logging! A huge noise scattered all around our code just to serve at different conceptual level (can you turn it off and on easily, safely, or remove it easily?)! After these long years no one stood up to tackle this and see this problem at language level (for sure there a Lisper out there who does not share my point of view). This is my first of first (!) and very valuable (conceptually at least) to me: C# as an abstraction layer "on .NET"; C# as a XSLT for aspects "into .NET" (90:00':00"). I thought .NET team and C# team bring us more of it (and if anybody listens hear: we need more in-depth essays of WPF and the "reason/philosophy" behind each bit of it to learn it more deeply).
Second (to be honest this second still has more deeply affected me than that first; maybe because it happens recently) reason of my disappointment is Scala. I melted down when I saw it: How is this possible? Even possible? I though these are elegant dreams! They should not exist in the real world! The second reason was: I "believed" something like Scala is "impossible"! Of-course your description of Scala way and "logical/rational" (political?) decisions about C#; are complete. Yet Scala provides a neat and clean statically typed meta-programming and even syntax manipulating environment.

Again XAML is a source of well landed ideas! I like it! (OK, OK!)

ii.
A long time ago I thought about this "Parameter-Level Interface Implementation" thing in a different way. It was like some sort of "something mimics something" one-liner. Exactly as you mentioned, this idea changed in my mind when I was playing with C# 4.0 dynamic to this "Parameter-Level Interface Implementation". It's cool (and maybe exceptionally really immediately useful!).

iii.
I have played a little with Haskell and have a (maybe not so exact) clue of higher-kinded type-system; yet I think that's hard to achieve in C# semantics. But at interface level we can do more compiler tricks easily (correct me please if I am wrong).

iv.
It would be very nice to have some sources about that language you have spoke of. Thanks

v.
I have not looked into Rx so maybe I am wrong but it seems Rx should co-exists with some immutability facilities (like even an attribute, bundled with a compiler trick) in the language itself. Without that many problems (troubles) will still continue to exist in our code (is it possible for us to have uniqueness typing in C# or even in .NET?). And what about continuations? Does Rx provide a facility to use that seamlessly in our code? I have read some essays (maybe) which described that a language with exceptions can provide a richer model for dispatching that languages with continuations (in simple that idea is using different exceptions to reach different places in code - as I remember). So theorically we have a good bit of it. But do we have it built-in (not blotted-on) the language?

Regards

Zyrthofar said:

I don't know about you, but I'd like inline assembly for time-critical sections of code.

Inline assembly defeats the point of C# as a cross-platform language. Whilst assemblies support mixed-mode with both CIL and Native instructions it makes it impossible to verify the correctness of the code, it's meant for interop and not performance.

If you're doing time-critical programming do it in C/C++ without any CLR involvement.

W3bbo said:

Zyrthofar said:

*snip*

Inline assembly defeats the point of C# as a cross-platform language. Whilst assemblies support mixed-mode with both CIL and Native instructions it makes it impossible to verify the correctness of the code, it's meant for interop and not performance.

 

If you're doing time-critical programming do it in C/C++ without any CLR involvement.

Got it ^-^.

Thanks

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            var s1 = Enumerable.Range(1, 10);
            var s2 = s1.Select(x => x - 10);
            var s3 = Enumerable.Empty<int>();
            try
            {
                s3 = s1.Zip(s2, (a, b) => a / b);
            }
            catch (DivideByZeroException) // we'd like to catch the insect here
            {
                Console.WriteLine("got it");
            }
            foreach (var x in s3) // but this is where it shows itself
                Console.WriteLine(x);
            Console.ReadLine();
        }
    }
}

It's quite easy to build extension methods to catch and handle exceptions and chain these on a LINQ expression. It just doesn't follow the normal syntax for dealing with exceptions.

Hmm...

exoteric said:

Open question. Should there be special support for this scenario?

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            var s1 = Enumerable.Range(1, 10);
            var s2 = s1.Select(x => x - 10);
            var s3 = Enumerable.Empty<int>();
            try
            {
                s3 = s1.Zip(s2, (a, b) => a / b);
            }
            catch (DivideByZeroException) // we'd like to catch the insect here
            {
                Console.WriteLine("got it");
            }
            foreach (var x in s3) // but this is where it shows itself
                Console.WriteLine(x);
            Console.ReadLine();
        }
    }
}

 

It's quite easy to build extension methods to catch and handle exceptions and chain these on a LINQ expression. It just doesn't follow the normal syntax for dealing with exceptions.

 

Hmm...

Hmm, well, that's the framework, not C#, but I think the issue here is accepting how enumerables work. If you really need to know right now that nothing will cause the enumerable to throw then do something to materialize it right now, like s1.Zip(...).ToArray(). Alternatively, because you know where the exception can happen just put your catch in the right place.

Curt Nichols said:

exoteric said:

*snip*

Hmm, well, that's the framework, not C#, but I think the issue here is accepting how enumerables work. If you really need to know right now that nothing will cause the enumerable to throw then do something to materialize it right now, like s1.Zip(...).ToArray(). Alternatively, because you know where the exception can happen just put your catch in the right place.

It's actually a language issue with library design implications: to force exceptions to happen "eagerly" and therefore behave well with try/catch/finally, one often splits up methods in two parts: one for the iterator and another for the eager exception throwing.

I can see the design choice: it's easy to say everything is lazy about an iterator. It's simpler and one should have good reasons to complicate the design.

Doing ToArray is also not the answer if you have a stream that is either very long, very computationally expensive to exhaust, very IO expensive to exhaust - and maybe you don't even need all elements - that's part of what laziness allows you: to disregard non-needed elements, or maybe infinite.

Maybe the answer isn't changing how iterators work (no can do) or introducing an eager code block syntax. Maybe the answer is just make try/catch live over the entire lifetime of an iterator that is allocated inside a try block. Maybe not.

It's been forever since I used fxcop, maybe it has rules for such things heh.

  to Implement a common Interface ( INum )

 or Inherit from a common base class (NumBase)    Easy to remember as I've got a Numb *. (or the ruder version.

So then you can implement a Generic methods just focused on numbers stuff and not have to reimplement it for each type.

AdamSpeight2008 said:

Have all Base Class Number Type and Numberic,

  to Implement a common Interface ( INum )

 or Inherit from a common base class (NumBase)    Easy to remember as I've got a Numb *. (or the ruder version.

 

So then you can implement a Generic methods just focused on numbers stuff and not have to reimplement it for each type.

Generic math would be very sweet. I'm reminded of this pretty old Eiffel library by Chris Saunders that has always intrigued me, check out the superb use of code contracts: http://efsa.sourceforge.net/archive/saunders/math.htm 

And one more idea. This one very desirable. Probably much more than most other suggestions (except perhaps for non-nullability)

Flattened iterators in C#; "yield foreach" - Wes Dyer on Iterators and Erik Meijer & Co. on Iterators revisited. This should make tricks over enumerators unnecessary. I hope the concurrency focus won't drown that cool feature which will help a lot with performance and program elegance.

I have a class that is a performance timer, derived from Stopwatch. You can call Start and Stop on it multiple times and it has the following properties:

Count - Total number of runs (int).
Min   - Minimum run lenght in seconds (float)
Max   - Maximum run lenght in seconds (float)
Avg   - Average run length in seconds (float)

Pretty simple. But this class needs to be thread safe, for instance a background thread can be calling Start/Stop continuously, and the UI thread can be polling for results periodically. So just having simple properties does not work because the values can change while you are reading the properties one by one. So a tuple seems like a good plan, since I can use a lock to create the tuple that contains all values, making it thread safe.

But here is the problem: Everywhere I used the tuple, I had to go back and see what the order of the items were. It is not enough to know that the 2nd item is a float, and the 3rd item is a float, etc. You can spell it out in the method summary so that the IDE picks that up, but it still seems prone to error.

So I was thinking, how about a language feature where you can return a tuple like this:

 return Tuple.Create(Count = runCount, Min = runMin, Max = runMax, Avg = runAvg);

Then I can use it like:

var result = SomeStopwatch.Results;
Console.WriteLine("Count = " + result.Count);
Console.WriteLine("Min = " + result.Min);
Console.WriteLine("Max = " + result.Max);
Console.WriteLine("Avg = " + result.Avg);

Not sure how possible something like that would be, but it would make it not only type safe (like it already is), but also less likely to get the items mixed up.

Basically tuples with named items.

BitFlipper said:

I have been playing with tuples but ran into an issue that made them not very useful to me...

 

I have a class that is a performance timer, derived from Stopwatch. You can call Start and Stop on it multiple times and it has the following properties:

 

Count - Total number of runs (int).
Min   - Minimum run lenght in seconds (float)
Max   - Maximum run lenght in seconds (float)
Avg   - Average run length in seconds (float)

 

Pretty simple. But this class needs to be thread safe, for instance a background thread can be calling Start/Stop continuously, and the UI thread can be polling for results periodically. So just having simple properties does not work because the values can change while you are reading the properties one by one. So a tuple seems like a good plan, since I can use a lock to create the tuple that contains all values, making it thread safe.

 

But here is the problem: Everywhere I used the tuple, I had to go back and see what the order of the items were. It is not enough to know that the 2nd item is a float, and the 3rd item is a float, etc. You can spell it out in the method summary so that the IDE picks that up, but it still seems prone to error.

 

So I was thinking, how about a language feature where you can return a tuple like this:

 

 return Tuple.Create(Count = runCount, Min = runMin, Max = runMax, Avg = runAvg);

 

Then I can use it like:

 

 

var result = SomeStopwatch.Results;
Console.WriteLine("Count = " + result.Count);
Console.WriteLine("Min = " + result.Min);
Console.WriteLine("Max = " + result.Max);
Console.WriteLine("Avg = " + result.Avg);

 

 

Not sure how possible something like that would be, but it would make it not only type safe (like it already is), but also less likely to get the items mixed up.

 

Basically tuples with named items.

Tuples with named items: sounds like records: sounds like classes - anonymous classes.

Problem is, it doesn't seem possible (?) to return these literals from methods because to return them their type would have to be declared, making them that much less anonymous. Still, I think it would make sense to have something like this

public static new { T X, T Y } Vector2<T>(this T k)
{
    return new { X = k, Y = k };
}

On the other hand, it's pretty simple to create a simple class in your scenario. The tuple scenario is kind of like carrying along hidden metadata - or how would this statistics tuple look in a signature?

exoteric said:

BitFlipper said:

*snip*

Tuples with named items: sounds like records: sounds like classes - anonymous classes.

 

Problem is, it doesn't seem possible (?) to return these literals from methods because to return them their type would have to be declared, making them that much less anonymous. Still, I think it would make sense to have something like this

 

public static new { T X, T Y } Vector2<T>(this T k)
{
    return new { X = k, Y = k };
}

 

On the other hand, it's pretty simple to create a simple class in your scenario. The tuple scenario is kind of like carrying along hidden metadata - or how would this statistics tuple look in a signature?

Well, if you look at anonymous methods and captured variables etc, the compiler already creates anonymous classes in that case as you mention. We don't really care too much about the signature of these classes, since they are mostly hidden from us (although you can certainly see them in the debugger). In addition, when you use IEnumerable and yield return, the compiler infers the type from the return value. So if you combine those two concepts, you can basically have tuples with named items, right?

So in my example, the type of "result", would be something like "<Tuple>a__1" or whatever, but it would contain the public members with the correct names and types. Edit: And this is also what you would see if you used reflection to query the enclosing class's properties.

BTW, in my example then it should really be returned like this:

public ITuple Result
{ 
    get { return (Count = runCount, Min = runMin, Max = runMax, Avg = runAvg); } 
}

So just like you use IEnumerable when using yield return, you use ITuple, and the return type determines its true signature.

BitFlipper said:

exoteric said:

*snip*

Well, if you look at anonymous methods and captured variables etc, the compiler already creates anonymous classes in that case as you mention. We don't really care too much about the signature of these classes, since they are mostly hidden from us (although you can certainly see them in the debugger). In addition, when you use IEnumerable and yield return, the compiler infers the type from the return value. So if you combine those two concepts, you can basically have tuples with named items, right?

 

So in my example, the type of "result", would be something like "<Tuple>a__1" or whatever, but it would contain the public members with the correct names and types. Edit: And this is also what you would see if you used reflection to query the enclosing class's properties.

 

BTW, in my example then it should really be returned like this:

 

public ITuple Result
{ 
    get { return (Count = runCount, Min = runMin, Max = runMax, Avg = runAvg); } 
}

 

So just like you use IEnumerable when using yield return, you use ITuple, and the return type determines its true signature.

 

 

This is very similar to anonymous types:

var x = new { Count = runCount, Min = runMin, Max = runMax, Avg = runAvg };

The only difference is that anonymous types can only be used in a local scope.  I think that you should be able to return them from methods.  It is still just as type-safe but a lot more succinct:

public var GetAnonymous() {
  return new { Count = runCount, Min = runMin, Max = runMax, Avg = runAvg };
}

ktr said:

BitFlipper said:

*snip*

This is very similar to anonymous types:

 

var x = new { Count = runCount, Min = runMin, Max = runMax, Avg = runAvg };

 

The only difference is that anonymous types can only be used in a local scope.  I think that you should be able to return them from methods.  It is still just as type-safe but a lot more succinct:

 

public var GetAnonymous() {
  return new { Count = runCount, Min = runMin, Max = runMax, Avg = runAvg };
}

Yes in that case you don't even need tuples any more. I guess the only time these dynamic "tuples" would be problematic is if you want to assign them to a pre-existing variable (in cases where you can't use "var"). But if they are strictly used for the purpose of return values, then that should not a problem.

LOL, I think we can go even further then, by saying you can declare these tuples like this:

private var<int Count, float Min, float Max, float Avg> m_result;

Nested iterators (yield foreach); a serious performance booster (and similar features to democratize LINQ to Objects; increasing their practicality to the extreme) 

Non-nullability; a serious correctness booster

Design by Contract sugar; a serious correctness booster (well with or without sugar of course)

requires count > 0 vs Contract.Requires(count > 0)

requires any: count > 0 vs Contract.Requires(count > 0, "any")

Your top 3?

exoteric said:

Personal top 3 in retrospect

 

Nested iterators (yield foreach); a serious performance booster (and similar features to democratize LINQ to Objects; increasing their practicality to the extreme) 

 

Non-nullability; a serious correctness booster

 

Design by Contract sugar; a serious correctness booster (well with or without sugar of course)

requires count > 0 vs Contract.Requires(count > 0)

requires any: count > 0 vs Contract.Requires(count > 0, "any")

 

Your top 3?

What do you mean by nested iterators? I ask because a while ago I wanted to create an iterator (using yield return) that enumerates all child nodes (including nested children) of a specified node. I created a recursive iterator and surprisingly it worked.

Maybe you mean something else?

EDIT: Nevermind. I think you were specifically talking about a performance improvement when using nested iterators...

BitFlipper said:

exoteric said:

*snip*

What do you mean by nested iterators? I ask because a while ago I wanted to create an iterator (using yield return) that enumerates all child nodes (including nested children) of a specified node. I created a recursive iterator and surprisingly it worked.

 

Maybe you mean something else?

 

 

EDIT: Nevermind. I think you were specifically talking about a performance improvement when using nested iterators...

See this paper.

Iterators revisited: proof rules and implementation

Bart Jacobs, Erik Meijer, Frank Piessens, and Wolfram Schulte

Sven Groot said:

And another thread where I need to post so I can browse beyond page 1...

I believe one way to get around that bug is to right click on the "next/last page" button and select "Open in new tab/window". 

EDIT: I just noticed that sometimes those buttons are disabled, so the above suggestion doesn't always work. But I did find another trick: Scroll all the way to the top, then press F5 to refresh (dismiss any dialogs that might pop up). Then, while the page is still refreshing, the buttons will appear but will only stay enabled for a brief moment. If you then quickly click on one before the page completes loading, it should work.

Man can they only get this thing right...?

    /// <summary>
    /// An optional value.
    /// </summary>
    /// <typeparam name="V">The value type.</typeparam>
    public struct Maybe<V>
    {
        public Maybe(bool exists, V value)
        {
            _exists = exists;
            _value = value;
        }
        public Maybe(Nullable<V> item) where V: struct
        {
            _exists = item.HasValue;
            if (_exists)
                _value = item.Value;
        }
        
        .....
     }

For constructors and implicit conversion operators it would be pretty nice if you could apply constrained genericity.

Can't seem to do that. Possible?

Sven Groot said:

Replying because the thread was broken again...

How about this?

public this_t Add(this_t other)
{
    ...
}

where this_t is of course the type of this.

C# makes writing polymorphic numeric code living hell; e.g.

    public static class NumericEx
    {
        public static bool LessThan<T, V>(this T value1, T value2) where T : INumeric<T, V> { 
            return ...
        }
    }

[edited]

Calling the extension method one must supply the type parameters T and V explicitly, they will not be inferred.

I would like to see multiple inheritance with classes like in C++ supported within C#.

Maybe I'm crazy, but I've felt the class-interface inheritance style wasn't very good.... 

LinWinOverlord said:

This probably won't happen, but...

 

I would like to see multiple inheritance with classes like in C++ supported within C#.

 

Maybe I'm crazy, but I've felt the class-interface inheritance style wasn't very good.... 

BURN THE HERETIC!

W3bbo said:

LinWinOverlord said:

*snip*

BURN THE HERETIC!

Genuine LOL  -- glad no-one was around to see.

Herbie

LinWinOverlord said:

This probably won't happen, but...

 

I would like to see multiple inheritance with classes like in C++ supported within C#.

 

Maybe I'm crazy, but I've felt the class-interface inheritance style wasn't very good.... 

And now for a more sincere response:

Multiple-inheritance is a can of worms and introduces far more problems than it solves. Let's start off by saying this is actually impossible because the design of the CLR enforces single class inheritance. (Note this isn't to say some CIL compiler could hack it with interfaces and convulted behind-the-scenes design pattern generation),

Generally speaking, if you're using MI then you're probably doing something wrong that can't be solved using Design Patterns.

Show us some examples where you find yourself needing MI and we'll prove you wrong.

W3bbo said:

LinWinOverlord said:

*snip*

And now for a more sincere response:

 

Multiple-inheritance is a can of worms and introduces far more problems than it solves. Let's start off by saying this is actually impossible because the design of the CLR enforces single class inheritance. (Note this isn't to say some CIL compiler could hack it with interfaces and convulted behind-the-scenes design pattern generation),

 

Generally speaking, if you're using MI then you're probably doing something wrong that can't be solved using Design Patterns.

 

Show us some examples where you find yourself needing MI and we'll prove you wrong.

Describes the implementation and integration of the full power of the Eiffel language and method, including Design by Contract, multiple inheritance, genericity, and other advanced facilities, into the Microsoft .NET Framework, creating an environment that provides a best-of-breed solution for ambitious Internet software developers. (27 printed pages)

http://msdn.microsoft.com/en-us/library/ms973898.aspx 

That was 2002. Eiffel of course predates this. Now in 2010 we see Design by Contract enter .Net - as a library construct. Maybe in a few years we'll see it in C#. Eiffel is like Scala - a highly harmonious integrated language where features play together; I'd say multiple inheritance is no exception although I'm no particular advocate of multiple inheritance. Powerful generics, constrained genericity, co- and contra-variance, covariant return types, etc. are more important to me.

public N Succ<N>(this N x) where N : INumeric<N>
{
    yield return x.Add(x.Unit);
}

Nicely applicable to the implementation of lazy data structures and algorithms in general.

And a couple of foobar ideas...

class Laz
{
    strict int X; // explicitly eager
    int Y; // implicitly either lazy or eager
    yield int Z; // explicitly lazy
    Laz()
    {
        X = yield Slow(); // error
        Y = yield Slow(); // ok, Y is now lazy
        Y = Slow(); // error, must assign yielded computation
        Z =Slow(); // error; Z is lazy, must assign yielded computation
    }
    ...
}

exoteric said:

Explicit, concealed laziness -

 

public N Succ<N>(this N x) where N : INumeric<N>
{
    yield return x.Add(x.Unit);
}

 

Nicely applicable to the implementation of lazy data structures and algorithms in general.

 

And a couple of foobar ideas...

 

class Laz
{
    strict int X; // explicitly eager
    int Y; // implicitly either lazy or eager
    yield int Z; // explicitly lazy
    Laz()
    {
        X = yield Slow(); // error
        Y = yield Slow(); // ok, Y is now lazy
        Y = Slow(); // error, must assign yielded computation
        Z =Slow(); // error; Z is lazy, must assign yielded computation
    }
    ...
}

I'd really want grouped exceptions:

try

{

}

catch (SocketException)

catch (WebException)

{

    // some common handling here

}

vs.

try

{

}

catch (SocketException)

{

    // some handling here

}

catch (WebException)

{

    // same handling as above

}

Ion Todirel said:

exoteric said:

*snip*

I'd really want grouped exceptions:

 

try

{

}

catch (SocketException)

catch (WebException)

{

    // some common handling here

}

 

vs.

 

try

{

}

catch (SocketException)

{

    // some handling here

}

catch (WebException)

{

    // same handling as above

}

or something like:

try
{ 
    ... 
}
catch (System.IO.FileLoadException, System.IO.FileNotFoundException)
{
    ...
}

This is something I've been wanting for a while.  I especially hate having one line of code catch blocks just because I needed to catch some random exception that I didn't want caught by System.Exception.  Something like this would make things look cleaner I think.

Evok said:

Ion Todirel said:

*snip*

or something like:

 

try
{ 
    ... 
}
catch (System.IO.FileLoadException, System.IO.FileNotFoundException)
{
    ...
}

 

This is something I've been wanting for a while.  I especially hate having one line of code catch blocks just because I needed to catch some random exception that I didn't want caught by System.Exception.  Something like this would make things look cleaner I think.

That fails if your catch statement also defines an exception variable.

Wht I'd like to see is something more like switch() statements, with fall-through:

try {

} catch(IOException) {

    case FileNotFoundException fex: // variable 'fex' defined

        break; // break is optional

    case FileLoadException: // no variable defined

        // message to user

    default:

       // IOException or some IOException subclass

} catch(StackOverflowException soex) {

}

W3bbo said:

Evok said:

*snip*

That fails if your catch statement also defines an exception variable.

 

Wht I'd like to see is something more like switch() statements, with fall-through:

 

try {

 

} catch(IOException) {

    case FileNotFoundException fex: // variable 'fex' defined

        break; // break is optional

    case FileLoadException: // no variable defined

        // message to user

    default:

       // IOException or some IOException subclass

} catch(StackOverflowException soex) {

 

}

 

What do you mean fails? It'd just define multiple exception variables.

try
{ 
    ... 
}
catch (FileLoadException fle,FileNotFoundException fnfe)
{
    ...
}

Still, I'm ambivalent about these syntaxes, Ion's is perhaps better.

I don't like the concrete syntax you propose (in particular it looks messy and introduces a different looking syntax for inner exceptions; which happens to look like switch statements but is different; and which  does not handle more than 2-levels of inheritance) although the idea of a more "structured" exception handling syntax may not be half-bad.

A more sane approach may be to prefix exception names by ancestor - which is something the new Visual Studio might also be able to do visually using an extension; the nice thing here is that because we do not have multiple-inheritance of exceptions due to the fact that exceptions are class-based and we don't have multiple-class inheritance, we cannot get a multiple-parent conflict. Multiple-inheritance plus pattern matching over exceptions could be pretty interesting too.

try
{
   // ...
}
catch (FileException.FileNotFoundException e)
{
   // ...
}
catch (FileException.FileLoadException e)
{
   // ...
}
catch (SecurityException.AccessDeniedException e)
{
   // ...
}

Still, looks somewhat overkill. Let's get better static verification of exception handling first. (Maybe this too can be implemented as a VS extension which visually shows static analysis information about leaking exceptions: that is, uncaught exceptions.)

As a note: In haXe enumerations can be recursive and switch be used to pattern patch over values. Exceptions might be implemented as enumerations (in a sense abstract datatypes) with some support keyword(s) for exception handling semantics as opposed to non-side-effecting, pure value pattern matching. Not sure this is a very good approach but it might be a good approach to unify some syntax... in some other language...

Atlanta9 said:

Appears that C# has only very limited support toward the mix-in paradigm  (ex, interfaces and extension methods).  So, possibly, adding mix-in rich feature set would be a great addition to the language.

No thanks. I hate extension methods as they are, not sure if I could live with mixins. If the implementation is nice, perhaps. Show us what syntax you had in mind.

if (a & b == b)

if (a | b == a)

you had a shorthand. Of course, you could think about it like the += and -= operators, and just shrink the expression:

if (a &== b) // a includes b

if (b |== a) // b is included in a

but I think it would be more useful to give the expressions different meanings, so they would function like this:

if (a |== b) // any of the values of a ( 0x001 | 0x010 | 0x100 | etc.) is equal to any of the values in b

if (a &== b) // the combined values of a ( 0x001 & 0x010 & 0x100 & etc.) is equal to the combined values of b 

if (a ^== b) // the excluded values of a ( 0x001 ^ 0x010 ^ 0x100 ^ etc.) are excluded from b

then they could be reversed and still have the same meaning

if (b |== a) // any of the values of a ( 0x001 | 0x010 | 0x100 | etc.) is equal to any of the values in b

if (b &== a) // the combined values of a ( 0x001 & 0x010 & 0x100 & etc.) is equal to the combined values of b 

if (b ^== a) // the excluded values of a ( 0x001 ^ 0x010 ^ 0x100 ^ etc.) are excluded from b

because it would also apply to the values of b and not just a

brian.shapiro said:

How about making flag testing more simple with a new operator, so instead of

if (a & b == b)

if (a | b == a)

you had a shorthand. Of course, you could think about it like the += and -= operators, and just shrink the expression:

if (a &== b) // a includes b

if (b |== a) // b is included in a

but I think it would be more useful to give the expressions different meanings, so they would function like this:

if (a |== b) // any of the values of a ( 0x001 | 0x010 | 0x100 | etc.) is equal to any of the values in b

if (a &== b) // the combined values of a ( 0x001 & 0x010 & 0x100 & etc.) is equal to the combined values of b 

if (a ^== b) // the excluded values of a ( 0x001 ^ 0x010 ^ 0x100 ^ etc.) are excluded from b

then they could be reversed and still have the same meaning

if (b |== a) // any of the values of a ( 0x001 | 0x010 | 0x100 | etc.) is equal to any of the values in b

if (b &== a) // the combined values of a ( 0x001 & 0x010 & 0x100 & etc.) is equal to the combined values of b 

if (b ^== a) // the excluded values of a ( 0x001 ^ 0x010 ^ 0x100 ^ etc.) are excluded from b

because it would also apply to the values of b and not just a

I like your idea, but I find the second definitions a bit hard to follow (granted, it is 3am).

I'm more interested in anything that takes away the verbose bitwise operations and additional parentheses. I don't get why bitwise operators are so low in the precedence table.

"(a & b) == a" can easily be read as "a & b == a" as "a && b == a" so I don't get the distinction.

W3bbo said:

brian.shapiro said:

*snip*

I like your idea, but I find the second definitions a bit hard to follow (granted, it is 3am).

 

I'm more interested in anything that takes away the verbose bitwise operations and additional parentheses. I don't get why bitwise operators are so low in the precedence table.

 

"(a & b) == a" can easily be read as "a & b == a" as "a && b == a" so I don't get the distinction.

Yea I edited it to make it clear what I want to achieve. Its like a recursive logic/equational operation. The goal is just to make an equation thats bi-directional, so |== is different than &==, and it also doesn't matter what side the variables are on.

Except I guess its a little more complex than I'm making it sound like, because you'd also want to find (a | b) in (a | b | c) , so it has to be like a search operation. It can't be exactly like I described ... where any value on one side is equal to any value on the other side.. you have to search multiple values, and can't split a group to do a test.

For OR, either (a | b) is in one of the groupings of (a | b | c),  OR (a | b | c) is in one of the groupings of (a | b).

(a | b) = (a | b) OR (a | b) = (b | c) ---  OR, (a | b | c) = ?

Otherwise it may not work in two directions. I'm not sure how AND and XOR would work exactly.

brian.shapiro said:

W3bbo said:

*snip*

Yea I edited it to make it clear what I want to achieve. Its like a recursive logic/equational operation. The goal is just to make an equation thats bi-directional, so |== is different than &==, and it also doesn't matter what side the variables are on.

 

Except I guess its a little more complex than I'm making it sound like, because you'd also want to find (a | b) in (a | b | c) , so it has to be like a search operation. It can't be exactly like I described ... where any value on one side is equal to any value on the other side.. you have to search multiple values, and can't split a group to do a test.

 

For OR, either (a | b) is in one of the groupings of (a | b | c),  OR (a | b | c) is in one of the groupings of (a | b).

(a | b) = (a | b) OR (a | b) = (b | c) ---  OR, (a | b | c) = ?

 

Otherwise it may not work in two directions. I'm not sure how AND and XOR would work exactly.

I think if its shorthand like assignment operators, it should be collapsed the other way anyway

if (b == a & b)

if (a == a | b)

to

if (b &== a) // b is included in a

if (a |== b) // a includes b

That feels better to me

    ensures

        positive: result > 0

One simple function I've found extremely blissful for contract programming is implies, defined as

    implies a b = not a or b

As an example, transitivity expressed with implication/entailment:

    (a > b and b > c) implies (a > c)

It's a bit of a shame we can use neither the natural words for logical operators, nor their symbolic representatives.

I may sound like a broken record, always praising Eiffel but there's also much to be loved about C#. Iterators, lamda expressions and extension methods for example. It doesn't hurt to look around though. Contracts are a way to specify, constrain and verify the state machines we are surrounded with.

exoteric said:

Design by Contract syntax also comes with some very useful keywords such as old; in Eiffel the return value always has a name, called Result (this, by the way, encourages structured programming where control flow is expressed with if-then-else, making control flow visually clear via scoping), so there it is easy to refer to it when forming a post-condition; e.g.

 

    ensures

        positive: result > 0

 

One simple function I've found extremely blissful for contract programming is implies, defined as

 

    implies a b = not a or b

 

As an example, transitivity expressed with implication/entailment:

 

    (a > b and b > c) implies (a > c)

 

It's a bit of a shame we can use neither the natural words for logical operators, nor their symbolic representatives.

 

I may sound like a broken record, always praising Eiffel but there's also much to be loved about C#. Iterators, lamda expressions and extension methods for example. It doesn't hurt to look around though. Contracts are a way to specify, constrain and verify the state machines we are surrounded with.

I like the idea! But that doesn't fit with C# 's style, you want this:

ensures (result > 0); // The result is within spec limits

ensures immutable someLocalOrClassLevelMemebr; // The state doesn't change during method execution, this may be useful in multithreaded scenarios

require (arg1 > 0 && arg2 < 10);

require (arg1 /*string*/); // The compiler will emit code depending on the inputs, e.g. for string it would emit !String.IsNullOrWhitespace(arg1)

Just dreaming. This probably never will get into C#.

Ion Todirel said:

exoteric said:

*snip*

I like the idea! But that doesn't fit with C# 's style, you want this:

 

ensures (result > 0); // The result is within spec limits

ensures immutable someLocalOrClassLevelMemebr; // The state doesn't change during method execution, this may be useful in multithreaded scenarios

 

require (arg1 > 0 && arg2 < 10);

require (arg1 /*string*/); // The compiler will emit code depending on the inputs, e.g. for string it would emit !String.IsNullOrWhitespace(arg1)

 

Just dreaming. This probably never will get into C#.

Agreed; I just wrote it like that to show how nicely readable it is. I would prefer non-nullness at the type level (string! arg1) and stronger conditions in the contract (requires !arg1.IsWhitespace()).

Bart mentions the Sum method which exits from the IEnumerable monad. As when you evaluate this expression

Enumerable.Range(0, 10).Sum()

the result is 45 but you have left the monad.

Staying alive, in the monad, one might imagine this simple code

Enumerable.Range(0, 10).Sum2()

driven by these extension methods

public static IEnumerable<T> Reduce<S, T>(this IEnumerable<S> source, Func<IEnumerable<S>, T> transform)
{
    yield return transform(source);
}
public static IEnumerable<int> Sum2(this IEnumerable<int> source)
{
    return source.Reduce(xs => xs.Sum());
}

Now looking at this code I cannot help but wonder whether the Sum2 method should not be implementable as

public static IEnumerable<int> Sum2(this IEnumerable<int> source)
{
    return source.Reduce(Sum);
}

or if that's too much magic. It should know the type of source and therefore also know about the extension methods available. See that one matches and resolve to use that.