dropSpace not exported in ByteString
Hi all, I'm writing a Haskell program to do some address cleansing. The program uses the ByteString library. Data.ByteString.Char8 documentations shows functions for removing whitespace from start or end of a ByteString. Those functions are said to be more efficient than the dropWhile / reverse mixes. It looks exactly like what I'm searching for, but apparently those functions are not exported by the Data.ByteString.Char8 module. Are those functions only called by rules? Transformation of dropWhile isSpace into dropSpace? I've seen such a rule for dropSpace but did not found an equivalent rule for dropSpaceEnd. Is there a way to call the dropSpace and dropSpaceEnd or do I have to code with dropWhile and hope that some rule will magically transform my dropWhileS into dropSpaceS? Thanks, Olivier.
olivier.boudry:
Hi all,
I'm writing a Haskell program to do some address cleansing. The program uses the ByteString library.
Data.ByteString.Char8 documentations shows functions for removing whitespace from start or end of a ByteString. Those functions are said to be more efficient than the dropWhile / reverse mixes.
It looks exactly like what I'm searching for, but apparently those functions are not exported by the Data.ByteString.Char8 module. Are those functions only called by rules? Transformation of dropWhile isSpace into dropSpace? I've seen such a rule for dropSpace but did not found an equivalent rule for dropSpaceEnd.
Is there a way to call the dropSpace and dropSpaceEnd or do I have to code with dropWhile and hope that some rule will magically transform my dropWhileS into dropSpaceS?
The latter: "FPS specialise dropWhile isSpace -> dropSpace" dropWhile isSpace = dropSpace check that the rule fires with -ddump-simpl-stats There's no rule for dropSpaceEnd, but you can certainly inline the defn in your code, if perf. matters. -- Don
Hi Don,
In fact I'm not really looking at performance, I don't expect performance to
be a big issue in my application.
I was just looking at using some simple functions found in the documentation
and avoid redefining them.
In fact dropSpace and dropSpaceEnd are doing exactly what I'm looking for.
But of course if they're not exported it's not a problem and I'll use their
dropWhile equivalent.
Thanks for your reply,
Olivier.
On Nov 15, 2007 5:24 PM, Don Stewart
The latter:
"FPS specialise dropWhile isSpace -> dropSpace" dropWhile isSpace = dropSpace
check that the rule fires with -ddump-simpl-stats
There's no rule for dropSpaceEnd, but you can certainly inline the defn in your code, if perf. matters.
-- Don
olivier.boudry:
Hi Don,
In fact I'm not really looking at performance, I don't expect performance to be a big issue in my application.
I was just looking at using some simple functions found in the documentation and avoid redefining them.
In fact dropSpace and dropSpaceEnd are doing exactly what I'm looking for. But of course if they're not exported it's not a problem and I'll use their dropWhile equivalent.
Thanks for your reply,
Let me know if the rule fires. If it isn't, that's a bug, essentially. -- Don
On 11/15/07, Don Stewart
Let me know if the rule fires. If it isn't, that's a bug, essentially.
-- Don
Don, As you can see the rule fires. C:\Temp>ghc --make -O2 -fasm -ddump-simpl-stats DropSpaceTest.hs ... 3 RuleFired 1 FPS pack/packAddress 2 FPS specialise dropWhile isSpace -> dropSpace ... By the way, what's the reason dropSpaceEnd is defined but not exported nor used through a rule? I'm just curious. Best regards, Olivier.
olivier.boudry:
On 11/15/07, Don Stewart <[1]dons@galois.com> wrote:
Let me know if the rule fires. If it isn't, that's a bug, essentially.
-- Don
Don,
As you can see the rule fires.
C:\Temp>ghc --make -O2 -fasm -ddump-simpl-stats DropSpaceTest.hs ... 3 RuleFired 1 FPS pack/packAddress 2 FPS specialise dropWhile isSpace -> dropSpace ...
Great! The first rule is also a good sign.
By the way, what's the reason dropSpaceEnd is defined but not exported nor used through a rule? I'm just curious.
Looking at the source, its not actually defined -- its commented out. Perhaps you're looking at an older version of the source? -- Don
On Thu, 2007-11-15 at 21:55 -0500, Olivier Boudry wrote:
By the way, what's the reason dropSpaceEnd is defined but not exported nor used through a rule? I'm just curious.
We decided when trying to standardise the API to start with just the equivalents of the Data.List functions. We have tracked changes to Data.List, adding intercalate and isInfixOf. If there is a compelling reason to add dropSpaceEnd to the Data.ByteString API then the same would probably apply to Data.List and so it should be proposed for there and then Data.ByteString will track it too. Alternatively, someone should make the case for why it should be added to bytestring but not list. There is probably room for more string oriented list functions in some library somewhere (especially crazy Unicode stuff), like Data.String. Duncan
Hello Duncan, Friday, November 16, 2007, 2:43:05 PM, you wrote:
Alternatively, someone should make the case for why it should be added to bytestring but not list.
the reason is very simple - FPS lib is upgradeable, so there is no problems if its various versions are not compatible with each other. adding anything to base library is a nightmare, meaning that programs that use this new functionality, will be compatible only with GHC HEAD in the next 0-12 months -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 11/16/07, Duncan Coutts
On Thu, 2007-11-15 at 21:55 -0500, Olivier Boudry wrote:
By the way, what's the reason dropSpaceEnd is defined but not exported nor used through a rule? I'm just curious.
We decided when trying to standardise the API to start with just the equivalents of the Data.List functions. We have tracked changes to Data.List, adding intercalate and isInfixOf.
If there is a compelling reason to add dropSpaceEnd to the Data.ByteString API then the same would probably apply to Data.List and so it should be proposed for there and then Data.ByteString will track it too.
Alternatively, someone should make the case for why it should be added to bytestring but not list. There is probably room for more string oriented list functions in some library somewhere (especially crazy Unicode stuff), like Data.String.
Duncan
I understand the need for standardization. Having consistent functions across modules is something I really appreciate in Haskell. Thanks for the information, Olivier.
participants (4)
-
Bulat Ziganshin -
Don Stewart -
Duncan Coutts -
Olivier Boudry