<div dir="ltr">offtopic, but since we are talking about Parsec/Attoparsec, is there a way to have try by default in Parsec as well?<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 8, 2015 at 9:23 AM Chris Wong <<a href="mailto:lambda.fairy@gmail.com">lambda.fairy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brian,<br>
<br>
Parsec and Attoparsec have very similar interfaces (afaik the only<br>
difference is that Attoparsec backtracks by default, so the "try"<br>
combinator is a no-op) so there's no harm in trying both.<br>
<br>
Alternatively: if the data format is simple enough, you can write the<br>
parser by hand. The Data.Text.Read module may help if you pursue this<br>
option. [1]<br>
<br>
Chris<br>
<br>
[1]: <a href="https://hackage.haskell.org/package/text-1.2.1.1/docs/Data-Text-Read.html" target="_blank">https://hackage.haskell.org/package/text-1.2.1.1/docs/Data-Text-Read.html</a><br>
<br>
On Mon, Jun 8, 2015 at 11:04 AM,  <<a href="mailto:briand@aracnet.com" target="_blank">briand@aracnet.com</a>> wrote:<br>
> Hi,<br>
><br>
> My file is pretty straightforward text file with a small amount of somewhat annoying state:<br>
><br>
> comments*<br>
> config line<br>
> comments*<br>
> data line*<br>
><br>
> if there is no config line it's an error.  the data lines can have a variable number of values and it matters how many values there are (hey- it's not my file format !).  the data lines can also have a comment at the end.<br>
><br>
> My initial thought was to go with parsec but the data files could be as large as 40-50MB and upon further reading it really seemed like attoparsec would be better. Error handling wouldn't be too sophisticated.  if a data line has something other than 1 or more floating point values and the optional comment, failing out with "error line X" is fine.<br>
><br>
> parse time is somewhat critical only because i'll have multiple files to parse, so while 5-10 seconds is ok for one file, i have to multiply that by 5-10.<br>
><br>
> I've seen several comments talking about the fact that parsec can be slow, but so far unable to find anything the quantifies "slow".<br>
><br>
> Any opinions on which would be better for my application (although i think i've just talked myself into using attoparsec) ?<br>
><br>
> In particular- am i going to get at least reasonable "error on line X" error handling using attoparsec ?<br>
><br>
><br>
> Thanks,<br>
><br>
> Brian<br>
><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br>
<br>
<br>
--<br>
<a href="https://lambda.xyz" target="_blank">https://lambda.xyz</a><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>