Re: Perl culture, perl readabillity
[EMAIL PROTECTED] (Simon Cozens) wrote on 26.03.01 in [EMAIL PROTECTED]: Oh, and you think Perl is more English than German? In fact, I've come up with the same idea independently. Except I'd go a bit further and claim that only a native English speaker could possibly come up with the idea that irregularity is useful. It's most definitely not. [1] Why do people want programming languages to look like human languages anyway? We use them for such completely different problem domains... Well, I never quite understood this particular argument of Larry either. MfG Kai
Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.
[EMAIL PROTECTED] (Tony Olekshy) wrote on 15.08.00 in
[EMAIL PROTECTED]:
What if we implemented something like the following?
Seems that the basic unwinder is
except { ... } = catch { ... }
and everything else can be written in terms of this:
catch { ... }
except { 1 } = catch { ... }
catch "ClassName" { ... }
except { $@-isa($ClassName") } catch { }
finally { ... }
except { 1 } = catch { ... ; throw $@ }
MfG Kai
Re: RFC 84 (v1) Replace = (stringifying comma) with =
[EMAIL PROTECTED] (Nathan Torkington) wrote on 15.08.00 in [EMAIL PROTECTED]: Stephen P. Potter writes: Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). If that were the case, I think students would have an easier time grasping hashes. It seems very common (yes yes, you all got them immediately, but merely by piping up and saying so, you do not invalidate my point, so please don't) that beginners take a long time to use hashes because they find them hard to get their heads around. I see two possible reasons for that: 1. Hashes aren't explained right. 2. They already know about computers and arrays. To someone who doesn't know about computers and arrays, hashes are the more natural concept, because they are how you do stuff like that in real life, and arrays are just a special case of hashes. There's a reason symbol tables are hashes and not arrays: people are better with names than with numbers. (Of course, one of the problems with hashes is the name. For most purposes, the fact that a (non-tied) hash uses hashing is completely irrelevant to someone learning the language.) Perl really goofed here. The generic concept should be the collection. Collections can be indexed in lots of different ways, and (Perl) hashes and arrays are just two of many options. (Think of trees, for example.) This isn't why it's silly, just a comment on the idea that hashes and arrays are conceptually very similar. Well, they are. world. I like Perl being able to optimize internally based on my simple one-character data typing (%). I'd actually prefer if the computer could work that out for itself. That's the type of stuff computers are supposedly good at. MfG Kai
Re: RFC 109 (v1) Less line noise - let's get rid of @%
[EMAIL PROTECTED] (Nathan Torkington) wrote on 15.08.00 in [EMAIL PROTECTED]: * you misunderstand the purpose of $ and @, which is to indicate singular vs plural. Yes. That's one of the things that's wrong with it - maybe the biggest of all. It's one of the things that require constant attention to get right for me. It's *not* natural. Yes, singular and plural per se are natural. But an array element *is not* singular to an array. Look at that sentence. It contains two singulars: an array, and an array element. There's no plural in there. Perl "plural" is a very different concept from natural language plural, and *that* is why it's bad. $ vs. @ is not really about singular or plural. It's about context dependency. And context dependency is bad for people. There is a reason that no language after Algol68 used a context dependant grammar. There is a reason that nearly all modern computer languages don't make expression evaluation dependant on expression context. The reason is *not* that this is easier for computers. It is easier, sure, but not all that much. But it is *a lot* easier for humans. A rose is a rose is a rose. Human minds really don't like context dependancy. MfG Kai
Re: RFC 109 (v1) Less line noise - let's get rid of @%
[EMAIL PROTECTED] (Russ Allbery) wrote on 15.08.00 in
[EMAIL PROTECTED]:
All variables should be C$x. They should behave appropriately
according to their object types and methods.
No thanks. I frequently use variables $foo, @foo, and %foo at the same
time when they contain the same information in different formats. For
example:
$args = 'first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ = ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely. I'd be very upset if this idiom went away.
That would be nice if the punctuation actually *were* part of the variable
name.
However, it isn't: to access 'second', you'd say $args[1], NOT @args[1].
It's one of the Perl features that most confuses newcomers.
If there's no better argument than this, I'd throw this distinction away
in a heartbeat.
If the syntax can be changed so I never have to write @{some array ref}
again to explain to perl that yes, I really want to use this array as an
array, I'll be a happy man.
MfG Kai
Re: RFC 109 (v1) Less line noise - let's get rid of @%
[EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in [EMAIL PROTECTED]: The ultimate target of a program's source code is the *programmer*. True. Programmers, being people (well, more or less... :), work best with symbols and rich context. This particular programmer *hates* what Perl does with @ and %. Stripping contextual clues out of code does the programmer a disservice. You mean like when you access members of @x, you have to write $x? We're at the point where we don't have to cater to the limitations of the computer hardware. That means we'll be better off if we cater to the limitations (and strengths!) of people's wetware. Please do, and get rid of this particular language misfeature. MfG Kai
Re: Eliminate dynamic variables entirely?
[EMAIL PROTECTED] (Nathan Wiger) wrote on 14.08.00 in [EMAIL PROTECTED]:
Well, lexical variables don't belong to any package in Perl. They're not
in the symbol table, hence why others can't mess with them. That's why a
"my $var" is different from a "$pkg::var". The latter gets in the symbol
table, the former doesn't.
I think Perl'd profit from using a structure similar to the following:
1. Package variables $package::var, presumably you'd have to declare those
and the default would be
2. lexical variables,
except that different from the current way, you'd have access to a stack
of lexical symbol tables. (Doesn't mean it needs to be the same
datastructure internally, just so long as you can access it with the same
syntax.)
So you'd find a global var via $package::{'var'}, and a lexical var via
$STACK[3]{'var'} ($STACK[0] being where my() declares new variables, and
$STACK[$#STACK] the symbol table where top-level my() declares file-scope
variables).
Except for access to the symbol table, that's very similar to what other
languages have.
Furthermore, in the "more rope" department, it might be possible to make
local() work on my() variables this way.
MfG Kai
