Thanks! Ok, from a type inferencing perspective...
Nathan Torkington wrote:
>
> Symbolic references are used for dynamic function generation:
>foreach my $func (qw(red green blue)) {
> *$func = sub { "@_" }
>}
Probably have to punt on checking user code in a main routine that does
Steve Fink writes:
> My code for doing what I thought Exporter did is:
>
> sub import {
> my $p = caller(1);
> *{"${p}::E"} = \%{"${p}::E"};
> }
>
> but that doesn't run afoul of use strict 'refs'. Can you point me to the
> passage in Exporter.pm that uses this?
It does run afoul of use
(thread intentionally broken)
Nathan Torkington wrote:
>
> Steve Fink writes:
> > True. Would anyone mourn @$scalar_containing_variable_name if it died?
> > I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
> > notice $x="var"; print @$x either -- it'll complain if you mentio
Steve Fink writes:
> True. Would anyone mourn @$scalar_containing_variable_name if it died?
> I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
> notice $x="var"; print @$x either -- it'll complain if you mention @var
> once.
These are symbolic references. You can forbid them
Nathan Torkington wrote:
>
> Don't forget that the rationale behind the infix dereferencing is
> this:
>
> @variable_name
> @{variable_name}
> @$scalar_containing_variable_name @$scalar_containing_value_ref
> @{ code evaluating to variable name } @{ code giving value ref }
True. Wou
"Casey R. Tweten" wrote:
>
> This looks counter intuitive, my brain says to dereference the reference at the
> begining, just like you make the reference, in other words, keep it all the
> same:
>
> $hashref->{key}->@ # Deref
> $hashref->{key}->$ # Deref
> $hashref->{key}->% # Deref
> $hashref->
Don't forget that the rationale behind the infix dereferencing is
this:
@variable_name
@{variable_name}
@$scalar_containing_variable_name @$scalar_containing_value_ref
@{ code evaluating to variable name } @{ code giving value ref }
Nat
Today around 2:47pm, Jerrad Pierce hammered out this masterpiece:
: That's pretty damn nifty, too problems though:
Thanks :-)
: print SCALAR $hashref->{key}, "\n";
: is bogus, SCALAR eats the newline as an argument.
: Granted this could be fixed with parens, but somehwat disap
In reply to your message from the not too distant future: next Friday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Fri, 18 Aug 2000 14:47:44 EDT
From: Jerrad Pierce
That's p
Today around 2:04pm, Casey R. Tweten hammered out this masterpiece:
: Today around 10:45am, Steve Fink hammered out this masterpiece:
:
: : Ted Ashton wrote:
: : >
: : > > all
: : > > dereferencing can be done with ->.
: : >
: : > I
Today around 10:45am, Steve Fink hammered out this masterpiece:
: Ted Ashton wrote:
: >
: > > all
: > > dereferencing can be done with ->.
: >
: > Is that "can be done with" or "must be done with"?
: >
: > Either way, I like the ide
Ted Ashton wrote:
>
> > all
> > dereferencing can be done with ->.
>
> Is that "can be done with" or "must be done with"?
>
> Either way, I like the idea. To me it reads more smoothly, and as I seldom
> dare to use the double-punctu
Damien Neil wrote:
>
> On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote:
> > My proposal would be what I implemented for perl5 a while back (Sarathy
> > didn't dislike it, but wasn't convinced enough to put it in): all
> > dereferencing can be done with ->.
> >
> > $x->@ is the same as
Thus it was written in the epistle of Steve Fink,
>
> Which has next to nothing to do with any particular issue. And it's too
> hard to argue when we agree.
:-).
> If I asked you which variable $x[4] is accessing, I bet you'd say @x.
> Which is one source of the confusion -- in one case, you us
On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote:
> My proposal would be what I implemented for perl5 a while back (Sarathy
> didn't dislike it, but wasn't convinced enough to put it in): all
> dereferencing can be done with ->.
>
> $x->@ is the same as @$x
> $x->% is the same as %$x
>
Karl Glazebrook wrote:
>
> Ariel Scolnicov wrote:
> >
> > Karl Glazebrook <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > o Why do I think perl has too much line noise? Because of code like this:
> > >
> > > @{$x->{$$fred{Blah}}}[1..3]
> >
> > This is indeed horrible. However, I fail to se
Ted Ashton wrote:
>
> > But the most direct way to measure how well the
> > language slides into people's heads is by seeing how hard it is for them
> > to get the hang of it.
>
> Nope. I've yet to be convinced that "fits in your head" is the same as
> "went in easily". Hang
David Corbin wrote:
>
> Ariel Scolnicov wrote:
> >
> >
> > So how do I make C into an array in the first place? Well, I say
> > something like C. But wait -- that's ambiguous! Is
> > C now a copy of the list (1,2,3) (in which case it's an array),
> > or is it a reference to (1,2,3) (in which c
Ariel Scolnicov wrote:
>
> Karl Glazebrook <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > o Why do I think perl has too much line noise? Because of code like this:
> >
> > @{$x->{$$fred{Blah}}}[1..3]
>
> This is indeed horrible. However, I fail to see how cutting out the
> "line noise" would m
Ariel Scolnicov wrote:
>
>
> So how do I make C into an array in the first place? Well, I say
> something like C. But wait -- that's ambiguous! Is
> C now a copy of the list (1,2,3) (in which case it's an array),
> or is it a reference to (1,2,3) (in which case it's a scalar)? In the
> first
Thus it was written in the epistle of Steve Fink,
> Bah. I will claim neither that being easy to learn is Perl's main goal,
> nor that I know what Perl's main goal is, but I have enough of an
> intuition (or did I misspell "opinion"?) to assert that ease of learning
> is a far more important _benc
Karl Glazebrook <[EMAIL PROTECTED]> writes:
[...]
> o Why do I think perl has too much line noise? Because of code like this:
>
> @{$x->{$$fred{Blah}}}[1..3]
This is indeed horrible. However, I fail to see how cutting out the
"line noise" would make it easier to decipher (I can, however, se
Karl Glazebrook <[EMAIL PROTECTED]> writes:
> o Why do I think perl has too much line noise? Because of code like this:
> @{$x->{$$fred{Blah}}}[1..3]
You're taking the value of the key "Blah" in the hash referred to by $fred
and using it as the key into the hash referred to by $x, treating th
Ted Ashton wrote:
>
> Thus it was written in the epistle of Russ Allbery,
> >
> > This falls firmly in the category of things that are powerful for
> > experienced users of the language but may be somewhat difficult to learn.
> > I don't think Perl has being easy to learn as it's primary goal, no
"Myers, Dirk" wrote:
>
> Karl Glazebrook wrote:
>
> > But what is $x[3] ?
>
> > It could be a scalar.
>
> > BUT it could be a reference to a list.
>
> > It could be a reference to a 2D PDL image.
>
> ... but references are scalar. So, $x[3] *is* a scalar.
>
> That scalar could be a refe
Karl Glazebrook wrote:
> But what is $x[3] ?
> It could be a scalar.
> BUT it could be a reference to a list.
> It could be a reference to a 2D PDL image.
... but references are scalar. So, $x[3] *is* a scalar.
That scalar could be a reference to a list. It could be a reference to a 2D
f out of your bubble and think again.
[EMAIL PROTECTED] on 08/17/2000 10:48:00 AM
To:
cc: [EMAIL PROTECTED]@Internet (bcc: Syloke Soong/Americas/NSC)
Subject: Re: RFC 109 (v1) Less line noise - let's get rid of @%
To go through a few points that has arisen:
o Why do I
John Porter writes:
> > push is _not_ a method. @var is not an object.
>
> You are deluded.
This is a highly unproductive avenue of discourse.
Let the people who want to drop punctuation propose dropping
punctuation. Arguing about it won't change their mind, but it will
(a) piss everyone of
To go through a few points that has arisen:
o Why do I think "@" is useless?
OK clearly @x is a list. Good old perl4.
But what is $x[3] ?
It could be a scalar.
BUT it could be a reference to a list.
It could be a reference to a 2D PDL image.
etc.
so clearly we have no real i
John Porter <[EMAIL PROTECTED]> writes:
> Ariel Scolnicov wrote:
> > John Porter <[EMAIL PROTECTED]> writes:
> > > foo = bar;
> > >
> > > foo could be just about anything: a string, a hashref, some other
> > > blessed ref (with op"=" possibly overloaded!), or even an lvalue sub.
> > > Do you k
Jon Ericson wrote:
> John Porter wrote:
> > ...all variable types (scalar, array, hash) are simply objects.
>
> Not in Perl.
Yes, in perl.
> $dog and $cat are objects. $dog can bark and $cat can scratch. The
> author of the module (Zoo::Animal?) should have documented these
> methods.
And
Mike Pastore wrote:
> On Wed, 16 Aug 2000, John Porter wrote:
> > grep() always treats its "second" arg as a list, even if it's a scalar,
> > or some other list-of-one (or none); and grep() always returns a list,
> > even if it's a list of one (or none).
>
> True on the first part, false on the s
Ariel Scolnicov wrote:
> John Porter <[EMAIL PROTECTED]> writes:
> > foo = bar;
> >
> > foo could be just about anything: a string, a hashref, some other
> > blessed ref (with op"=" possibly overloaded!), or even an lvalue sub.
> > Do you know? Should you care?
>
> I don't know, but I think
John Porter <[EMAIL PROTECTED]> writes:
> Bryan C. Warnock wrote:
> >
> > Composer::Post.assumes(Iterator.each(Iterator.all(List)=="Programmers")
> > ->programs=(Language::Programming.uses("Perl")==true &&
> > Methodology.implemented(Style.OO==true,Time.all==true)))==true;
>
> Not at al
On Wed, Aug 16, 2000 at 05:36:25PM -0400, Karl Glazebrook wrote:
> My take: I like perl, I don't mind it the way it is. But I'd be happier if
> it was a lot more like python! (indentation aside)
Why, then, don't you just use Python?
I'm not being sarcastic. Python is a very good language. It h
On Wed, Aug 16, 2000 at 09:04:00PM +0200, Kai Henningsen wrote:
> And context dependency is bad for people.
Actually, people deal very well with context dependency.
"Have you paid Bill?"
"Have you paid that bill?"
"It looks like a duck's bill."
"The President vetoed the bill."
> A rose
On Wed, Aug 16, 2000 at 05:34:51PM -0400, Karl Glazebrook wrote:
> > You appear to arguing that expressions in function argument lists should
> > not be evaluated in a list context. Is this really what you mean?
>
> I guess I do. I guess I just hate contexts!
Context is a fundemental part of Pe
Real quick:
On Wed, 16 Aug 2000, John Porter wrote:
> grep() always treats its "second" arg as a list, even if it's a scalar,
> or some other list-of-one (or none); and grep() always returns a list,
> even if it's a list of one (or none).
True on the first part, false on the second. In scalar c
John Porter wrote:
> Mike Pastore wrote:
> Highlander variables acknowledge the fact that all variable types (scalar,
> array, hash) are simply objects. Objects of different classes, sure; but
> still just objects.
Not in Perl.
> You get no visual help in cases like
>
> $dog->bark();
Mike Pastore wrote:
>
> Scenario 2:
>
> ret = grep(/hand/, var);
>
> *puzzled expression* "Grepping a scalar for a string? Grepping a list for
> a string? Returning a list or a scalar?"
You have failed to enter the mind of an expert perl programmer. ;-)
grep() always treats its "second"
> What makes Perl feel like Perl is, of course, subjective, but to me
> the punctuation is a lot of it. We're trying to improve Perl, not
> replace it.
This is an extremely loaded statement, and we've been hearing it a lot.
RFC 0, remember? Invoking RFC0 immediately after stating your own
per
On Wed, 16 Aug 2000, David Corbin wrote:
> Mike Pastore wrote:
>
> > $hashish{'dog'}# one whutzit
> > @hashish{'dog', 'cat'} # more than one whutzits
> > each %hashish # one whutzit, indexed
> > %hashish # all whutzits, indexed
> > keys %hashish
Karl Glazebrook wrote:
> Jon Ericson wrote:
> > I've spent almost a day trying to come up with a polite response to this
> > suggestion. I have started this mail 3 or 4 times but deleted what I
> > wrote because it was too sarcastic, angry or dismissive. This RFC
>
> Thanks!
>
> > strikes to t
Karl Glazebrook writes:
> Well said!
>
> My take: I like perl, I don't mind it the way it is. But I'd be happier if
> it was a lot more like python! (indentation aside)
This begs the question of why you're not using python. If it's just
indentation, that's silly. Surely there are patches to th
Karl Glazebrook wrote:
> Nathan Wiger wrote:
> > Yeah, and isn't it cool that Perl gives you easy access to using and
> > understanding such complex data structures:
> >
> >print @{ $cars->{$model} };
> >
> > That "junk" makes it easy to see that you're derefencing a hashref that
> > contains
Jon Ericson wrote:
> I've spent almost a day trying to come up with a polite response to this
> suggestion. I have started this mail 3 or 4 times but deleted what I
> wrote because it was too sarcastic, angry or dismissive. This RFC
Thanks!
> strikes to the very heart of Perl as far as I'm c
Well said!
My take: I like perl, I don't mind it the way it is. But I'd be happier if
it was a lot more like python! (indentation aside)
I guess the question arises - how radical is perl6 allowed to be?
Karl
Kai Henningsen wrote:
> And context dependency is bad for people.
>
> There is a reas
Damien Neil wrote:
> What makes you presume this? Perhaps snrub() is something like this:
>
> sub snrub {
> foreach (@_) {
> frobnicate $_;
> }
> }
>
> You appear to arguing that expressions in function argument lists should
> not be evaluated in a list context. Is this real
Kai Henningsen <[EMAIL PROTECTED]> writes:
> 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.
Well, I think it is; it's just
Karl Glazebrook wrote:
>
> Jon Ericson wrote:
> > But @ and % provide important context clues (if not to perl than
> > certainly for programmers). We could also eliminate the plural case in
> > English, but this would be endlessly confusing for native speaker
> > (err... speakers). Why not chan
On 16 Aug 2000, Kai Henningsen wrote:
> > 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 i
[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 th
[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 con
[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 Per
John Porter <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> $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
Nathan Torkington wrote:
> John Porter writes:
> > foo $= ( bar, quux ); # provide scalar context to both sides
> > foo @= ( bar, quux ); # provide list context to both sides
>
> I assume you've dropped this idea as well, given the argument that you
> would be dropping prefix symbols bu
Jonathan Scott Duff wrote:
> As for $a[$something], if @a had been declared as
> "my @a : assoc;", then perl should stringify $something, otherwise
> numify. Hmm.. I guess this implies that all hashes need to be
> pre-declared. :-(
That was kinda along the lines of my suggestion; that the behav
Damien Neil wrote:
>
> I'm not saying that Perl's choices are better than everyone else's;
> they are, however, Perl's.
True enough.
> Are you saying that a tied $a should be able to return a list in list
> context? I would hope not; this rather seriously breaks the principle
> of least sur
John Porter writes:
> foo $= ( bar, quux ); # provide scalar context to both sides
> foo @= ( bar, quux ); # provide list context to both sides
>
> This is very harmonious with the provision of two sets of operators
> for numeric and string comparisons.
I assume you've dropped this
On Wed, Aug 16, 2000 at 10:04:22AM -0700, Damien Neil wrote:
> I'm not certain that I like the idea of string-indexed arrays; I don't
> know that I like the thought that $a[5] and $a[05] might suddenly
> mean something different.
They wouldn't. In $a[05], 05 is a number. To get a string, quotes
On Wed, Aug 16, 2000 at 12:31:23PM -0400, John Porter wrote:
> Sorry, this is exactly the argument we get from the C/C++/Java heads,
> who find perl's lack of discrimination between strings and numbers so
> distasteful. But if we can gloss over the difference between a string
> and a number, we c
Jonathan Scott Duff wrote:
>
> I'll give you my comments right now ... It seems we are eliminating
> punctuation to make the language simpler in one respect, yet, because
> of that, creating new punctuation so that we can use the language in
> ways we are used to. If that must be the case, then
Today around 9:49am, Damien Neil hammered out this masterpiece:
: One of the fundamental concepts in Perl is context. Would you care to
: address the point of what happens to context when you remove @ and %
: prefixes?
Such as prototypes?
In case you wonder, I agree with Damien.
--
print(joi
John Barnette wrote:
> John Porter wrote:
> > The punctuation imposes context on the variable expression.
> > $foo[0]
> > accesses an array. Where's the "@"?
>
> It accesses an *element* of the array, which is a scalar.
Still, the "$" does not describe the type of the variable, which
On Wed, Aug 16, 2000 at 12:44:50PM -0400, John Porter wrote:
> Jonathan Scott Duff wrote:
> >
> > Gee, I'd hate to lose simple assignment to a hash from a list.
>
> foo %= bar;
No, wait, that obviously leaves the modulus of division scalar foo by
scalar bar to foo... No, wait, tha obviou
On Wed, Aug 16, 2000 at 10:24:09AM -0400, Karl Glazebrook wrote:
> It was the response which was blithe, it just re-iterated arguments we
> are all completely familar with and did not address my point in the RFC.
Then perhaps we need to agree to disagree. I feel that a number of
people have addr
> > > No, it's not. Where are we taught this? It's a myth.
> > > The punctuation imposes context on the variable expression.
> > > $foo[0]
> > > accesses an array. Where's the "@"?
> >
> > It accesses an *element* of the array, which is a scalar. This scalar
> > might be blessed into a
On Wed, Aug 16, 2000 at 12:44:50PM -0400, John Porter wrote:
> Jonathan Scott Duff wrote:
> >
> > Gee, I'd hate to lose simple assignment to a hash from a list.
>
> foo %= bar;
>
> Hmm, I think I need to write an RFC!
I'll give you my comments right now ... It seems we are eliminating
pu
Karl Glazebrook wrote:
>
> The tie interface is not very useful for multidim arrays, you have
> to say
>
> $x[42][44][49]
>
> and do multiple levels of tieing whereas one just desires to say
> $x[42,44,49]
But if that is indeed what you desire to say, then there is only
one level, and tie beco
Jonathan Scott Duff wrote:
>
> Gee, I'd hate to lose simple assignment to a hash from a list.
foo %= bar;
Hmm, I think I need to write an RFC!
--
John Porter
On Wed, Aug 16, 2000 at 10:38:30AM -0600, John Barnette wrote:
> John Porter wrote:
> > Russ Allbery wrote:
> > > $args = 'first second third';
> > > @args = split (' ', $args);
> > > my $i = 0;
> > > %args = map { $_ => ++$i } @args;
> > >
> > > This is very Perlish to me; the pun
John Porter wrote:
> Russ Allbery wrote:
> > $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.
>
> No, it
Steve Fink wrote:
>
> It's already withered away some in perl5. Functions can return lists or
> scalars with no distinguishing marks, which was harmless until the
> advent of lvalue subs. Now you have $object->listmember = (1,2,3);
> $object->scalarmember = 42;. Anyone up for an RFC on allowing a
Russ Allbery wrote:
>
> $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.
No, it's not. Where are we taught this
Damien Neil wrote:
> I like being able to treat arrays and hashes differently from other
> things. ... I know, just by looking
> at the expression, with absolutely no further knowledge of what the
> function and variable involved are, the general nature of what is
> going on. I know whether the
>print @{ $cars->{$model} };
>print "Welcome back, $fullname, to $website!\n";
O.k., I'm convinced.
> Only $scalars can hold objects. Now, @arrays and %hashes can
> hold groups of objects, but only $scalars can hold objects.
That's not quite correct. @array or %hash can "hold" an obje
Bryan C. Warnock wrote:
>
> Composer::Post.assumes(Iterator.each(Iterator.all(List)=="Programmers")
> ->programs=(Language::Programming.uses("Perl")==true &&
> Methodology.implemented(Style.OO==true,Time.all==true)))==true;
Not at all. But in
foo = bar;
foo could be just abo
On Wed, Aug 16, 2000 at 10:27:17AM -0400, Karl Glazebrook wrote:
> Nathan Torkington wrote:
> > * current typing provides rudimentary compile-type checking.
> >Saying:
> > $foo = (1,3,5);
> >gives a warning. Saying:
>
> this would create a $foo array
If () are array constructors,
Darn, I sent this to perl6-announce instead of perl6-language.
Let's try again.
--- Forwarded mail from "Andy Wardley" <[EMAIL PROTECTED]>
I thought very carefully about this before writing the Highlander
Variables RFC, and came to the conclusion that it's a bad idea.
I've read your proposal, b
I thought very carefully about this before writing the Highlander
Variables RFC, and came to the conclusion that it's a bad idea.
I've read your proposal, but I'm afraid I still think it's a bad idea.
Those funny characters tell the programmer what's going on, and they
tell the compiler what the
"J. David Blackstone" wrote:
>
> > =head1 TITLE
> >
> > Less line noise - let's get rid of @%
>
> I understand that with the pervasiveness of object-orientation we
> are now more than ever seeing objects that behave like arrays and
> hashes and that it seems strange to see these listlike or ha
Damien Neil wrote:
>
> On Tue, Aug 15, 2000 at 05:45:04PM -0400, Karl Glazebrook wrote:
> > I hope people will actually read the RFC before coming back with these
> > canned responses which I (and presumably everyone else on this list)
> > am completely familiar with. I used to believe that too!
Nathan Torkington wrote:
> * you misunderstand the purpose of $ and @, which is to indicate
>singular vs plural. You say a $ indicates a string or number,
>but really it indicates a single thing. Similarly @ isn't just
>a variable marker, it's used to indicate that you get multiple
Nathan Wiger wrote:
> Ok, here goes. First off, I *did* read the RFC. I never respond before
Thanks, this response is more like it.
> reading. Personally, I wish people would quit coming up with these silly
> "let's drop the prefixes" RFC's that everyone on this list is completely
> familiar wit
On Aug 15, 3:16pm, Russ Allbery wrote:
> Wholeheartedly agreed. If something is an array, it should start with @.
> If we're adding language changes that introduce arrays that don't start
> with @, that's the mistake.
Agreed, but with a slight change of perspective. I don't think it's
so impor
On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote:
> Let's not move backwards and force people to work like machines. Instead,
> lets force machines to work like us.
I dred to think what kind of machine we would make :)
Graham.
"J. David Blackstone" <[EMAIL PROTECTED]> writes:
> I find the standard prefix symbols so intuitive I find it hard to
> articulate the reasons why I balk at giving them up. It's like
> explaining breathing or the ability to distinguish colors.
Bravo! What he said! Hear, hear!
[FX: Waves order
On Tue, 15 Aug 2000, Karl Glazebrook wrote:
> or one could just *use* english plurals...
>
I tried this once with filters. It sort of worked.
(With the obvious bombs, of course.)
> my $speaker = 'Jim';
> my $speakers = ('Fred','Bill','Sally','Betty');
>
> my $male_speakers = $speakers[0:1]; #
On Tue, Aug 15, 2000 at 05:45:04PM -0400, Karl Glazebrook wrote:
> I hope people will actually read the RFC before coming back with these
> canned responses which I (and presumably everyone else on this list)
> am completely familiar with. I used to believe that too! Honest...
I think you do a si
Jon Ericson wrote:
>
> Perl6 RFC Librarian wrote:
>
> [snip reconstructionist history and newer-is-better fallacy]
>
> > I argue in this Brave New World the distinction between C<$x>, C<@x> and
> > C<%x> are no longer useful and should be abolished. We might want
> > to use all kinds of array o
Perl6 RFC Librarian wrote:
[snip reconstructionist history and newer-is-better fallacy]
> I argue in this Brave New World the distinction between C<$x>, C<@x> and
> C<%x> are no longer useful and should be abolished. We might want
> to use all kinds of array objects, why should @x be special? Ra
91 matches
Mail list logo
