9 Jun
2006
9 Jun
'06
7:11 a.m.
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