> Frank Poettgen <Frank.Poett...@Post.RxWyTxH-AyAzCyHzEyN.de> writes:
>> I would expect
>> reads "1.2" :: [(Int,String)]
>> to be evaluated to
>> [(1,".2")]
>> but using Hugs (Version Sep 2006) it is just
>> []
>> Bug or feature? > Good question. GHCi, version 6.8.2, agrees with Hugs.
The reason at least in GHC is that all numeric instances use the same function to parse the string. The string is then converted, unless conversion fails. Because of that, one also gets e.g.
> reads "1e2" :: [(Int,String)]
[(100,"")]
AFAIK the report doesn't specify exactly how to parse a number, so I strongly suspect "feature". But I never noticed that before, too.
> Mark T.B. Carroll <Mark.Carr...@aetion.com> wrote: >> Frank Poettgen <Frank.Poett...@Post.RxWyTxH-AyAzCyHzEyN.de> writes:
>>> I would expect
>>> reads "1.2" :: [(Int,String)]
>>> to be evaluated to
>>> [(1,".2")]
>>> but using Hugs (Version Sep 2006) it is just
>>> []
>>> Bug or feature?
>> Good question. GHCi, version 6.8.2, agrees with Hugs.
> The reason at least in GHC is that all numeric instances use the same > function to parse the string. The string is then converted, unless > conversion fails.
Thanks for your explanation.
> Because of that, one also gets e.g. >> reads "1e2" :: [(Int,String)] > [(100,"")]
Really? -Hugs says [].
:type 1e2 100.0 :: Fractional a => a
> AFAIK the report doesn't specify exactly how to parse a number, so I > strongly suspect "feature". But I never noticed that before, too.
It can be a problem doing parsing with polymorphism. Consider '.' to be a binary infix symbol describing the branching of a tree of arbitrary type. Then one gets e.g.
parseTree "'a'.'b'.'c'.'d'" :: (Tree Char) /\ /\d /\c ab
Frank Poettgen <Frank.Poett...@post.rxwytxh-ayazcyhzeyn.de> wrote: > Dirk Thierbach schrieb: >> Because of that, one also gets e.g. >>> reads "1e2" :: [(Int,String)] >> [(100,"")]
> Really? -Hugs says [].
Interesting. Then GHC and Hugs differ :-)
> :type 1e2 > 100.0 :: Fractional a => a
But that's a numeric literal in the *language*, not how parsing is done in the *library*. So it doesn't say anything.
>> AFAIK the report doesn't specify exactly how to parse a number, so I >> strongly suspect "feature". But I never noticed that before, too. > It can be a problem doing parsing with polymorphism.
Very certainly not. BTW, Hugs should also have the source code for the Prelude packaged up somewhere, so you can have a look.