Damian Conway writes: > It's Sunday evening and, as promised, here's the new draft of S26.
Wow, thanks for that -- it's most impressive and I'm already excited about what it will allow and how it permits improved documentation. > * Hence it must always parsed using full Perl 6 grammar: perl6 -doc Having a multi-character option preceded by a single hyphen doesn't play well with bundling of single-character options (such as perl -wle in Perl 5): * The above looks like a bundled version of -d -o -c. That some of those don't exist doesn't affect that impression: it isn't reasonable to expect a user to know all options before she uses any of them, so if she's seen some single-letter options but doesn't know about -doc then she will misinterpret -doc. * In order for -doc to work, 'long' options have to trump 'bundled' options with the same spelling. If a version of Perl 6 introduces all of the -d, -o, and -c options then -cdo, -cod, -ocd, and so on will all be synonyms but -doc will be completely different. Putting arbitrary restrictions on bundling order that aren't related to the options themselves is an irritating cognitive load: if you're adding the -c option to a program that already has -do it matters where you put the "c". * If long options with single hyphens are permitted in general then a future version of Perl 6 may add new ones. That means that _no_ single-character option bundling is safe to use from a forwards compatibility viewpoint, because any sequence may become a long option -- and hence radically change semantics -- in future. Using double-hyphens for all long options disambiguates them from bundled short options, and is familiar to many users from other software which follows that convention. Indeed others (including S19) already seem to believe that two hyphens are needed: jerry gay writes: > this is why it's spelled 'perl6 --doc' Smylers
