Do we have benchmarks for your proposed change? <div>Does it handle hex and binary formats too ?<br><br>On Sunday, October 2, 2016, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Yeah, that. With a paren count and an accumulator and for fractional numbers some care around the decimal point or slash, we can look at each digit just once. Fast/lazy failure would be a pleasant side effect of running a numbers-only process from top to bottom. Yes, Read is supposed to read things that look like Haskell expressions, but it's really not a Haskell parser and pretending it is only hurts.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 2, 2016 12:07 AM, "Ivan Lazar Miljenovic" <<a href="javascript:_e(%7B%7D,'cvml','ivan.miljenovic@gmail.com');" target="_blank">ivan.miljenovic@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2 October 2016 at 14:34, David Feuer <<a href="javascript:_e(%7B%7D,'cvml','david.feuer@gmail.com');" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
> Instead of scanning first (in lexing) to find the end of the number and then<br>
> scanning the string again to calculate the number, start to calculate once<br>
> the first digit appears.<br>
<br>
As in multiply the current sum by 10 before adding each new digit?<br>
<br>
><br>
><br>
> On Oct 1, 2016 10:07 PM, "wren romano" <<a href="javascript:_e(%7B%7D,'cvml','winterkoninkje@gmail.com');" target="_blank">winterkoninkje@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Sep 12, 2016 at 11:03 AM, David Feuer <<a href="javascript:_e(%7B%7D,'cvml','david.feuer@gmail.com');" target="_blank">david.feuer@gmail.com</a>><br>
>> wrote:<br>
>> > By the way, I believe we should be able to read numbers more efficiently<br>
>> > by<br>
>> > parsing them directly instead of lexing first. We have to deal with<br>
>> > parentheses, white space, and signs uniformly for all number types. Then<br>
>> > specialized foldl'-style code *should* be able to parse integral and<br>
>> > fractional numbers faster than any lex-first scheme.<br>
>><br>
>> I follow the part about parentheses and negations, but I'm not sure I<br>
>> get the rest of what you mean. E.g., I'm not sure how any parser could<br>
>> be faster than what bytestring-lexing does for Fractional and Integral<br>
>> types (ignoring the unoptimized hex and octal functions). What am I<br>
>> missing?<br>
>><br>
>> --<br>
>> Live well,<br>
>> ~wren<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Libraries mailing list<br>
> <a href="javascript:_e(%7B%7D,'cvml','Libraries@haskell.org');" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
><br>
<br>
<br>
<br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="javascript:_e(%7B%7D,'cvml','Ivan.Miljenovic@gmail.com');" target="_blank">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" rel="noreferrer" target="_blank">http://IvanMiljenovic.wordpres<wbr>s.com</a><br>
</blockquote></div></div>
</blockquote></div>