> >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
>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
> Do we have an RFC yet that proposes Perl to be easier parsable?
> Damian?
Working on it.
Damian
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
> =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
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
> > "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 *
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
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
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
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
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
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
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
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 $
> : 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
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
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
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
19 matches
Mail list logo
