Luke == Luke Palmer [EMAIL PROTECTED] writes:
Luke But you don't really need to parse to syntax highlight, either. You
Luke just need to tokenize.
Unfortunately, to tokenize, you also have to know the state of the parse.
As long as / is both divide and begin regex, you're toasted.
Please see
Randal L. Schwartz wrote:
Luke == Luke Palmer [EMAIL PROTECTED] writes:
Luke But you don't really need to parse to syntax highlight, either. You
Luke just need to tokenize.
Unfortunately, to tokenize, you also have to know the state of the parse.
As long as / is both divide and begin regex,
Matthew == Matthew Walton [EMAIL PROTECTED] writes:
Matthew So you're saying that in Perl 6 it will be entirely impossible to
Matthew determine if / appears as the division operator or as the beginning of
Matthew a regex from a purely syntactic examination of the source code?
Yes.
Matthew I'm
Randal L. Schwartz wrote:
Matthew == Matthew Walton [EMAIL PROTECTED] writes:
Matthew So you're saying that in Perl 6 it will be entirely impossible to
Matthew determine if / appears as the division operator or as the beginning of
Matthew a regex from a purely syntactic examination of the source
Matthew == Matthew Walton [EMAIL PROTECTED] writes:
Matthew Perl 6 has formal parameters for subs, methods etc. I don't see any
Matthew mention of Perl 5-style prototypes in S6, and I honestly can't see how
Matthew they could possibly fit with formal parameters. Hopefully Larry or
Matthew
Randal L. Schwartz wrote:
Matthew == Matthew Walton [EMAIL PROTECTED] writes:
Matthew Perl 6 has formal parameters for subs, methods etc. I don't see any
Matthew mention of Perl 5-style prototypes in S6, and I honestly can't see how
Matthew they could possibly fit with formal parameters.
Randal L. Schwartz wrote:
All the handwaving in the world won't fix this. As long as we have
dual-natured characters like /, and user-defined prototypes, Perl
cannot be lexed without also parsing, and therefore without also
running BEGIN blocks.
And user-defined prototypes that change when the
James Mastros skribis 2004-11-26 14:36 (+0100):
And user-defined prototypes that change when the argument list of a
function ends, that is. If we forced the argument list for all
functions to have parens (including empty parens for argument less
functions), then we'd be OK, I'm fairly
On Thu, 25 Nov 2004, Adam Kennedy wrote:
I thought it was about time I brought some concerns I've been having lately
to the list. Not so much on any particular problem with perl6, but on
problems with perl5 we would seem to have the opportunity to fix but aren't.
(So far as I can tell).
So why
Let's say you want to write a yacc grammar to parse Perl 6, or
Parse::RecDescent, or whatever you're going to use. Yes, that will be
hard in Perl 6. Certainly harder than it was in Perl 5.
In the end, I concluded there was _no_ way to write even a Perl 5 parser
using any sort of pre-rolled
Michele Dondi wrote:
On Thu, 25 Nov 2004, Adam Kennedy wrote:
I thought it was about time I brought some concerns I've been having
lately to the list. Not so much on any particular problem with perl6,
but on problems with perl5 we would seem to have the opportunity to
fix but aren't. (So far as
Smylers wrote:
Adam Kennedy writes:
perl itself would also appear unable to understand perl source,
instead doing what I would call RIBRIB parsing, Read a bit, run a
bit.
RIBRIB? RABRAB, surely!
Smylers
Yes, you are right, typo.
On Thu, 25 Nov 2004 22:00:03 +1100, Adam Kennedy [EMAIL PROTECTED] wrote:
And just after the snip you will see I qualify parse in this context
as loading the perl in some form of DOM-type tree.
And yet you disqualify the Perl6 rule system, with its tree of match
objects? What, exactly, is it
On Thu, Nov 25, 2004 at 02:31:46PM +1100, Adam Kennedy wrote:
: Let's say you want to write a yacc grammar to parse Perl 6, or
: Parse::RecDescent, or whatever you're going to use. Yes, that will be
: hard in Perl 6. Certainly harder than it was in Perl 5.
:
: In the end, I concluded there was
Herbert Snorrason wrote:
On Thu, 25 Nov 2004 22:00:03 +1100, Adam Kennedy [EMAIL PROTECTED] wrote:
And just after the snip you will see I qualify parse in this context
as loading the perl in some form of DOM-type tree.
And yet you disqualify the Perl6 rule system, with its tree of match
objects?
Adam Kennedy wrote:
What I'm after are 3 critical features.
1. You always get back out what you put in.
$source eq serialize(parse($source)).
As Larry pointed out, this will depend on how much metadata your parser
augments your parse-tree with. I think it will be doable (probably by
subclassing
Adam Kennedy writes:
Herbert Snorrason wrote:
On Thu, 25 Nov 2004 22:00:03 +1100, Adam Kennedy [EMAIL PROTECTED] wrote:
And just after the snip you will see I qualify parse in this context
as loading the perl in some form of DOM-type tree.
And yet you disqualify the Perl6 rule system,
Hi folks
I thought it was about time I brought some concerns I've been having
lately to the list. Not so much on any particular problem with perl6,
but on problems with perl5 we would seem to have the opportunity to fix
but aren't. (So far as I can tell).
One of the biggest problems I have had
Adam Kennedy writes:
Getting (finally) to perl6, I could have sworn I saw an RFC early on
which said Make perl6 easier to parse.
But it would appear the opposite is occurring. Source filters have
become grammars and will now be officially approved and acceptable
(yes?) while so far as I
Luke has answered this better than I would have. In particular, he wrote:
Perl's contextual sensitivity is part of the language. So the best you
can do is to track everything like you mentioned. It's going to be
impossible to parse Perl without having perl around to do it for you.
That first
Adam Kennedy writes:
perl itself would also appear unable to understand perl source,
instead doing what I would call RIBRIB parsing, Read a bit, run a
bit.
RIBRIB? RABRAB, surely!
Smylers
21 matches
Mail list logo
