Jonathan S. Shapiro wrote: > wren ng thornton <w...@freegeek.org> wrote: >> If the former, does BitC have a special (efficient, non-allocating,...) >> way of dealing with other common combinators like 'flip', K, W, S,...? >> One of the major benefits of functional programming from a practical >> perspective is that we can define and use these combinators in order to >> clean up API integration issues. > > We don't. But I have no problems with having these operations and letting > them be allocating operations. I merely want to preserve a useful and > powerful subset language in which it is possible to have fully > non-allocating programs.
The reason I mentioned them is that if you have a non-allocating implementation of (.)/B then I'm pretty sure the same tricks would allow you to define non-allocating implementations for these other combinators. The I, K, and flip combinators should be easy. W and S might be harder because of sharing--- or rather, sharing in the face of mutability. > Perhaps it is a failure of my imagination, but I don't see writing > high-performance kernels with a functional idiom any time soon. The > functional idiom only performs because it can be aggressively optimized. An > implication of this is that the idiom *per se* is describing something > relatively distant from the machine behavior. To the extent that this is > true, it is a failing idiom for low-level systems programs. I'm not sure I agree. One of the principal reasons why functional programs can be optimized so aggressively is because of the focus on purity. Even impure functional languages have a large pure functional core which enables optimization. The purity=>optimizable theme is a big reason why everybody is starting to incorporate functional ideas today. Even, most strategies for optimizing horrifically impure languages like C rely on first translating that language into a functional form in order to expose the purities that allow for optimization.[1] I'll agree that the focus on higher-order functions may be at odds with low-level programming, but HOFs are only a part of what the functional paradigm is all about. Then again, HOFs are incredibly important to effective kernel programming--- provided they're implemented correctly. One of the main uses of macro systems like the C preprocessor is to add HOFs to an otherwise first-order language. [1] Ironic, since many optimizations for functional languages rely on taking advantage of the horrific impurities C offers :) Then again, that just means there's a time and place for everything. Most performance bugs come from programs being too strict ...or too lazy. Either one can kill you, and for the same reasons. -- Live well, ~wren _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
