2008/12/28 Phil Pirozhkov <span dir="ltr"><<a href="mailto:pirj@mail.ru">pirj@mail.ru</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thank you for helping me out again, Robert!<br>
<br>
The point was that adding elements to matched list doesn't work.<br>
<br>
This one works fine:<br>
blocks -> blocks block : '$1' ++ ['$2'].<br>
<br>
And this one (i used before):<br>
blocks -> block blocks : ['$1' | '$2'].<br>
(yes, blocks and block reverted here compared to the first example,<br>
because of $2 (blocks) should be a list, and $1 (block) - a value).<br>
<br>
This is odd, because [H|T] seems to be more erlang'ish (and more optimal i suggest?)<br>
than ++.</blockquote><div><br>These two are basically equivalent. If I remember correctly then the first one is more efficient from a yecc/LALR(1) point of view , while the second is more erlangy. I would personally use the second style.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Just rolled back TokenLine changes, they doesn't affect parser at all, i.e.<br>

it works perfectly fine with leex provided tuples of the following format:<br>
<br>
[{'{'},{forc},{identifier,a},{in},{identifier,b},{'}'},{'{'},<br>
     {identifier,a},{'}'},{text," kg"},{'{'},{endc},{'}'}].</blockquote><div><br>Yes, this will work as long as you don't get any parse errors. Yecc assumes all tokens are tuples where the first element is the type and the second element is the line number. It will access the the second element to get the line number when it detects an error. Yecc ignores other elements in the token tuple so you are free to put data in extra elements which can then be accessed in the productions. That is the reason for giving the format of tokens as<br>
<br>{Type,TokenLine} or {Type,TokenLine,TokenValue}<br><br>You can of course have more values if necessary. It is not wise not to follow the "standard" token formats.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just to notice, '$end' is not required too, works fine without it.<br>
Maybe line numbers and '$end' should be marked as optional in yecc docs.<br>
I agree that line numbers are very helpful when it comes to seek for issues<br>
in the data provided to parser, but this only eats up memory when is not required.</blockquote><div><br>Yecc is kind and adds a '$end' token, so it is optional. As I explained above the line numbers are not optional and yecc assumes that they are there.<br>
<br>The amount of extra memory needed for the line numbers is small and I wouldn't worry about. Also they are so easy to generate from leex or a hand-written scanner that there is really no reason not to put them in. Even in LFE where I can't use yecc I still have the line numbers to give better error reporting.<br>
<br>Robert<br><br></div></div>