81 lines
2.5 KiB
Markdown
81 lines
2.5 KiB
Markdown
|
# 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"
|
||
|
|
||
|
1. LINQ
|
||
|
2. 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 `AssociatedType`s, 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
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|