Larry Wall:
# For various reasons, some of which relate to the sequence-of-integer
# abstraction, and some of which relate to "infinite" strings
# and arrays,
# I think Perl 6 strings are likely to be represented by a list of
# chunks, where each chunk is a sequence of integers of the same size or
Jarkko Hietaniemi writes:
: > What I notice, though, is that the current code does not warn for
: > characters beyond 0x10, which is definitely a bug.
:
: Ahh, it's all coming back now... warning about such characters
: causes pain in the complementing tr///... have to look at this later.
I
> > switch(...) {
> >case 1: ...;
> >nobreak; /* intentional fall-through */
> >case 2: ...;
> >break;
> >case 3: ...;
> > }
> >
> > Does anyone agree that `nobreak' reads much better than `skip'?
>
> "skip" was uncomforta
On Wed, 30 Jan 2002, Ted Ashton wrote:
> Thus it was written in the epistle of Dave Hartnoll,
> > > Oh, one other tweak. The RFC proposes to overload next
> > > to mean "fall through to the next case". I don't think [...]
> >
> > I would like to suggest a different keyword that does not imply s
> Damian was meant to be writing Parse::FastDescent and then
> Parse::Perl,but as we all know, he's a Very Busy Man.
Indeed.
But my 2002 Perl Foundation grant list those two modules (only!) as
deliverables. I'd say they'll be delivered -- probably by Christmas ;-)
Damian
begin quote from Angel Faus:
> I recall reading somewhere that Perl6 was going to be parsed by something
> very much like Parse::RecDescent, just that faster.
Damian was meant to be writing Parse::FastDescent and then Parse::Perl,
but as we all know, he's a Very Busy Man. If anyone *wants* to try
Simon wrote:
:> Have you an idea about what will be the 'final'
:> parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?)
:
:Yep, LALR1, probably yacc generated.
I recall reading somewhere that Perl6 was going to be parsed by something
very much like Parse::RecDescent, just that faster.
¿has
Thus it was written in the epistle of Dave Hartnoll,
> > Oh, one other tweak. The RFC proposes to overload next
> > to mean "fall through to the next case". I don't think
> > this is wise, since we'll often want to use loop controls
> > within a switch statement. Instead, I think we should
> > use
