Larry Wall wrote:
Well paint yourself unchagrined, because S04 sez:
Parameters are by default constant within the block. You can declare a parameter read/write by including the "is rw" trait. If you rely on $_ as the implicit parameter to a block, then then $_ is considered read/write by default. That is, the construct:
for @foo {...}
is actually short for:
for @foo -> $_ is rw {...}
so you can modify the current list element in that case. However, any time you specify the arguments, they default to read only.
< gets out unchagrining paint and splashes it about. :-) >
You know, the amazing thing about those Synopses and Apocalypses you wrote is that no matter how many times I read them, I always find 5 new things in them on each pass. And I'm the kind of guy who typically absorbs entire 200 page reference manuals in one pass. I swear you found the English equivalent of Quantum Mechanics in there, where entire paragraphs exist and don't exist at the same time, without changing. :-)
Of course, I now have to question the need for C<given>. Other than linguistics, which is not to be dismissed, what difference is there between
given $expr { ... }and
for $expr { ... }with equivalent ...'s?
hmm. Come to think of it, the C<for> would flatten $expr if it happened to look like an array or something equally "bumpy", where C<given> would not. But perhaps it would make sense to define C<for> and C<given> as synonyms in all other ways but "autoflatten".
As far as linguistics go, "for" makes a suitable replacement for "given" in my head. It's just a very heavily loaded term when you leave English and enter CS-speak.
-- Rod Adams
