On Sat, Jul 27, 2013 at 10:18 AM, Jonathan S. Shapiro <[email protected]>wrote:
> And yes, if I did, I would actively remove Rust's current pointer
> mechanisms. At present, they are poorly designed and framed, which is
> causing so much confusion that even the Rust team is making bad decisions
> grounded in that confusion.
>
That reads very harshly; probably more so than is fair. Graydon *et al* have
made an interesting attempt to simplify a rich heap semantics into
something they felt users could understand more easily. In doing so, I'm
sure they were aware of languages like Cyclone that failed to make more
general solutions palatable. The question is *why* were they unpalatable,
and that's a judgment call. Graydon and I have different views.
But one thing I feel pretty confident about: if the pointer types in your
language are confusing the users, then either (a) you've got them designed
wrong, or (b) you've got the wrong defaults. Personally I think that Rust
suffers from *both* issues. Unfortunately, I think that in deciding to
remove GC from the language they are removing the part of the pointer
system that is general-purpose, coherent, and explicable, and committing
themselves to the part that currently consists of complex and non-connected
corner cases. I think it would be better to (a) test the degree to which
sigils *per se* are the problem (as opposed to keywords) (b) test the
degree to which effects and inference in the context of a coherent region
system make prescriptive typing unnecessary.
But it has to be said that *expressing* all of this stuff is a major pain,
and that introducing the keywords to talk about this stuff has a way of
making code unreadable to even expert programmers. This may turn out to be
an area where IDEs are critical. As I mentioned a few minutes ago, the *
semantics* of the program isn't tied to its allocation behavior. And this
leads me to some random thoughts:
1. When I'm focusing on getting an algorithm right, I may actually want the
IDE to hide the pointer class annotations from me, because they are a
distraction.
2. Since we are really talking about effects in this case, I probably want
to start by specifying an effect on the function ("NoGCAlloc") that
requires the inference engine to check for me. I probably shouldn't start
annotating pointers until the inference mechanism can't satisfy the effect.
But that's going to bring us into the user-perceived cognitive overload of
a general effect system, which may actually be worse than the pointer
classification problem in terms of its intrusion on the programmer.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
