On Wed, 2008-08-06 at 17:12 -0400, Jonathan S. Shapiro wrote: > Collectively, these statements seem to suggest that an impure procedure > can *always* be passed where a pure procedure is expected, *provided* > the expression evaluation is not occurring in a pure computation > context.
(I actually see a contradiction with the previous part of your email, but I'm gonna take this paragraph as if you meant it) Maybe that's a case you are taking into account above, but what about a pure function used in a multithreaded context? One important thing about pure functions, besides sequential optimizations (call only once for a given set of arguments, reordering), is that you have a guarantee that there will be no need for any kind of locking. A dynamic library might want to know that it is given a pointer foo to a pure function (say a multithreaded map over a complex structure, running foo() in different parts of the structure at the same time). In this context, it would be good for the type system to infer pure. For these reasons I do not agree with the statement that an impure function can always be used where a pure function is expected from the point of view of the type system. (That statement being obviously wrong from the point of view of optimization, but we all know that.) This is also one of the reasons why the whole mutable/const debate matters: immutable by default is useful in a multithreaded context: it focuses the attention on the mutable structures, when looking for locking/sharing issues. Also, you might want to consider extensions/reuse of BitC in the context of hardware synthesis: there is a lot of work these days to use C there, and one can only imagine that BitC will be used for that as well. In this context, pure functions are central as they are straightforward to turn into a circuit. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
