Me Here (>), Carl (>>), Me Here (>>>): >> > What is the point of marking things readonly if you can turn it off? >> >> There are many possible reasons, I think. >> >> * The code that declares the variable readonly might not be available >> to you (compiled to bytecode, fetched by RCP etc), >> * or it might be available but used by other clients which expect the >> variable to be read-only. >> * You might be writing a one-time hack, which can be done the easy way >> by turning off read-only checking. >> * You might be writing test code, which is greatly simplified by your >> just reaching in an changing the damn thing. >> >> In short, I have no problem with _turning off_ read-only checking. >> That, I think, can be done on a suit-yourself basis. >> >> I'm arguing for having read-only checking at compile level (which >> everyone seemingly agrees on), and spec-requiring of a compiler to >> check this (and here opinions divide). > > And that pretty much sums up about half of the traffic on this list. > Speculative considerations of theoretically possible scenarios without > any consideration of whether they would ever actually arise. Or be > useful if they did. The result is a spec so complex that there is > almost no chance of verification against it, even if enough people > understand the intersection between all the speculative what-ifs and > the few more concrete 'will's and 'must be's, to actually come close to > implementing it.
I'm sorry you feel that way. On my part, I've always been amazed that the spec documents have been kept current and open in the way the have the last few years. That's a brave way to develop a new language. Naturally, there's always the risk that the spec grows too complex due to a "many chefs" phenomenon, but by and large Larry et al seem to have the opposite effect, distilling the best from the obstreperous opinions of perl6-language into precise spec-lingo. Some on the list want theoretical rigour, some want practicality. The spec often ends up disquieting very few. Maybe you're confusing the discussion here on perl6-language with the spec itself? (If not, do you have any specific places in the spec which you find unclear, overly complex, or unverifiable? I'm sure people would be grateful to hear about them.) > Perl made it's name by adopting the useful, pragmatic parts of other > languages, and leaving out all the abstract, purely theoretical and > only useful to one-legged, six-fingered theologians on wet Wednesdays > in October. > > Sometimes it's a good idea to return to the beginning and ask yourself > why do we want this feature in the first place. Sure! The RO-ness of variables seems a point of agreement between us. It's whether one should be able to switch it off with a pragma that's up for discussion. I made a quick grep through the Perl 5 @INC directories on my computer and found 263 occurrences of "no strict 'refs'" in various CPAN modules, core and non-core alike. Everyone knows that strict 'refs' is a good thing, but some things are possible or just plain simpler without it. I suspect the same will be true of RO variables. > What does adding the ability to mark variables or parameters RO by the > programmer using the language? > > In Perl 5, people are beginning to jump through hoops in order to > achieve encapsulation that cannot be subverted. Giving > module/subroutine users the ability to ignore the authors mutability > annotations makes them worthless. I see where you're coming from: it's the idea that the one who wrote the module you're using knows best how to use that module. It's also the idea that programmers should not be given tools that might be used for bad things. Now tell me this: given that Perl 6 will be a multi-language/changeable environment, wherein people will be able to switch to a language/dialect without the RO restriction if they so choose, and given that at some point, someone _will_ want to change a RO variable (for the reasons I listed above), which one do you prefer, the circumnavigational hackish way through a language with different rules, or a pragma? > What does adding the default assumption that subroutine or method > parameters are RO buy the language implementor? > > This provision could be used my the language implementor to achieve > some extra level of efficiency by allowing them to hoist RO values into > registers; avoid locking of RO values in threaded environments; perform > compile-time constant folding and expression substitutions > (term-rewriting); and similar. The moment you allow the RO annotations > to be overridden at either compile-time or runtime, those optimisations > go out the window. > > In other words, if you allow RO annotations to be overridden, all the > benefits that could accrue from having them go out the window, so you > might as well simplify everyones life and discard them all together. > Now maybe that's the way to go. Historically, the few places where the > readonly attribute is applied in Perl 5 it tends to create anomalies > and rarely improves performance. But if you are serious about providing > the facility, don't go screwing it up for the benefit of the six guys > in the world that could count their number on one hand, on one of four > days a year when the sun might shine anyway. Whether we're risking the loss of important compiler optimizations by allowing overriding of variable RO-ness is not for me to say, that's up to the compiler writers around here. It seems to me you make it sound worse than it really is, that optimizations can still be made in many cases, and that a programmer who turns off RO stricture simply takes a calculated risk. Perl is a lot of things to a lot of people, and Perl 6 will be that too. Favouring simplicity before being everything to everybody might be a noble goal, but it's not one that Perl has taken often. :-) I also came to think about this relevant quote from Jamie Zawinski: <http://www.jwz.org/doc/java.html> (]): ] System.in, out and err (the stdio streams) are all final variables. ] They didn't used to be, but some clever applet-writer realized that ] you could change them and start intercepting all output and do all ] sorts of nasty stuff. So, the whip-smart folks at Sun went and made ] them final. But hey! Sometimes it's okay to change them! So, they ] also added System.setIn, setOut, and setErr methods to change them! ] ] ``Change a final variable?!'' I hear you cry. Yep. They sneak in ] through native code and change finals now. You might think it'd give ] 'em pause to think and realize that other people might also want to ] have public read-only yet privately writable variables, but no. ] ] Oh, but it gets even better: it turns out they didn't really have to ] sneak in through native code anyway, at least as far as the JVM is ] concerned, since the JVM treats final variables as always writable to ] the class they're defined in! There's no special case for ] constructors: they're just always writable. The javac compiler, on ] the other hand, pretends that they're only assignable once, either in ] static init code for static finals or once per constructor for ] instance variables. It also will optimize access to finals, despite ] the fact that it's actually unsafe to do so. // Carl
