RE: [svn:parrot] r28689 - trunk/languages/perl6/t ("-" versus "_")
Conrad Schneiker
> 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
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Official Parrot Wiki - http://www.perlfoundation.org/parrot
Moritz Lenz
With the small distinction that there are case insensitive, case
preserving and case sensitive file systems, whereas identifiers are
always case sensitive.
My experience is that it's hard to get case right on the former two
types of systems because you don't have real testing. That's why I'm in
favor of all lower case file names.
> 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 think it could cause confusion, but it should be so easy to do that
you'll just be able to try it out. Just allow '-' in the mid of an
identifier, and longest token matching takes care of the rest. Since
whitespaces terminate LTM, they automatically disambiguate operators.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Bob Rogers
Date: Wed, 2 Jul 2008 12:25:58 -0700
Moritz Lenz wrote (on perl6-compiler)
> Patrick R. Michaud wrote:
> > 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).
A better reason for preferring hyphens is that they do not require
shifting, and are therefore easier on the pinkies.
-- Bob