On 2017-05-07 11:21, Dmitry Olshansky wrote:
But in this case I'm afraid that we end-up with the same noise as for the newtype. But instead of construct to and deconstruct from newtype we will have to define aspects on type level for caller and define constraint for function. Usually type-level syntax is more complicated...
On the one hand, I get what you're saying. I'm not sure I'm totally convinced my idea is bad because of it, but I'll ponder that. On the other hand… in a way, we're working with two programming languages, a value level one and a type level one. And you're right that the type level programing language can be quite obtuse, even without my proposed additions. But I don't directly see that as an argument against my proposal. It's more of an argument to straighten out our type level language. I mean what is our type level language? It's basically a logic programming language that guides a constraint solver. We state facts and relationships, and we get an "ok" or errors and as "side effects" we sometimes get dictionaries. Now look at Prolog and how simple it is. Our language is more specialized, so we have more specialized operators. But that alone would only make the language more complex, not necessarily more complicated. In an ideal world I would also just be able to use existing tools of our type level language to implement my additions. Right now I can't, so something is amiss. To be honest I don't have any idea how to fix this. And as long as we don't, your argument against my proposal is indeed valid through this indirection. But I'm not happy that it is… Cheers, MarLinn