Front page | perl.perl6.internals.api.parser |
Postings from November 2000
On Mon, Nov 27, 2000 at 05:17:47PM +0000, Nicholas Clark wrote:
> On Mon, Nov 27, 2000 at 11:09:03AM -0500, Chaim Frenkel wrote:
> > >>>>> "ST" == Sam Tregar <sam@tregar.com> writes:
>
> > Look throught the RFCs this was one of Damian Conway's.
> >
> > <chaim> =~ /RFC/
>
> http://dev.perl.org/rfc/93.html
>
> I know I read it, I just don't remember reading it.
>
> IMPLEMENTATION
>
> Dammit, Jim, I'm a doctor, not an magician!
>
> Probably needs to be integrated with IO disciplines too.
>
> He's right, but Nick's intending to implement an unread() (rather than just
> ungetc()) so there should be enough rope for people to implement whatever
> knots take their fancy (including the Jack Ketch knot)
>
> Hugo makes some comments about implementation of this in:
> http://archive.develooper.com/perl6-language-regex@perl.org/msg00459.html
Bah. meant to add that it might be logical for
<chaim> =~ /RFC/
to seek to the beginning of the file before it starts
<chaim> =~ /\GRFC/gc
carries on from the previous position and doesn't seek back to the beginning
(or otherwise throw all the buffered data away)
Which effectively makes pos analogous to seek/tell.
So do we get rid of poss and seek() our scalars? :-)
It also allows the possibility of pos on file handles being fsetpos/fgetpos
Maybe that should have been an rfc 3 months ago, and really doesn't even
matter if perlio obsoletes stdio and internalises stdio's distinction between
text and binary streams.
BTW I am serious about needing a /gc not to chuck the buffered data.
It makes something like
@found = <chaim> =~ /RFC +(\d+)/;
not spend time stacking a lot of data back that's only about to be discarded.
But this isn't internals really, is it? I'm miles off topic.
Nicholas Clark
Thread Previous
|
Thread Next