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.

--John

Reply via email to