On 11/03/2011 11:35 PM, David Herman wrote:
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.
Yeah, we're going to have to have some serious conversations about
effect polymoprhism in the near future. Like when the effect-checking
pass for rustc gets written. I'm worried that a proper treatment will
cause too much cognitive load, wind up sinking (or seriously wounding)
the effect system. That'd be a real shame, if so.
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.
My guess is it's *almost* synonymous with the unsafe effect, which is
carried by every native (C) function. Since we are never going to be
interrupting / de-scheduling a C call in flight, they're all "blocking"
until they return to rust. The only question is how *long* the C call
blocks.
My further guess is that the set of C calls you'd want to 'auth' the
native effect on -- scrubbing them of the effect -- is about the same
set you'd want to mark as non-blocking. This is all pretty hand-waving
though. We'll have to see how it shakes out in practice.
Also depends a lot on the idiomatic I/O interfaces we wind up leaning
most heavily on. We haven't discovered or chosen those yet.
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.
My main reservations are that (a) I don't understand typeclasses very
well, and (b) they'll add to the cognitive load of the language. Pretty
broadly.
It's clear to me we're a bit too weak, expressiveness-wise, in the
dialect we're writing rustc in. Too many bits of verbosity and/or
awkwardness. But I want to explore the options for improving that in
order of cognitive "cheapness":
- Enhancing the obj and fn constructs (self, narrow/extend, lambda)
- Exploring a 'simple' static self-type dispatch system as we've
been discussing. Moral equivalent of C++ non-virtual methods.
- Maybe some kind of richer overloading or typeclass scheme.
It's not clear to me that we'll need to get to stage 3 on this list
before the language is "comfortably" expressive. I'm really hopeful
we'll be ok with #2 or less. I don't want to shoot for the stars here,
in terms of expressiveness. Doing better than C or Java, sure. But no
need to try to show up Haskell, Lisp, Forth or APL. There are other
matters in direct trade-off that matter more to me.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
