On Wed, 2002-09-11 at 19:11, [EMAIL PROTECTED] wrote:
> Hello everybody,
>
> that's a few month i'm following this mailing list. i dont like all the changes
> that are being made to perl
Imagine how I felt when Perl 4 came out, with all that silly binary I/O
stuff! I had no idea what Larry had
From: Ken Fox [EMAIL PROTECTED]
> BTW, does anybody else find "is rx" funny?
Only because they're not called regular expressions anymore. How about
"px" for "pattern expression"?
-Miko
mail2web - Check your email from the web
Ken Fox:
# derivations. In the case of the simultaneous parse, they can
# actually return multiple parse trees and let the code
# generator decide how to interpret things.
Of course, in Perl 6, they'd return a superposition of all possible
parses, and trying to use the superposition would cause
> BTW, there are some parser generators that handle
> ambiguous grammars -- they either support backtracking,
> infinite lookahead, or simultaneously parse all possible
> derivations. In the case of the simultaneous parse, they
> can actually return multiple parse trees and let the
> code generato
Luke Palmer wrote:
> On Thu, 12 Sep 2002, Ken Fox wrote:
> > Perl already needs infinite lookahead.
>
> Really? Where?
Indirect objects need infinite lookahead and they are
in the core language. Hyper operators may need lookahead.
Place holders may need lookahead. User defined rules
will definit
On Thu, 12 Sep 2002, Ken Fox wrote:
> Luke Palmer wrote:
> > This requires infinite lookahead to parse. Nobody likes infinite
> > lookahead grammars.
>
> Perl already needs infinite lookahead. Anyways, most people
> don't care whether a grammar is ambiguous or not -- if we did,
> natural human
Luke Palmer wrote:
> This requires infinite lookahead to parse. Nobody likes infinite
> lookahead grammars.
Perl already needs infinite lookahead. Anyways, most people
don't care whether a grammar is ambiguous or not -- if we did,
natural human languages would look very different.
People want
Hello everybody,
that's a few month i'm following this mailing list. i dont like all the changes
that are being made to perl, i'm using perl since '97, anyway if i think about
it they're mostly all (until i understand everything) benefit to the language.
To make the background i was an assembl
Luke Palmer wrote:
[Piers wrote:]
> > Look, closing braces, ending statements, not on a line by
> > themselves. There's code like this all through the apocalypse and
> > its associated Exegesis, so it looks to me like C<< rx/\} \s* \n/ >>
> > is the regex for 'end of statement'. Either that or w
> Luke Palmer wrote:
> > [quote from A4]
> > To me, this looks like it has answers to all these questions.
>
> Up to a point. Look at the discussion of given/when in the same
> Apocalypse. Here's some example code from A4:
>
>
> given $! {
> when Error::Overflow { ... }
> wh
Luke Palmer <[EMAIL PROTECTED]> writes:
> This is for everyone: <
>In Perl, this problem comes up most often when people say "Why do I
>have to put a semicolon after do {} or eval {} when it looks like a
>complete statement?"
>
>Well, in Perl 6, you don't, if the final c
Luke Palmer wrote:
> This is for everyone: <
>... put a semicolon after do {} or eval {} when it looks like a
>complete statement?"
>
>Well, in Perl 6, you don't, if the final curly is on a line by
>itself.
>
> To me, this looks like it has answers to all these questions.
This is for everyone: < Piers Cawley wrote:
>
> > So, the new rule for blocks and when the need semicolons seems to be
> > "You don't need a semicolon if the block is the last argument of a
> > subroutine which expects a block as its last argument", which is all
> > very well and all, but ... Ah.
Piers Cawley wrote:
> So, the new rule for blocks and when the need semicolons seems to be
> "You don't need a semicolon if the block is the last argument of a
> subroutine which expects a block as its last argument", which is all
> very well and all, but ... Ah... hang on, that's *expression* no
So, the new rule for blocks and when the need semicolons seems to be
"You don't need a semicolon if the block is the last argument of a
subroutine which expects a block as its last argument", which is all
very well and all, but where does that leave:
sub foo ( &block ) {...}
...
$wibb
15 matches
Mail list logo
