2010/8/9 Jonathan S. Shapiro <[email protected]>: > So the truth is that we don't know. As a matter of language design, BitC > straddles this fence. But as a matter of library design, my strong suspicion > is that the two idioms do not mix well for reasons of non-composability. If > that turns out to be correct, then the user base will ultimately converge on > one idiom or the other. I just don't know which one.
Peter Van Roy and Seif Haridi, in their book "Concepts, Techniques, and Models of Computer Programming", seems to me to defend the composability of functional and imperative styles. As if we were just in the beginning of programming history, and many kinds of programs were simply inaccessible to us because we insist in attacking them with a single paradigm at time, while a "bridge" between them is just hard to spot. But let me change the subject: how their "dataflow concurrent programming" could be supported in BitC? They have a very neat semantics where whenever a unbound variable is referenced, it's no error in itself and the program stops to wait for it. It's maybe inappropriate to express it directly in a language with first class mutability, but maybe a "dataflow variable" type in the standard library would be nice (like, with a operator to wait for it), maybe with some syntactic support. (Like OCaml's implementation of lazy evaluation, where they have a keyword for creating them, and a function for forcing. Actually, this kind of lazy evaluation seems nice for BitC, too) -- Elias Gabriel Amaral da Silva <[email protected]> _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
