> Moritz Lenz wrote (on perl6-compiler)
> Patrick R. Michaud wrote:
> >> +S02-builtin_data_types/num.t
> >> S02-builtin_data_types/type.t
> >> S02-literals/autoref.t
> >> S02-literals/hex_chars.t # pure
> >> S02-literals/radix.t
> >> S02-polymorphic_types/subset-code.t # pure
> >> S02-polymorphic_types/subset-range.t
> >> +S03-operators/assign-is-not-binding.t
> >> S03-operators/autoincrement.t # pure
> >> S03-operators/comparison.t
> >> S03-operators/context.t
> >
> > In the test suite, could we perhaps aim for some
> > consistency on the use of hyphens versus underscores,
> > or at least articulate when one is used versus the other?
> > For example, "assign-is-not-binding.t" versus "hex_chars.t"
> > in the above.
> >
> > Personally I vastly prefer hyphens to underscores,
>
> Same here. Since the directly names already match m/^S\d\d-/ I'll
> assume
> that will be our standard.
>
> > but I
> > suspect people have good reasons for preferring underscores.
One reason (probably not a good one) is to use the same
convention as programming language variable names (which is
typically more of a "CamelCase" versus "not_Camel_case" issue).
Likewise, I suspect some people would also prefer hyphens to
either {underscores or CamelCase} in variable names as well (as
in Lisp).
So would a user-supplied Perl 6 syntax-morphing module to allow
use of embedded-hyphens in variable names (and other names, such
as labels and subs) to Perl 6 (with minimally-sane adjustments
needed to make hyphen-related operator parsing unambiguous) be
reasonably feasible? Or does this open a messy Pandora's box of
cascading language-redesign kludges?
(I suspect similar issues came up in language design discussions,
but my initial searches didn't turn up anything directly
relevant.)
Best regards,
Conrad Schneiker
www.AthenaLab.com
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Official Parrot Wiki - http://www.perlfoundation.org/parrot
