Okay, you want comments, I got yer comments...
I am, naturally, most interested in this part:
[24]RFC 16: Keep default Perl free of constraints such as warnings and
strict.
(Keep the groans to a dull roar, please.)
To me, one of the overriding issues is whether it's possible to
translate Perl 5 code into Perl 6 code. One particular place of
concern is in the many one-liners embedded in shell scripts here and
there. There's no really good way to translate those invocations, so
requiring a new command line switch to set ``no strict'' is not going
to fly.
I thought we'd made the point that we didn't expect stricture for
-e. Perhaps this speaks to shell scripts that do perl ENDOFSCRIPT. I
wouldn't call them one-liners but they would still suffer from
unanticipated strictness.
A closely related question is how Perl is going to recognize when it
has accidentally been fed Perl 5 code rather than Perl 6 code. It
would be rather bad to suddenly give working code a brand new set of
semantics. The answer, I believe, is that it has to be impossible by
definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6
must assume it is being fed Perl 5 code until it knows otherwise. And
that implies that we must have some declaration that unambiguously
declares the code to be Perl 6.
Okay, but if you can tell that you're parsing Perl 6 rather than Perl 5,
why not leave the default strictness the way it is for Perl 5 programs, and
turn it on for Perl 6 programs? New language, new expectations, chance to
make new rules. I keep coming back to the POD that says that the fact that
-w is not the default is a bug.
Now with one fell swoop, much of the problem of programming in the
large can be dealt with simply by making modules and classes default
to strict, with warnings. But note that the default in the main
program (and in one liners) is Perl 5, which is non-strict by
definition. We still have to figure out how Perl 6 main programs
should distinguish themselves from Perl 5 (with a ``use 6.0'' maybe?),
and whether Perl 6 main programs should default to strict or not (I
think not), but you can already see that a course instructor could
threaten to flunk anyone who doesn't put ``module Main'' at the front of
each program, and never actually tell their pupils that they want that
because it turns on strictures and warnings.
Sorry? It wouldn't just turn on strictures and warnings, it would change
the interpretation from Perl 5 to Perl 6... and there appear to be enough
clues about Perl 6 to deduce that one would know whether one was writing
Perl 5 or Perl 6.
And "module Main" would be a no-op except for the side effect... so might
as well say "use 6.0" instead since it makes the intent clearer.
I love the stuff about policy files.
I also happen to agree with this RFC because it's my philosophical
position that morality works best when chosen, not when mandated.
Nevertheless, there are times when morality should be strongly
suggested, and I think modules and classes are a good place for that.
This goes to the point. I could argue that I don't see strictures as
'morality', and I think that's just an accidental consequence of the name;
suppose it had been called 'use salvation' instead? But there's no way to
win a values debate.
--
Peter Scott
Pacific Systems Design Technologies
