Front page | perl.perl6.language |
Postings from May 2008
Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote: > Reasonable to expect it, yes -- but whether or not this rises to the > level of being a "requirement in the spec" may be a different matter. > > I could envision the possibility that some otherwise-very-capable > Perl 6 implementation might be better served by having such checks > performed at runtime (they have to be done there also) and leaving > compile-time checking as an optimization. I suspect this is what > Pugs did. Or an implementation might not have a clear-cut notion > of "compile time". > > So, as long as the assignment is properly prevented, I think that > may be sufficient. (If the language designers decide otherwise, > that's okay with me too. :-) > I'm interested in drafting standardeze verbage to specify these kinds of details, and that is one of the issues. In general, optimization level can change what is caught at compile time. It is certainly possible to define the meaning unambiguously, regardless of whether it is "compiled" per-se. This is really interesting once you get into generics where the implementation =might= specialize the code in advance or =might= do all run-time checks. It is important to understand what range of behavior is allowed, guaranteed, and disallowed in order to write portable code. In the case of assignment to a variable declared as read-only, there are clear "episodes" (to use my nomenclature thus far) of processing a block. There is definitely a time when it digests the statement and would only execute it if it was a BEGIN block, otherwise it files it away for later. The filing away might itself be to another episode. But there is a sequence point (using the term without precision as of yet) before it digests the next statement. It should fail at this point, with an allowed range of side-effects due to the running of the grammar etc. at compile time, but clearly not running the code that's being analyzed. Clearly if there was a BEGIN block it would have already been done and cannot be undone. Likewise, when are exception handlers brought on line, =exactly=, in the sequence of things? Lots of details. --JohnThread Previous | Thread Next