POD Parser
Joseph Lewis
Here is my project proposal for GSoC 2011 (POD Parser):
https://docs.google.com/document/pub?id=1JRw-lgO6Qw1GEnVM9YamB31FFMS4nfTJQXGi10YIBaE
If you have the time, would you leave comments?
Thanks,
Joe
--
Public Key: [0xF8462E1593141C16]
Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
- NASA
Carl Mäsak
> Here is my project proposal for GSoC 2011 (POD Parser):
> https://docs.google.com/document/pub?id=1JRw-lgO6Qw1GEnVM9YamB31FFMS4nfTJQXGi10YIBaE
>
> If you have the time, would you leave comments?
Looks good overall.
(Oh, and my "TPF grant proposal" mentioned in your project proposal is
more of a grant proposal draft than anything else, which means there's
no real conflict of interest here. I'd mainly like to see this project
carried out, so that Rakudo can have a good Pod parser.)
In the interest of full disclosure, there's a second student (tadzik)
zeroing in on the same project. I didn't know that before yesterday
evening. We had some discussion last night [1], during which I
realized that the important thing for a Pod parser project isn't
necessarily many backends (though that's certainly nice to have), but
the 'bidirectional communication' between ambient Perl 6 and Pod.
(Compare Perl 6 regexes, where variables from the Perl 6 code can be
interpolated in a regex, and captured values are represented as Perl 6
data structures after the match. Pod has analogous interactions;
constants can be interpolated at compile time, and documentation can
be introspected from the ambient code at runtime through the .WHY
macro.)
I think this bidirectionality is an important aspect of making the
code be not just a fourth attempt at a Pod parser, but an integrated
component in Rakudo. I'll be happy to discuss this further, either via
email or on IRC.
[1] http://irclog.perlgeek.de/perl6/2011-03-28#i_3434101 (19:39 .. 20:31)
Regards,
// Carl
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Vasily Chekalkin
Sorry, there is strong -1 from me for this project.
Implementing something which is run on one of the languages running on
top of Parrot VM doesn't give us anything useful.
Implementing new language - yes. Improving existing language - may be
yes. Improve VM - yes. Bring new capability (like "POST
optimizations", "PBC emit from POST", "Improve GC", etc) - definitely
yes.
--
Bacek.
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Moritz Lenz
> Implementing something which is run on one of the languages running on
> top of Parrot VM doesn't give us anything useful.
I guess this should really be a project for The Perl Foundation (TPF),
not Parrot.
There might be some confusion, because both Parrot and TPF had POD
project ideas. Parrots idea was to implement a POD5 parser in nqp (or
related technogy) to depend less on perls infrastructure.
The TPF idea was basically what Joseph proposed.
Cheers,
Moritz
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Carl Mäsak
>> Implementing something which is run on one of the languages running on
>> top of Parrot VM doesn't give us anything useful.
>
> I guess this should really be a project for The Perl Foundation (TPF), not
> Parrot.
> There might be some confusion, because both Parrot and TPF had POD project
> ideas. Parrots idea was to implement a POD5 parser in nqp (or related
> technogy) to depend less on perls infrastructure.
> The TPF idea was basically what Joseph proposed.
Oh, sorry; I wasn't aware that there were two similar Pod project
ideas. And it's not my intent to take up parrot-dev bandwidth
discussing projects that are better discussed in a more Perl
6-specific forum.
With that, I'm only left wondering whether Vasily's sentiment above
would be less applicable if HLL interop was more of a reality in
Parrot.