All I could think was, "good thing the 3rd Camel came out before Larry
used it to classify RFCs." :)
I am glad RFC 141 was rejected, even if Larry claims it was for
entertainment value. For the same reason people feel the need to explain
the use of "apocalypse", the design of Perl 6 should not focus on being
the final "thing", even if everyone believes it will be. This would rob
Jon of future tantrum opportunities.
I was very glad to see Larry address RFC 28 in the way he did; this will
be quoted often in the future, both concerning being "needlessly fearful"
of Perl adopting a different language paradigm, as well as the "essence"
of Perl being context sensitivity ("Perl culture, Perl readability"
threaders take note).
The example suggestion about breaking the @foo -- $foo[] relationship is
a perfect indicator of where he sees this going: breaking some behaviour
to gain consistency in context treatment. I think such "courage" as he
puts it is absolutely worth the benefit. I want to see more paragraphs
like this in future documents; they really give a glimpse into what he
wants to happen.
I agree with what has been said regarding the "package" vs.
"module/class/blah" 5/6 differentiation. Keep it simple. It won't be long
before we (I) scoff at a module starting with "package" the way we (I) do
now with "require cgi_lib.pl;". Kidding.
I think there is much discussion to be had concerning RFC 73, regarding
Larry's suggestion that core functions return objects that are struct
tm's. I'm wondering what Chip thinks about this. Also, I'm wondering if
the intent of the RFC was what Larry describes. References to 48 suggest
list, array, arrayref, hash, and hashref contexts, in addition to scalar
and string. Does Larry feel that all of these are important? I guess we're
not talking about 48, though. :)
