The thing to remember is with typeclasses i- interfaces are only concerned with methods, not types. This opens interesting ideas like you could impl one on a static type and pass those around through genericconstraints as Type T because they aren't instances - but then you get swappable static calls
The. More i think about it the more I realize I'm just describing type classes because you can impl there instance in the type def too with certain syntax similar to the instance syntax outside the type def
You could have a syntactic structure demanding a grouping of interface methods so you expect them all in one place for each interface- like the instance creation in Haskell
You can just create interface impls for any type anywhere. The compiler just has to verify if one method says it imls part of a contract that after all is parsed it can find the rest of the contracts parts to match that one part
You would get rid of the interface|sum type confusion in the grammar, and make extension methods and Su types able to tie a type to a contract with identical fashion as the class internal impl approach so it would be consistent across the board
You know how on explicit interface impl in c# you annotate a method to say it impls Ifoo.Bar? Imagine that without the class annotation for the interface
Iduno, I would prefer the consistency of only method level interface declarations so for all types and techniques- in or out of the actual class impl, on a Su type or not, it's always done with the same method annotations only
You could use that operator at method level for them to dictate they're adding a piece ofa contract. Have to check they completed the whole contract at compile though
You could even then implement the interface on methods with different names than the interface dictates by having them say they implement IFoo.bar while being named baaz
@Telastyn cool blog, though the thing I love about typeclasses is it decouples the interface definition from the type implementing it. You might ponder putting the interface on the methods instead of the class- like how in C# you can do explicit interface implementation where the method says its fulfilling part of an interface- having a note on the method and not on the class itself. This would also clean the grammar where you have sum types at the top of the class
@BarryTheHatchet sure, but your fork will be promptly ignored; you don't get a say. That's the whole point. You get to pick from the list, but not create it.
@AaronHall and now you know. Control the chunks ftw. Anytime I have to deal with that sort of crap I typically find myself making chunk sizes configurable because different input sets always end up working best with differing chunk sizes
It's exact same concept as a file-based merge sort which is what a merge sort is for: sorting large amounts of information when you've got very little memory to hold it in
