Hi,
according to PRParagraphTest#testParseSpare, a blank line in the input should produce an empty paragraph... I'd prefer something like in LaTeX where linefeeds are like spaces but blank lines separate paragraphs... In fact I'm trying to adapt a CSS to Pier, but the environment is parsed as a paragraph: PRDocumentParser parse: '<div>foo</div>' "returns a PRParagraph" So the html output is incorrect---well, it's legal HTML but it doesn't mean much semantically to have everything in a <p>... Also, is it really simpler to use SmaCC than to write a recursive descent parser (sort of reversed Interpreter pattern)? Granted, only writing the grammar is cool, but how do you debug an LALR transition table? (I feel trollish asking that, but I just want your opinion/experience(s)) -- Damien Pollet type less, do more _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Hi Damien,
> according to PRParagraphTest#testParseSpare, a blank line in the input > should produce an empty paragraph... I'd prefer something like in > LaTeX where linefeeds are like spaces but blank lines separate > paragraphs... that is certainly possible, but you need to modify the parser. > In fact I'm trying to adapt a CSS to Pier, but the environment is > parsed as a paragraph: > PRDocumentParser parse: '<div>foo</div>' "returns a PRParagraph" > So the html output is incorrect---well, it's legal HTML but it doesn't > mean much semantically to have everything in a <p>... you are probably not using the latest version. Earlier versions of Pier generated that kind of code and it is invalid to have a div (block-element) inside of a <p>. The current version of Pier generates <div class="paragraph">. This is valid and can be easily configured using CSS selectors, so that i behaves different to paragraphs in a Wiki page. > Also, is it really simpler to use SmaCC than to write a recursive > descent parser (sort of reversed Interpreter pattern)? Granted, only > writing the grammar is cool, but how do you debug an LALR transition > table? (I feel trollish asking that, but I just want your > opinion/experience(s)) I do only black-box testing of the parser: I give input strings and check what is coming back. The tests of the Pier parser actually cover all the rules of the code (at least they did the last time I checked). I guess nobody wants to directly mess with the transition tables, that is too low-level. Mhh, it would be cool to have a tool generating the finit set of valid programs of the maximal size n that can be parsed by a given SmaCC parser, this means to use the parser the inverse way. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Free forum by Nabble | Edit this page |