Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
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.
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
On 2008 May 17, at 4:10, Carl Mäsak wrote: 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. The compiler should in fact assume that is ro is a hard fact; if the programmer chooses to override, on her own head be it. Examples using other existing languages: GHC doesn't compromise its optimization rules just because someone might be using unsafePerformIO (this is in fact quite similar as unsafePerformIO means a presumed read-only expression can vary at runtime) or unsafeCoerce#. gcc doesn't compromise its just because someone might use an asm() to do something naughty where the C / C++ layer can't see it. Etc. I also came to think about this relevant quote from Jamie Zawinski: Java is a remarkable example of how to do it wrong, for many values of it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
Carl Mäsak wrote: ] 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. I'm pleased to note that you made my point for me. Sure, you can sneak in under the covers of the JVM and compromise the immutability of its final data. But you do have to sneak in. And when you do, and things go belly up in interesting ways, or worse continue to run but produce mysteriously wrong output, don't go running to blame either the Java spec or the JVM. Their writers made their optimisations, and the proofs of correctness of those optimisations, and proof of correctness of the entire system, based upon the specification of final. You hack it. Your problem. But, if you add *is ro* to the P6 spec and then specify a way for users to ignore or turn it off, and you render it entirely worthless. Indeed it's worse than worthless because it is extra complication for no benefit. If it doesn't allow the compiler writeres to make any extra assumptions, it's just tying up space in symbol tables, consuming cycles in the parser, and most damningly, mindspace in the spec and users. If you add it to the spec. Mean it. If you don't mean it, don't add it. If you mean it, but it doesn't initially get implemented that's fine. Someday it might and someday we might benefit from it. Add it to the spec whilst offering a way to ignore it and you've wasted everyones time. b. --
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
John M. Dlugosz wrote: Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote: Pm (): In Rakudo's case, we just haven't implemented read-only traits on variables yet. Goodie. I guessed as much. But yes, I expect that it will be caught as a compile-time error. And do you agree it's reasonable to expect this of every compiler? // Carl I think that is the point of declared types. But, something like no strong_type_check :rw in scope can turn that off, in case you want to play dirty tricks. What is the point of be able to mark things readonly if the compiler does reject assignment attempts? What is the point of marking things readonly if you can turn it off? --
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
Me Here (), John (), Carl (), Patrick (): But yes, I expect that it will be caught as a compile-time error. And do you agree it's reasonable to expect this of every compiler? I think that is the point of declared types. But, something like no strong_type_check :rw in scope can turn that off, in case you want to play dirty tricks. What is the point of be able to mark things readonly if the compiler does reject assignment attempts? Oh, as long as you predeclare that you're breaking the rules, I'm fine. We're not making stuff impossible just for the heck of it -- this isn't Java. 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). // Carl
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
On 2008 May 15, at 1:30, Me Here wrote: John M. Dlugosz wrote: no strong_type_check :rw in scope can turn that off, in case you want to play dirty tricks. What is the point of be able to mark things readonly if the compiler does reject assignment attempts? (assuming you meant doesn't) What is the point of marking things readonly if you can turn it off? Documentation. Backward type-API compatibility. I am unsure at this point if this applies to Perl 6, but in Haskell it is possible to do in-place update by diving into IO behind the scenes with (read-only by default) data structures. In this case is ro would be a reminder that the caller has expectations that you must be careful not to violate while you're working behind the curtain. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
Carl Mäsak wrote: 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). // Carl 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. 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. 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. 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. b. --
