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
- 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)
- 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