Thanks for your feedback John. I think it's an interesting, attainable project so hopefully someone picks it up. On Sun, Feb 22, 2015 at 7:06 AM, John MacFarlane wrote: > +++ Ivan Lazar Miljenovic [Feb 22 15 14:12 ]: > > On 22 February 2015 at 10:27, John MacFarlane wrote: >> >>> +++ John MacFarlane [Feb 21 15 15:15 ]: >>> >>>> >>>> +++ Matthew Pickering [Feb 20 15 21:45 ]: >>>> >>>>> >>>>> Dear list, >>>>> >>>>> I have created a ticket on the Haskell.org GSoC idea list for one of >>>>> the >>>>> ideas which John suggested[1] would be suitable. It is important that >>>>> that >>>>> projects are fairly freestanding (not requiring intimate knowledge of >>>>> the >>>>> architecture) and are selected based on utility to the Haskell >>>>> community >>>>> as >>>>> a whole. >>>>> >>>>> If anyone has any comments, feel free to edit the proposal or reply >>>>> here >>>>> and I will make the changes. >>>>> >>>>> https://ghc.haskell.org/trac/summer-of-code/ticket/1660#ticket >>>>> >>>> >>>> >>>> It's a good proposal. Some further motivation: pandoc's current >>>> Markdown parser is not very efficient. It even goes exponential on some >>>> inputs, which is not good for web use. >>>> >>>> I've already developed algorithms for parsing CommonMark efficiently, >>>> without backtracking. They are so much more efficient than what pandoc >>>> currently does that even the JavaScript implementation of commonmark is >>>> 3-4 times faster than pandoc, and the C implementation is 30-40 times >>>> faster. >>>> >>>> So I'd hope for a 10X speedup with a rewrite. >>>> >>> >>> >>> Further thoughts on this. >>> >>> The best GSOC projects benefit the whole community (infrastructure). >>> >>> So, it might make more sense to write a standalone CommonMark parser >>> library with a liberal (BSD) license, that could be used in other >>> Haskell projects (e.g., potentially, in some future version of Haddock). >>> >>> If this is made extensible, pandoc could simply use this library. >>> But the library would also be available for other purposes. >>> >>> Pandoc itself won't ever be relicensed. But I think it would be a good >>> idea, if contributors will agree, to dual license pandoc-types BSD3/GPL. >>> (There are only a few commits by people other than me, so this is >>> feasible.) >>> >> >> If pandoc-types is licensed BSD3, is there any real need for it to >> also be licensed GPL (especially since Cabal doesn't really understand >> dual-licensing)? >> > > Probably not. > > -- > You received this message because you are subscribed to the Google Groups > "pandoc-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To view this discussion on the web visit https://groups.google.com/d/ > msgid/pandoc-discuss/20150222070657.GB42783%40localhost.hsd1.ca.comcast. > net. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CALuQ0m9j-jWK6LLuQZirKMvwBQZ%2BPDSOS15WUypUH_TRzXe8%2BA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.