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'


Reply via email to