Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Some Insights from a Traveler Between Languages

by jonadab (Parson)
on Apr 24, 2005 at 12:43 UTC ( [id://450932]=note: print w/replies, xml ) Need Help??


in reply to Some Insights from a Traveler Between Languages

@biz = [1, 2, 3];
In the fourth case, you end up with an array of just one element, and that element is a reference to the array that was on the RHS. Ugh... Not having mentally transitioned from Python, I fell for the trap of the fourth case.

In other words, you used the punctuation you would have used in the other language, but it meant something rather different in Perl. This is unavoidable when going from language to language, unless the syntax is so *completely* different that it doesn't overlap at all (e.g., moving from elisp to Perl does not cause this problem in my experience, because the syntax in elisp is impossible to confuse with Perl's). I assert that you would have the same type of problem suddenly moving from Perl to Python, or Perl to Ruby, or Ruby to Python, or Python to C++, or C++ to Inform, or cetera.

So, what is Perl's justification for having these latter two cases?

The third case is arguable; it's there for convenience, and it's mightily convenient, and I use it with quite significant frequency, but yes, needing to do an explicit length would not be the end of the universe.

The fourth case, OTOH, is another matter; I do not see how it would be possible for Perl to get by without the ability to assign references. Doing away with that would make Perl quite a lot less useful than it is. We're not talking about syntactic sugar here; it is absolutely *necessary* to be able to assign a reference to an annonymous array into a variable. The fact that the syntax used to do that doesn't mean the same thing in all programming languages is just a symptom of the fact that not all programming languages are identical.

So, why is length(@foo) perfectly acceptable syntax? Furthermore, since it is valid syntax, why does it do something so thoroughly dumbfounding?

Yes, I agree that length should have been overloaded. Even though there's a shorter way to take the length of an array, being able to do it explicitely would not have been a bad thing.

The Perl6 approach to fixing this is to do away with length altogether; instead you will specify $string.bytes if that is what you want, or, if your characters might not all be a single byte long, $string.graphemes or $string.codepoints or some other Unicode-related thing. For arrays, I think there will be @array.elems or somesuch. Note that this still won't solve the problem of different languages having different syntax; indeed, I expect moving back and forth between Perl5 and Perl6 to be rather painful at times.


"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

Replies are listed 'Best First'.
Re^2: Some Insights from a Traveler Between Languages
by skyknight (Hermit) on Apr 24, 2005 at 14:10 UTC

    Well, here's the thing. I don't have a huge problem with different languages having similar syntactic constructs with different semantic interpretations, though I do find it irksome and perhaps even unnecessary. However, I do consider it problematic that two syntactically very similar constructs in a language have two very differerent semantic interpretations while operating on the same kind of stuff (arrays/lists). This is just a land mine waiting for someone to step on it. I like that Python skirts the issue by only having [] for working with lists, as opposed to Perl which has () on top of that.

    In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one. For example, the fact that you can return a reference to a local (er, my) variable inside a function is indicative to me that Perl doesn't seem to have the concept of auto variables. Presumably the things getting placed onto the function call stack are not actual variables, but reference counting pointers. I could be wrong, as I have never looked at Perl's internal code, but given its behavior I can't imagine it working differently. As such, why do we even bother with the variable/reference distinction? What does that buy us over Python's strategy of allowing you only to store references? I think Perl's way of dealing with stuff is a legacy of C-style thinking that needlessly complicates things. Do we really need to care about the distinction between variables and references? We don't even have guarantees about when garbage collection occurs, so what's the point?

    Also, you're totally confusing the issue with point four. Perl could survive just fine if the scenario I described were a syntax error. All you'd have to do is wrap your RHS in parentheses, making it explicit that your intention is to assign to an array with an array reference being the first and only element. This doesn't kill any Perl constructs. It just makes things a lot safer by requiring a little more syntax.

    Perl is a fantastic language for rapid prototyping. It makes things that would be tedious in other languages very easy to bang out quickly so you can stay focused on your nascent ideas and ignore the potentially messy implementation details, if just for the moment. To this end, Perl ought also to try to prevent users from making careless mistakes that cause them to bog down in debugging. Having dangerous syntactic constructs that can easily lead to mental traps undermines the goals of rapid prototyping. Every time a programmer has to deal with the vagaries of a language, he's missing the rapid prototyping boat. The whole point of choosing a language like Perl for rapid prototyping is that it should be as transparent as possible to your endeavors to rapidly craft a prototype.

      In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one.

      IMO its a pretty useful distinction. For instance:

      my @array; my $arrayref=[] my @copy=@array; my $refcopy=$arrayref;

      So now what happens to the thing $arrayref references when when we modify $refcopy->[0]? It changes. What happens to @array when we modify $copy[0]. Nothing.

      The point is that you can determine many things about manipulating an object by its sigil. For instance a copy of a ref is cheap, a copy of an array is not. Modifying the contents of a ref will change the results of all things using the same ref. Modifing the contents of an array will only change that array or things that reference it.

      Maybe im too close to the trees but I see a big difference between them and good reasons to have both. Sure you can provide all the same effects with only references (provided you have a way to clone/copy an array) but there is a lot to be said for making them visually distinct. I mean personally i find

      my @copy = @array;
      to be preferable to
      my $copy=$array->copy;
      the former says loudly that a new thing is being created where the latter could be doing anything.

      ---
      demerphq

        In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one.
        IMO its a pretty useful distinction. For instance:
        my @array; my $arrayref=[]
        I should probably let the perl 6 experts talk about this, but as I remember it the distinction is being downplayed somewhat for Perl 6. People need to use references so often that in Perl 6 you're going to tend to get references to things by default, rather than as a special case that you need to ask for.
        ObDisclaimer: I'm no monk, I'm relatively beginner.

        I can't imagine that "my $copy=$array->copy;" is more ambiguous than "my @copy = @array;". The former is IMHO clearer conceptually, the latter is the more ambigiuous to my beginner brain. If I need to copy, I'll be glad to make it explicit with some more typing. Otherwise knowing everything is a ref "normally" would be just peachy for me.
      In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one.

      This is the core of the issue right here.

      For example, the fact that you can return a reference to a local (er, my) variable inside a function is indicative to me that Perl doesn't seem to have the concept of auto variables.

      It's indicative of the fact that Perl does have the concepts of lexical scope, anonymous objects, and, in particular, lexical closures. my variables are not local in the same sense that e.g. Inform means by "local variable". (They are closer to it than Perl's local variables, which are dynamically scoped, but that is neither here nor there ATM.) In particular, it is an easy mistake to make (and one that I made once upon a time, when I was very new to Perl) to misunderstand Perl's lexical variables, thinking either that they are persistently scoped to a given function or block ("static" in C parlance) or to go wrong in the other direction, failing to account for references and assuming immediate destruction at the end of the block. But neither of these semantics would be nearly as useful as the one Perl has (although the former could be a useful *additional* option, and I think we may be getting that in Perl6; I cannot think of any use for the latter).

      Presumably the things getting placed onto the function call stack are not actual variables, but reference counting pointers

      The function call stack is not part of Perl (as a language). It is part of perl (the interpreter), an implementation detail that could change between minor versions without having any significant impact on existing Perl code.

      Reference counting is another matter; yes, Perl5 does reference counting. (Perl6 will have real GC, so I am told, likely of the mark-and-sweep variety.) However, that rears its head in other situations, such as when you have cyclic data structures. In the case you're talking about (assuming I correctly understand what it is you are talking about), the same thing would happen if Perl5 had mark-and-sweep garbage collection today. You can do the same thing in Scheme, for instance. If you can't do it in Python, that is because Python deliberately steers you to thinking according to the OO paradigm; Perl embraces various paradigms: OO, FP, contextual, ... this is the essential paradigmatic flexibility that makes Perl the language that it is. TMTOWTDI, and for various situations or problems one of them may be more helpful than another.

      Do we really need to care about the distinction between variables and references?

      Yes, absolutely -- or, at least, we have to have a distinction between references and the things that they reference. The question of what constitutes a "variable" is another whole thread, and one that I suspect would be a tangent here, not the real issue.


      "In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://450932]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (3)
As of 2024-03-19 04:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found