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
