Closed marco-comini closed 5 months ago
Isn't that the point of reads
, that it returns all possible parses?
Well, not in this sense. One should have more than one solution in case of ambiguous grammars when there are many possible "proper" parse trees. For instance for expression '3+4*2' (when there are no assumptions/specifications on priorities) we can have two parse trees.
In case of literals usually there is just one result. Like (reads :: ReadS Float) "3.567" that evaluates to [(3.567,"")] and not [(3.0,"567"),(3.5,"67"),(3.56,"7"),(3.567,"")] since the extra results are considered incomplete parses, non parsing alternatives.
Why in this case the fractional part of the seconds should be interpreted differently from just one number of pico-seconds? And also, why in older versions of the package this was interpreted univocally?
Thanks
Fixed.
I just tried to use GHC 9.2.4 (now recommended) with one of my projects. I've found a discrepancy of time-1.12.2 and time-1.11.1.1 with respect to time-1.9.3 about parsing of times (that is causing me some issues).
A minimal example is
fmap ((reads :: ReadS Data.Time.LocalTime) . show) Data.Time.getCurrentTime
that in time-1.9.3 gives just one result (as I would expect), while in time-1.12.2 and time-1.11.1.1 gives 7 instead (where the last result is what I would expect, while the others are those that do not"consume" all the digits after the point).
Is this intentional or a bug?
Thanks, Marco