http://www.perlmonks.org?node_id=1038191

Today a proposal came up on the Perl 5 Porters mailing list to have a new pragma that would replace the dereference and method call operator (->), with the dot (.). Since this is now used as the concatenation operator, for the purpose of concatenation the tilde (~) would be used. (It is now used as the one’s complement operator, and would still mean that in unary contexts, but between two terms would mean to concatenate.)

There are two pretty good reasons for this. First, the dot is easier to type than the ->, and since this is one of the most used operators in all of Perl, it would save a lot of typing (and saved characters, the necessity for wrapped lines, etc.). Second, many other common computer languages use the dot as the object method call, so this would ease learning of Perl by those familiar with other languages (and, I suppose, learning of other languages by people familiar with Perl).

I’m not sure this is the right thing to do, for a couple of reasons. One of the reasons is purely semantic. In Western written natural languages, the dot is normally used to end a sentence. That’s the opposite meaning of the dot here: it indicates that the part after the dot is a qualification or function dependent on the part before the dot. If any single character in ASCII indicates that, it would be the colon (:), a character which, on its own, is terribly underutilized in Perl, introducing the third part of the conditional operator (?:).

But the other reason is the joint use of tilde as binary concatenation operator and unary one’s-complement operator. These are two uses of the same character that have absolutely nothing to do with each other. The perl interpreter will, no doubt, have no trouble determining whether, in a particular spot, the use of the tilde is unary or binary. But will that be as easy for people to figure out?

I hesitate to go further, because I’m afraid it will mark me as un-perly and I’ll be exiled, forced to live in a world that uses significant whitespace. But I think the tendency of Perl to use lots of different ASCII punctuation in lots of different ways can be confusing, especially when white space isn’t always required between terms. Is that “&” the bitwise and operator or the sigil for a code reference? Does that dot mean concatenation, or is it the decimal point? Is the three-dot combination ... the flip-flop operator or the “yada yada yada” operator indicating that more is to be written later? Is that octothorpe (#, confusingly enough sometimes called the hash) introducing a comment or is it part of the $# array count symbol?

And, of course, punctuation variables add more ambiguity. I know that perl generally can figure this out, although the several entries in perldiag beginning “Ambiguous use of…” makes me wonder. But people often have more difficulty. (In spoken natural language, one can always inquire of the speaker to clarify ambiguity; not so here. Perhaps natural languages are different than computer languages? Can I say that?)

It’s too late now to go back and give Perl a set of clear, unambiguous operators.

(In my dreams I imagine a Perl where punctuation variables are replaced by variables beginning with control characters. Where terms made of punctuation would always be separated from other punctuation terms by whitespace [so +=- would be a trigraph, not an addition-assignment followed by a unary minus]. Where . is always the decimal point; where & and % are either sigils or operators but not both. Then I start thinking about whether @fred could be the same as @$fred, and &fred the same as &$fred, and if so whether we really need @fred and &fred at all, and then whether we need sigils at all, and then I wake up in a cold sweat.)

But, although perhaps my opinion is colored by a deep unperliness, I don’t think adding more ambiguity is the right direction.

Just to be clear, I don't actually program in much anything except Perl (and, shudder, Applescript)... so I don't think I can be accused of being corrupted by the outside. Naïve about other languages, certainly.

Replies are listed 'Best First'.
Re: Thoughts on replacing -> with .
by davido (Cardinal) on Jun 11, 2013 at 06:59 UTC

    If this is seriously being considered (as opposed to the lively banter that goes on within the p5p list, usually leading to no change), I'm very much opposed.

    This is Perl. I want to be able to look at Perl code and know that the -> operator does what it's been known for more than a decade to do, and that the ~ and . operators do what they also are expected to do. I don't want to have to look through the code for some pragma use that changes the meaning.

    I totally get the usefulness of // and //=. I even get the well intentioned but possibly overly ambitious and misguided rationale that brought us ~~. But to change the meaning of existing operators just so that -> is easier to type, and looks more like JavaScript... that's an utter waste of time and energy, at best. At worst, it will contribute to harder to maintain, harder to understand code as well as an entirely new round of Perl-internals bugs to squash before finally deciding it was a bad idea and deprecating it for Perl 5.24.

    If it's such a great idea, let someone implement it via overload and put its use into production. If he's still employed in 60 days, we can revisit the issue. ;) I do see that Acme::RenameTheOperators is an available namespace.

    It's fine to dream and think, "what if?" But honestly, before a change gets into the core, someone ought to be asking the question, "What problem is this solving that justifies the additional complexity?" Because make no mistake, this does introduce additional complexity. And it doesn't make anything possible or easier that was previously impossible or difficult.


    Dave

[reply]
[d/l]
[select]

      I just wanted to follow up by mentioning that I have now read the entire Perl5-Porters thread, and am surprised at how well received this is. There are a few dissenters, but a lot of "hey, neat" sentiment.

      My opinion remains the same, if it doesn't make impossible things possible, or hard things easy, it isn't worth the added complexity, confusion, and certain need for debugging that would be levied on the poor user base. But perhaps it does beg a different discussion; the proposed change requires a patch to the Perl code base. Rather than patch to make this change, patch to make it easier to implement such a change without modifying Perl itself. In other words, make it possible for mortals to create a "dots" pragma without each such pragma requiring a change to the Perl core. That would be a more generalized and more useful solution, and while it would still be adding complexity and a round of debugging, it would at least be giving the users the tools rather than the widget made by the tools. We know exactly how a "dots" pragma would be used (if at all). Its advantages seem only to shave a few keystrokes. What benefits a language more is those features that are general enough that we cannot predict all use cases.

      If hooks were implemented in Perl's code base to allow a "dots" pragma to be created without recompiling Perl, the pragma could be placed on CPAN rather than as part of the Perl core. CPAN is really where something like this belongs. And someone might actually find a way to use those hooks that is more meaningful than just re-purposing dot, and eliminating ->.


      Dave

[reply]
        I believe it's the squawking of overzealous minority, which gives the impression of the silent majority -some thinking this is a sick joke and others really just too tired at this point to defend yet another trojan horse proposal.
[reply]
Re: Thoughts on replacing -> with .
by hdb (Monsignor) on Jun 11, 2013 at 06:48 UTC

    Coming from a C++ background (though not having used it for a long time), it always made a lot of sense to me, that the method call operator is ->. After all, objects in Perl are used via references, which is closer to a pointer to an object than to an object itself.

    Loosing the dot as string concatenation is IMHO a rather severe event. The tilde is a bad replacement choice, in particular in the form of the assignment operator. $str ~= "ccc" will be concatenation, $str =~ "ccc" will be matching. Quite confusing and a likely cause for error.

    The visual appearance of -> versus the dot for calling methods is a bad guide in my opinion, not even taking into account that code will look more like VB than classic Perl. What will be gained in changing -> to dot, will be lost from the change of the dot to the tilde. There is good reason that this character only appears rarely in code and usually in conjuntion with the equal sign to form the matching operator.

    The esthetics of well written Perl code contrasted with the visual appearance of a tilde separated file. What a terrible outlook!

[reply]
[d/l]
[select]
Re: Thoughts on replacing -> with .
by Jenda (Abbot) on Jun 11, 2013 at 15:21 UTC

    Changing the operators like this was a bad idea for Perl 6 and is an even worse idea for Perl 5. pragma or nopragma.

    Introducing two incompatible yet similar syntaxes for no good reason would confuse the hell out of everyone, including those poor guys coming from the languages that use the dot. Especially them. They would see examples using ->, they'd see examples using dots, they'd see examples using dot that means concatenation, ...

    Bad proposal, no cookie!

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

[reply]
      I agree that this is a bad idea for Perl 5, but why is it bad for Perl 6?
[reply]

        For the same reasons, though on a very slightly lower scale. For very little gain, it causes a lot of confusion. Or rather would if Perl6 ever started being used and there was a chance to see and confuse Perl5 and Perl6 code.

        I don't think Perl6 ever gains a reasonable sized comunity. Not because it's several years late, though that adds to the problem, but because it went completely overboard with special characters. While they "simplified" sigils (read: changed the way they worked for years) and changed the object-method "separator" to something that's kinda resembling the standard (again changing things that worked for years causing confusion), they also introduced lots of new line-noise operators and their combinations and twists.

        If Perl5 looked like line noise to an unaccustomed eye, Perl6 looks like line noise even to those that love and use Perl for years.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

[reply]
Re: Thoughts on replacing -> with .
by talexb (Chancellor) on Jun 12, 2013 at 16:40 UTC

    I'm not a fan of this change.

    Whenever I hear that something's "easier to type", I think of PHB's exclaiming, "The source code's much smaller now!" -- it's mostly irrelevant.

    For me, the point of high level languages is that the source code can easily be read by developers, so that they can get the gist of what's going on. You have to read a whole pile of assembler to get an idea of what's going on. I like the -> shape -- it reminds me that the thing to the left is a reference (or a pointer, as my 15 years of C tells me), either to a data structure or an object. I like that.

    You're confused about what that & means? I think context explains it very nicely. That's as it should be.

    What does the dot mean here? Context solves this again.

    What's the octothorpe doing? Context.

    The human brain's actually very good at dealing with context. It allows us to understand the difference in pronunciation of "Get the lead out!" and "Lead the way!", where the key word 'lead' is spelled the same way but sounds different in each of the two phrases.

    If Perl were a new language, I can see there being some leeway. I've been fortunate to use Perl for about 15 years, and it was around for 10 years before that.

    I think this change will be a poor choice for Perl.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]
[d/l]
[select]
Re: Thoughts on replacing -> with .
by hippo (Bishop) on Jun 11, 2013 at 17:31 UTC

    For those, like me, who are not habitual readers of p5p here is the discussion.

    FWIW I think this is a really bad idea. If typing "->" is such hard work for someone they should become au fait with the macro system in their $EDITOR. There is no reason at all for that to affect the rest of us. As a perl user of almost 20 years now the use of the dot as the concatenation operator is so ingrained that I suspect it would be almost impossible to supplant. Let us hope that sense is seen and that this "feature" is parked indefinitely.

[reply]
Re: Thoughts on replacing -> with . (safe dereference)
by Anonymous Monk on Jun 11, 2013 at 10:55 UTC
    Me? I want the colon operator CGI:new:param('colon');

    But seriously, I don't mind . in other languages, but in perl? It makes me queasy

    OTOH, what would be safe dereference?
     -. $rock-.()-.the-.kasbah(); $rock-.  ()-.  the-.   kasbah();
     ~. $rock~.()~.the~.kasbah(); $rock~.  ()~.  the~.   kasbah();
     &. $rock&.()&.the&.kasbah(); $rock&.  ()&.  the&.   kasbah();
     ?. $rock?.()?.the?.kasbah(); $rock?.  ()?.  the?.   kasbah();
     +. $rock+.()+.the+.kasbah(); $rock+.  ()+.  the+.   kasbah();
     !. $rock!.()!.the!.kasbah(); $rock!.  ()!.  the!.   kasbah();
     -.. $rock-..()-..the-..kasbah(); $rock-.. ()-.. the-..  kasbah();
     -.-. $rock-.-.()-.-.the-.-.kasbah(); $rock-.-.()-.-.the-.-. kasbah();
     ==. $rock==.()==.the==.kasbah(); $rock==. ()==. the==.  kasbah();
     ?-. $rock?-.()?-.the?-.kasbah(); $rock?-. ()?-. the?-.  kasbah();
     -.? $rock-.?()-.?the-.?kasbah(); $rock-.? ()-.? the-.?  kasbah();
     &-. $rock&-.()&-.the&-.kasbah(); $rock&-. ()&-. the&-.  kasbah();
     &&-. $rock&&-.()&&-.the&&-.kasbah(); $rock&&-.()&&-.the&&-. kasbah();
     -&. $rock-&.()-&.the-&.kasbah(); $rock-&. ()-&. the-&.  kasbah();
     -&&. $rock-&&.()-&&.the-&&.kasbah(); $rock-&&.()-&&.the-&&. kasbah();
     -.& $rock-.&()-.&the-.&kasbah(); $rock-.& ()-.& the-.&  kasbah();
     -.&& $rock-.&&()-.&&the-.&&kasbah(); $rock-.&&()-.&&the-.&& kasbah();
     -=. $rock-=.()-=.the-=.kasbah(); $rock-=. ()-=. the-=.  kasbah();
     =-. $rock=-.()=-.the=-.kasbah(); $rock=-. ()=-. the=-.  kasbah();
     ?. $rock?.()?.the?.kasbah(); $rock?.  ()?.  the?.   kasbah();
     ?-. $rock?-.()?-.the?-.kasbah(); $rock?-. ()?-. the?-.  kasbah();
     ?-.: $rock?-.:()?-.:the?-.:kasbah(); $rock?-.:()?-.:the?-.: kasbah();
     ~.: $rock~.:()~.:the~.:kasbah(); $rock~.: ()~.: the~.:  kasbah();

    $f.{a}.{b}.{c}
$f->{a}->{b}->{c}
$f->{a}{b}{c}
$$f->{a}{b}{c}
$f.{a}{b}{c}

    [download]

    I hope I muddied the waters some :)

[reply]
[d/l]
[select]
Re: Thoughts on replacing -> with .
by sundialsvc4 (Abbot) on Jun 11, 2013 at 19:01 UTC

    It would be a “gratuitous change,” contrary to decades of Perl history, and for no apparent better reason than “someone out there decided that to do so would make Perl somehow –er.”   Adding grammar-altering pragmas, just to let people who can’t make up their minds avoid doing so, would be even worse, because now you have to notice whether you said use apples; or use oranges;.   You’ve added a cognitive burden to the human being, who now has to wade through a large and unfamiliar legacy program that uses both alternatives (of course ...).   And all of this “for what, exactly?”

    Hmm... how far could we take this?   ;-)

    use COBOL;

[reply]
Re: Thoughts on replacing -> with .
by perl514 (Pilgrim) on Jun 11, 2013 at 11:22 UTC

    Hi,

    I use Perl once in a while, and still think that -> should not be replaced. Leave it be if that's possible.

    Perlpetually Indebted To PerlMonks

    use Learning::Perl;
use Beginning::Perl::Ovid;
print "Awesome Books";

    [download]
    http://dwimperl.com/windows.html is a boon for Windows.

[reply]
[d/l]
[select]

      I find that many people do something like:

      $var->{key1}->{key2}->{key3}

      [download]

      when the following should suffice:

      $var->{key1}{key2}{key3}

      [download]
[reply]
[d/l]
[select]

        I’m one of those people, and I’m not entirely sure why I do it. I’m fully aware that the later arrows are optional. The one arrow notation feels a bit asymmetric, and it doesn’t show that they all are refs in there, I guess.

[reply]

        I usually write ${${$$var{key1}}{key2}}{key3}, or, very rarely $$var{key1}{$key2}{$key3} or an intermediate variant. I never use arrow dereferencing.

[reply]
[d/l]
[select]
Re: Thoughts on replacing -> with .
by choroba (Cardinal) on Jun 11, 2013 at 07:51 UTC
    Another "small" step to make Perl 5 closer to Perl 6?
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]

      Maybe, if we're making operator changes, we could go all out.

      use colons - uses : for method calls and dereferencing. Uses !! for introducing the last part of the ternary operator. (Uses of "!!" to mean "not not" will have to be replaced by "! !", that is, with a space in the middle. This is clearer anyway.)

      use colon_equals -- uses := for assignment instead of =, and uses = for numeric comparison

      use nostash -- Eliminates the stash, in favor of just having a scalar entry and dereferencing as necessary. @x becomes shorter syntax for @{$x}, %x shorthand for %{$x}, you get the idea.

      use worddot -- "." is confusing, since inside regular numbers (and v-strings I guess) it forms part of a term, but elsewhere is an operator that separates terms. (Why doesn't 5.5 result in the concatenation of the stringifications of the two 5s?). This pragma would (as in, I vaguely recall, QuickBASIC) make dot a word character, instead of "_". This pragma would replace "_" with "." except that the decimal point would still be "." Then "." would always be a character inside a term, and _ would always be a regular punctuation character, usable for operators.

      Might be a while before I can learn enough to write patches...

[reply]
[d/l]
[select]
        and of course the perldocs need to be cleaned too!

        Cheers Rolf

        ( addicted to the Perl Programming Language)

[reply]

        That ?? !! ternary operator in P6 is hideous.

[reply]
[d/l]
Re: Thoughts on replacing -> with .
by Ralesk (Pilgrim) on Jun 12, 2013 at 11:14 UTC

    A very definite no from me too.

    I agree with most points brought up above, especially the cognitive burden one and the havoc of ~= versus =~.

[reply]
[d/l]
[select]

      Note that =~ and ~= are both valid Perl already.

[reply]
[d/l]
[select]

        Hmm, I don’t see ~= in perlop; and ~ is the unary bitwise negation operator, so it wouldn’t make much sense to have ~=. What is it?

[reply]
[d/l]
[select]
Re: Thoughts on replacing -> with .
by radiantmatrix (Parson) on Jun 17, 2013 at 21:36 UTC

    This is a big change, I hope the Porters don't rush to any decision. My thoughts in brief, as a Perl developer for nigh-on 20 years:

    1. Being "more like other languages" is not a good reason for a major operator change
    2. -> is, fundamentally, a dereference operator; it's used for objects because Perl objects are blessed references. Changing the operator for objects but not other references needlessly hides this
    3. ~ as a concatenation operator is, IMO, a recipe for developer confusion
    4. In most code I've worked with, concats are vastly more common than method calls. Why make the less-common operator easier to type and the more-common one harder to type? I acknowledge this may only reflect my opinion and the way I use Perl
    5. I happen to like the visual separation that -> provides. Its sheer width helps make method calls stand out; likewise, I like . as a concat, since its narrowness helps see that the elements "run together"

    I have always wondered why no one seems to have proposed the use of some variant of the :: notation as an optional alternative to ->...

    <–radiant.matrix–>
    “A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.” — Herm Albright
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
[reply]
[d/l]
[select]
Re: Thoughts on replacing -> with .
by Your Mother (Archbishop) on Jun 11, 2013 at 19:13 UTC
    You have caused confusion and delay.
[reply]
Re: Thoughts on replacing -> with .
by mrallen1 (Initiate) on Jun 11, 2013 at 16:54 UTC
    You will be delighted to learn that Erlang uses : for method dispatch.
[reply]
[d/l]

      Well, I guess that's an argument for the colon over the dot, although I'm not sure it's really a good idea to change this at all.

      One change that might, maybe, make sense would be to allow Unicode operators:

      use utf8;
use Something;
my $obj = Something→new(ARG⇒'value');
      I'm not sure, but it might be reasonable, and people could have their editors rewrite things or bind a key, and it would take less space in listings. But not if it means that -> and => would then not work.

[reply]
[d/l]
[select]
Re: Thoughts on replacing -> with .
by vsespb (Chaplain) on Jun 16, 2013 at 15:23 UTC
    IMHO This is really bad proposal.
[reply]
Re: Thoughts on replacing -> with .
by perlfan (Vicar) on Jun 11, 2013 at 17:54 UTC
    Quite simply, this change is both dishonest and subversive. We all know what the real reason for such "innocent" and "easy" changes are.
[reply]

Back to Meditations