On Sun, Jan 5, 2014 at 9:34 PM, Ben Kloosterman <[email protected]> wrote:
> On Mon, Jan 6, 2014 at 4:29 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> > 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 . > Maybe because Haskell fans suffer from a high degree of optimism? :-) Admit it, you walked in to that. But this is interesting. How many prototypes like this are done deliberately, and how often are they more than a convenience decision by a single individual who happens to know both languages? Expected answers: rarely, and never. That is: this prototyping decision rarely reflects the planned intention of a development team. OK. I know somebody is going to pick on me now about Galois. And I actually do know of a couple of other groups that do highly specialized programming that have adopted similar practices. But that's 25-30 folks globally. > > >> 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? >> > > - Interfaces are a form of modularization. > Yes. But more generally: - Polymorphism is a form of modularization - Existential encapsulation is a much stronger form of modularization. I think Keean on LtU said it very well. If we set aside the existential encapsulation for a moment, then TCs are compile-time polymorphism where Interfaces are run-time polymorphism. That's actually a very good way to think about a lot of the question. Further, it's a nice boundary to be able to straddle, because the presence of both capabilities in the languages means that the programmer can explicitly trade off code size and run-time dispatch. , 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) > Indeed. In fact, the main differences between an interface and a module are: - a module has exactly one (static) instantiation - a module can export a symbol whose type is something other than function. > 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. > Point taken. For my part, I like the fact that I can do a covering TC instance forall 'Type IMPLEMENTING TCRelatedInterface TC instance 'Type { ... implementation relying on 'Type as TCRelatedInterface ... } and then do specialized instances where performance requirements motivate the code cost of inlining. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
