2.5 KiB
C# Language Design Notes for Oct 16, 2017
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
"Being on the same floor as SPJ is a good way to shake out difficult corner cases"
- LINQ
- Shapes
Applying to LINQ
Mixed results.
Looking for perf, and ways to do more selective specialization.
Sum
Specialized to some numeric types, but not all. 500 lines of code. In those, the loop is unspecialized too.
One page of code!
A new design dimension: should I use interfaces or concepts: pay for abstraction or pay for specialization
Generic soup: this may be a superficial design issue, or even tooling issue.
For instance, the AssociatedTypes, other languages allow them to be retrieved by dot notation. Jeremy Siek paper "Associated Types and ...". TColl.TEnum etc.
From experience, abstracting over enumerators tends to need associated types or higher-kinded types.
Shouldn't be too discouraged by being smoked by LINQOptimizer. That one optimizes big queries, but what keeps people away from LINQ is more the death by a thousand paper cuts of using LINQ all the time. Roslyn avoids things that allocate, which today means not using LINQ. THis could be the thing that would allow it to.
Select
The return type is associated. The problem is that adding new instances can change the return type from afar, upsetting the consuming code.
Improves by 2/3rds when the array specialization is used.
SelectMany
The generic type inference gets very messy here. It shows that concept inference needs to be interleaved with type inference in a way that we are still only loosely grasping.
This is a place where LINQ allocates a lot, whereas this allocates hardly anything. We go at .75 the time even unspecialized. Also, the specialized version is twice as fast as the unspecialized.
It shows that if you open up for specializations to be plopped in, there's quite a lot to gain.
Conclusion
Some promise on optimization. Pinches of salt here and there. The approach definitely seems to have promise.
More tests to do.
Shapes
Concepts can tie in to the richness of expression in C# around different kinds of operations (operators, conversions, constructors...)
Interesting to consider whether there's more of a specialization relationship between concepts and instances, rather than a type/instance relationship.
If this went further, there's a very large laundry list.
Conclusion
We really would like to be able to do the post-hoc implementation of concepts. This