On Tue, Aug 15, 2000 at 09:27:23PM -0700, Ask Bjoern Hansen wrote:
>LIST: perl6-language-objects
>CHAIR: Nathan Wiger <[EMAIL PROTECTED]>
>MISSION:Develop RFCs related to objects and OO programming in
>Perl, possibly rationalising existing RFCs where they
Please take this discussion to perl6-language-datetime. Thanks!
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664
Mark Cogan wrote:
> At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >You are missing the beauty of vector/matrix operations.
>
> No, I'm not; I'm opining that the vast majority of Perl users don't need
to
> do vector/matrix ops, and that they don't belong in the core.
>
The vast majority of Perl
Damien Neil <[EMAIL PROTECTED]> writes:
> Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
> but add an element to one and you can change the order of everything in
> it.
Formally, I believe it's permissable for a hash implementation to return a
different order the second
On Tue, Aug 15, 2000 at 11:15:03PM -0700, Peter Scott wrote:
> No, || is half-consistent at the moment: the left hand side is forced into
> scalar context but the result context propagates down the right hand
> side. I challenge anyone to come up with a rationalization for this that
> does not
At 04:02 PM 8/16/00 +1000, Jeremy Howard wrote:
>Nathan Torkington wrote:
> > Your [Jeremy's] RFC says:
> > > Currently, operators applied to lists in a list context behave
> > > counter-intuitively:
> >
> > Counter-intuitively is different from consistently. Your title is
> > misleading. Perl's
Mark Cogan wrote:
> At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
> >It seems obvious that @a should be the whole array @a, not the size of
the
> >array. If I want to check the size of @a, I should have to do so
explicitly,
> >with scalar or $#.
> >
> >This is non-obvious if you think that || is
On Tue, Aug 15, 2000 at 10:26:13PM -0600, Nathan Torkington wrote:
> I like the idea of adding the context-aware operators, but I don't
> think I'd use them as often as I use "the number of things in the
> array". I think most Perl programmers would be in the same camp.
> Unless you can show a co
On Tue, Aug 15, 2000 at 11:46:04PM -0400, Stephen P. Potter wrote:
> Why is it silly? Hashes and arrays are *conceptually* very similar (even
> if they are extremely different implementation-wise). One of them has
> implicit key, the other has an explicit key. They both provide some sort
> of o
Nathan Torkington wrote:
> Your [Jeremy's] RFC says:
> > Currently, operators applied to lists in a list context behave
> > counter-intuitively:
>
> Counter-intuitively is different from consistently. Your title is
> misleading. Perl's ops *are* applied consistently: they consistently
> give the
"Stephen P. Potter" wrote:
>
> I think fail() and handle() are good. Something fail()ed and
> it was handle()d by an exception.
Fail is no good, because exceptions can be used to indicate success.
Just because you don't isn't a counter-argument. Exceptions are
*not* the same as errors, that's
Dan Sugalski wrote:
> At 05:55 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?' # :-)
> > > >
> > > my int @a: sparse;
> >
> >I see: you have a time machine and I don't. So
[EMAIL PROTECTED] writes:
> I don't think this is a language issue. However, I don't believe
> there's a -doc working group yet, either.
>
> Is it time for a -doc group to form?
Not unless there's a significant interest in doc issues, as reflected
in RFCs.
Nat
Jeremy Howard writes:
> It seems obvious that @a should be the whole array @a, not the size of the
> array. If I want to check the size of @a, I should have to do so explicitly,
> with scalar or $#.
It depends. Which interpretation depends on which action you'll want
most often.
> @result = @
> I assume you meant that :lvalue() takes a parameter list. Either a
> singleton named variable $, @, or %.
I'm proposing that an lvalue subroutine have access to the rvalue
assigned through a channel other than the standard argument list @_. I
used, as an example, an explicit named paramete
Your RFC says:
> Currently, operators applied to lists in a list context behave
> counter-intuitively:
Counter-intuitively is different from consistently. Your title is
misleading. Perl's ops *are* applied consistently: they consistently
give their arguments scalar context (except for the short
Chaim Frenkel writes:
> You are missing the beauty of vector/matrix operations. The math folks
> really would like to be able to describe the operation wanted and have
> perl do the optimization.
Fine, but make it an option.
> Would adding another character be helpful
>
> @result = @a x||
Jeremy Howard writes:
> Note that RFC 82 (http://tmtowtdi.perl.org/rfc/82.pod) proposes that _all_
> operators behave the same way in a list context. To me, this consistancy
> would be a real win.
I don't know. Perl has been all for breaking consistency when it made
the programmer's life easier,
Subscribe by sending mail to
[EMAIL PROTECTED]
More details at http://dev.perl.org/lists.shtml
LIST: perl6-language-objects
CHAIR: Nathan Wiger <[EMAIL PROTECTED]>
MISSION:Develop RFCs related to objects and OO programming in
Perl, possibly rationalisi
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
immedia
Chaim Frenkel said:
> BB> Unfortunately, the valid range of time supported is easily determined,
> BB> and disturbingly short:
>
> BB> Into the future: to next December 31st or June 30th, whichever is
> BB> closer.
> BB> Into the past : to past January 1st or July 1st, whichever is
> BB>
(Reply-to set to -datetime list)
Chaim Frenkel writes:
> NT> Epoch seconds are a convenient representation for dates and times.
> NT> Varying epochs make it an unreliable representation when data are
> NT> shared. A consistent epoch would fix this.
>
> Sorry, I don't buy that. Not every program
NOTICE: reply-to set to the -language-datetime list.
Ted Ashton writes:
> Well then, why 1970? If we're defining our own, why buy into one
> which is scheduled to blow up in 2038? Why not at the very least
> start with Jan 1, 2K?
This works, provided epoch seconds are stored in some form of bi
At 11:05 PM 8/15/00 -0500, Jonathan Scott Duff wrote:
>On Tue, Aug 15, 2000 at 08:59:25PM -0700, Mark Cogan wrote:
> > At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
> > >Counter example:@a = \($a, $b, $c);
> >
> > I guess I'm missing the point; how is this different from
> >
> > @a = [$a
Lightning flashed, thunder crashed and "Jeremy Howard" <[EMAIL PROTECTED]> whispered:
| @unzipped_list2 should not be([X,Y,Z], [A,B,C], [M]). The RFC's proposed
| behaviour makes it work as the inverse of zip(), which is the desired
| behaviour.
The reason I used letters instead of the actual val
On Tue, Aug 15, 2000 at 08:59:25PM -0700, Mark Cogan wrote:
> At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >Counter example:@a = \($a, $b, $c);
>
> I guess I'm missing the point; how is this different from
>
> @a = [$a,$b,$c];
Well, I've lost the point of this thread, but
On Tue, Aug 15, 2000 at 11:17:16PM -0400, Chaim Frenkel wrote:
> Sorry, I don't buy that. Not every program will be perl. Plus you are
> assuming that epoch seconds are good everywhere. And even if it were
> why should any other program use the same epoch.
Well, we're not talking about *every* pr
At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
> > "MC" == Mark Cogan <[EMAIL PROTECTED]> writes:
>
>MC> What should:
>MC> @a = defined @a;
>MC> return?
>
>Counter example:@a = \($a, $b, $c);
I guess I'm missing the point; how is this different from
@a = [$a,$b,$c];
which works to
Lightning flashed, thunder crashed and Dan Sugalski <[EMAIL PROTECTED]> whispered:
| At 04:03 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
| > > open, you fall through, someimes through several floors, until somewhere
| > > you encounter a safety net: you were caught. You can continue from
| > > the
Lightning flashed, thunder crashed and Dan Sugalski <[EMAIL PROTECTED]> whispered:
| > > Doesn't it make more sense to get rid of arrays and just use hashes?
| >
| >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 easi
> "MC" == Mark Cogan <[EMAIL PROTECTED]> writes:
MC> What should:
MC> @a = defined @a;
MC> return?
Counter example:@a = \($a, $b, $c);
(Not really a full fledged counter example since it is a liter list.)
>> Treating || as a special case is asking for trouble. If you want a flow
>>
At 10:28 PM 8/15/00 -0400, Ted Ashton wrote:
>I don't know for sure what Perl's main goal is, but it's definitely
>significant to Perl to make life easier and it has done that.
It seems to be the language to Fix Things That Annoy Us. :) Or so it's
always seemed to me. (And it seems to be the dr
At 05:55 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?' # :-)
> > >
> > my int @a: sparse;
>
>I see: you have a time machine and I don't. So very unfair...
Need to upgrade to
On Tue, Aug 15, 2000 at 06:53:30PM -0400, Chaim Frenkel wrote:
> What if you want to print to a default file handle and also to STDOUT?
>
> select(OTHERFH);
> print "This goest to OTHERFH\n";
> print STDOOUT "This went to STDOUT\n";
print $_ "Here I come to save the day!\n" for
I assume you meant that :lvalue() takes a parameter list. Either a
singleton named variable $, @, or %.
Or If it makes sense even a more complex parameter list could be
demanded.
sub foo :lvalue(Dog $fido, int @array, %hash) {}
foo() = ($name, 0..10, %bar);
> "BB" == Buddha Buck <[EMAI
On Tue, Aug 15, 2000 at 10:38:23PM -0400, Ted Ashton wrote:
> Well then, why 1970? If we're defining our own, why buy into one which is
> scheduled to blow up in 2038? Why not at the very least start with Jan 1, 2K?
Um, it's not guaranteed to blow up in 2038. That's an implementation
detail.
> "s" == skud <[EMAIL PROTECTED]> writes:
s> Command line options aren't really a language issue, however I'm not
s> sure that there is a better list for them. Anyone on bootstrap got any
s> good ideas?
shove it over onto -internals.
They will have to implement it anyway.
The only other
On Wed, Aug 16, 2000 at 08:54:28AM +1000, Damian Conway wrote:
>> 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
At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
>You are missing the beauty of vector/matrix operations.
No, I'm not; I'm opining that the vast majority of Perl users don't need to
do vector/matrix ops, and that they don't belong in the core.
>The math folks
>really would like to be able to de
> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
RA> Buddha Buck <[EMAIL PROTECTED]> writes:
>> Leap-seconds are a PITA for generic time routines.
RA> Unix time ignores leap seconds. POSIX basically says "don't worry about
RA> them" and by and large that works. It means your system clock
> "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:
>> Why? What is the gain? Perl only runs on the local machine.
>>
>> As long as one can increment and take the difference what difference
>> does the epoch make?
>>
>> What is of more interest would be knownig the valid range of time
>> supp
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> Why? What is the gain? Perl only runs on the local machine.
NT> Epoch seconds are a convenient representation for dates and times.
NT> Varying epochs make it an unreliable representation when data are
NT> sh
You are missing the beauty of vector/matrix operations. The math folks
really would like to be able to describe the operation wanted and have
perl do the optimization.
Would adding another character be helpful
@result = @a x|| @b?
@result = @a ||| @b?
or perhaps a modifier?
Command line options aren't really a language issue, however I'm not
sure that there is a better list for them. Anyone on bootstrap got any
good ideas?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins
Please take this discussion to the new -errors sublist. Thanks in
advance!
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile:
On Tue, Aug 15, 2000 at 08:03:44PM -, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Standardize ALL Perl platforms on UNIX epoch
>
>=head1 VERSION
>
> Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
> Date: 14 Aug 2000
> Last-Modified: 15 Aug 2000
> Version: 2
> Mailing List: [EMAIL PROTECTED]
On Tue, Aug 15, 2000 at 07:12:08AM -0700, Syloke Soong wrote:
>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 th
At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
>Mark Cogan wrote:
> > At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
> > >Jeremy Howard writes:
> > > > @result = @a || @b;
> > > >
> > > > Which applies '||' component-wise to elements of @a and @b, placing
>the
> > > > result in @result.
>
Mark Cogan wrote:
> At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
> >Jeremy Howard writes:
> > > @result = @a || @b;
> > >
> > > Which applies '||' component-wise to elements of @a and @b, placing
the
> > > result in @result.
> >
> >*Ptui* That's not how *I* want || to behave on lists/arr
Thus it was written in the epistle of Nathan Torkington,
> Chaim Frenkel writes:
> > Why? What is the gain? Perl only runs on the local machine.
>
> Epoch seconds are a convenient representation for dates and times.
> Varying epochs make it an unreliable representation when data are
> shared. A
On Tue, Aug 15, 2000 at 05:47:53PM -0600, Nathan Torkington wrote:
> I want
> @result = @a || @b;
> to be like:
> (@result = @a) or (@result = @b);
>
> That's what all my students keep expecting it to mean.
And that's what I keep wishing it meant too.
-Scott
--
Jonathan Scott Duff
[EMAIL
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, nor
> should it.
Russ,
Would
> Damian Conway wrote:
> >
> >> Now, if this is what you want, add a :readonly attribute:
> >
> > So the proposal is: make the dangerous one the default.
> > I don't think that's a good idea.
>
> You're going to have to explain to me how these differ in their
> dangerousness:
>
>$r->fu
Buddha Buck <[EMAIL PROTECTED]> writes:
> Leap-seconds are a PITA for generic time routines.
Unix time ignores leap seconds. POSIX basically says "don't worry about
them" and by and large that works. It means your system clock drifts a
little over time and then gets corrected back by xntpd or
Nathan Wiger writes:
> > So the proposal is: make the dangerous one the default.
> > I don't think that's a good idea.
>
> You're going to have to explain to me how these differ in their
> dangerousness:
Nathan, you misunderstand Damian. What's dangerous is making every
subroutine lvaluable. H
On Tue, 15 Aug 2000, Buddha Buck wrote:
> Leap-seconds are a PITA for generic time routines.
>
Not really. They don't happen very often so you simply have a subroutine
that has them all (this is how SLALIB does it). The pain is that you have
to release a new version of perl each time a new leap
Chaim Frenkel writes:
> Why? What is the gain? Perl only runs on the local machine.
Epoch seconds are a convenient representation for dates and times.
Varying epochs make it an unreliable representation when data are
shared. A consistent epoch would fix this.
Nat
> Why? What is the gain? Perl only runs on the local machine.
>
> As long as one can increment and take the difference what difference
> does the epoch make?
>
> What is of more interest would be knownig the valid range of time
> supported on each platform. Even if you standardize the epoch, the
Peter Scott wrote:
> I have often wished that digraphs were not bundled with variables in this
> respect, i.e., I wanted to put a string containing \n inside single quotes
> just 'cuz it didn't contain variables to be interpolated. Whether there's
> a way of improving this behavior or not I don't
At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
>Jeremy Howard writes:
> > @result = @a || @b;
> >
> > Which applies '||' component-wise to elements of @a and @b, placing the
> > result in @result.
>
>*Ptui* That's not how *I* want || to behave on lists/arrays.
>
>I want
> @result = @a |
Damian Conway wrote:
>
>> Now, if this is what you want, add a :readonly attribute:
>
> So the proposal is: make the dangerous one the default.
> I don't think that's a good idea.
You're going to have to explain to me how these differ in their
dangerousness:
$r->func = $x; # this mo
Nathan Torkington wrote:
> Jeremy Howard writes:
> > @result = @a || @b;
> >
> > Which applies '||' component-wise to elements of @a and @b, placing the
> > result in @result.
>
> *Ptui* That's not how *I* want || to behave on lists/arrays.
>
> I want
> @result = @a || @b;
> to be like:
>
John Porter writes:
> I think as long as equivalent (and better!) functionality is available,
> through equivalently terse syntax, who's to care? Why is
>
> $h{'foo'} = 'bar';
>
> instrinsically preferable to
>
> assoc( %h, 'foo', 'bar' );
I'm horrified you have to ask this quest
John Porter writes:
> Heh, that's not OO-like syntax! That's a switch statement! :-(
>
> Maybe this is "OO":
>
> attempt = new Try { cough "outa here"; };
> attempt.catch( matawba => { sustain } );
> attempt.catch( ebola => { overrule } );
> attempt.catch( { punt } );
>
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>> I want this to *always* print out the _value_ of @stuff, even if it's
>> unititalized.
PS> Arrays aren't uninitialized. They contain zero or more scalars, some of
PS> which may be uninitialized.
I don't know if it is still true. But at
> =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 hashlike
objects represented as scalars. Howev
Perl6 RFC Librarian writes:
> =head1 TITLE
>
> Less line noise - let's get rid of @%
I have some problems with this RFC:
* 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.
On Tue, 15 Aug 2000, John Porter wrote:
> Yes. OTOH, if it doesn't add *enough* information, it's not cost-
> effective. Most of proposals, such as highlander types and this 109,
> reduce the amount of info carried by the symbol to the point that it
> isn't worth having. Furthermore, if the OO
(-internals removed from the CC list)
[EMAIL PROTECTED] writes:
> All calendar systems are arbitrary.
Yup. So let's use Larry's birthdate-and-time as the epoch marker.
Seriously, stick with 1970 (if we need an arbitrary marker, no reason
it can't be a familiar one) and extend date/time values
On Tue, 15 Aug 2000, Nathan Wiger wrote:
> Jarkko Hietaniemi wrote:
> >
> > > Is Perl currently using different epochs on different platforms? If so, I
> >
> > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
> > just to be portable.) MacOS' epoch zero is 1900 (or was i
Jeremy Howard writes:
> @result = @a || @b;
>
> Which applies '||' component-wise to elements of @a and @b, placing the
> result in @result.
*Ptui* That's not how *I* want || to behave on lists/arrays.
I want
@result = @a || @b;
to be like:
(@result = @a) or (@result = @b);
That's what
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]; #
At 12:57 PM 8/15/00 -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
>
>2. $|, $\, $/, etc will probably go away entirely in
> favor of object methods such a
Steve Fink <[EMAIL PROTECTED]> writes:
> I would very much hate to see the prefixes go away or merge into a
> single one, but I'm not so sure I agree with Russ. I've had to teach
> lots of beginners that even though $x refers to scalar x, $x{...} refers
> to %x, but don't think of it that way bec
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 formats. For
> exampl
Peter Scott wrote:
> I have often wished that digraphs were not bundled with variables in this
> respect, i.e., I wanted to put a string containing \n inside single quotes
> just 'cuz it didn't contain variables to be interpolated. Whether there's
> a way of improving this behavior or not I don'
John Porter wrote:
> So, instead of "throw": "throwup".
That leads me down the path of "puke" and "scrub" instead of "throw" and
"catch". Actually, I rather liked the "oops" Scott suggested, but used in
place of "throw" instead of a rename of "exception". So how about "oops" and
"recover" inst
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
Why? What is the gain? Perl only runs on the local machine.
As long as one can increment and take the difference what difference
does the epoch make?
What is of more interest would be knownig the valid range of time
supported on each platform. Even if you standardize the epoch, the
platform may
> Now, if this is what you want, add a :readonly attribute:
So the proposal is: make the dangerous one the default.
I don't think that's a good idea.
Damian
> > > 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
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
> 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
> "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:
> "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
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
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 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
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
> 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
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
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
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
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
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: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
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
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
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
1 - 100 of 207 matches
Mail list logo
