FAQ

[P5P] [PATCH] use dots - allow '.' instead of '->' everywhere and concat with '~'

Rev. Chip
Jun 9, 2013 at 10:08 pm
As discussed at YAPC, this patch adds the pragma "use dots" allowing users to
write . instead of -> in all places. Infix ~ (a la Perl 6) provides string
concatenation.

To any skeptics, I suggest you find a nice big OO module of your own and
globally replace arrows with dots, then just look at it. You'll be amazed
how much easier it is to read (and write) modern Perl this way.

Under "use dots", "->" is disallowed by default to avoid user confusion.
Any user who uses dots will also be reading a lot of code that doesn't. We
want any arrows present to be a signal that dot is concatenation. In cases
where intermixing is Really Wanted, "use dots 'mixed'" is available, but not
recommended.

Incidentally, Leon Brocard had the same basic idea a few years ago, but his
implementation didn't mature. For example, it looks like it wouldn't
properly handle autoquoting of method names. Also, he made it a feature.
This seems good at first, but we don't want "use v5.20" to imply "use dots".

This patch is also pushed in branch "chip/dots".

commit 7e4b75ad02fa8593c1fc7237cc24026cd19a97cb
Author: Chip Salzenberg <chi...@...com>
Date: Wed Jun 5 16:49:52 2013 -0500

     "use dots": Class.method $obj.method [$a].[0] {a=>1}.{a} $str ~ $concat

diff --git a/MANIFEST b/MANIFEST
index e76d4af..e7caff5 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -4083,6 +4083,8 @@ lib/diagnostics.pm Print verbose diagnostics
  lib/diagnostics.t See if diagnostics.pm works
  lib/DirHandle.pm like FileHandle only for directories
  lib/DirHandle.t See if DirHandle works
+lib/dots.pm For "use dots"
+lib/dots.t See if "use dots" works
  lib/dumpvar.pl A variable dumper
  lib/dumpvar.t A variable dumper tester
  lib/English.pm Readable aliases for short variables
diff --git a/Porting/Maintainers.pl b/Porting/Maintainers.pl
index 2f94757..83873b0 100755
--- a/Porting/Maintainers.pl
+++ b/Porting/Maintainers.pl
@@ -2068,6 +2068,7 @@ use File::Glob qw(:case);
                  lib/charnames.{pm,t}
                  lib/dbm_filter_util.pl
                  lib/deprecate.pm
+ lib/dots.{pm,t}
                  lib/dumpvar.{pl,t}
                  lib/feature.{pm,t}
                  lib/feature/
diff --git a/lib/dots.pm b/lib/dots.pm
new file mode 100644
index 0000000..2a1f48a
--- /dev/null
+++ b/lib/dots.pm
@@ -0,0 +1,97 @@
+package dots;
+use strict;
+
+our $VERSION = '1.00';
+
+our $enable_bit = 0x00000001;
+our $mixed_bit = 0x00000002;
+
+sub import {
+ shift;
+ $^H{dots} = $enable_bit;
+ while (@_) {
+ local $_ = shift;
+ if ($_ eq 'mixed') {
+ $^H{dots} |= $mixed_bit;
+ }
+ else {
+ require Carp;
+ Carp::croak("dots: unknown subpragma '$_'");
+ }
+ }
+}
+
+sub unimport {
+ shift;
+ my $mask;
+ while (@_) {
+ local $_ = shift;
+ if ($_ eq 'mixed') {
+ $mask = $mixed_bit;
+ }
+ else {
+ require Carp;
+ Carp::croak("dots: unknown subpragma '$_'");
+ }
+ }
+ if (defined $mask) {
+ $^H{dots} &= ~$mask;
+ }
+ else {
+ delete $^H{dots};
+ }
+}
+
+'dot dot dot';
+__END__
+
+=head1 NAME
+
+dots - perl pragma to use dots to follow references and call methods
+
+=head1 SYNOPSIS
+
+ use dots; # '.' follows refs; '~' is concat
+
+ my $obj = Foo.new(...); # call class method
+ $obj.method; # call object method
+ my $href = { a => 1 };
+ $href.{a}; # follow hash ref
+ my $aref = [ sub {...} ];
+ $aref.[0].(@args); # follow array ref; call code
+
+ say "hello" ~ " world"; # '~' concatenates strings
+
+ say $a->[0]; # '->' is not allowed by default
+ use dots 'mixed';
+ say $a->[0]; # allow '->' explicitly
+
+ no dots 'mixed'; # disallow '->' again
+
+ no dots; # back to Perl defaults again
+
+=head1 DESCRIPTION
+
+With the C<dots> pragma you can switch out Perl's '->' operator for the much
+easier to type, easier to read, and industry standard '.' operator. It does
+everything '->' usually does in following references and calling methods.
+
+The '~' binary operator, previously unused, becomes string concatenation.
+
+By default, C<use dots> forbids using '->'. This is important for
+readability; seeing an arrow should be a reliable sign that C<use dots> is
+off and '.' does string concatenation. It also leaves open that '->' can be
+repurposed someday. But if you really want to mix arrows and dots, this is
+supported; just write C<use dots 'mixed'>.
+
+To undo C<use dots 'mixed'>, write C<no dots 'mixed'>.
+
+To turn off dots, write C<no dots>.
+
+=head1 CAVEATS
+
+This pragma is lexically scoped and only has effect at compile time.
+Decompilers like C<-MO=Deparse> will generate the arrow version until
+someone teaches them to write dots instead (hint hint).
+
+=cut
diff --git a/lib/dots.t b/lib/dots.t
new file mode 100644
index 0000000..7214653
--- /dev/null
+++ b/lib/dots.t
@@ -0,0 +1,47 @@
+#!./perl
+
+# This tests syntax under variations of "use dots".
+
+BEGIN {
+ chdir 't' if -d 't';
+ @INC = qw(../lib);
+}
+
+use strict;
+use warnings;
+
+use Test::More tests => 9;
+
+my $a = ['foo', 'bar'];
+my $h = { corge => 1, grault => 2 };
+my $c = sub { '"Bob"' };
+
+eval q{
+ use strict;
+ use dots;
+ ok($a.[0] eq 'foo');
+ ok($h.{corge} == 1);
+ ok($c.() eq '"Bob"');
+};
+diag($@) if $@;
+ok(!$@, "dots");
+
+eval q{
+ use strict;
+ use dots;
+ is('Praise ' ~ '"Bob"!', 'Praise "Bob"!', "~ concat");
+};
+diag($@) if $@;
+ok(!$@, "dots");
+
+eval q{
+ use strict;
+ use dots 'mixed';
+ my $x = [ sub { "hi" } ];
+ is($x.[0]->(), 'hi', "mixed expression");
+};
+diag($@) if $@;
+ok(!$@, "use dots 'mixed'");
+
+eval q{ use dots; [0]->[0] };
+ok($@, "mixed is off by default");
diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index e41038c..808cb66 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -24,6 +24,23 @@ here, but most should go in the L</Performance Enhancements> section.

  [ List each enhancement as a =head2 entry ]

+=head2 C<use dots>
+
+The new C<use dots> pragma replaces the '->' operator with the shorter,
+easier-to-read, and industry standard '.' operator within a lexical scope.
+
+Under C<use dots>:
+
+=over 4
+
+=item '.' follows references and invokes methods
+
+=item '~' concatenates strings (same as Perl 6)
+
+=item '->' is disallowed, unless requested by writing C<use dots 'mixed'>
+
+=back
+
  =head1 Security

  XXX Any security-related notices go here. In particular, any security
diff --git a/pod/perldiag.pod b/pod/perldiag.pod
index a228d23..416dc2f 100644
--- a/pod/perldiag.pod
+++ b/pod/perldiag.pod
@@ -6318,6 +6318,18 @@ what you want, put an & in front.)
  not get any randomness out of your system. This usually indicates
  Something Very Wrong.

+=item use dots in effect; replace '->' with '.'
+
+(F) You should replace all instances of '->' with '.' under C<use dots>.
+
+The C<use dots> pragma makes code easier to write and read by using '.'
+intead of '->' for all purposes, and using the infix '~' operator for string
+concatenation. When C<use dots> is in effect, '->' is forbidden, so readers
+know that if they see '->' then '.' means concatenation.
+
+If you know what you're doing, you can request mixing of '->' and '.' by
+writing C<use dots 'mixed'>.
+
  =back

  =head1 SEE ALSO
diff --git a/toke.c b/toke.c
index d3bc457..b3f6824 100644
--- a/toke.c
+++ b/toke.c
@@ -4585,6 +4585,23 @@ S_word_takes_any_delimeter(char *p, STRLEN len)
       (p[0] == 'q' && strchr("qwxr", p[1]))));
  }

+/* coordinate with dots.pm */
+
+#define HINT_DOTS_ENABLED 0x00000001
+#define HINT_DOTS_MIXED 0x00000002
+
+#define hint_dots() S_hint_dots(aTHX)
+STATIC U32
+S_hint_dots(pTHX) {
+ HV * const hinthv = GvHV(PL_hintgv);
+ if (hinthv) {
+ SV ** const svp = hv_fetchs(hinthv, "dots", FALSE);
+ if (svp)
+ return SvUV(*svp);
+ }
+ return 0;
+}
+
  /*
    yylex

@@ -5613,40 +5630,41 @@ Perl_yylex(pTHX)
    s = --PL_bufptr;
       }
   }
- {
- const char tmp = *s++;
- if (*s == tmp) {
- s++;
- if (PL_expect == XOPERATOR)
- TERM(POSTDEC);
- else
- OPERATOR(PREDEC);
- }
- else if (*s == '>') {
- s++;
- s = SKIPSPACE1(s);
- if (isIDFIRST_lazy_if(s,UTF)) {
- s = force_word(s,METHOD,FALSE,TRUE,FALSE);
- TOKEN(ARROW);
- }
- else if (*s == '$')
- OPERATOR(ARROW);
- else
- TERM(ARROW);
- }
- if (PL_expect == XOPERATOR) {
- if (*s == '=' && !PL_lex_allbrackets &&
- PL_lex_fakeeof >= LEX_FAKEEOF_ASSIGN) {
- s--;
- TOKEN(0);
- }
- Aop(OP_SUBTRACT);
+ s++;
+ if (*s == '-') {
+ s++;
+ if (PL_expect == XOPERATOR)
+ TERM(POSTDEC);
+ else
+ OPERATOR(PREDEC);
+ }
+ else if (*s == '>') {
+ s++;
+ if ((hint_dots() & (HINT_DOTS_ENABLED|HINT_DOTS_MIXED)) == HINT_DOTS_ENABLED)
+ Perl_croak(aTHX_ "use dots in effect; replace '->' with '.'");
+ arrow:
+ s = SKIPSPACE1(s);
+ if (isIDFIRST_lazy_if(s,UTF)) {
+ s = force_word(s,METHOD,FALSE,TRUE,FALSE);
+ TOKEN(ARROW);
       }
- else {
- if (isSPACE(*s) || !isSPACE(*PL_bufptr))
- check_uni();
- OPERATOR('-'); /* unary minus */
+ else if (*s == '$')
+ OPERATOR(ARROW);
+ else
+ TERM(ARROW);
+ }
+ if (PL_expect == XOPERATOR) {
+ if (*s == '=' && !PL_lex_allbrackets &&
+ PL_lex_fakeeof >= LEX_FAKEEOF_ASSIGN) {
+ s--;
+ TOKEN(0);
       }
+ Aop(OP_SUBTRACT);
+ }
+ else {
+ if (isSPACE(*s) || !isSPACE(*PL_bufptr))
+ check_uni();
+ OPERATOR('-'); /* unary minus */
   }

      case '+':
@@ -5746,7 +5764,10 @@ Perl_yylex(pTHX)
       Eop(OP_SMARTMATCH);
   }
   s++;
- OPERATOR('~');
+ if (PL_expect == XOPERATOR && (hint_dots() & HINT_DOTS_ENABLED))
+ Aop(OP_CONCAT);
+ else
+ OPERATOR('~');
      case ',':
   if (!PL_lex_allbrackets && PL_lex_fakeeof >= LEX_FAKEEOF_COMMA)
       TOKEN(0);
@@ -6693,11 +6714,13 @@ Perl_yylex(pTHX)
        pl_yylval.ival = 0;
    OPERATOR(DOTDOT);
       }
- if (*s == '=' && !PL_lex_allbrackets &&
- PL_lex_fakeeof >= LEX_FAKEEOF_ASSIGN) {
- s--;
- TOKEN(0);
- }
+ if (hint_dots() & HINT_DOTS_ENABLED)
+ goto arrow;
+ if (*s == '=' && !PL_lex_allbrackets &&
+ PL_lex_fakeeof >= LEX_FAKEEOF_ASSIGN) {
+ s--;
+ TOKEN(0);
+ }
       Aop(OP_CONCAT);
   }
   /* FALL THROUGH */
reply

Search Discussions

63 responses

  • H.Merijn Brand at Jun 10, 2013 at 6:23 am

    On Sun, 9 Jun 2013 15:07:58 -0700, "Rev. Chip" wrote:

    As discussed at YAPC, this patch adds the pragma "use dots" allowing users to
    write . instead of -> in all places. Infix ~ (a la Perl 6) provides string
    concatenation.

    To any skeptics, I suggest you find a nice big OO module of your own and
    globally replace arrows with dots, then just look at it. You'll be amazed
    how much easier it is to read (and write) modern Perl this way.

    Under "use dots", "->" is disallowed by default to avoid user confusion.
    Any user who uses dots will also be reading a lot of code that doesn't. We
    want any arrows present to be a signal that dot is concatenation. In cases
    where intermixing is Really Wanted, "use dots 'mixed'" is available, but not
    recommended.

    Incidentally, Leon Brocard had the same basic idea a few years ago, but his
    implementation didn't mature. For example, it looks like it wouldn't
    properly handle autoquoting of method names. Also, he made it a feature.
    This seems good at first, but we don't want "use v5.20" to imply "use dots".

    This patch is also pushed in branch "chip/dots".
    If this is lexical, how hard would it be to have string concats like in
    c/cpp? e.g. no op at all

      printf ("%d: %s\n" /* look ma, no concat */
              "%d: %c (0x%02x)\n",
                  c_foo, foo,
                  c_bar, bar, bar);
  • Tom Christiansen at Jun 10, 2013 at 1:13 pm

    If this is lexical, how hard would it be to have string concats like in
    c/cpp? e.g. no op at all
    printf ("%d: %s\n" /* look ma, no concat */
    "%d: %c (0x%02x)\n",
    c_foo, foo,
    c_bar, bar, bar);
    This was considered a Bad Thing by Larry, and why he made an
    explicit concatenation operator. You miss too many mistakes
    if you treat the absense of an operator as a concatenation.

    Please don't break this.

    --tom
  • Johan Vromans at Jun 10, 2013 at 10:01 am

    "Rev. Chip" <rev...@...com> writes:

    To any skeptics, I suggest you find a nice big OO module of your own and
    globally replace arrows with dots, then just look at it. You'll be amazed
    how much easier it is to read (and write) modern Perl this way.
    Unless you first replace a carefully chosen selection of dots by tildes
    you'll indeed be amazed.

    -- Johan
  • Ricardo Signes at Jun 10, 2013 at 2:29 pm
    * "Rev. Chip" [2013-06-09T18:07:58]
    As discussed at YAPC, this patch adds the pragma "use dots" allowing users to
    write . instead of -> in all places. Infix ~ (a la Perl 6) provides string
    concatenation. Neat. :)
    To any skeptics, I suggest you find a nice big OO module of your own and
    globally replace arrows with dots, then just look at it. You'll be amazed
    how much easier it is to read (and write) modern Perl this way.
    To me, it doesn't help. That's okay, everybody likes different stuff.

    I like that this patch is so small with such a seemingly clear-cut change. If
    it might help people make the language feel more homey for them, that would be
    nice. It really has to work as described, though: the two operator swaps, and
    that's it.

    Right now, that's not quite what we get, so I want to table any discussion
    until we know whether we can really get that without making the patch become an
    insidious everywhereism.

    Examples:

       $ ./perl -Ilib -le '$_ = "z"; $a = 0; $b = chomp . $a; print $b'
       00

       $ ./perl -Ilib -Mdots -le '$_ = "z"; $a = 0; $b = chomp ~ $a; print $b'
       Can't modify 1's complement (~) in chomp at -e line 1, near "$a;"
       Execution of -e aborted due to compilation errors.

    ...and the similar, but less fatal:

       $ ./perl -Ilib -le '$_ = "z"; $a = 0; $b = print . $a; print $b'
       z
       10

       $ ./perl -Ilib -Mdots -le '$_ = "z"; $a = 0; $b = print ~ $a; print $b'
       18446744073709551615
       1

    I can look for more trouble cases, but I thought I'd give some initial
    examples. The more of these that exist, the more this gives us an option to
    enable a dialect, rather than an option to swap two operators. This makes me
    wary.

    Hopefully everything found will boil down to some teensy little fix.

    --
    rjbs
  • Ricardo Signes at Jun 10, 2013 at 6:19 pm
    * Ricardo Signes [2013-06-10T10:29:31]
    Hopefully everything found will boil down to some teensy little fix.
    (It may be that the fix is a word of warning, telling people to bear in mind
    that they will need to keep in mind that ~ might be interpreted as unary ~
    where it could've never been unary dot. Thinking about this makes me ask
    again, though maybe for the first time here: for whom does this feature have
    (the most) positive value?)


    --
    rjbs
  • Johan Vromans at Jun 10, 2013 at 8:47 pm

    Ricardo Signes writes:

    for whom does this feature have (the most) positive value?
    There are always people who think that it is cool to make a language
    look like another, presumably cooler, language. But in the end a change
    like this does not have any value, except for creating confusion.

    Perl is not perl6. It is not C, it's not Java or whatever. It's perl,
    and that's what makes it unique. And cool. And lovable.

    There have been other attempts in the near past to make perl look like
    perl6. Remember ~~ .

    -- Johan
  • Rev. Chip at Jun 10, 2013 at 11:01 pm

    On Mon, Jun 10, 2013 at 10:47:05PM +0200, Johan Vromans wrote:
    There have been other attempts in the near past to make perl look like
    perl6. Remember ~~ .
    Smart match in p5 was an error of semantics, not syntax. It tried to take a
    useful pattern for one *type* system and use it on another *type* system
    without accounting for the differences. The syntax mattered not.
    Introducing a named operator "smart" instead of "~~" would have had the same
    problems.

    Conversely, "use dots" improves syntax while leaving semantics untouched.
  • H.Merijn Brand at Jun 11, 2013 at 5:57 am

    On Mon, 10 Jun 2013 16:01:42 -0700, "Rev. Chip" wrote:
    On Mon, Jun 10, 2013 at 10:47:05PM +0200, Johan Vromans wrote:
    There have been other attempts in the near past to make perl look like
    perl6. Remember ~~ .
    Smart match in p5 was an error of semantics, not syntax. It tried to take a
    useful pattern for one *type* system and use it on another *type* system
    without accounting for the differences. The syntax mattered not.
    Introducing a named operator "smart" instead of "~~" would have had the same
    problems.

    Conversely, "use dots" improves syntax while leaving semantics untouched.
    *improves* is in the eye of the beholder.

    I'm with rjbs here: "… to say that this can land, because there seems
    to be great popular acclaim, and I'll not use it or include it in my
    much-imagined 2E of Perl Best Practices. My concern is the future
    maintenance cost. So far, it seems low."
  • Peter Rabbitson at Jun 11, 2013 at 6:13 am

    On Tue, Jun 11, 2013 at 07:57:30AM +0200, H.Merijn Brand wrote:
    My concern is the future maintenance cost. So far, it seems low."
    ... that is until a widely-depended-upon CPAN module starts using .
    instead of -> and the deciding author goes for the "Wanna use it? -
    Upgrade!" line. I believe allowing such basic language syntax
    alterations is another step towards madness (folks are already running
    away screaming after encountering the feature pragma)

    my 2c

    Cheers
  • Nicholas Clark at Jun 11, 2013 at 7:22 am

    On Tue, Jun 11, 2013 at 04:12:48PM +1000, Peter Rabbitson wrote:
    On Tue, Jun 11, 2013 at 07:57:30AM +0200, H.Merijn Brand wrote:
    My concern is the future maintenance cost. So far, it seems low."
    It does seem low. Using it does, however, mean that pretty much every code
    example out there isn't going to work for you. Using it is about as much
    of a lurch as changing print so that it has to take (). But at least with
    this you can run with both dialects at once.
    ... that is until a widely-depended-upon CPAN module starts using .
    instead of -> and the deciding author goes for the "Wanna use it? -
    Upgrade!" line. I believe allowing such basic language syntax
    at which point (if it matters) it's no-longer a widely-depended-upon CPAN
    module, because someone will fork it.

    If it *matters*, it will be worked around.
    alterations is another step towards madness (folks are already running
    away screaming after encountering the feature pragma)
    If you really want *no* change, you don't upgrade.
    Or you defect to something else, like Python. Oh wait...

    There is a balance to be struck between no change at all, and so much change
    that for the majority the change is more costly than the benefits.

    But the balance point *isn't* "no change".


    Now, as to whether this feature would be used - personally if I were in charge
    of code policy somewhere I'd insist on *consistency* across the codebase,
    both in-house and external code. And as the external code is only going to be
    in one form...

    *That's* my opinion on it.

    Nicholas Clark
  • Peter Rabbitson at Jun 11, 2013 at 7:31 am

    On Tue, Jun 11, 2013 at 08:22:23AM +0100, Nicholas Clark wrote:
    On Tue, Jun 11, 2013 at 04:12:48PM +1000, Peter Rabbitson wrote:
    On Tue, Jun 11, 2013 at 07:57:30AM +0200, H.Merijn Brand wrote:
    My concern is the future maintenance cost. So far, it seems low."
    It does seem low. Using it does, however, mean that pretty much every code
    example out there isn't going to work for you. Using it is about as much
    of a lurch as changing print so that it has to take (). But at least with
    this you can run with both dialects at once.
    ... that is until a widely-depended-upon CPAN module starts using .
    instead of -> and the deciding author goes for the "Wanna use it? -
    Upgrade!" line. I believe allowing such basic language syntax
    at which point (if it matters) it's no-longer a widely-depended-upon CPAN
    module, because someone will fork it.
    You say it like CPAN forking is virtually free and has no drawbacks for
    CPAN as a whole. ::ButMaintained much? :)
    If it *matters*, it will be worked around.
    alterations is another step towards madness (folks are already running
    away screaming after encountering the feature pragma)
    If you really want *no* change, you don't upgrade.
    I am curious which part of my first post makes it sound like "AUGGHHH NO
    CHANGE NO NO NO NO!"
    There is a balance to be struck between no change at all, and so much change
    that for the majority the change is more costly than the benefits.

    But the balance point *isn't* "no change".
    Totally agree. I was trying to say that switching the method/dereference
    syntax of a language, even if (or maybe especially if) limited by scope
    is a beyond-massive change. As a contrast example - s///r is an awesome
    change where the benefits far outweigh the backcompat drawbacks (and the
    "shit we need to fix CPAN" effort is low if it comes to one)

    Cheers
  • Nicholas Clark at Jun 11, 2013 at 8:01 am

    On Tue, Jun 11, 2013 at 05:31:21PM +1000, Peter Rabbitson wrote:
    On Tue, Jun 11, 2013 at 08:22:23AM +0100, Nicholas Clark wrote:
    On Tue, Jun 11, 2013 at 04:12:48PM +1000, Peter Rabbitson wrote:
    On Tue, Jun 11, 2013 at 07:57:30AM +0200, H.Merijn Brand wrote:
    My concern is the future maintenance cost. So far, it seems low."
    It does seem low. Using it does, however, mean that pretty much every code
    example out there isn't going to work for you. Using it is about as much
    of a lurch as changing print so that it has to take (). But at least with
    this you can run with both dialects at once.
    ... that is until a widely-depended-upon CPAN module starts using .
    instead of -> and the deciding author goes for the "Wanna use it? -
    Upgrade!" line. I believe allowing such basic language syntax
    at which point (if it matters) it's no-longer a widely-depended-upon CPAN
    module, because someone will fork it.
    You say it like CPAN forking is virtually free and has no drawbacks for
    CPAN as a whole. ::ButMaintained much? :)
    Yes, true, and fair point.

    None of this stuff is simple. I've been chewing over parts of it for a while
    and I don't have an answer either. I think related problems in the big
    picture

    1) we have a situation where people have offered up no-brainer patches to fix
        problems in modules (eg affected by changes in v5.18.0, such as SvUPGRADE),
        and the module's owner hasn't (yet) made a release incorporating them.
        (But the social contract of CPAN is that it's the uploader's code, not
         CPAN's code)

    2) As brian d foy made me realise - CPAN is built round a KISS model with
        only one index, and monotonic increasing version numbers.
        This means that it can only tell you about one version of a module.
        Which might be a module that is too new for your Perl, even though an
        older existing module will work just fine on it. CPAN can't tell you about
        that older version.
        (eg most people are not as crazy as me to go spelunking backpan to find a
         version of Test::More that will still work on 5.004. :-) What's their
         business case for spending time on that?)
    I am curious which part of my first post makes it sound like "AUGGHHH NO
    CHANGE NO NO NO NO!"
    I think I assume too much, and get it wrong. Either that or:

    07:45 <+dipsy> Nicholas: Your excuse is: the AA battery in the wallclock sends
                    magnetic interference

    Sorry.
    There is a balance to be struck between no change at all, and so much change
    that for the majority the change is more costly than the benefits.

    But the balance point *isn't* "no change".
    Totally agree. I was trying to say that switching the method/dereference
    syntax of a language, even if (or maybe especially if) limited by scope
    is a beyond-massive change. As a contrast example - s///r is an awesome
    change where the benefits far outweigh the backcompat drawbacks (and the
    "shit we need to fix CPAN" effort is low if it comes to one)
    Yes. This is a reworking change, rather than an addition change.
    (And if one didn't do it lexically, it's a flag day change and the ecosystem
      will divorce the language. And if one does do it lexically, well, is having
      both actually a *better* design than just having the less good one?)

    And even if I can't answer that trade off, it doesn't to *my* mind feel like
    a change that's a good idea to use, because

    1) It will make your local code inconsistent with your third party code
    2) The benefit of using it on code uploaded to CPAN is small compared with
        the cost to most people who might want to use your code

    but the counter issue to that (which is bugging me too) is that it's also
    true that

    1) other people do seem to want it
    2) there isn't any other level where it's technically viable to do it

    Nicholas Clark
  • Peter Rabbitson at Jun 11, 2013 at 8:25 am

    On Tue, Jun 11, 2013 at 09:01:06AM +0100, Nicholas Clark wrote:
    On Tue, Jun 11, 2013 at 05:31:21PM +1000, Peter Rabbitson wrote:

    You say it like CPAN forking is virtually free and has no drawbacks for
    CPAN as a whole. ::ButMaintained much? :)
    Yes, true, and fair point.

    None of this stuff is simple. I've been chewing over parts of it for a while
    and I don't have an answer either. I think related problems in the big
    picture

    1) we have a situation where people have offered up no-brainer patches to fix
    problems in modules (eg affected by changes in v5.18.0, such as SvUPGRADE),
    and the module's owner hasn't (yet) made a release incorporating them.
    (But the social contract of CPAN is that it's the uploader's code, not
    CPAN's code)

    2) As brian d foy made me realise - CPAN is built round a KISS model with
    only one index, and monotonic increasing version numbers.
    This means that it can only tell you about one version of a module.
    Which might be a module that is too new for your Perl, even though an
    older existing module will work just fine on it. CPAN can't tell you about
    that older version.
    All I can say to the above is "yes, it all sucks". The problem isn't
    that CPAN itself provides one index - this is easily fixable as
    demonstrated by DrHyde. The problem is that all our CPAN clients suck
    (cpanm included).
    (eg most people are not as crazy as me to go spelunking backpan to find a
    version of Test::More that will still work on 5.004. :-) What's their
    business case for spending time on that?)
    I don't have a business case but I do this kind of stuff quite regularly
    (to the annoyance of most peers ;) I guess I will chalk this to "most
    people are not..." :)
    There is a balance to be struck between no change at all, and so much change
    that for the majority the change is more costly than the benefits.

    But the balance point *isn't* "no change".
    Totally agree. I was trying to say that switching the method/dereference
    syntax of a language, even if (or maybe especially if) limited by scope
    is a beyond-massive change. As a contrast example - s///r is an awesome
    change where the benefits far outweigh the backcompat drawbacks (and the
    "shit we need to fix CPAN" effort is low if it comes to one)
    Yes. This is a reworking change, rather than an addition change.
    Yes! This is a rather precise way to put it, ++.
    (And if one didn't do it lexically, it's a flag day change and the ecosystem
    will divorce the language. And if one does do it lexically, well, is having
    both actually a *better* design than just having the less good one?)
    It is horrific design. I think everyone, including Chip, would agree on
    this. The problem is that without support for such lexical syntax
    switch, you simply can't go from "here" to "there" (unless you ditch CPAN as
    a whole, and do the massive work of updating what ships with p5 core).
    And even if I can't answer that trade off, it doesn't to *my* mind feel like
    a change that's a good idea to use, because

    1) It will make your local code inconsistent with your third party code
    2) The benefit of using it on code uploaded to CPAN is small compared with
    the cost to most people who might want to use your code

    but the counter issue to that (which is bugging me too) is that it's also
    true that

    1) other people do seem to want it
    People overwhelmingly (like you wouldn't believe the sheer numbers) want
    Perl7, but this doesn't autmoatically make it a good idea... and I think
    I just Godwined this thread ;)
    2) there isn't any other level where it's technically viable to do it
    Unfortunately you are right... If only there was a language with
    plugabble grammars since its first version... oh wait. In other words
    this is borderline importing a perl6 construct (akin to ~~), but on a
    different level.

    Coming back to your statement above - I guess one can claim that Perl is
    mature (old, crufty, boring, use whatever word) enough to no longer be
    amenable to *reworking* changes of such magnitude.

    The problem is aggravated by the fact that this change is an easy first
    hit - i.e. no immediate harm will come from it. It is only years down
    the road (I'd say 4 to 5) when the potential "codebase divorce"
    instances *might* pile high enough to make everyone go "what were we
    thinking?!". At which point it will be (as usual) too late.

    Cheers
  • Aaron Priven at Jun 11, 2013 at 3:50 pm
    I said what I had to say about this on Perlmonks ( http://perlmonks.org/?node_id=1038191 ) rather than clutter the list with it.
  • Tatsuhiko Miyagawa at Jun 13, 2013 at 10:14 pm

    On Tue, Jun 11, 2013 at 1:25 AM, Peter Rabbitson wrote:

    2) As brian d foy made me realise - CPAN is built round a KISS model with
    only one index, and monotonic increasing version numbers.
    This means that it can only tell you about one version of a module.
    Which might be a module that is too new for your Perl, even though an
    older existing module will work just fine on it. CPAN can't tell you about
    that older version.
    All I can say to the above is "yes, it all sucks". The problem isn't
    that CPAN itself provides one index - this is easily fixable as
    demonstrated by DrHyde. The problem is that all our CPAN clients suck
    (cpanm included).
    You can tell cpanm about an older version with @ or ~ syntax and it
    fetches the right (99% right, not 100% because PAUSE) from
    metacpan/BackPAN.

       % cpanm pla...@...9987
        --> Working on Plack
        Fetching http://www.cpan.org/authors/id/M/MI/MIYAGAWA/Plack-0.9987.tar.gz
    ... OK

    Carton adds another layer on top of that, to record what you have
    today, in your git repository, then to recreate the modules you have,
    including sub-dependencies, on other machines, even 1 year later.


    --
    Tatsuhiko Miyagawa
  • Aristotle Pagaltzis at Jun 14, 2013 at 4:12 am

    * Tatsuhiko Miyagawa [2013-06-14 00:15]:
    On Tue, Jun 11, 2013 at 1:25 AM, Peter Rabbitson wrote:

    2) As brian d foy made me realise - CPAN is built round a KISS model with
    only one index, and monotonic increasing version numbers.
    This means that it can only tell you about one version of a module.
    Which might be a module that is too new for your Perl, even though an
    older existing module will work just fine on it. CPAN can't tell you about
    that older version.
    All I can say to the above is "yes, it all sucks". The problem isn't
    that CPAN itself provides one index - this is easily fixable as
    demonstrated by DrHyde. The problem is that all our CPAN clients suck
    (cpanm included).
    You can tell cpanm about an older version with @ or ~ syntax and it
    fetches the right (99% right, not 100% because PAUSE) from
    metacpan/BackPAN.

    % cpanm pla...@...9987
    --> Working on Plack
    Fetching http://www.cpan.org/authors/id/M/MI/MIYAGAWA/Plack-0.9987.tar.gz
    ... OK

    Carton adds another layer on top of that, to record what you have
    today, in your git repository, then to recreate the modules you have,
    including sub-dependencies, on other machines, even 1 year later.
    I think what Peter (and brian) is looking for would be something like

         $ cpanm Test::mor...@...006001

    which would then install an old version of Test::More from BackPAN that
    will work on that ancient perl. And of course, if you’re running cpanm
    under 5.6.1 (uh, if cpanm even runs on a perl that old!), you shouldn’t
    even have to specify which perl you want the module for. You can get
    there using CPXXXAN now but that’s more of a workaround than a proper
    solution, and even so is too manual.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Tatsuhiko Miyagawa at Jun 14, 2013 at 4:18 am

    On Thu, Jun 13, 2013 at 9:12 PM, Aristotle Pagaltzis wrote:
    I think what Peter (and brian) is looking for would be something like

    $ cpanm Test::mor...@...006001

    which would then install an old version of Test::More from BackPAN that
    will work on that ancient perl. And of course, if you’re running cpanm
    under 5.6.1 (uh, if cpanm even runs on a perl that old!),
    Unfortunately it doesn't, because quite a few of fatpacked modules don't.
    you shouldn’t
    even have to specify which perl you want the module for. You can get
    there using CPXXXAN now but that’s more of a workaround than a proper
    solution, and even so is too manual.
    I get that, but I'm confused about that since:
    The problem isn't
    that CPAN itself provides one index - this is easily fixable as
    demonstrated by DrHyde. The problem is that all our CPAN clients suck
    (cpanm included).
    If the problem isn't CPAN having only one index, then what is the
    problem about CPAN clients that is capable of switching CPAN mirrors
    with options?


    --
    Tatsuhiko Miyagawa
  • Aristotle Pagaltzis at Jun 14, 2013 at 4:52 am

    * Tatsuhiko Miyagawa [2013-06-14 06:20]:
    If the problem isn't CPAN having only one index, then what is the
    problem about CPAN clients that is capable of switching CPAN mirrors
    with options?
    It’s not part of the data model of the tools that non-equivalent indices
    exist, so the tools cannot DWIM for the user. (That doesn’t qualify them
    for “suck” IMO though. They aren’t there yet, that’s all.)
  • Peter Rabbitson at Jun 14, 2013 at 9:50 am

    On Thu, Jun 13, 2013 at 09:18:07PM -0700, Tatsuhiko Miyagawa wrote:
    The problem isn't
    that CPAN itself provides one index - this is easily fixable as
    demonstrated by DrHyde. The problem is that all our CPAN clients suck
    (cpanm included).
    If the problem isn't CPAN having only one index, then what is the
    problem about CPAN clients that is capable of switching CPAN mirrors
    with options?
    There is no client (afaik) which will take a set of mirrors and conflate
    their contents into a "cascaded index" so that each module will be taken
    from the first index that satisfies the required version.

    All the solutions you and others described are manual, and what's worse
    - static. The "pornpan" indices update continuously, even for 5.6.2
    stuff (in cases where e.g. I fix a module to start building on 5.6
    again).

    Cheers
  • Tatsuhiko Miyagawa at Jun 14, 2013 at 7:21 pm

    On Fri, Jun 14, 2013 at 2:50 AM, Peter Rabbitson wrote:
    If the problem isn't CPAN having only one index, then what is the
    problem about CPAN clients that is capable of switching CPAN mirrors
    with options?
    There is no client (afaik) which will take a set of mirrors and conflate
    their contents into a "cascaded index" so that each module will be taken
    from the first index that satisfies the required version.
    cpanm --cascade-search --mirror A --mirror B --mirror-only
    Module~"version requirement"


    --
    Tatsuhiko Miyagawa
  • David Cantrell at Jun 14, 2013 at 11:15 am

    On Fri, Jun 14, 2013 at 06:12:29AM +0200, Aristotle Pagaltzis wrote:

    I think what Peter (and brian) is looking for would be something like

    $ cpanm Test::mor...@...006001

    which would then install an old version of Test::More from BackPAN that
    will work on that ancient perl. And of course, if you???re running cpanm
    under 5.6.1 (uh, if cpanm even runs on a perl that old!), you shouldn???t
    even have to specify which perl you want the module for. You can get
    there using CPXXXAN now but that???s more of a workaround than a proper
    solution, and even so is too manual.
    FWIW, I'd not have any objections at all if cpanm were to sprout a
    tentacle like that and direct traffic to cpxxxan. I'm not (currently)
    paying for bandwidth, and it's all static files.

    I suggest, though, that the bit after the @ match the hostname for the
    version of the CPAN that you want. That way as well as getting things
    like this:

    $ cpanm Test::mor...@...2an

    you also get, without any extra work:

    $ cpanm Test::More@cp5.8.8-irixan
    $ cpanm Test::More@cp2002-03an

    The limiting factor from my point of view is how long it takes to
    regenerate the indexes. Excluding the date-based ones (they only need
    to be created once, obviously), it currently takes 3h10.

    --
    David Cantrell | Bourgeois reactionary pig

    I hate baby seals. They get asked to all the best clubs.
  • Ricardo Signes at Jun 14, 2013 at 12:55 pm
    * Tatsuhiko Miyagawa [2013-06-13T18:14:04]
    You can tell cpanm about an older version with @ or ~ syntax and it
    fetches the right (99% right, not 100% because PAUSE) from
    metacpan/BackPAN.
    cpanm is a great program, and I'mma let you finish, but this needs to go to a
    new thread.

    --
    rjbs
  • Christian Walde at Jun 11, 2013 at 9:34 am

    On Tue, 11 Jun 2013 10:01:06 +0200, Nicholas Clark wrote:

    Which might be a module that is too new for your Perl, even though an
    older existing module will work just fine on it. CPAN can't tell you
    about that older version.
    The client CPAN.pm won't, but for a certain amount of history
    (Test::Simple reports go to 5.5.3), cpantesters will tell you about that:

    http://www.cpantesters.org/distro/M/Mojolicious.html#Mojolicious-4.14

    --
    With regards,
    Christian Walde
  • Renee B at Jun 11, 2013 at 9:44 am

    On 11.06.2013 11:34, Christian Walde wrote:
    On Tue, 11 Jun 2013 10:01:06 +0200, Nicholas Clark wrote:

    Which might be a module that is too new for your Perl, even though an
    older existing module will work just fine on it. CPAN can't tell
    you about that older version.
    The client CPAN.pm won't, but for a certain amount of history
    (Test::Simple reports go to 5.5.3), cpantesters will tell you about that:

    http://www.cpantesters.org/distro/M/Mojolicious.html#Mojolicious-4.14
    And we could tell people about http://cp5.6.2an.barnyard.co.uk/ etc...
  • Father Chrysostomos at Jun 12, 2013 at 12:54 am

    Nicholas Clark wrote:
    2) there isn't any other level where it's technically viable to do it
    Except a pluggable infix operator mechanism. I thought Peter Martini
    posted a prototype somewhere.
  • Lukas Mai at Jun 12, 2013 at 5:20 am

    On 12.06.2013 02:54, Father Chrysostomos wrote:
    Nicholas Clark wrote:
    2) there isn't any other level where it's technically viable to do it
    Except a pluggable infix operator mechanism. I thought Peter Martini
    posted a prototype somewhere.
    That would need to be very pluggable indeed because -> doesn't follow
    any "normal" operator syntax rules. I'm thinking of:

       * ->[ ], ->{ }, ->( ) - all postcircumfix operators made of 3 tokens
         each
       * ->FOO( ) - sort of a meta (postcircumfix) operator where FOO can be
         either an identifier or a simple scalar
       * ->FOO - same, but postfix


    I,I meta-postcircumfix

    --
    Lukas Mai <plo...@...com>
  • Nicholas Clark at Jun 14, 2013 at 11:19 am

    On Wed, Jun 12, 2013 at 07:20:39AM +0200, Lukas Mai wrote:
    On 12.06.2013 02:54, Father Chrysostomos wrote:
    Nicholas Clark wrote:
    2) there isn't any other level where it's technically viable to do it
    Except a pluggable infix operator mechanism. I thought Peter Martini
    posted a prototype somewhere.
    I believe that he did, but it so far it only supports plugging in extra
    operators. Not redefining what existing operators do.
    That would need to be very pluggable indeed because -> doesn't follow
    any "normal" operator syntax rules. I'm thinking of:

    * ->[ ], ->{ }, ->( ) - all postcircumfix operators made of 3 tokens
    each
    * ->FOO( ) - sort of a meta (postcircumfix) operator where FOO can be
    either an identifier or a simple scalar
    * ->FOO - same, but postfix
    I'm really not familiar enough with the tokeniser to be sure if that best
    maps how the tokeniser models these things internally. But it turns out
    that the patch is incomplete :-( Specifically


    String interpolation:

    $ ./perl -Ilib -lwe '$x = [ "A", "B", "C" ]; print "$x->[1]";'
    B
    $ ./perl -Ilib -lwe 'use dots; $x = [ "A", "B", "C" ]; print "$x->[1]";'
    use dots in effect; replace '->' with '.' at -e line 1.
    $ ./perl -Ilib -lwe 'use dots; $x = [ "A", "B", "C" ]; print "$x.[1]";'
    ARRAY(0x92c288c).[1]


    Regular expression interpolation:

    $ ./perl -Ilib -lwe '$x = [ "A", "B", "C" ]; print qr/$x->[1]/;'
    (?^:B)
    $ ./perl -Ilib -lwe 'use dots; $x = [ "A", "B", "C" ]; print qr/$x->[1]/;'
    use dots in effect; replace '->' with '.' at -e line 1.
    $ ./perl -Ilib -lwe 'use dots; $x = [ "A", "B", "C" ]; print qr/$x.[1]/;'
    (?^:ARRAY(0x961d88c).[1])


    A skim of the tokeniser suggests three places that would need changing to
    implement "dots" consistently for strings and regular expressions. However,
    I'm not confident that I've missed some more. This also suggests that almost
    no-one commenting on this thread has actually tried building from git, to
    see how the code behaves.


    To be consistent with the behaviour for perl code, interpolation would need
    to change. But to be consistent with how interpolation currently works, the
    unrecognised case should not interpolate.

    That would mean

                     no dots; use dots; use dots 'mixed';
    "$x->[1]" $x->[1] $x ~ '->[1]' $x.[1]
    "$x.[1]" $x . '.[1]' $x.[1] $x.[1]

    qr/$x->[1]/ qr/${$x}[1]/ qr/${x}->[1]/ qr/${$x}[1]/
    qr/$x.[1]/ qr{${x}.[1]/ qr/${$x}[1]/ qr/${$x}[1]/

    No cases should generate errors.

    (There may be errors in that table above. I've fixed 3. Without working code
    it's hard to test it)


    This would mean that some double quoted strings and regular expressions
    could need changing to work under `use dots`. In particular, it's not
    going to be a trivial global substitution to take existing code (or
    examples) for classic Perl 5 and be confident that you've got it right, as
    some of the mistakes the above creates are only runtime errors, and some
    are just data corruption.


    I believe that nested regular expression compilation is still done
    (partially) by interpolation into the containing regex, so one would think
    that there's a way to get confused when passing regular expressions between
    scopes (most likely modules) written for `use dots` and those not. However,
    as all this affects is interpolation, and there is only a single round of
    interpolation in regular expressions, I don't think that it can leak out.
    In my examples, qr/$x->[1]/ has already been compiled as if it's qr/B/,
    so there's no "wrong" dereferencing to leak into the other paradigm.


    However, the need to have the qq, qr etc parsers know which characters are
    special makes it hard to implement `use dots` as something pluggable, even
    without the "mixed" mode. toke.c would have to talk closely with the
    pluggable operator state to know which sequences to look for in qq, qr, etc
    to treat as dereferencing.

    Nicholas Clark
  • Reverend Chip at Jun 11, 2013 at 6:41 pm

    On 6/10/2013 11:12 PM, Peter Rabbitson wrote:
    folks are already running
    away screaming after encountering the feature pragma
    [citation needed]
    [statistics needed]
  • Peter Rabbitson at Jun 11, 2013 at 8:54 pm

    On Tue, Jun 11, 2013 at 11:41:30AM -0700, Reverend Chip wrote:
    On 6/10/2013 11:12 PM, Peter Rabbitson wrote:
    folks are already running
    away screaming after encountering the feature pragma
    [citation needed]
    But, Sir! I come prepared! ;)

    http://www.reddit.com/r/perl/comments/1foibl/in_perl_520_what_will_come_of_smartmatch_given/cackmzb
    [statistics needed]
    Well... I am not doing so well on that front ;) But I can totally
    sympathize with the problem of a language that tries to both "grow
    organically" and "offer stability".

    Cheers
  • Reverend Chip at Jun 12, 2013 at 12:10 am

    On 6/11/2013 1:54 PM, Peter Rabbitson wrote:
    On Tue, Jun 11, 2013 at 11:41:30AM -0700, Reverend Chip wrote:
    On 6/10/2013 11:12 PM, Peter Rabbitson wrote:
    folks are already running
    away screaming after encountering the feature pragma
    [citation needed]
    But, Sir! I come prepared! ;)

    http://www.reddit.com/r/perl/comments/1foibl/in_perl_520_what_will_come_of_smartmatch_given/cackmzb
    "For years we didn't have use features? [sic] In between perl versions
    there was no assumption of backwards or forwards compatibility."

    Oooo kay. He *wants* that. If a new or removed feature might break
    code, he wants Perl to tell users to go Cheney themselves. Consider me
    unmoved. In fact, If that's a representative opinion against C<use
    features>, then being *for* it is obviously correct.

    I can totally
    sympathize with the problem of a language that tries to both "grow
    organically" and "offer stability".
    Yeah. That.
  • Johan Vromans at Jun 12, 2013 at 8:05 am

    Reverend Chip writes:

    I can totally
    sympathize with the problem of a language that tries to both "grow
    organically" and "offer stability".
    Yeah. That.
    The point is: use dots does not provide anything that cannot already be
    done, with the same amount of operators and the same generic syntax.

    -- Johan
  • Reverend Chip at Jun 12, 2013 at 8:31 am

    On 6/12/2013 1:05 AM, Johan Vromans wrote:
    Reverend Chip <rev...@...com> writes:
    I can totally
    sympathize with the problem of a language that tries to both "grow
    organically" and "offer stability".
    Yeah. That.
    The point is: use dots does not provide anything that cannot already be
    done, with the same amount of operators and the same generic syntax.
    "True, but probably unimportant." - Gag Halfrunt

    Naming all the dimensions in which the patch has no effect is not
    particularly helpful. Of course operator count is not affected; it's
    orthogonal to the patch's purpose. OTOH, *character* count and visual
    clutter are the targets, as I explained at some length. (I'm loathe to
    bore p5p with a copypasta.)
  • Johan Vromans at Jun 12, 2013 at 4:07 pm

    Reverend Chip writes:

    "True, but probably unimportant." - Gag Halfrunt
    I beg to differ.

    Language is for communication. That is also true for programming
    languages. The programmer communicates with the system *and* with other
    programmers.

    Systems are patient, you can swap operators and they'll execute your
    code without blinking.

    Programmers, otoh, are human and prefer, actually: they *need*,
    consistency. Swapping operators will only cause confusion.

    -- Johan
  • Rev. Chip at Jun 10, 2013 at 10:59 pm

    On Mon, Jun 10, 2013 at 10:29:31AM -0400, Ricardo Signes wrote:
    * "Rev. Chip" [2013-06-09T18:07:58]
    As discussed at YAPC, this patch adds the pragma "use dots" allowing users to
    write . instead of -> in all places. Infix ~ (a la Perl 6) provides string
    concatenation.
    I like that this patch is so small with such a seemingly clear-cut change. If
    it might help people make the language feel more homey for them, that would be
    nice.
    It's not about being homey, it's about Huffmanizing. Object and reference
    access is very very common. By the same reasoning that gave us $h{a}
    instead of $h{'a'}, less typing and less visual clutter for a frequent
    construct is an improvement. I type and read -> way, way too much. It's
    two characters requiring three keystrokes that have to be visually combined
    into a lexeme to be properly read. Dot is objectively better.

    As for whether reducing gratuitous social incompatibility is good, consider:
    What is the Perl nature if not willingness to steal freely and precisely?

    Consider how many different ways Larry could have made file tests, quoting,
    and block structure work. He just took the -x operators from /bin/test
    without change; '' vs. "" and \ from the shell without unnecessary change;
    and block structure of C without change. He took all of C's relevant
    operators without change, and kept their relative precedence identical even
    where C was dumb! ("&" has adjacent precedence to "&&")

    Today, dots are the de facto standard for reference following in languages
    with which Perl programmers most often cross-work, soon to include Perl 6.
    Same same.

    Calling this mere "homey"ness treats genuine value as if it were nostalgia.
    It's the opposite. Forcing the continued use only of C++ syntax (->) since
    it's always been done that way, even though coders of both Perl and C++ are
    vanishingly rare (*raises hand*) is no virtue.
    Examples:

    $ ./perl -Ilib -le '$_ = "z"; $a = 0; $b = chomp . $a; print $b'
    00

    $ ./perl -Ilib -Mdots -le '$_ = "z"; $a = 0; $b = chomp ~ $a; print $b'
    Can't modify 1's complement (~) in chomp at -e line 1, near "$a;"
    Execution of -e aborted due to compilation errors.
    Ah, yes; no unary concat. This may be soluble in the grammer.

    Even if it isn't soluble, I don't think it's fatal. All is fair if you
    predeclare. This is a pragma, not a feature; no one will get it by
    surprise. It is for new code or conversions done by humans, not for a
    global search-and-destroy on running code they don't understand. And if a
    "dotify" tool comes to be, it certainly can fix these cases; it just has to
    look for function or operator without parens on the lhs.
  • Ricardo Signes at Jun 10, 2013 at 11:22 pm
    * "Rev. Chip" [2013-06-10T18:59:07]
    It's not about being homey, it's about Huffmanizing.
    I'm not sure I think it's better Huffmanization, overall. That is, once in a
    syntax, there's one fewer character to read (or write) to know what you're
    doing: (.) instead of (- >)

    ...but there's an extra bit of context for all code: am I reading code that is
    traditional or dotty? So we've shaved one bit down in the tree while adding a
    top-level branch for context. Of course, that one you read once and keep in
    your head, while the other you re-encounter all the time. There's another
    tradeoff, which is that $x~=$re becomes stupid instead of a compile failure.
    This is just the kind of stupid thing that would bite me every day, despite my
    impeccable tyipng.

    I think that $x.y would've been better encoding from the start, but that having
    both now is worse, not better.

    *That said,* my current inclination is to say that this can land, because there
    seems to be great popular acclaim, and I'll not use it or include it in my
    much-imagined 2E of Perl Best Practices. My concern is the future maintenance
    cost. So far, it seems low.
    Ah, yes; no unary concat. This may be soluble in the grammer.
    I'm guessing that the solution (more complexity) would be worse than the
    problem (surprising consistency), but that's just the cynical prognosticator
    daemon that lives in my skull talking. He's sort of a no-nothing, even if his
    record is decent... :) He accepts proof of wrongness gracefully, at least.
    Even if it isn't soluble, I don't think it's fatal.
    No, I just think it means people need to take greater care when adopting dotty
    style. I see a "=head1 CAVEATS" in your future. :)

    --
    rjbs
  • Johan Vromans at Jun 11, 2013 at 7:54 am

    Ricardo Signes writes:

    So we've shaved one bit down in the tree while adding a top-level
    branch for context. Exactly.
    my current inclination is to say that this can land, because there
    seems to be great popular acclaim,
    Really? I've heard that argument over and over again, for things that
    died quickly. Kurila, anyone?
    My concern is the future maintenance cost. So far, it seems low.
    Maintenance cost of Perl, that is. Maintenance cost of applications and
    modules will get higher since you have to deal with multiple
    significantly different syntaxes.

    IMO, the gain is next to nothing, the pain may be substantial.

    PS: If you (in general sense) want perl to look like cool languages like
    C and Java, first get rid of the sigils.

    -- Johan
  • Ricardo Signes at Jun 12, 2013 at 5:56 pm
    * Ricardo Signes [2013-06-10T19:22:19]
    ...but there's an extra bit of context for all code: am I reading code that
    is traditional or dotty? So we've shaved one bit down in the tree while
    adding a top-level branch for context. Of course, that one you read once and
    keep in your head, while the other you re-encounter all the time. There's
    another tradeoff, which is that $x~=$re becomes stupid instead of a compile
    failure. This is just the kind of stupid thing that would bite me every day,
    despite my impeccable tyipng.

    I think that $x.y would've been better encoding from the start, but that
    having both now is worse, not better.

    *That said,* my current inclination is to say that this can land, because
    there seems to be great popular acclaim, and I'll not use it or include it in
    my much-imagined 2E of Perl Best Practices. My concern is the future
    maintenance cost. So far, it seems low.
    There's been a bunch of talk. My questions remain:

    * cui bono?
    * who will use it? (this is different than the first question, significantly)
    * how much will it cost to keep working over time?
    * how many subtle changes have we missed?

    I don't think we need more "yeah, I won't use this." I already feel that way.
    Unless somebody has a specific new answer for the above, I think this thread
    and patch can cool heels for a little while. I'm not excited to introduce a
    feature that can only live in the tokenizer in haste. Let's give it a week or
    two to settle and then we'll either apply or not.

    I'd be interested in hearing whether there really is a significant performance
    impact, as Brian F. suggested — not in theory, but in practice. Thought
    experiments need not apply.

    Also: dots.pm needs to be marked as an experiment.

    --
    rjbs
  • Reverend Chip at Jun 12, 2013 at 9:12 pm

    On 6/12/2013 10:56 AM, Ricardo Signes wrote:
    * cui bono?
    * who will use it? (this is different than the first question, significantly)
    I will use it (no surprise), as will my dayjob once we convert to 5.20.
    I'll probably end up making a dotify helper program if/when the patch is
    merged; the . change to ~ is too fiddly for hand conversion.

    For context, my own application code and that of my cow orkers *always*
    uses:

        Method::Signatures::Simple
        Any::Moose [I won't use Moo until strictures is resolved]
        Mo?seX::Locked
        Mo?seX::StrictConstructor
        mro 'c3'
        no indirect
        namespace::sweep
        Scalar::Util qw( weaken )
        List::Util qw( min max )
        Hash::Util qw( lock_hash )
        Coro, AnyEvent [whenever concurrency is needed]

    So you see I already code in a dialect of Perl. Adding one more quirk
    to that dialect to make it better (for me and my peeps) is a no brainer.

    Of course I can't use dots in my CPAN modules for a long time. Those
    whose work consists entirely of CPAN modules would reasonably dislike
    dots. But they are not the world, nor even most of it.
    * how much will it cost to keep working over time?
    I know you know we can't see the future, so what does this mean?
    * how many subtle changes have we missed?
    How can we ever be sure? These are unknown unknowns.
  • Elizabeth Mattijsen at Jun 13, 2013 at 8:20 am

    On Jun 12, 2013, at 7:56 PM, Ricardo Signes wrote:
    * Ricardo Signes [2013-06-10T19:22:19]
    ...but there's an extra bit of context for all code: am I reading code that
    is traditional or dotty? So we've shaved one bit down in the tree while
    adding a top-level branch for context. Of course, that one you read once and
    keep in your head, while the other you re-encounter all the time. There's
    another tradeoff, which is that $x~=$re becomes stupid instead of a compile
    failure. This is just the kind of stupid thing that would bite me every day,
    despite my impeccable tyipng.

    I think that $x.y would've been better encoding from the start, but that
    having both now is worse, not better.

    *That said,* my current inclination is to say that this can land, because
    there seems to be great popular acclaim, and I'll not use it or include it in
    my much-imagined 2E of Perl Best Practices. My concern is the future
    maintenance cost. So far, it seems low.
    There's been a bunch of talk. My questions remain:

    * cui bono?
    I don't think this makes sense for Perl 5. First of all, it will make it easier for people coming from other languages to understand Perl code (e.g. front-end developers using Javascript needing to get some backend Perl into place). Secondly, it will make any migration from Perl 5 to Perl 6 for a developer more easy. These are all things we do not want to happen!

    Or do we?

    I think the only factor in the final decision on whether or not to include this in Perl 5's core, is the future maintenance cost. Seeing as to how few of Perl's post 5.10 new capabilities are actually in use in any CPAN module, I have no worry we will see much use of "use dots" there any time soon. And who cares about what people decide to do in Darkpan? They will either use it (like Chip indicated), or they won't.

    As an experienced programmer, well versed in multiple languages, you already should be able to change your "parsing" rules quickly when reading other people's programs, even if they are still only in classic Perl 5. Let alone in another language, such as Javascript and the like.



    Liz
  • Breno at Jun 13, 2013 at 3:14 pm

    On Wed, Jun 12, 2013 at 2:56 PM, Ricardo Signes wrote:
    There's been a bunch of talk. My questions remain:

    * cui bono?
    People coming from other languages and either missing their own idioms
    or finding it hard to figure out the arrow when writing their own
    code. We've been doing it forever, but so what? Since TIMTOWTDI, I
    feel those people should be enabled by Perl 5 with potential
    alternatives. Also, as Liz pointed out, people thinking about
    (eventually) porting their 5 code to 6 (since dots appeared to be
    considered enough of a good and perlish idea to be fully incorporated
    there).
    * who will use it? (this is different than the first question, significantly)
    People who own their own codebase and find the dots syntax simpler or
    easier to grasp, who don't really care about backcompat or CPAN in
    general, as I hardly think modules using 'dots' will be used on CPAN a
    lot. I also don't think this should be a problem when deciding this,
    since we've had that before and I'm not aware of any heavily depended
    upon CPAN modules using //, say or given/when - and I'm talking about
    features that ship with Perl 5 for almost 6 years now. Are we really
    afraid that a 'dots' pragma will be massively adopted? Because if we
    are, then I feel this is even more reason to do it.
    * how much will it cost to keep working over time?
    * how many subtle changes have we missed?
    Patch seems simple and reasonable enough, but I don't think that
    should be a problem at all because...
    Also: dots.pm needs to be marked as an experiment.
    Isn't the experimental feature exactly for this kind of, well,
    experiment? We warn users, fix what comes up, and if we screw up or it
    becomes too much of a burden, we kill it, and they have been
    (literally) warned.

    I likely would not use it too (so what?) but I don't think anyone
    would have any trouble parsing it in their heads, and a scoped 'use
    dots' / 'no dots' sounds reasonable enough to me. I have seen a lot of
    people rooting for 'dots' for a long time now, be it as a standalone
    pragma, as a feature, as a CPAN module, as moving to another language,
    or as Perl 6.

    What are we so afraid of?

    Cheers,

    garu
  • Aaron Priven at Jun 10, 2013 at 5:29 pm

    On Jun 9, 2013, at 3:07 PM, Rev. Chip wrote:

    As discussed at YAPC, this patch adds the pragma "use dots" allowing users to
    write . instead of -> in all places. Infix ~ (a la Perl 6) provides string
    concatenation.
    I have never understood why a period is the best alternative to the admittedly unwieldy -> for this purpose, other than that that's what all the cool languages do. If you're going to change the punctuation, is this the best way? (I mean, in English a colon is used to introduce a "list or explanation preceded by a clause that can stand by itself", which seems more akin to how -> is used. And single colons are used infrequently in Perl. Yes, I know, "everybody wants the colon.")

    --
    Aaron Priven, aar...@...com, www.priven.com/aaron
  • Christian Walde at Jun 11, 2013 at 9:27 am

    On Mon, 10 Jun 2013 00:07:58 +0200, Rev. Chip wrote:

    Infix ~ (a la Perl 6) provides string concatenation.
    Just a thought, inspired by Template::Toolkit: Couldn't _ be used for that?

    --
    With regards,
    Christian Walde
  • Aristotle Pagaltzis at Jun 11, 2013 at 11:29 pm

    * Christian Walde [2013-06-11 11:30]:
    On Mon, 10 Jun 2013 00:07:58 +0200, Rev. Chip wrote:
    Infix ~ (a la Perl 6) provides string concatenation.
    Just a thought, inspired by Template::Toolkit: Couldn't _ be used for
    that?
    That is what Perl 6 originally had, and they seem like about the worst
    possible choice.

    They’re part of valid identifiers, so must often follow whitespace,
    resulting in _ lots of _ floating _ lone _ underscores which draw too
    much attention to the empty space above them because of their prominence
    beneath it. Droppings on the floor where something fell off the wall.

    And when they can be packed tight due to lack of ambiguity in context,
    "that just"_"looks"_"even worse". They crowd up to the neighbouring bits
    but at the same time recede visually, leading to the distinct chic of
    cramped slum architecture on muddy streets.

    (Within_identifiers, it_just_evokes_whitespace, so there it isn’t at all
    problematic. Still, I have always been a-fan-of-using-dashes-instead
    when I can, as in XSL and XPath, and as of some time ago – you guessed
    it – Perl 6.)

    The dot is really the very best choice for concatenation – Perl got that
    one exactly right. But if you have dedicated the dot to other purposes,
    then the tilde seems ~ about ~ as good as ~ you can manage ~ instead. It
    even has a subtle visual connotation of rope tying things together.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Paul "LeoNerd" Evans at Jun 12, 2013 at 11:40 am
    I wonder; much has been discussed on the (lack of) actual new ability
    this patch gives, instead deferring to arguments on neater syntax,
    conformity with other languages, and help for new people learning the
    language.

    Personally, I happen to _prefer_ -> over . as an indirection operator.
    It calls out to the fact that the LHS is a reference, that the thing
    being operated on is "over there" and a neat little arrow to indicate
    where it is. It reminds me I have to -follow- a long chain of
    references to get to the end of

       $foo->bar(@args)->{key}->[index]
    which I wouldn't get with

       $foo.bar(@args).{key}.[index]


    Secondly, given all these other {}s and []s and so on, there's a limit
    to which anyone can really claim it is visually neater. If we wanted
    more visual neatness in some Perl code, can I posit my new hypthetical
    invention, sigils.pm?

       no sigils;

       my message = "Hello, world";
       say message;

       my names = ["Frank", "Jim", "Bob", "Alice"];
       push names, "Eve"; ### Thanks 5.14 ;)
       say grep { length == 3 } @names;


    Thirdly, has anyone actually -asked- a newbie whether they want this
    choice? Newbies generally do not want choices - they don't want to be
    told "hey, you can do it this way, or that way, whatever you wish".
    They are new, they can't make that informed choice yet. This choice of
    two different spellings for -exactly- the same thing will not help
    anyone. Already now, we tell everyone to always "use strict; use
    warnings;" but then most code samples you find around don't -actually-
    have those first lines. They're just sortof implied. What will happen
    if "use dots" becomes standard, that everyone should use all the time
    so nobody writes it in little examples? Unlike with strict or warnings,
    dots actually -changes- the meaning of the written code that follows
    it. Missing that on an example will lead to massive amounts of newbie
    confusion when they copypaste it and find it doesn't work, because the
    pragma is not in effect.

    This I feel is the real problem here - a well-intentioned attempt to
    help some newbies will in fact result in a much worse situation for
    them, and no improvement for anyone else.


    In summary then, while I feel that this is a cute implementation of an
    interesting situation (and credit where credit is due - it does show
    how neatly such a thing can be implemented) I don't feel this change
    will help anybody, and will hinder the people it tries to help the most.

    --
    Paul "LeoNerd" Evans

    leo...@...uk
    ICQ# 4135350 | Registered Linux# 179460
    http://www.leonerd.org.uk/
  • Paul "LeoNerd" Evans at Jun 12, 2013 at 11:50 am

    On Wed, 12 Jun 2013 12:40:11 +0100 Paul "LeoNerd" Evans wrote:

    no sigils;

    my message = "Hello, world";
    say message;

    my names = ["Frank", "Jim", "Bob", "Alice"];
    push names, "Eve"; ### Thanks 5.14 ;)
    say grep { length == 3 } @names;
                              ----^
    I should note, for clarity, this is not the lexical variable "@names"
    with a sigil, but instead the @ array-indirection operator @{...} being
    applied to the sigil-less "names" variable.

    What 5.14 started, with its ability for core operators to treat ARRAY
    and HASH references as if they were actual array or hash variables, can
    be so much more than just that. It can remove the three-namespace
    scalar/array/hash naming, the sigils, and become a lot neater,
    simpler, less cluttered way of writing code that, if you care about
    looking similar to other languages (did I hear JavaScript and Python
    mentioned?), does a lot more in this direction than changing -> to .

    --
    Paul "LeoNerd" Evans

    leo...@...uk
    ICQ# 4135350 | Registered Linux# 179460
    http://www.leonerd.org.uk/
  • Ricardo Signes at Jun 12, 2013 at 12:23 pm
    * Paul LeoNerd Evans [2013-06-12T07:40:11]
    This I feel is the real problem here - a well-intentioned attempt to
    help some newbies will in fact result in a much worse situation for
    them, and no improvement for anyone else.
    I asked on Monday: for whom does this feature have (the most) positive
    value?

    It is not clear to me that the intent here was to help new Perl programmers.
    It will make things somewhat harder, as "all" the documentation will use
    traditional style, and (as of yet) conversion to dotty style will not be a
    simple matter of substitution, given the cases in which tr/./~/ will result in
    a unary ~.

    It seems like this has to be aimed more at programmers who already know Perl,
    but want to save some of those keystrokes.

    --
    rjbs
  • Kent Fredric at Jun 12, 2013 at 12:48 pm

    On 12 June 2013 23:40, Paul LeoNerd wrote:
    $foo->bar(@args)->{key}->[index]
    which I wouldn't get with

    $foo.bar(@args).{key}.[index]
    On a related note, could 'dots' be asked to use another presently
    unclaimed, and possibly utf8 character instead of '.' ?

       use dots char => "→";
       $foo→bar(@args)→{key}→[index]

       # Hurr durr PHP
       use dots char => "\\";
       $foo\bar(@args)\{key}\[index]


    --
    Kent
  • Paul "LeoNerd" Evans at Jun 12, 2013 at 1:07 pm

    On Thu, 13 Jun 2013 00:47:55 +1200 Kent Fredric wrote:

    use dots char => "→";
    I'm not sure that -quite- qualifies under ease-of-typing, but sure
    looks fun ;)

    --
    Paul "LeoNerd" Evans

    leo...@...uk
    ICQ# 4135350 | Registered Linux# 179460
    http://www.leonerd.org.uk/
  • Kent Fredric at Jun 12, 2013 at 1:12 pm

    On 13 June 2013 01:07, Paul LeoNerd wrote:

    On Thu, 13 Jun 2013 00:47:55 +1200
    Kent Fredric wrote:
    use dots char => "→";
    I'm not sure that -quite- qualifies under ease-of-typing, but sure
    looks fun ;)

    --
    Paul "LeoNerd" Evans

    leo...@...uk
    ICQ# 4135350 | Registered Linux# 179460
    http://www.leonerd.org.uk/
    Well, my logic train was "not everyone has the same keyboard layout".
    Sure, you may not have → on your keyboard as a single key press, but what
    if somebody does? That would be a typing improvement for them.

    And when you start thinking of international key layouts, you find people
    who have problems with things we on US Layouts take for granted, and it may
    be more convenient for them to use, say, » instead of -> , if they can't
    type ">" in a single keypress but can type » in a single key press.

    foo»bar»( hello )

    Not too bad =)
  • H.Merijn Brand at Jun 12, 2013 at 2:04 pm

    On Thu, 13 Jun 2013 01:11:56 +1200, Kent Fredric wrote:
    On 13 June 2013 01:07, Paul LeoNerd wrote:

    On Thu, 13 Jun 2013 00:47:55 +1200
    Kent Fredric wrote:
    use dots char => "→";
    I'm not sure that -quite- qualifies under ease-of-typing, but sure
    looks fun ;)
    AltGr-'-'-'>' (→) is almost as easy as ->

    In the code *I* write, I doubt if I use -> more than I do use .
    Shift-` for ~ sure doesn't weigh up for me in less keystrokes for .
    instead of -> and *I also prefer -> for ease of reading.

    As George said, it is all in the perception of the programmer, and as
    long as I can write it my way, and the person preferring whatever
    syntax can do it her/his way and we do not make eachothers lives more
    difficult, I am completely fine with that. I also agree with rjbs that
    consistency in a team is vital, but if you write a CPAN module, please
    use whatever you like, but remember: Do not use that syntax in the
    documentation, as noone will understand it. (unless of course it is
    describing the syntax itself).
    --
    Paul "LeoNerd" Evans
    Well, my logic train was "not everyone has the same keyboard layout".
    Sure, you may not have → on your keyboard as a single key press, but what
    if somebody does? That would be a typing improvement for them.
    I think that *reading* code is way more important in this discussion
    than *typing* code. Once written, how often do you read it when finding
    problems? If you can honestly say that you gain time reading . as deref
    instead of -> (e.g. because it is a mixed language project and all
    other languages use .), then using the dot in that project seems
    warranted to me. I see no gain in less keystrokes for this feature.
    And when you start thinking of international key layouts, you find people
    who have problems with things we on US Layouts take for granted, and it may
    be more convenient for them to use, say, » instead of -> , if they can't
    type ">" in a single keypress but can type » in a single key press.
    AltGr-'>'-'>' (») and many more are - at least on Linux - just a
    ~/.XCompose away

      if ($a ≈ $b) say "a ≅ b";
    foo»bar»( hello )

    Not too bad =)
    I want to stress the levels :)

      foo→bar ($val)▷print▶value;

Related Discussions