POD Parser

1 view
Skip to first unread message

Joseph Lewis

unread,
Mar 28, 2011, 11:00:40 PM3/28/11
to parro...@lists.parrot.org
Hi everyone,

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

unread,
Mar 29, 2011, 3:36:06 AM3/29/11
to Joseph Lewis, parro...@lists.parrot.org
Joseph (>):

> 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

unread,
Mar 29, 2011, 6:03:53 AM3/29/11
to Joseph Lewis, parro...@lists.parrot.org
Hello.

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

unread,
Mar 29, 2011, 6:09:46 AM3/29/11
to parro...@lists.parrot.org
Am 29.03.2011 12:03, schrieb Vasily Chekalkin:
> 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

unread,
Mar 29, 2011, 7:41:28 AM3/29/11
to parrot-dev
Vasily (>>), Moritz (>):

>> 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.

Reply all
Reply to author
Forward
0 new messages