-3

I understand the rules with sigils. I can make hashes from lists, and pass refs around with the mediocre-ist of them. What I don't understand are the benefits sigils provide in Perl.

Some of the reasons I've heard are:

  • String Interpolation
    • Ruby has the "#{myVar}" syntax, which solves almost all of these issues, including having full expressions without having to resort to the "@{[$count + 1]}" syntactical hack.
  • Readibility
    • IDEs. And any text editor worth its weight in salt has syntax highlighting.
  • Allowing for variable subNamespacing
    • Allowing me to declare $foo and @foo as two different variables will only lead to ruin in the future.

One very helpful feature in a programming language is consistency. My curiosity drives me to ask if I declare a list as "@foos", and a counter "$count", how does it make sense to need to access elements by saying "$foos[$count]"? Oh! But I may use the "@" if I'm reading elements out into list context; so saying "@foos[$idx1, $idx2]" now makes sense! I can tell from looking at the sigil that I'm going to be reading an array instead of a single scalar!

  • I can still tell I'm reading a single element by saying "foos[count]"
  • I can still tell I'm reading multiple elements by saying "foos[idx1, idx2]".
  • I can still tell I'm reading a single value by saying "foos{key}"
  • I can still tell I'm reading multiple values by saying "foos{key1, key2}"

This same pattern holds true for almost any case I can think of. The meaning of what is being done is clear no matter which sigil is being used, or none for that matter. The only difference is that I have to keep track of the context and be sure to keep sigils in line as well;

user63438
  • 5
  • 1
  • 3
    Counterexample: `@foos[$idx1]` gives you a list of one element, whereas `$foos[$idx1]` gives you a scalar value. – cdhowie May 09 '18 at 15:26
  • 3
    IDEs? I think you misunderstand where `perl` starts. Perl pre-dates the IDE that you seem to _need_ to work in some languages. Maybe that's not as true now, but ... I still find it very useful to be able to work in a programming language with little more than a basic text editor. – Sobrique May 09 '18 at 15:37
  • 2
    Re "*What is the benefit of Sigils in Perl?*", 1) The sigils tells what the type of variable is without having to use hungarian notation or similar. (Well, you could actually argue that it is a form of hungarian notation.) 2) The sigils allow scalars, arrays, hashes, subs, etc to have the same name. (Whether that's a good thing or not is another matter.) – ikegami May 09 '18 at 20:35
  • to ikegami's point, sigils let text editors such as vim, npp++ and TextMate provide syntax styling based on variable types, which I find to be useful – beasy May 10 '18 at 19:17
  • cdhowie: In a consistent world, @foos[$idx1] would give you a single element, and getting it in a list would mean putting it in a list: [ @foos[$idx1] ] – user63438 May 30 '18 at 13:37
  • @Sobrique: Things change. simply because it started from a classical stance where it made valid choices does mean the validity of those choices hold true to today. Situations must be considered in the reality of today, with the context of the past. – user63438 May 30 '18 at 13:39
  • @ikegami: The name of the variable should indicate what the variable contains. "$name" vs "name". If your naming is confusing, consider a better variable name. As for allowing multiple variables to have the same name, I don't consider making it easier to shoot yourself in the foot in a way no sane person would do, to be a good thing in just about any case; variable overloading like that should never be done, and so holds very little weight as a "plus" towards sigils/perl. – user63438 May 30 '18 at 13:42
  • @beasy Funny how those same editors can handle syntax highlighting of non-sigil'd languages just fine.... – user63438 May 30 '18 at 13:43
  • @user63438 uh yeah but they can't style based on variable type. differentiating variables is the point of sigils. it's not better out worse, it just is – beasy May 30 '18 at 13:52
  • as far as your point about maintaining the consistency of the sigil in all contexts, Perl6 takes a different approach than Perl5. in Perl6 the sigil of a variable never changes based on context. I use both 5 and 6 and have no problem with either one. – beasy May 30 '18 at 13:54
  • @user63438, You think you are contradicting me, but you're not. %animal vs $animal both contain information about an animal as you say, but the only the sigil indicates the type of the data as I said. /// Re "*I don't consider making it easier to shoot yourself in the foot*", When I pointed out this was a matter of debate, it wasn't an invitation to start one. It also meant I was already aware that someone people might feel your way. Congratulations on breaking the rules for nothing. – ikegami May 30 '18 at 15:46
  • @beasy So, in Perl 6 the sigils remain constant, meaning they can be replaced with convention, meaning they can be replaced with nothing, and so they provide no additional benefit... – user63438 May 30 '18 at 22:45
  • @user63438 in fact, in Perl6 you don't have to use sigils. you can instatiate any type of variable without a sigil. however, I usually still use sigils because I find that they do provide the benefits I and Ikegami have already stated. – beasy May 30 '18 at 22:50
  • @ikegami: I didn't mean to start a non-civil debate/discussion. Sigils introduce complexity and overhead to the language and the people who write/read the code. If it doesn't simplify situations or disambiguate then it's a pointless holdover from an earlier time. In the case you provided, it would make sense for $animal to contain some sort of string identifier and for %animal to be some sort of property bag about the animal, of which its name might be a property. The issue arrives when $animal might also refer to a reference to an %aninal, but may be some Moose-backed complex object. – user63438 May 30 '18 at 23:01
  • @ikegami: pt2: Once you begin to introduce more types than there are sigils, the sigils need to be overloaded and lose even more meaning. – user63438 May 30 '18 at 23:01
  • Re "*I didn't mean to start a non-civil debate/discussion*", But you did try to start a debate/discussion. Not allowed. Comments are not for that. – ikegami May 30 '18 at 23:03
  • Re "*Once you begin to introduce more types than there are sigils*", There can't be more variable types than there are sigils in Perl, by definition. – ikegami May 30 '18 at 23:04
  • @ikegami: Is a scalar a string, a number, a reference, or an object? They all use "$" for their sigil. That's at least 4 discreet types with one sigil. And I don't think I've heard a good answer as to what they add to the language which other non-sigil'd approaches already address. In that sense the original question remains unanswered. – user63438 May 30 '18 at 23:17
  • But those aren't types of variables. Those are types of values, and they have nothing to do with the sigil. And that has always been the case. There could even be more than one of those in a single scalar! – ikegami May 30 '18 at 23:18
  • `perl -MScalar::Util=dualvar -E'$x=dualvar(123,"abc"); say for 0+$x, "$x";'` No magic or overloads. `dualvar` truly creates a scalar with two values. – ikegami May 30 '18 at 23:27
  • In any practical sense, a variable is used as one type of value. Cute tricks can apply, but if a single variable is used as multiple types, it will introduce a while new round of developer headaches. – user63438 May 30 '18 at 23:31
  • Re "*In any practical sense, a variable is used as one type of value.*", No, not in Perl. $x = "456"; ($x contains a string) $x=123; ($x contains a signed int.) "$x" ($x contains a string and a signed int) – ikegami May 30 '18 at 23:32
  • In regards to dualvar, that is in no way helpful, utterly confusing to anyone maintaining the code, and can immediately be addressed by having either two variables or two values in a hash, referenced by sensible keys. – user63438 May 30 '18 at 23:33
  • They still exist. What you're saying is besides the point, and completely false for a few reasons. This program uses a triple var and a dual var: `open(my $fh, '<', "file") or die $!;` – ikegami May 30 '18 at 23:34
  • A variable may _hold_ multiple types, but as soon as you actually _use_ code, switching between types only confuses anyone hoping to maintain what was written – user63438 May 30 '18 at 23:35
  • You are wrong. There is nothing confusing about `open(my $fh, '<', "file") or die $!;`. The scalar returned by `open` has three values, and `$!` has two. – ikegami May 30 '18 at 23:36
  • Perl6 has an even better kind of dual-var: You can attach error info to a false value, allowing you to return the same information as an exception without actually forcing the use of exception-handling code. – ikegami May 30 '18 at 23:40
  • Well...... A function in which a variable gets declared in the same line as a parameter (and within the parentheses) which keeps living past the execution of the function in question is confusing as all hell, but I'll give that a pass for now. :) – user63438 May 30 '18 at 23:48
  • I don't see how the scalar returned has three values... The only thing returned is a status code indicating success. I can't speak to your perl 6 example since it 1) makes no sense to a non-perl-6-ist 2) is out of scope. :) – user63438 May 30 '18 at 23:50

1 Answers1

1

The best explanation is found in perldata in perldoc. They function like articles and pronouns in natural language.

The '$' symbol works semantically like the English word "the" in that it indicates a single value is expected.

Entire arrays (and slices of arrays and hashes) are denoted by '@', which works much as the word "these" or "those" does in English, in that it indicates multiple values are expected.

Perl 6 went a different way, so opinions on their value are varied, but that's the theory behind them.

Community
  • 1
  • 1
dsolimano
  • 8,870
  • 3
  • 48
  • 63
  • The problem is that programming is not speaking in a natural language. Certain things don't apply. Programming needs to be much more strict about semantics and definitions. In any case, a quoting of Larry Wall's reasoning does not answer the question. – user63438 May 30 '18 at 13:45
  • @user63438 that's not some dicta from Larry Wall, that's Perl's documentation on why it is the way it is. And yes, Perl 6 went in another direction since it seems it wasn't very useful. – dsolimano May 30 '18 at 13:47
  • I understand why Larry did it. I was wondering if, in hindsight, it served any practical purposes. So far, I've not heard anything, and perl 6 has opted for a consistent-sigil approach. As stated before, if the sigils are constant, they can be replaced with convention, and then replaced with an empty string as the convention, and then replaced with nothing, and we are back to not having sigils. – user63438 May 30 '18 at 23:40