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
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
|
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.
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|