>> Frankly, I thought it was absurd when I first wrote it...
>> but then I looked at again, and now I'm not so sure I dislike it!
>>
>> =head1 CHANGES
>> =over 4
>> =item * Detailed implementation description
>> =item * Add a new pragma 'varlock' for controlling the concurrency
>> =ba
At 10:38 AM 9/13/00 -0400, John Porter wrote:
> > 2. Allowing $/ (or its successor, perhaps set on a per-filehandle
> > basis) to be a regular expression, not a string. (Surely there's an RFC
> > on that somewhere.)
>
>This is a good idea too, and should probably be considered independently.
*A
At 09:19 AM 9/13/00 -0700, I wrote:
>At 10:38 AM 9/13/00 -0400, John Porter wrote:
>> > 2. Allowing $/ (or its successor, perhaps set on a per-filehandle
>> > basis) to be a regular expression, not a string. (Surely there's an RFC
>> > on that somewhere.)
>>
>>This is a good idea too, and should
On Wed, 13 Sep 2000 10:58:51 -0400, John Porter <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
> > Are we being clever again?
> > Rephrase: "No empty lines".
> > I know you understood, but ... (no, I won't say it)
>
> Frankly, I thought it was absurd when I first wrote it...
> but then I look
H.Merijn Brand wrote:
> Are we being clever again?
> Rephrase: "No empty lines".
> I know you understood, but ... (no, I won't say it)
Frankly, I thought it was absurd when I first wrote it...
but then I looked at again, and now I'm not so sure I dislike it!
=head1 CHANGES
=over 4
=item *
On Wed, 13 Sep 2000 10:19:38 -0400, John Porter <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
> > On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > > This and other RFCs are available on the web at
> > > http://dev.perl.org/rfc/
> > >
> > > =head1 TITLE
> >
Andy Dougherty wrote:
>
> 1. A standard library function to safely but forgivingly read in a
> "paragraph". I have cc'd perl6-stdlib since this strikes me as a sensible
> candidate for the standard library.
I like this idea a lot. It would work very well with my RFC 79.
> 2. Allowing $/ (o
H.Merijn Brand wrote:
> On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> > =head1 TITLE
> >
> > POD should tolerate white space.
>
> I don't want any newlines needed at all, tho
> POD should tolerate white space where it now requires empty lines
[...]
> =head1 IMPLEMENTATION
>
> Seems like it should be just a regexp stuck in somewhere
I think this is a specific problem calling for a more general solution.
I can think of two possible ones:
1. A standard library func
>I can't think any reason why POD tags require "\n" instead of /^\s*$/.
Because then you can set $/ = "" and sail through a source file, of course!
--tom
> On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > POD should tolerate white space.
>
> I don't want any newlines needed at all, though I think I stand somewhat alone
> here.
> --
> H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
I
On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> POD should tolerate white space.
I don't want any newlines needed at all, though I think I stand somewhat alone
here.
On Wed, Sep 13, 2000 at 07:18:15AM -, Perl6 RFC Librarian wrote:
> POD should tolerate white space where it now requires empty lines
I used to trip over this problem alot in my code. In fact, patches
#5507 and #5493 to perl were just about stripping whitespace out of
POD, IIRC.
I can't thin
13 matches
Mail list logo