Is interface
instantiation implicit driven by constraints as type classes are?
Until we start looking at how interfaces relate to type classes, the answer
is "no", because interfaces are always passed as explicit arguments. In
effect, they are just abstract classes.
I think this is an interesting line in C# / Java you rarely use inheritance
etc anymore but interfaces are becoming ubiquitous.
The argument of implementing "struct methods /members " easily porting from
C++ doesn't hold . You will be forced to redesign anyway since
- A lot of new C++ code uses templates
- C++ uses multiple inheritance especially in GUI libs
- You will need abstract classes
And hence to me this is better held over till v2 , there will be many
changes then , some strong parts will be enhanced others can be scrapped so
planning for it is not really worth it. We have some big unknowns on how
it will pull together.
I know I am repeating but the following are highly desirable as they blend
the C nature into type classes and hence make it easier to pickup the
language with little to no adverse affects.
1. Some form of interfaces ( even if type classes in disguise) and
Interface/ type class as a parameter not a constraint.
2. Some form of encapsulation on structs eg local functions .
3. Simplification of Type classes for new users ( eg interfaces above)
4. Specifying struct functions in a type class ( eg Has field)
The fact that most of the above can be implemented on top of type classes
shows it provides an excellent base , but Haskells lack of penetration in
many fields shows we should make them as simple as possible for new users.
Id like to see the interface proposal but sub classing type classes into
interfaces don't seem beneficial to me ( though it may be that many things
in a type class can not be represented as an interface so implementing an
interface would allow the type class to be used in that manner) . This gets
back to are multi param type classes useful.
Interfaces I have already discussed but moving the where to a parameter as
an option reduces code and makes it simpler even if there are a few corner
cases where a single param type class is not exactly an interface. IMHO
your not going to see these issues until you write a 50K app then it will be
apparent whether it needs some adjustments.
You can also get limited polymorphism using normal functions on structs eg
behind the scenes the struct function is just translated to a normal
function with the first param being an instance of the struct. The
compiler then gets the call site to just pass the reference to the struct in
as the first param without the programmer being aware of it. The
polymorphism comes in when it is used as a parameter ie the function (
ISampleInterface if , bool value ) is just the same as
Where hasField('a ,fn(do_something))
function ('a, bool value )
the compiler creates one copy of the function for every concrete type
that implements that interface and the call site just does a direct
function call. Modules providing new concrete instances of the type also
provide the concrete function . You could get chains of unknowns but they
can be resolved by tracing from main which bitc does. Obviously its not
true polymorphism and many things don't work like functions that return a
new instance of that type and hence "pull" dependency injection etc.
For these you would need a further form of indirection where the type is
looked up at runtime eg vtable , capsules etc but im not convinced it is
needed though I may change my mind In a large project.
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
