On Wed, 2008-03-12 at 18:03 +0000, Sam Mason wrote: > OK, I didn't realise it was doing this. It'll be fun/awkward writing > code that doesn't do any heapification then :)
We have in mind to build an audit tool for this, so that code can be annotated as "should not allocate" and a checker can test this. > I've also just thought of > another issue with mutable by-refs, I think it's going to make auditing > harder? Take the following function: > > (defun (f x : (mutable int32)) > (g x) > x) Yes, there is definitely an auditing issue here. That is a real concern, and an important one. So let's look at that, and look at the alternatives. First, note that the issue only arises for (by-ref (mutable T)). If the reference type is immutable, no audit issue arises. The problem with *removing* BY-REF is that we have many cases in practice where we have some very large structure and we need to initialize or update some part of it. For example, in the Coyotos kernel we have lots of structures that contain capabilities, and we "prepare" these frequently. Our options are: capSlot := prepare(capSlot) ; pass by copy or prepare(capSlot); pass by mutable reference Unfortunately, the performance advantages of the second are quite overwhelming. This seems to be a case where there is an unavoidable tradeoff between performance and audit, and in this case I think the argument in favor of performance is quite strong. And going back to an earlier discussion, somebody suggested building an audit tool that annotates associativity to support audit. That's not a bad idea at all, and it could be done for this type of thing as well. Fortunately, the declaration of the called procedure must declare itself to be BY-REF. In that sense, there is nothing "hidden" here beyond the usual considerations of lexical scoping. > How do I know, without looking at it, whether g is going to change > the value of x. Without by-ref's, I know that it can't---it can only > change it's own private copy. I thought this was a big complaint of the > similar feature in C++. I can't speak for others, but that isn't the complaint in my mind. The complaint in my mind is that C++ references are supposed to be guaranteed to be non-null, but the language doesn't actually enforce this, and it's fairly easy to get a dangling C++ reference. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
