Possible, yes. Worth the additional combinatorics in the possible effects a function can have? Not as clear, to me anyway.
Without effect polymorphism -- which is nice in principle but can be hard to keep lightweight enough to be usable -- each effect you add to the language increases the possibility of code duplication for polymorphic functions. (For example, you end up with a version of `map' for each possible combination of effects its function argument could have.) We may well have to consider effect polymorphism eventually, but IMO each effect we consider adding to the type system really has to prove its worth. I guess more to the point, if blocking ends up being a pretty rare thing in idiomatic Rust, programmer discipline may be perfectly sufficient to manage blocking, without the need for checking in the type system. Oh, and another alternative, at least for monomorphic types, would be to express blocking as a predicate and enforce it via refinement types. For polymorphic types, it would have to be more like a type class. I know Marijn has been talking about type classes, but Patrick and I have our reservations, and I imagine Graydon may too. Dave On Mar 11, 2011, at 11:23 PM, Peter Hull wrote: > On Fri, Mar 11, 2011 at 4:47 PM, Graydon Hoare <[email protected]> wrote: >> On 11/03/2011 3:16 AM, Marijn Haverbeke wrote: >>> >>> Related to this, are library functions allowed to block, or will that >>> hold up all tasks? >> >> Yes, but it should be done very judiciously, isolated to particular >> functions that are understood to do so. Not just blocking willy-nilly. > Would it be possible to have a blocking 'effect' (if that is the right > term) to mark functions that may block (works like impure does) Then > the compiler could warn. > > Pete > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
