I don't think virtual functions are great at all , a lot was promised and it hasn't delivered on many of them
What I suggested was more syntactic sugar to make it easier for developers and for struct methods to make sense by making it look like an interface/abstract class but not actually making it one. I still think there is a roll for relationship style type classes but only for the advanced lib writer. Ie the system still uses type classes as now , but type classes are broken down into single and multiple mainly so some features are allowed in some contexts but not others eg a multi parameter type class makes no sense as a function parameter. The single variable is allowed to be used as a type but this is merely syntactic sugar ( you can still use the old where notation and a single compiler parse will convert these type class parameters as parameter constraints). Single variables also support member functions . Multiple parameter type classes remain as now though we could consider a relationship based notation as mentioned. The alternative syntax suggested ( which may be optional ) will make it easier to use with the type classes behind the scene so we get an escalation in learning eg a c dev may progress as follows - uses the standard lib which looks like inheritance to him - develops his own single variable type classes and uses them - extends the standard lib classes - learns more about multi variable type classes through exposure in the standard lib - starts using mixfix/infix and multi variable type classes. Implementation should be simple, a single parse converting single parameter type classes as types to where clauses and some support recognizing member functions passing the struct in by default ( note member functions returning a different ( but single) type class is "interesting" . eg they would allow a standard collection iterator for collections ) . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
