Friday, May 05, 2006

May 4th, 2006 -- A long silence, and function application

The last post was on midnight of Sunday, 4 days ago. There were three in class midterms in 37 hours from Tuesday morning to noon of Wednesday. They are "special topics on graph algorithms," PDE, and compiler. Yes, I'm taking a compiler course this semester, which is a required course for junior. The exam problem is quite cool: given a grammar of Java-like (or may it's really a snip of java spec) array-newing syntax, write a parser accepting it, 100 points. No other constrains on algorithm. And here comes the bonus: write another one, 50 points. It took me some time to convince myself that write a parser in Perl 6 Rule will not count.

Then I wrote the proposal of summer of code and submitted it in evening. There are some more detail thought about the new plan with not many new ideas. But the may-faced challenging part is one of them:
  1. The parsed grammar saved in Perl 5 hash-and-array tree-like data structure is extremely complex and nearly unreadable. Since the correctness has not been tested much, debugging modules using it is a difficult job.

  2. We don't know if the Perl 5 Rule parser is powerful and efficient enough to handle the full grammar. Currently translating a sample grammar file with five small rules takes one minute CPU time on a Xeon 2.8GHz machine (may be unprecise due to HTT).

  3. We don't know if Parsec is powerful enough to handle all functionality provided by Perl 6 Rules. Hopefully, we should be able to use only those which can be translated easily in the first version of the full grammar of Perl 6. And since Parsec code was copied into Pugs' source tree for the ease of modifying, it's not that serious.
clkao asked my plan on that if the second one really happened.
clkao> scw: what are you going to do if perl5 based rule parser is too slow?
scw> clkao: tune it :p
* clkao grins
I love the idea.

And some real-work reports. I fixed the variable and function naming rule so that it doesn't consume too many things in the afternoon. That makes function application as a operand of summation works. Then a little rewrite of rules of function application with parameters makes it work, too.

The performance problem seems affect my development more and more. I now do changing only on the generated Perl 5 module and only when everything works I'll merge the change to the grammar file and run the translation script again to see if the result is still correct. The reason is that I found the rule I used in the afternoon took one minutes and twelve seconds to translate and the one I committed several minutes before took nearly two minutes. It seems time to hack into Pugs::Compiler::Rule.

On the another hand, fglock++ revised the benchmark between P::C::R, inlined matching functions and Perl 5 regular expression. The performance seem to be ten times better one by one from the last one (P5regex) to the first one (P::C::R). Maybe I'll then write my own translation script in P5regex (a *lot* to do then) or inlined P::C::R structure instead of current one which uses P::C::R.


Post a Comment

Links to this post:

Create a Link

<< Home