@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
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
lus you could do stuff like impl the interface by extension methods, or on static types or sum types
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
We're thrilled to announce that the Russian-speaking community of software developers and programming enthusiasts, Stack Overflow in Russian, has been graduated. Congratulations colleagues for such incredible success!
The plan is that at the root level type :< interface {...} allows you to do it at the type level. The compiler will then make sure all of the functions are implemented somewhere
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
When you say method level interface declaration, what do you mean? I thought I understood, but you seem to be describing something different, and I can't imagine a way that would work.
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
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
This is probably a greater problem with the IL than anything because it requires class definitions to state their contracts huh?
Think again about type classes and how the type never states it's type classes- well I guess the derives is a nice feature but totally unnecessary
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 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
ould do that inside a class or outside
nstance IFoo {}
ested I the class, outside you do istance Bar is IFoo
r some syntactic indication that's nicely fitting the rest of the language
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
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
Imagine static XmlConfigReader vs DbConfigReader being passed swappably or other such
The Whiteboard
The Whiteboard