On Wed, Aug 16, 2000 at 04:49:15PM -0500, David L. Nicol wrote:
>
>
> or AUTOLOAD can be defined in terms of C
> and overloaded that way, rather than being its own
> kind of magic.
>
> catch "AUTOLOAD-$classname-$polymorphicsignature" {...
But why should I have to know that a sub I want
On Wed, Aug 16, 2000 at 11:15:40PM -0700, Peter Scott wrote:
>
>Sorry I didn't chime in earlier, but I would like to say that I prefer
>published deadlines. Reason: people will talk for as long as you give
>'em. However long a meeting is scheduled for, that's how long it will
>take. We're al
At 04:12 PM 8/17/00 +1000, [EMAIL PROTECTED] wrote:
>On Wed, Aug 16, 2000 at 10:35:09AM -0700, Nathan Wiger wrote:
> >I agree. I think the trend should be to establish some permanent
> >sublists, which we're informally leaning towards already. Something
> >like:
> >
> > -io = ALL I/O issue
On Wed, Aug 16, 2000 at 10:35:09AM -0700, Nathan Wiger wrote:
>I agree. I think the trend should be to establish some permanent
>sublists, which we're informally leaning towards already. Something
>like:
>
> -io = ALL I/O issues, like open/socket/filehandles
> -subs = ALL sub/method/
On Tue, Aug 15, 2000 at 08:05:25PM -, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>lvalue subs should receive the rvalue as an argument
>
>=head1 VERSION
>
>Maintainer: Andy Wardley <[EMAIL PROTECTED]>
>Date: 15 Aug 2000
>Version: 1
>Mailing List: [EMAIL PROTECTED]
>Number:
On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
>
>If "catch" can be defined DURING PARSING
>
>and SYNTAX ERRORS are catchable
>
>error handling can be used to define otherwise
>undefined syntax, becoming a macro language.
Please take this to the -errors sublist. Thanks...
K.
-
> >"Print this line.\n"<;
Some questions:
1. How do you specify alternate filehandles to output to?
select() doesn't count for the purposes of this question.
2. How do you support the list form of print, namely:
print "Hello there ", $r->fullname, "!\n";
3. Can you
Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]] wrote:
>
> On Wed, Aug 16, 2000 at 09:49:36AM -0400, Stephen P. Potter wrote:
> > Lightning flashed, thunder crashed and Jonathan Scott Duff
> <[EMAIL PROTECTED]> whispered:
> > | Um, it's not guaranteed to blow up in 2038. That's an
> implementatio
On Wed, Aug 16, 2000 at 11:42:20AM -1000, Tim Jenness wrote:
> What about:
>
> for (0..$#array) {
> print $array[$i], " is at index ", $i, "\n";
> }
>
> I use that whenever I need to loop over indices of two arrays at once.
And with the proposed zip() you may be able to do so
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Better constants and constant folding
=head1 VERSION
Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 15 2000
Last-Modified: Aug 16 2000
Version: 2
Mailing List: [EMAIL PROTECTE
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should have a print operator
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 5 August 2000
Last-Modified: 17 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Angle brackets should not be used for file globbing
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 4 August 2000
Last-Modified: 17 August 2000
Version: 2
Mailing List: [EMAIL PRO
Chaim Frenkel wrote:
> > "KH" == Kai Henningsen <[EMAIL PROTECTED]> writes:
>
> KH> Hashes and arrays, OTOH, really aren't different for people. The
concept
> KH> of an index needing to be a nonnegative number is a computer concept.
>
> I don't know about that. Good old PL/I had arbitrary rang
At 09:14 PM 8/16/00 -0600, Tony Olekshy wrote:
>Jonathan Scott Duff wrote:
> >
> > I can almost see what you're talking about but not quite. It sounds
> > like you want caller() info available to the exception handler... but
> > isn't it?
>
>The basic problem is that the stack traceback at the ti
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> The concept isn't that hard ":lvalue makes it so you can assign to
NW> subs". But the hard part is deciding *where* it should be used. I think
NW> it puts an unfair burden on a CPAN author to try and forsee all the
NW> possible uses of a
> "JS" == John Siracusa <[EMAIL PROTECTED]> writes:
JS> On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
>> It is proposed that a new syntax for declaring constants be introduced:
>>
>> my $PI : constant = 3.1415926;
>> my @FIB : constant = (1,1,2,3,5,8,13,21);
>> my %ENG_ERRORS : constant =
Folks,
I'm off on vacation until mid-next week some time (probably the 23rd). I
don't expect it'll make much of a difference, but just in case someone's
wondering where I've gone to and why I've not answered that burning e-mail
message...
Dan
-
> "KH" == Kai Henningsen <[EMAIL PROTECTED]> writes:
KH> Hashes and arrays, OTOH, really aren't different for people. The concept
KH> of an index needing to be a nonnegative number is a computer concept.
I don't know about that. Good old PL/I had arbitrary ranges for array
indices.
Hmm, I
"David L. Nicol" wrote:
>
> sub openrecord{
> my $RecordFileName = &GetRecordFileName;
> TRYOPEN:
> open REC, "$RecordFileName" or throw "FILE-NO-OPEN";
> #work with the file
> ...
>
> return;
>
> my $probl
> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> On Wed, Aug 16, 2000 at 12:48:12PM -0400, Dan Sugalski wrote:
>> At 11:09 AM 8/16/00 -0400, John Porter wrote:
>> >The difference between numbers and strings is analogous to --
>> >or, on further reflection, IDENTICAL to -- the d
At 11:05 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
> >> Also a use (within main or if it can work lexically) that would mean
> >> die_if_exception_thrown. Would treat the main routine as if it were
> >> wrapped in a try block that doesn't catch
Graham Barr wrote:
>
> On Wed, Aug 16, 2000 at 10:19:53AM -0400, Chaim Frenkel wrote:
> >
> > I would say that outside of the try block all throws are caught if
> > at all by the wrapping try. So that throws propogate outward. Never
> > back within itself.
>
> Agreed.
Throws propagate *forward*
Jonathan Scott Duff wrote:
>
> I can almost see what you're talking about but not quite. It sounds
> like you want caller() info available to the exception handler... but
> isn't it?
The basic problem is that the stack traceback at the time of catching
is not the same as the stack traceback at
Kai Henningsen wrote:
>
> Tony Olekshy wrote:
>
> > 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
Peter Scott wrote:
>
> If that were so, even without the ignore() function, I could just say
>
> sub Exception::IO::throw { 'do nothing' }
>
> and kill it that way.
Right. Just like overriding core die. At that point you can
change the semantics in such a way as to turn your code in
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > try { TryToFoo; }
> > catch { TryToHandleFailure; }
> > finally { TryToCleanUp; }
> > catch { throw "Can't cleanly Foo."; };
> >
> >In our production code we often add such blocks to major API entry
> >point
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> >[snip]And the following output was generated:
> >
> > Exception
> >
> > $ = Try::throw('Exception') called from scott2.pm[8].
> > $ = main::pling('Test') called from scott2.pm[4].
> > $ = main::bar('Test') called from scott1.pl[1].
Executive summary: I no longer want catch blocks to "daisy chain"
after a exception is thrown in a catch block. Thanks to everyone
who has helped me see the light on this.
Peter Scott wrote:
>
> At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
> >
> > The proposed omnibus Exceptions RFC uses the f
On Wed, 16 Aug 2000, Perl6 RFC Librarian wrote:
> This will ignore all leading white space on each line until the end terminator
> is found. It effectively does s/^\s*// before processing each following line.
I don't agree with this, but
> It also ignores whitespace (but not the line termi
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
>> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>>
PS> 1. When an exception is thrown perl looks for the enclosing try block; if
PS> there is none then program death ensues.
>>
>>
At 10:56 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >> Perhaps, throw can carry a return value?
> >>
> >> throw {"return value"} $exception;
> >> If there is an active try/catch context the
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> Okay, :-) Got a better syntax? Would you want the option of
PS> throwing up n (> 1) levels?
I've seen the term SIGNAL vs. RAISE used.
I don't think we should. That gives the callee too much intimate
knowledge of the caller.
Lets keep
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
>> Perhaps, throw can carry a return value?
>>
>> throw {"return value"} $exception;
>> If there is an active try/catch context then the $exception would
>> be propogated, otherwise $@ would
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> =head2 eval/die remains perfectly workable
DLN> as "die" is a perfectly serviceable method or raising an exception.
Actually, die is pretty nasty. Modules can't use it.
Another mechanism that means, short circuit, but let the user
Chaim Frenkel wrote:
>
> NW> P.S. If you're not on -io, this implicitly means you DON'T CARE and are
> NW> willing to accept whatever we come up with. So, everyone that's
> NW> interested please get on -io. Thanks again.
>
> That's a bit strong. All we are doing is filtering the garbage for Larr
> Either one or both of:
> Perl <-> Perl cross system will break.
> Perl <-> other program same system will break.
>
> Pick your poison. I'd rather have cross system break. But if the
> epoch were available then an adjustment could be made intellegently.
I'd take choice (b). I wa
On Wed, Aug 16, 2000 at 08:22:16PM -0400, Chaim Frenkel wrote:
> > "MF" == Michael Fowler <[EMAIL PROTECTED]> writes:
>
> MF> So what's insufficient about:
>
> MF> print <<"EOF";
> MF> Stuff
> MF> More stuff
> MF> Even more stuff
> MF> EOF
>
>
> Counting
> "MF" == Michael Fowler <[EMAIL PROTECTED]> writes:
MF> So what's insufficient about:
MF> print <<"EOF";
MF> Stuff
MF> More stuff
MF> Even more stuff
MF> EOF
Counting spaces, why make the programer work. Are those tabs or spaces?
And it doesn't strip t
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> [use wacky Unicode characters for new operators]
>> I can see that this would give problems for current editors and displays,
>> but by the time perl6 comes out, perhaps the situation would be better.
NT> No
> "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:
BB> stat() returns time stamps (made in the past). utime() sets time
BB> stamps. They should be compatible with time(). e.g., "utime
BB> time,time,@files" should still set the modify and access times of
BB> @files to "now".
With or without
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
Well, here's something I think I need to delegate. :)
The perl6-internals list hasn't seen nearly the traffic that perl6-language
has, has yet to spawn off any sub-lists, and has produced only a few RFCs.
This is, in general, a good thing, as it's somewhat premature to be getting
too deep into
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> P.S. If you're not on -io, this implicitly means you DON'T CARE and are
NW> willing to accept whatever we come up with. So, everyone that's
NW> interested please get on -io. Thanks again.
That's a bit strong. All we are doing is filterin
> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
TB> On Wed, Aug 16, 2000 at 05:23:04PM +1000, [EMAIL PROTECTED] wrote:
>> OK, weekly report. Ugh.
TB> Shouldn't these to go -announce as well?
I thought we agreed that they percolate upward.
The containing WG would report the results upward
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
Today around 7:17pm, Casey R. Tweten hammered out this masterpiece:
: Today around 2:34pm, Nathan Wiger hammered out this masterpiece:
:
: : > Think on this:
: : >
: : > use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'
: : >
: : > use perlrc qw/:all/;# Import
Today around 2:34pm, Nathan Wiger hammered out this masterpiece:
: > Think on this:
: >
: > use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'
: >
: > use perlrc qw/:all/;# Import all 'Resources'
:
: > This sounds much more managable than a .perlrc that get's a
At 07:06 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> >> There is one case to be considered, what if the try block wishes
> >> to avoid its own catch clauses, and start the unwinding with the
> >> uplevel try block.
>
>GB> Can you think of a ti
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> 1. When an exception is thrown perl looks for the enclosing try block; if
>PS> there is none then program death ensues.
>
>Err, if there isn't one. Don't throw the exception. Stop process
At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
>Perhaps, throw can carry a return value?
>
> throw {"return value"} $exception;
>If there is an active try/catch context then the $exception would
>be propogated, otherwise $@ would get loaded with $exception and
>the return value would be t
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> 1. When an exception is thrown perl looks for the enclosing try block; if
PS> there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing but
don't throw. You are imposing a style on your
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>> There is one case to be considered, what if the try block wishes
>> to avoid its own catch clauses, and start the unwinding with the
>> uplevel try block.
GB> Can you think of a time you would want that ?
Here's one. If the catch blocks t
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be
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();
On 8/16/00 4:00 PM, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Better constants and constant folding
>
> =head1 VERSION
>
> Maintainer: John Siracusa <[EMAIL PROTECTED]>
> Date: Aug 15 2000
> Version: 1
> Mailing List: [EMAIL PROTECTED]
> Number: 113
This RFC has been integrated with RF
> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> On Wed, Aug 16, 2000 at 12:36:42PM -0700, Peter Scott wrote:
>> If you use a switch statement and want implicit rethrow (and I do), then
>> your exception handler somehow has to look inside the switch to see if an
>> exception
During -internals discussions, we seem to have come up with, that the
flattenting will not be required by the implementation. (It might actually
be a win.)
All arrays/lists would be actually have a single reference on the data
stack. For backwards compatiblity, @_ would iterate of all arguments.
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
Graham Barr wrote:
>
>
> Create a new handle, like $DEFOUT. Then there would be no need
> for selectsaver either as you would do the equiv. of
>
> local($DEFOUT) = $newhandle;
Just submitted an RFC on this exact idea.
-Nate
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
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Sent: Wednesday, August 16, 2000 10:00 AM
Subject: Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs
should receive the rvalue as an argument)
> On Wed, Aug 16, 2000 at 12:14:09AM -0700, Nathan Wiger wr
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
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Perl6 RFC Librarian
<[EMAIL PROTECTED]>
> whispered:
> | =head1 TITLE
> |
> | Builtin: partition
> |
> | =head1 ABSTRACT
> |
> | It is proposed that a new function, C, be added to Perl.
> | C would return @list broken into
> | refe
> So, what's so portable about file:// URLs again? How do they magically
> know that //c/ means / on UNIX? What do they do with //z/?
This is only one example. I'm not sure it's the best way. It's
definitely not the only way. Chaim asked:
> Or for that matter "file://u/frankeh/Projects" become
or AUTOLOAD can be defined in terms of C
and overloaded that way, rather than being its own
kind of magic.
catch "AUTOLOAD-$classname-$polymorphicsignature" {...
Jonathan Scott Duff wrote:
>
> On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
> > If "catch" can be def
=head2 eval/die remains perfectly workable
Perl5 has a perfectly agile exception handling method,
C, which syntax-checks at compile time and
returns the value of the value of the last expression
evaluated and sets the special error variables in cases
of errors.
We leave that alone, and use it f
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
Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > It is proposed that in a list context, operators are applied
> > component-wise to their arguments. Furthermore, it is proposed that
> > this behaviour be extended to functions that do not provide a specific
> > list context.
>
> I don't m
On 16 Aug 2000, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Implicit counter in C statements, possibly C<$#>.
>
> =head1 VERSION
>
> Maintainer: John McNamara <[EMAIL PROTECTED]>
> Date: 16 Aug 2000
> Ver
Well said!
Nathan Torkington wrote:
>
> Dan Sugalski writes:
> > Unfortunately, I think you're somewhat under-informed as to the inherent
> > capabilities of people's brains.
>
> Ok, at this point I think all parties have to step away and let the
> RFCs fall where they will.
>
> It's obvious
Nathan Torkington wrote:
> Piers Cawley writes:
> > > > 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
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
Chaim Frenkel writes:
> CN> Can we please cut down on the traffic to perl-announce, maybe make it
> CN> moderated? Thanks,
>
> Perhaps, the esteemed Librarian could make the -announce a Bcc?
One of the moderators was a little too approval-happy. I believe
this has been fixed as of a few hours
On Wed, Aug 16, 2000 at 08:27:04PM +, Nick Ing-Simmons wrote:
> Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >
> >In addition, this RFC recommends deprecating select(), since it is no
> >longer needed with the new fileobject approach described in RFC 14.
> >
> >
> > $oldoutput = select(
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
Dan Sugalski writes:
> Unfortunately, I think you're somewhat under-informed as to the inherent
> capabilities of people's brains.
Ok, at this point I think all parties have to step away and let the
RFCs fall where they will.
It's obvious that there are two types of people: those who don't mind
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
> Think on this:
>
> use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'
>
> use perlrc qw/:all/;# Import all 'Resources'
> This sounds much more managable than a .perlrc that get's applied globaly
> without asking for it.
Bingo. This feature should be off by de
On Wed, Aug 16, 2000 at 01:51:09PM -0600, Nathan Torkington wrote:
> Nathan Wiger writes:
> > Nonetheless, I think a better thing would be to figure out if it's
> > possible to "fix" this issue. I would *really* like lvalue subs ==
> > rvalue subs.
>
> I think conflating:
>foo(@vals)
> and
>
On Tue, 15 Aug 2000, Nathan Wiger wrote:
> Chaim Frenkel wrote:
> >
> > You forget that open() handles all the magic. "| ...", " ...|", and
> > the rest of the family. Sysopen specifically doesn't. So one could
> > easily (and does) use open to do the magic, and then uses sysread/syswrite
> > to
On Wed, Aug 16, 2000 at 08:03:31PM -, Perl6 RFC Librarian wrote:
> Perl should provide a mechanism to have common code autoloaded from a
> file. . . .
> A C file could be used to set system-wide defaults that
> the system administrator would like to promote. For instance,
> C could turn on
Peter Scott wrote:
> >Only one of them needs to be right. As long as one is right,
> >there is no problem.
>
> Right, I was just pointing out that it's harder for people to divine which
> one we picked without recourse to the documentation.
Yes; unfortunately, this problem exists generally, es
On Wed, Aug 16, 2000 at 02:38:33PM -0400, Uri Guttman wrote:
> i see problems with overlapping areas. I/O callbacks fall under both io
> and flow IMO. some of the error handling like dying deep in eval and
> $SIG{DIE} also fall under error and flow.
This is true, and inevitable. But IMHO it'd b
At 04:59 PM 8/16/00 -0400, John Porter wrote:
> > > > What interpretation should be placed on statements in the try block
> > > > following a catch block?
> > >
> > >Whatever you want. I can think of three possibilities.
> >
> > That's the problem. Only one of them will be right.
>
>Only one of
At 04:43 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> * There was some discussion about garbage collection, but it's not really
>DS> gone anywhere, besides to the bookstore. The current reference-count GC
>DS> scheme will probably go, thoug
> This would change the perl5 meaning of lvalue subroutines. Currently
> you must have the lvalue as the last value before the return, and the
> assignment is implicitly done by Perl. I advocate making it explicit:
>
> # this is perl5
> sub foo :lvalue {
> $variable
At 03:40 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Well, those of you writing "exception" RFCs be sure and include this
>example in there somewhere (if it's relevant to your RFC of course).
Done.
>I'm done thinking about exceptions now.
Some of us are hoping to do the same RSN :-)
--
Peter
> Random thoughts:
>
> open "http://www.perl.com";
> open "http://www.perl.com?foo=bar&baz=blat";
> open "http://www.perl.com", %args;
> open "http://www.perl.com", { mode => 'POST' }, %args;
>
> Hmm. I think that "modes" should be made explicit rather than relyi
Chaim Frenkel wrote:
>
> You forget that open() handles all the magic. "| ...", " ...|", and
> the rest of the family. Sysopen specifically doesn't. So one could
> easily (and does) use open to do the magic, and then uses sysread/syswrite
> to handle the dirty details of playing with a pipe.
Yea
Kai Henningsen wrote:
>
> 1. Package variables $package::var, presumably you'd have to declare those
> and the default would be
> 2. lexical variables,
Not bad, but I think #1 violates Laziness if I hear you right. Let's add
a "global" or "your" keyword to do this inside a package:
package M
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
Peter Scott wrote:
> Redirected to -errors to save a thousand eyeballs.
(I hope I'm on that list; please Cc me if not...)
> > > I find it quite intuitive :-)
> >
> >I note the smiley.
>
> It works without the smiley too.
Then you have the intuition of an Ascended Master.[1]
> > > What inte
Peter Scott wrote:
>
> qc?
A proposed form of in-line comment!
> > qc/try/ {
> > might_throw_E1_or_E2();
> > }
> > catch E1 {
> > might_throw_E2();
> > }
> > catch E2 {
> > # where did this E2 come from?
>
Nathan Wiger <[EMAIL PROTECTED]> writes:
>
>For other stuff, like print(), instead of using the "currently selected
>filehandle", just always have it print to $STDOUT unless something's
>specified. So:
>
> $oldstdout = $STDOUT;
> $STDOUT = $myfileobject;
> print "Hello, world!"; # always p
At 09:49 PM 8/16/00 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in
><[EMAIL PROTECTED]>:
>
> > At 06:04 PM 8/15/00 -0400, John Porter wrote:
> > >Dan Sugalski wrote:
> > > > >Generality good.
> > > >
> > > > For many things, yes. For computers, say. For peopl
1 - 100 of 341 matches
Mail list logo
