in reply to Re^4: Two more Features Perl 5 Maybe Needs
in thread Five Features Perl 5 Needs Now

I can tell you feel strongly about it, but I remain utterly and absolutely unconvinced that Perl needs to add more sigils in order to stay relevant. In fact, I believe that that would be going in exactly the wrong direction. Perl should drop sigils entirely. That would do a lot to convince the rest of the programming world that Perl is, or even could be, relevant.

(Of course, making such a change would entail changing other aspects of the language, such as context. But that would be OK, imho. Whatever is necessary to kill the sigil silliness.)

Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
  • Comment on Re^5: Two more Features Perl 5 Maybe Needs

Replies are listed 'Best First'.
Re^6: Two more Features Perl 5 Maybe Needs
by chromatic (Archbishop) on Dec 21, 2008 at 20:39 UTC
    Perl should drop sigils entirely.

    Having actually patched the Perl 5 parser and lexer multiple times, I'm going to pull an argument from authority and say that if you like never getting new features in Perl, dropping the sigils is a wonderful idea.

    To make Perl work without sigils, you probably have to drop context, you definitely have to drop barewords, you likely have to drop prototypes, you may have to drop import() in some cases, and you can probably get rid of BEGIN. Alternately, you have to namespace or prefix new keywords to prevent collisions.

    I can't imagine a pleasant result.

[reply]
[d/l]
[select]

      In case it wasn't clear, my anti-sigils rant is issued in full "wish-list mode". I don't actually expect anybody to do it, nor that it would even be feasible. And let me also state clearly for the record (in case anyone suspects otherwise) that I am very comfortable with sigils, and don't regret them in Perl 5 at all. But it's not about me.

      Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
[reply]
Re^6: Two more Features Perl 5 Maybe Needs
by Lawliet (Curate) on Dec 21, 2008 at 20:23 UTC
    Perl should drop sigils entirely.

    No! The conveniences of having sigils surely outweigh the inconveniences (whatever they are). Although, I know naught of other languages so I cannot give a convincing argument to why things should or should not change. I can, however, say that the current way works great for me :D

    That would do a lot to convince the rest of the programming world that Perl is, or even could be, relevant.

    I think I am confused about the word 'relevant' in this discussion. Relevant to what?

    And you didn't even know bears could type.

[reply]
Re^6: Two more Features Perl 5 Maybe Needs
by LanX (Saint) on Dec 21, 2008 at 20:00 UTC
    Well Princes of Perlport ... Sigils or not sigils, is this here the question?

    Many styleguides in many languages tell the programmers to use a naming convention e.g. special post- or prefixes to distinguish which datatype you use. (e.g. Hungarian notation)

    For me, well done sigils are just a build-in naming convention and perl6 tries to go this way, by making @arr[1] acting like $arr[1].

    And IMHO Perl without sigils already exists, it's called Ruby! ; )

    UPDATE: seriously, changing the parser such that he accepts variables without sigils IMHO results in reinventing Ruby...

[reply]
[d/l]
[select]
      a built-in naming convention

      That's sounds paradoxical; and in any case seems to violate the timtowtdi spirit of Perl.

      by making @arr[1] acting like $arr[1]

      And that's part of my argument: One of the few situations where sigils actually serve a constructive semantic purpose is being eliminated. Sigils are being rendered more gratuitous, not less. And sigils clearly violate the "Huffman encoding" philosophy of Perl grammar.

      Anyway, I've argued this in the past, and it's clear that @larry are quite undivorceably married to the idea of sigils, so they're staying. I have faith that Perl can cling to its relevance by other means.

      it's called Ruby!

      Need I say more.

[reply]
        > That's sounds paradoxical; and in any case seems to violate the timtowtdi spirit of Perl.

        Well my "language" might be creative but I think you got the point! ; )

        But I can't imagine to easily eliminate sigils while continuing the mechanisms of perl's contexts...

        I'd prefere having even more sigils, also for coderefs and objects, since single symbols are better to read than ..._cref, ..._aref, ..._href and ..._oref

        >> it's called Ruby!
        > Need I say more.

        Actually Ruby HAS sigils ... just at other places!

        And I really like the concept e.g. of distinguishing instance- and class-variables! While it's ugly to double sigils @@classvar it's much more readable to write @instvar than $self->{instvar}

        So for readability I'm in favour of much more sigils!

        And by making them optional to use: 

         
use Sigil qw{ € ¥ ¢ ° };

        [download]
        you still have MTOWTDI!

        I'd ask "so why don't you use Ruby straight away?" if the answer wouldn't be obvious... "Because it's not compatible with CPAN".

        So compability must be the crucial feature of any language extension. New sigils beyond standard ASCII can lead to this compability without many conflicts with old code.

        either in the coderange from 128-255 or Unicode! Keymapping of the editor might be a problem, so there might be a fallback solution like $@arr instead of €arr, like the fallback solution in perl6 for » with >>.

        and all these extra sigil could be automatically translated in plain perl code.

[reply]
[d/l]
[select]

In Section Perl News