Blank lines parse as paragraphs?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Blank lines parse as paragraphs?

Damien Pollet
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
Reply | Threaded
Open this post in threaded view
|

Re: Blank lines parse as paragraphs?

Lukas Renggli-2
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