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
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
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:
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 definitely
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 generator
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
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 at
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
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* not
This is for everyone: EOA4
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 curly is on a line by itself.
That is, if you
Luke Palmer wrote:
This is for everyone: EOA4
... 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.
It
Luke Palmer [EMAIL PROTECTED] writes:
This is for everyone: EOA4
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 curly
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 { ... }
when
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 we're back
14 matches
Mail list logo
