What should a "Stream" operator look like in C#?
Streams were one of the core concepts that I latched onto with Cw. It elevated enumerable lists as a first class problem domain. The fact that int* really was IEnumerable
Now I'm by no means a compiler writer, but that didn’t stop me from pondering what kind of operator could be used for IEnumerable<T>. As I understand it, the core issue is picking an operator that will not break existing code. Cw used the * operator which would conflict with unsafe pointers in C#.
Here's my first stab at it:
int? Nullable
List<int> List of ints C# 2.0
int[] Array of ints C# 1.0
int{} IEnumerable
It would seem that this could be parsed in the same way that an array declaration is but using {}. I'm sure there are huge holes in this that I have just missed. {} are typically used for code blocks so hopefully this difference is discernable by the compiler. This seems to make some sense in that at a later time you will use closures to perform operations on the stream ala foreach in C# and apply to all in Cw (more on that later). Conceptually it seems to pair well with arrays. [] are static lists where {} are dynamic lists or lazy lists.
Now on to the next Cw feature that I would love to see in some form in C# 3.0, Apply to all.
In Cw there was a shorthand for foreach that would "apply" a lamda to a stream:Cw:
int* evenNumbers = EvenIntegers();
evenNumbers.{ Console.WriteLine(it); }
C# could be:
int{} evenNumbers = EvenIntegers();
evenNumbers.{ it => Console.WriteLine(it) };
This could generate method calls just like select/where do:
evenNumbers.ForEach( it => Console.WriteLine (it) );
or
evenNumbers.ApplyToAll( it => cw(it) );
ForEach is already a method on the List
The ForEach/ApplyToAll could be provided by extension methods for IEnumberable
(from p in Process.GetProcesses()
where p.WorkingSet > 4000000).{
p => Console.WriteLine(p.MainModule.ModuleName)
}
Now, since I'm no expert in Cw or language design I'm sure there are all kinds of problems with these examples. I mostly want to point out how foundational "lists" seem to be in the future language features and as such should be given some special consideration by the language. Any time that I have to dip down into the implementation details the higher order concept gets lost.