FAQ
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".

Author: Chip Salzenberg <chip@pobox.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__
+
+
+dots - perl pragma to use dots to follow references and call methods
+
+
+ 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
+
+
+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>.
+
+
+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 ]

+
+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
+

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

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 */

## Search Discussions

•  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);
•  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.

--tom
•  at Jun 10, 2013 at 10:01 am ⇧

"Rev. Chip" <rev.chip@gmail.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
•  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 •  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 •  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 •  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. •  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." •  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 •  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 •  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 •  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 •  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 •  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. •  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 plack@0.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 •  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 plack@0.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::more@perl-5.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/>
•  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::more@perl-5.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 •  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.) •  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 •  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 •  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::more@perl-5.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::more@cp5.6.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. •  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 •  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 •  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... •  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. •  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 <plokinom@gmail.com> •  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
•  at Jun 11, 2013 at 6:41 pm ⇧

On 6/10/2013 11:12 PM, Peter Rabbitson wrote:
away screaming after encountering the feature pragma
[citation needed]
[statistics needed]
•  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:
away screaming after encountering the feature pragma
[citation needed]
But, Sir! I come prepared! ;)

[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
•  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:
away screaming after encountering the feature pragma
[citation needed]
But, Sir! I come prepared! ;)

"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.
•  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
•  at Jun 12, 2013 at 8:31 am ⇧

On 6/12/2013 1:05 AM, Johan Vromans wrote:
Reverend Chip <rev.chip@gmail.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.)
•  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

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

-- Johan
•  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.
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. •  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

--
rjbs
•  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
•  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 •  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. •  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
•  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
•  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, aaron@priven.com, www.priven.com/aaron
•  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
•  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/>
•  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

leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
•  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

leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
•  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
•  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
•  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

leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
•  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

leonerd@leonerd.org.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 )

•  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 )

I want to stress the levels :)

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

## Related Discussions

Discussion Overview
 group perl5-porters categories perl posted Jun 9, '13 at 10:08p active Jun 15, '13 at 3:42a posts 64 users 25 website perl.org

### 25 users in discussion

Content

People

Support

Translate

site design / logo © 2016 Grokbase