> "David L. Nicol" wrote:
> >
> > These things sound like perfectly reasonable CPAN modules.
> > What's the block prevenenting their implementation w/in the
> > perl5 framework?
>
> Jeremy and I are working on a general purpose matrix/unmatrix function
> that may well be core-worthy. This would al
On Sat, 12 Aug 2000 09:14:13 -0700, Nathan Wiger wrote:
>> But @ARGS has one disadvantage: it's a plural form.
>
>You're right, but one problem is that @ARG is already a synonym for @_.
Hey, and shift() works on both by default, depending on where you call
it, toplevel or in a sub. What a coinci
On 11 Aug 2000 16:22:33 -, Perl6 RFC Librarian wrote:
>Currently, Perl uses the C library C and C
>functions for date access. However, because of many problems, these
>should be replaced with two new functions, C and
>C
Gee, yet again, we'll get two virtually identical but still separate
fun
Sounds like a good idea. I propose a commandline arg that gives info about
modules in @INC also. I emailed this to the list earlier but it never seemed
to make it.
Something like
perl -M 'Digest'
might return:
/usr/local/lib/perl5/site_perl/:
-r--r--r-- 1 root other 4733 Aug
Today around 12:08am, Uri Guttman hammered out this masterpiece:
: i just found an interseting little oddity i want fixed. i (like many of
: you) run one liners for testing snippets of code. i typically use a -p
: or -n loop and type in test data. i get tired of retyping in all the
: data each ti
Yes it should be
use strict qw(..);
It would be wonderful if someone could invest in an RFC or two to propose the use of
strict.
I didn't intend to propose the use of such terms. I simply needed to put a handle on
some things.
- primitive data types; I used char, varchar, int, double as an
Kirrily Robert said:
> What relationship does this have to RFC 5 (multiline comments), and
> hasn't the discussion of inline comments occurred in detail already?
There is a distinction, because the proposal for multiline comments requires
(like all here docs) the opening and closing be on their o
On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote:
> Well, just to counter argue, I feel exactly the opposite way. I'd like
> the keyword to be "constant" instead of "const". I've always thought
> "const" was a needless save of 3 characters. Constants should be obvious
> to pick out. Th
On Tue, 15 Aug 2000, Casey R. Tweten wrote:
> cat /etc/passwd | perl -nfe 'print((split/:/)[0])'
>
> -f is just like $|=1 or, for example, $fh->autoflush(1);
When did -f come into being? Or was this just a proposed new switch?
> This, by the way (even as a test) was agravating to me because in
On Tue, Aug 15, 2000 at 09:14:20AM -0400, Casey R. Tweten wrote:
> This, by the way (even as a test) was agravating to me because in order to
> get decent output I really had to do this:
>
> cat /etc/passwd | perl -nfe '$\="\n";print((split/:/)[0])'
cat /etc/passwd | perl -lnfe 'print((s
Ed Mills wrote:
>
> Sounds like a good idea. I propose a commandline arg that gives info about
> modules in @INC also. I emailed this to the list earlier but it never seemed
> to make it.
>
> Something like
>
> perl -M 'Digest'
>
> might return:
>
> /usr/local/lib/perl5/site_perl/:
>-r-
On Tue, Aug 15, 2000 at 12:08:52PM +0200, Bart Lateur wrote:
> On 11 Aug 2000 16:22:33 -, Perl6 RFC Librarian wrote:
>
> >Currently, Perl uses the C library C and C
> >functions for date access. However, because of many problems, these
> >should be replaced with two new functions, C and
> >C
In message <[EMAIL PROTECTED]>
"J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> I always treat the return value of time() as a black-box value. I
> can perform specific actions on it, such as feeding it to localtime()
> or adding relative time intervals to it, such as a year of sec
Today around 11:52am, Philip Newton hammered out this masterpiece:
: On Tue, 15 Aug 2000, Casey R. Tweten wrote:
:
: > cat /etc/passwd | perl -nfe 'print((split/:/)[0])'
: >
: > -f is just like $|=1 or, for example, $fh->autoflush(1);
:
: When did -f come into being? Or was this just a propose
Today around 11:01am, Jonathan Scott Duff hammered out this masterpiece:
: On Tue, Aug 15, 2000 at 09:14:20AM -0400, Casey R. Tweten wrote:
: > This, by the way (even as a test) was agravating to me because in order to
: > get decent output I really had to do this:
: >
: > cat /etc/passwd | perl
On Tue, Aug 15, 2000 at 12:31:00PM -0400, Casey R. Tweten wrote:
> Frankly, they're both ugly. I personally like the *idea*, I'm not
> advocating my solution. It would be wonderful if we could assign values
> to Perl's special variables when we're doing a one line quick
> hack. Often, I will mo
On Tue, Aug 15, 2000 at 10:03:55AM -0700, Nathan Wiger wrote:
> Jonathan Scott Duff wrote:
> >
> > Well, now it's my turn to suggest something ;-> How about we give
> > perl the ability to look for a .perlrc file? (Yes, I know the reasons
> > against, but everything is up for grabs now right?
Following the lead of the sort operator, it would be a little
simpler to see reduce expressions use $a and $b instead of
$_[0], $_[1].
E.g.
Summation:
$sum = reduce{$a + $b} 0, @numbers;
$sum = reduce sub{$a + $b},0, @numbers;
Production:
On Tue, Aug 15, 2000 at 11:31:50AM -0500, Adam Krolnik wrote:
>
>
> Following the lead of the sort operator, it would be a little
> simpler to see reduce expressions use $a and $b instead of
> $_[0], $_[1].
The $a and $b of the sort comparator were A Bad Idea to begin with.
There's nothing wron
Jarkko Hietaniemi wrote:
>
> The $a and $b of the sort comparator were A Bad Idea to begin with.
Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't
be used, or even a more standard $1 and $2. Either one makes it more
obvious what's being operated on.
It also fixes the "'use
At 12:31 PM 8/15/00 -0400, Casey R. Tweten wrote:
>Frankly, they're both ugly. I personally like the *idea*, I'm not
>advocating my solution. It would be wonderful if we could assign values
>to Perl's special variables when we're doing a one line quick
>hack.
With a bit of luck, the special var
At 11:35 AM 8/15/00 -0700, Nathan Wiger wrote:
>Peter Scott wrote:
> >
> > Can someone knowledgeable on this issue speak to it?
> >
> > Will $| $/ $\ et al be retired, or be valid for some default filehandle?
> >
> > Will there still be default filehandles?
>
>There's been a big debate on the -io
Glenn Linderman <[EMAIL PROTECTED]>:
>
> An idea that produces a paired feeling would be to use one of the
> paired character pairs, as in "#<" and ">#".
> ...the three paired character possibilities ("<>", "()", "{}")
There is at least one more: "[]".
And the Perlish thing to do
iVAN Georgiev <[EMAIL PROTECTED]>:
>
> They behave similarly like &&, ||, and, or operator with one main
> distinction they "backtrack" for example:
>
> { block1 } B { block2 };
This would be a good use of the to-be-liberated => operator:
{ block1 } => { block2 };
In any case, "andthen" doe
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> whispered
> :
> | Here's a counter-proposal: throw out hashes as a separate internal
> | data type, and in its place define a set of operators which treat
> | (properly constructed) arrays as associat
Peter Scott wrote:
>
> I don't want to be in the -io discussion; I just want to know the
> conclusions that might affect -language. It seems silly to discuss
> command-line options for setting $| here if there isn't going to be a $|.
Ok, read this thread (4 messages long):
http://www.mail-arch
At 03:53 PM 8/15/00 -0400, John Porter wrote:
>Stephen P. Potter wrote:
> > Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
> whispered
> > :
> > | Here's a counter-proposal: throw out hashes as a separate internal
> > | data type, and in its place define a set of operators
Thus it was written in the epistle of Perl6 RFC Librarian,
>
> This is something that was put in to catch Perl 4 to Perl 5 migration.
> Perl 6 shouldn't need it, and should just assume that "@wiger" is an
> array, even if it's unitialized. This is what it does for all the other
> data types.
Bet
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote:
> Better yet, DWIM. If I write
>
> print "[EMAIL PROTECTED]";
>
> and no array @southern exists, I probably mean I want it to print
>
> [EMAIL PROTECTED]
>
> I'd say, if the variable exists, interpolate it. If not, print it as
On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote:
> This is a succinct summary of the basic conclusions thus far:
>
>1. a default filehandle IS needed sometimes, but only
> for stuff like print
Well, I think that C should always print to $PERL::STDOUT (or
whatever we call i
Ted Ashton wrote:
>
> Better yet, DWIM. If I write
> print "[EMAIL PROTECTED]";
> and no array @southern exists, I probably mean I want it to print
> [EMAIL PROTECTED]
> I'd say, if the variable exists, interpolate it. If not, print it as
> it stands.
Um, no. Something about the relaxati
On 15 Aug 2000, Perl6 RFC Librarian wrote:
> This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
> replaced with C<$x> for everything.
my $foo = ('apples', 'oranges');
my $bar = ('apples' => 'crunchy', 'oranges' => 'juicy');
my $zot = 'bananas';
my $ret = junkem(\$foo, \$bar, $zot);
Karl Glazebrook <[EMAIL PROTECTED]>:
>
> This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
> replaced with C<$x> for everything.
>
> The only distinction left would be between things which are
> variables (prefixed by C<$>) and not-variables (subroutines and
> keywords).
A useless di
On Mon, 14 Aug 2000 12:32:32 -0500, David L. Nicol wrote:
>I find "throw" to be a perfectly good synonym for "raise" an exception. The
>english language equivalent is a piece of steel machinery, when it breaks
>while running, which is said to "throw a rod" or "throw a bolt" depending
>of course
> Just to make sure some opposition is heard: I've always thought of
> "throw" as very silly word. To me, a program is much like a maze, a
> multilevel walk in an old castle. There are unexpected trapdoors, but as
> long as they stay closed, you can simply continue. If such a trapdoor
> open, you
I think about the word some OO gurus use: "raise".
Makes some sense, as in "raise a red flag" or "raise an objection".
"Raise" means elevate, or escalate. Hmmm, "escalate" sounds good;
except it kinda assumes the prior existence of the thing (the
exception) being escalated.
So, instead of "throw
Or "popup" (as in, fly ball", and then "field".
Of course, if we had "raise", then we could have "sustain" and "overrule".
--
John Porter
John Porter wrote:
>
> Karl Glazebrook <[EMAIL PROTECTED]>:
> >
> > This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
> > replaced with C<$x> for everything.
> >
> > The only distinction left would be between things which are
> > variables (prefixed by C<$>) and not-variables (subrout
At 04:51 PM 8/15/00 -0400, John Porter wrote:
>Karl Glazebrook <[EMAIL PROTECTED]>:
> >
> > This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
> > replaced with C<$x> for everything.
> >
> > The only distinction left would be between things which are
> > variables (prefixed by C<$>) and
At 04:03 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
> > Just to make sure some opposition is heard: I've always thought of
> > "throw" as very silly word. To me, a program is much like a maze, a
> > multilevel walk in an old castle. There are unexpected trapdoors, but as
> > long as they stay clos
> lvalue subs should receive the rvalue as an argument
Here here! Amen!
> sub name : lvalue {
I don't think the :lvalue is needed. This isn't really an attribute - if
someone writes:
$r->name = 'Mithrandir';
there's no confusion that it's assigning it. I think you'd wind up with
people
Dan Sugalski wrote:
> At 03:53 PM 8/15/00 -0400, John Porter wrote:
> >
> >I guess it depends on what you think makes sense; but it seems to me
> >that an array is a more fundamental data type; that it's easier (i.e.
> >more efficient) to build associative arrays from arrays, than vice versa.
>
>
Dan Sugalski wrote:
>
> The ultimate target of a program's source code is the *programmer*.
> Programmers, being people (well, more or less... :), work best with symbols
> and rich context. Stripping contextual clues out of code does the
> programmer a disservice.
Then every proposal so far
My point is that I find the use of $x and @x visually confusing, and now
arrays are often objects anyway really confusing.
Also lots of $$x{'hmm'] and \@x[...] are no good.
This human wants less clutter!
Karl
Dan Sugalski wrote:
> The ultimate target of a program's source code is the *programm
Dan Sugalski wrote:
>
> Let's not move backwards and force people to work like machines. Instead,
> lets force machines to work like us.
Hear, Hear! I feel that this is worth a "me too".
Clayton
--
Clayton Scott
On Tue, Aug 15, 2000 at 05:20:11PM -0400, John Porter wrote:
> Dan Sugalski wrote:
> >
> > The ultimate target of a program's source code is the *programmer*.
> > Programmers, being people (well, more or less... :), work best with symbols
> > and rich context. Stripping contextual clues out of
> This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
> replaced with C<$x> for everything.
Let me be the first to say "No!". I like this feature. I always have,
and always will. It's super-duper easy to glance at this code and tell
what is what:
@stuff = read_stuff;
foreach (@s
punt. But, specialteam or runback?
die + raise = ascend.
The thing I don't like about C++/Java try/catch syntax is the way
the blocks are daisychained. That is not intuitive to the flow.
The exception handlers should be more closely bound -- syntactically --
to the try block. A sw
Today around 2:28pm, Nathan Wiger hammered out this masterpiece:
: > This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
: > replaced with C<$x> for everything.
:
: Let me be the first to say "No!". I like this feature. I always have,
: and always will. It's super-duper easy to glance
Jarkko Hietaniemi wrote:
>
> The point often missed is that the prefix carries information,
> it's not there just to annoy.
> ...
> I still don't know all but I do know more.
Yes. OTOH, if it doesn't add *enough* information, it's not cost-
effective. Most of proposals, such as highlander ty
Nathan Wiger wrote:
>
> This is one of the things I really like about Perl: being able to tell
> what type of thing I'm looking at. Is is a list? A single value? A hash
> of values? No sweat, look at the prefix.
I appreciate the point. I discuss it in the RFC and why I think it
no longer works.
> Better yet, DWIM. If I write
>
> print "[EMAIL PROTECTED]";
>
> and no array @southern exists, I probably mean I want it to print
>
> [EMAIL PROTECTED]
>
> I'd say, if the variable exists, interpolate it. If not, print it as
> it stands.
I initially was thinking this too, but there's
At 05:17 PM 8/15/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > At 03:53 PM 8/15/00 -0400, John Porter wrote:
> > >
> > >I guess it depends on what you think makes sense; but it seems to me
> > >that an array is a more fundamental data type; that it's easier (i.e.
> > >more efficient) to bu
At 05:22 PM 8/15/00 -0400, Karl Glazebrook wrote:
>My point is that I find the use of $x and @x visually confusing, and now
>arrays are often objects anyway really confusing.
>
>Also lots of $$x{'hmm'] and \@x[...] are no good.
>
>This human wants less clutter!
Less clutter is good. (I think that
At 05:20 PM 8/15/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> >
> > The ultimate target of a program's source code is the *programmer*.
> > Programmers, being people (well, more or less... :), work best with
> symbols
> > and rich context. Stripping contextual clues out of code does the
>
John Porter wrote:
> ...I think an OO syntax would be better. You know, something like
>
> try {
> cough "outa here";
>
> catch {
> matawba => { sustain; },
> ebola => { overrule; },
> { punt; }
> "Jonathan" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
Jonathan> Isn't that the way perl4 did it? I don't know what agony lwall and
Jonathan> friends went through that made them change this behaviour though. It
Jonathan> would be good for someone who does to speak up about it.
It
Dan Sugalski wrote:
> > assoc( %h, 'foo', 'bar' );
>
> Because it's conceptually clearer. You've more clues to what's going
> on--the syntax is rather specific, and more distinct. The function call
> method's much more general, and has fewer contextual clues as to what it's
> doing.
G
Dan Sugalski wrote:
>
> Tossing the worthless and confusing ones is good. Tossung the useless
> and distinguishing ones is bad.
Uh, which ones did you have in mind, by "useless and distinguishing"? ;-)
--
John Porter
Jon Ericson wrote:
> Why not change @x so that it can represent other
> types of arrays? For instance:
>
> my @x; # standard Perl array
> my @y[2, 3];# 2x3 matrix (syntax guess)
> my FIFO @z; # FIFO stack (another guess)
This is ENTIRELY my point: the more things a '@' can re
At 05:50 PM 8/15/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > > assoc( %h, 'foo', 'bar' );
> >
> > Because it's conceptually clearer. You've more clues to what's going
> > on--the syntax is rather specific, and more distinct. The function call
> > method's much more general, and h
On Tue, Aug 15, 2000 at 03:28:33PM -0500, Jonathan Scott Duff wrote:
> On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote:
> >1. a default filehandle IS needed sometimes, but only
> > for stuff like print
>
> Well, I think that C should always print to $PERL::STDOUT (or
> what
> I don't think the :lvalue is needed. This isn't really an attribute - if
> someone writes:
>
>$r->name = 'Mithrandir';
>
> there's no confusion that it's assigning it.
Ah, but there's definitely a confusion as to whether it's *meant*
to be assignable.
What if I (as the
At 05:57 PM 8/15/00 -0400, John Porter wrote:
>Jon Ericson wrote:
> > Why not change @x so that it can represent other
> > types of arrays? For instance:
> >
> > my @x; # standard Perl array
> > my @y[2, 3];# 2x3 matrix (syntax guess)
> > my FIFO @z; # FIFO stack (another guess
At 05:53 PM 8/15/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> >
> > Tossing the worthless and confusing ones is good. Tossung the useless
> > and distinguishing ones is bad.
>
>Uh, which ones did you have in mind, by "useless and distinguishing"? ;-)
D'oh! (or is that now D::oh?)
I meant
On Wed, Aug 16, 2000 at 08:01:12AM +1000, Damian Conway wrote:
>> I don't think the :lvalue is needed. This isn't really an attribute - if
>> someone writes:
>>
>>$r->name = 'Mithrandir';
>>
>> there's no confusion that it's assigning it.
>
> Ah, but there's definite
Dan Sugalski wrote:
> >Generality good.
>
> For many things, yes. For computers, say. For people, no. Generality bad.
> Specificity and specialization good. People aren't generalists. They're a
> collection of specialists. The distinction is important.
I'm sorry if I don't find this argument
Dan Sugalski wrote:
>
> If the symbol becomes content-free, perhaps the problem is with what made
> it useless, not with the symbol itself...
Yes!
--
John Porter
John Porter wrote:
> Dan Sugalski wrote:
> >
> > If the symbol becomes content-free, perhaps the problem is with what made
> > it useless, not with the symbol itself...
>
> Yes!
But that's not to say I agree that certain proposals which would have
the effect of rendering the symbol useless are
Jarkko Hietaniemi wrote:
> On Tue, Aug 15, 2000 at 11:31:50AM -0500, Adam Krolnik wrote:
> >
> >
> > Following the lead of the sort operator, it would be a little
> > simpler to see reduce expressions use $a and $b instead of
> > $_[0], $_[1].
>
> The $a and $b of the sort comparator were A Bad
> > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
> > consider the $ and $b to be warts.)
> >
> And anyhow, this will work just fine (see RFC 23):
>
> $sum = reduce ^a + ^b, @numbers;
I have been amply reminded of this, thanks :-) (Too little time
to spend on RFCs..
> 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
Dan Sugalski <[EMAIL PROTECTED]> writes:
> If the symbol becomes content-free, perhaps the problem is with what
> made it useless, not with the symbol itself...
Wholeheartedly agreed. If something is an array, it should start with @.
If we're adding language changes that introduce arrays that d
Jonathan Scott Duff wrote:
> On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote:
> > Well, just to counter argue, I feel exactly the opposite way. I'd like
> > the keyword to be "constant" instead of "const". I've always thought
> > "const" was a needless save of 3 characters. Constants
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote:
> Better yet, DWIM. If I write
>
> print "[EMAIL PROTECTED]";
>
> and no array @southern exists, I probably mean I want it to print
>
> [EMAIL PROTECTED]
>
> I'd say, if the variable exists, interpolate it. If not, print it as
At 06:04 PM 8/15/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > >Generality good.
> >
> > For many things, yes. For computers, say. For people, no. Generality bad.
> > Specificity and specialization good. People aren't generalists. They're a
> > collection of specialists. The distinction is
Lightning flashed, thunder crashed and Perl6 RFC Librarian <[EMAIL PROTECTED]>
whispered:
| =head1 TITLE
|
| Builtins: zip() and unzip()
|
[snip]
|
| its arguments. C would reverse this operation.
|
[snip]
|
| If the list to be unzipped is not an exact multiple of the partition size,
| the fin
Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> whispered
:
| Here's a counter-proposal: throw out hashes as a separate internal
| data type, and in its place define a set of operators which treat
| (properly constructed) arrays as associative arrays. It's the
Doesn't it m
This sort of thing is an excellent example of how method
selection based on calling context can help.
When somebody wants to overload existing keywords for their
slick new type, with overloading based on context they don't
have to touch the internals of the current methods at all.
rapt
John Porter wrote:
> iVAN Georgiev <[EMAIL PROTECTED]>:
> >
> > They behave similarly like &&, ||, and, or operator with one main
> > distinction they "backtrack" for example:
> >
> > { block1 } B { block2 };
>
> This would be a good use of the to-be-liberated => operator:
>
> { block1 } => { bl
On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote:
> The ultimate target of a program's source code is the *programmer*.
> Programmers, being people (well, more or less... :), work best with symbols
> and rich context. Stripping contextual clues out of code does the
> programmer a di
Stephen P. Potter wrote:
> | If the list to be unzipped is not an exact multiple of the partition
size,
> | the final list references are not padded--their length is one less than
> | the list size. For example:
> |
> | @list = (1..7);
> | @unzipped_list2 = unzip(3, \@list); # ([1,4,7], [2,5
Jonathan Scott Duff wrote:
>
> On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote:
> > This is a succinct summary of the basic conclusions thus far:
> >
> >1. a default filehandle IS needed sometimes, but only
> > for stuff like print
>
> Well, I think that C should always pr
At 05:06 PM 8/15/00 -0400, John Porter wrote:
>I think about the word some OO gurus use: "raise".
I think that came from the kernel or hardware people before OO was
around. Something about raising and lowering IPLs.
--
Peter Scott
Pacific Systems Design Technologies
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
whispered
> :
> | Here's a counter-proposal: throw out hashes as a separate internal
> | data type, and in its place define a set of operators which treat
> | (properly constructed) arrays as associat
At 05:33 PM 8/15/00 -0400, John Porter wrote:
>The thing I don't like about C++/Java try/catch syntax is the way
>the blocks are daisychained. That is not intuitive to the flow.
I find it quite intuitive :-)
>The exception handlers should be more closely bound -- syntactically --
>to the try bl
On Wed, Aug 16, 2000 at 08:26:26AM +1000, Jeremy Howard wrote:
> Doesn't RFC 82 (Make operators behave consistantly in a list context)
> provide this functionality? This is perfectly valid under that proposal:
>
> @result = @a || @b;
>
> Which applies '||' component-wise to elements of @a and
On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote:
> Stephen P. Potter wrote:
> > Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
> whispered
> > :
> > | Here's a counter-proposal: throw out hashes as a separate internal
> > | data type, and in its place define a
Jonathan Scott Duff wrote:
>
> On Mon, Aug 14, 2000 at 09:40:07PM -0500, David L. Nicol wrote:
> > Jonathan Scott Duff wrote:
> > >
> > > > context-based method overloading
> > >
> > > I think you should s/method/subroutine/ everywhere in this document.
> > > What you say of methods is equally as
> 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 am looking forward to reading some *real* criticisms...
Ok, here goes. First
At 03:14 PM 8/15/00 -0700, Russ Allbery wrote:
> > 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 f
At 02:44 PM 8/15/00 -0700, Nathan Wiger wrote:
> > Better yet, DWIM. If I write
> >
> > print "[EMAIL PROTECTED]";
> >
> > and no array @southern exists, I probably mean I want it to print
> >
> > [EMAIL PROTECTED]
> >
> > I'd say, if the variable exists, interpolate it. If not, print it as
Jarkko Hietaniemi wrote:
> On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote:
> > Stephen P. Potter wrote:
> > > Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
> > whispered
> > > :
> > > | Here's a counter-proposal: throw out hashes as a separate internal
> > >
At 05:41 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
> > No, neither proposal makes sense. Arrays can be stored compactly and
>
>$a[1_000_000_000] = 'oh, really?' # :-)
Now, now, there have been credible proposals for sparse arrays, you know
that...
--
Peter Scott
Pacific Systems Design Technolo
> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote:
>> This is a succinct summary of the basic conclusions thus far:
>>
>> 1. a default filehandle IS needed sometimes, but only
>> for stuff like print
JSD> Well, I thi
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW>2. $|, $\, $/, etc will probably go away entirely in
NW> favor of object methods such as $handle->autoflush
It think they will still be needed as lexical variables used as an
initializer for the corresponding per-filehandle valu
> As I understand things:
>
>BLOCK1 andthen BLOCK2
>
> evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates
> BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2
> evaluates to "false", then BLOCK1 is re-evaluated.
So how is that different from:
> The difference is one of use, not one of meaning. Why not extend
> "method" to be any subroutine, just as we have apparently extended
> "subroutine" to include "function" by not acknowledging any
> distinction there either?
In fact, Class::Multimethods *doesn't* distinguish methods
Damian Conway wrote:
>
> Ah, but there's definitely a confusion as to whether it's *meant*
> to be assignable.
>
> What if I (as the class designer) want to give you read access but not
> write access to an object's name?
I think this misses the mark. We're talking about functions, right?
:lvalu
> > > No, neither proposal makes sense. Arrays can be stored compactly and
> >
> > $a[1_000_000_000] = 'oh, really?' # :-)
> >
> my int @a: sparse;
I see: you have a time machine and I don't. So very unfair...
> $a[1_000_000_000] = 'Yes, really!' # :P
>
> OK, so I cheated... I haven't subm
1 - 100 of 207 matches
Mail list logo
