On 5 Aug 2000 21:40:43 -, Perl6 RFC Librarian wrote:
>It would be nice to be able to say
>
> @a = @b || @c
>
>instead of having to resort to
>
> @a = @b ? @b : @c
Would it? It looks like a small win, unless @b is actually a list
instead of just an array.
Currently, || is a scalar op
On Sat, 26 Aug 2000 19:04:48 +1000, [EMAIL PROTECTED] wrote:
>Righto. I'll coach Sumesh through how to post an RFC properly, and how
>to check whether something's in Perl yet or not.
>
>DO NOT fill -language with discussions of these pseudo-RFCs. Please.
>I'm begging you.
I don't get it. There
Bart Lateur wrote:
> Next, you'll say that every idea must be actually submitted as an RFC
> before being worthy of discussion.
Have to say, I agree with Bart on this. While being in the RFC format
was distracting, far better that he dumped them straight to the list
before submitting them as re
> : That numerical part could then form the basis of the extended exception
> : mechanism. No, the programmer shouldn't memorize the error numbers:
> : there should be predefined constants, like
> :
> : ERROR::filenotfound
> :
> : which are numeric, and which could then be used for the catch
2000-08-22-15:13:23 Peter Scott:
> I too would rather say
>
> my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
> my $fh; try { $fh = open $filename } catch { die "Couldn't copy
> source: ", $@->syserr }
I'd usually rather just say
my $fh = open $
At 10:20 AM 8/27/00 -0400, Bennett Todd wrote:
>I'd usually rather just say
>
> my $fh = open $filename;
>
>and be done with it, but then I'd always "use Fatal qw(:all);". But
>if I'd done such a "use Fatal", and then wanted to catch one, I sure
>hope I wouldn't have such a rabid try/catc
Damian Conway wrote:
>
>> Well, RFC 23 doesn't mention ^0, and has several examples starting
>> at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
>> etc. I didn't make it up.
>
> My apologies. The examples you refer to are incorrect. They were added by
> a helper, but t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Here Docs Terminators (Was Whitespace and Here Docs)
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 27 Aug 2000
Mailing List
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Filtering Here Docs
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 162
=head1 A
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 168
=head1 ABSTRACT
RFC 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
type inference
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Last Modified: 27 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 4
=head1 ABSTRACT
Types
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C<||> and C<&&> should propagate result context to both sides
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last-Modified: 26 Aug 2000
Mailing List: [EM
> > "Array and placeholder indices both start at *zero*!"
>
> Sorry for being late, but "why?!"
>
> It makes more sense in a vacuum, but given $1, $2, etc, I'd *much* more
> expect them to start with ^1, ^2, and so on. It's much more consistent.
But ^1, ^2, etc. have *
Damian Conway wrote:
>
> But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically.
> And I'm removing that analogy from the next version of the RFC! ;-)
>
> They have *everything* to do with $_[0], $_[1], $_[2], etc.
I realize this, but I don't think most people will see it that w
Making 0 the first element makes as much sense as 1- just a convention.
However there is precedence for letting the user decide. Does anyone else
remember
)ORIGIN 1
? So we establish a var $something=n where n is the array origin.
I don't think I'd ever use it personally, having been a c "k
> Do we have an RFC yet that proposes Perl to be easier parsable?
> Damian?
Working on it.
Damian
>THING =~ OTHER_THING
>
> is translated to
>
>bind(THING,OTHER_THING)
>
> with bind() having user-defined semantics.
>
> I think Damian has an RFC in-the-works on operator overloading that
> will address this.
That one's been passed to brian d foy and (if
> >Damian's Text::Balanced does a pretty good job of tokenizing Perl
> >as it is. / by itself requires a lot of lookahead, and it's still
> >a guess.
>
> I don't get it. What makes it so hard? If you see a "/" when you're
> expecting an operator, or end of statement, then it's
> =head1 ABSTRACT
>
> C and C are
...part of...
> what makes Perl hard to tokenize. Requiring
> them to be written C and C would
...help to...
> solve this.
Damian
19 matches
Mail list logo
