Re: Perl 6 and Perl 5 parsing

Perl 6 syntax is more complex, in the sense the grammar is mutable.

That's not what "syntax" means.

I mean to say willn't it suffer from the same problem. If the grammar is muted runtime, shouldn't it be sent back to the parser. Which in case it won't be parsed statically(I can't take the bytecode alone and run it, I will always need the parser along with it).

Not sure it makes sense for the grammar to be mutated at runtime, since the source code will already have been parsed and generated by then.

You are correct in the sense that Perl 6 leans heavily on a way to switch between compile-time and run-time, so the two components need to be connected somehow. This is nothing new, though: BEGIN and &eval have allowed this for a long time in Perl.

Comment on Re: Perl 6 and Perl 5 parsing Select or Download Code

Replies are listed 'Best First'.
Re^2: Perl 6 and Perl 5 parsing by Anonymous Monk on Jan 14, 2011 at 10:03 UTC
Then whats the point in separating compile time and run time in Perl6? In a way so as long there is a BEGIN block isn't that impossible.	[reply]
Re^3: Perl 6 and Perl 5 parsing by masak (Scribe) on Jan 14, 2011 at 10:45 UTC
Then whats the point in separating compile time and run time in Perl6? In a way so as long there is a BEGIN block isn't that impossible. In the general case it's impossible to "separate" compile time and run time, yes. In Perl 5 as well as 6. But please remember that `BEGIN` and `&eval` aren't there because one day we looked the other way and they just snuck in. They're there because sometimes we need them as escape hatches when what we want to do can't be done by less crude means.	[reply] [d/l] [select]
Re^3: Perl 6 and Perl 5 parsing by ikegami (Patriarch) on Jan 14, 2011 at 18:58 UTC
Then whats the point in separating compile time and run time Speed. There's no reason to compile code every time it's executed. That would be very slow, and there's no advantages to doing it that way. In a way so as long there is a BEGIN block isn't that impossible. Not at all. It just prevents the compile-time of all code blocks from happening at the same time.	[reply]
Re^4: Perl 6 and Perl 5 parsing by moritz (Cardinal) on Jan 14, 2011 at 19:20 UTC
Speed And consistency. Consider code like `for (1..10) { # some statements # grammar modification here }` [download] If compile time and run time modification were not separated, the head of the loop would be once parsed without the grammar modifications, and then reparsed with grammar modifications - a nightmare for readability and debugging. Perl 6 - second systems done right	[reply] [d/l]
Re^5: Perl 6 and Perl 5 parsing by ikegami (Patriarch) on Jan 14, 2011 at 19:24 UTC
Re^6: Perl 6 and Perl 5 parsing by moritz (Cardinal) on Jan 14, 2011 at 20:21 UTC
Some notes below your chosen depth have not been shown here
Re^2: Perl 6 and Perl 5 parsing by educated_foo (Vicar) on Jan 14, 2011 at 13:26 UTC
That's not what "syntax" means. Really?	[reply]
Re^3: Perl 6 and Perl 5 parsing by masak (Scribe) on Jan 14, 2011 at 16:54 UTC
Heh, I'm not arguing against the fact that grammars specify syntax. I'm saying that just because Perl 6 as a language allows for more explicit hooks into its grammar engine than Perl 5 does, it doesn't then follow that "Perl 6 syntax is more complex".	[reply]
Re^4: Perl 6 and Perl 5 parsing by educated_foo (Vicar) on Jan 15, 2011 at 02:28 UTC
Encouraging programmers to change the syntax in arbitrary ways MAY make the syntax more complex. I guess that's all I'm saying, heh.	[reply]


P is for Practical
	PerlMonks