On Mon, Jan 6, 2014 at 4:29 AM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sat, Jan 4, 2014 at 5:57 PM, Ben Kloosterman <[email protected]>wrote: > >> In most cases interfaces will stll be slower when you use them in a >> polymorphic manner. >> > > That's a whole lot less clear than you might think. > > A responder on LtU pointed out that TCs provide compile-time polymorphism > where interfaces provide runtime polymorphism. That much is clearly true, > and I think you're assumption about performance is being driven by that. > > But the reality is weirder than that, because BitC doesn't have virtual > functions. Here's why that matters: > > While interfaces encapsulate existentially, there are many many cases > where the underlying existential type variable is externally known. When we > see: > > ObType ob; > ... > ob *as* SomeInterface > > > we can type the result as (making up notation on the fly): > > SomeInterface *on ObType* > > > The "on ObType" part is additional information that we are free to forget > at any moment. But wherever we still *have* this information, we are free > to do compile-time specialization in exactly the way that we would for type > class instances. > Agree about most cases but but the polymorphic runtime case is exactly when you want interfaces and you wont be able to determine it. Also how deep does it go eg when you have DLLs and your propagating ICollection which then becomes IEnumerable . And of course, if we have a JIT system, we can do polymorphic inline > caching for this. > Yes. A lot depends on the runtime... > > And finally, code explosion isn't free, and one of the dark consequences > of type classes over unboxed types (or, indeed, boxed types) is that they > induce code explosion of epic proportions, in much the way that C++ > templates do. Unlike C++ templates, we can't exploit our ability to break > the type system to produce common implementations of the common cases. > > If prototyping or writing smaller single exe apps than you may as well >> just use type classes. >> > > Good thought. > Consider this though , why is Haskell often used to protype something which is then rewritten in C# or C++. Is it purely the soft factors like lack of skills ? Or is there more . > How should this thought be guiding me as a *library* author? What I'm > really asking is: what assumptions should a general library author be > adopting? > Well one thing im struggling with is interfaces are more loosely coupled than classes but im not sure about type classes. They can be loosely coupled , esp through HasField but it may not be depending on the amount of code exposed , "pure /scientific " concepts like Eq and Ord create loose coupling but more vague business concepts like Account will quickly degrade. - Interfaces are a form of modularization , your lib fascade(s) is a great contract and more flexible than module scopes . ( The publically exposed parts of a module can be seen as an interface) - For each object /type you expose you need to hide the internal representation. - A springling of Interfaces will result in less code explosion as your isolating parts of the program. A interface cant normally give a type relation eg GetABC() is an object ( value or reference) not a type class. Hence there will be a break in type class propogation, - Scientific / Programming libs with pure concepts should prefer type classes with a possible fascade. They concept wont change. - More loose concepts where things change frequently and may be irrational / difficult to determine like a business logic DLL should use interfaces . In business apps you dont have time to get the essence of the problem. I think the last 2 points may be the crux of the problem. The only performance consideration i have is code explosion . Im sure as the language matures these performance points when to use what will get more clear , but i dont think its that relevant . I do like keeping type classes fast ( except for code expl..) because you can expose raw data and run functions over them so no cost , this is much harder in the interface approach as the methods are part of the interface. You may get to raw performance but you cant beat it. Expanding more in Java /C# right now you have interface methods like ABCObj GetSomething() , in our case many more of these ( when your not dealing internal to the module) will become IABC GetSomething() since we dont want to expose an unencapsulated object. This is good programming anyway but it may eat a lot of gains. > >> If you care about security / POLA you will prefer interfaces. >> > > I'm not clear here why one is better than the other. > Well i can see an encapsulated interface ( at least when its wrapping a ref object - not that it matters) is an oCap. I dont see that for type classes with entities. When your working with type classes your entities will become more exposed. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
