haskell / haskell/bytestring

Overhaul Data.ByteString.Builder.RealFloat

Open
#636 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
Haskell
Stars
301
Forks
144
Avg merge
7d 22h
Merged PRs (30d)
1

Description

I have created the following PRs but they seem to be intermingled and perhaps a larger pull would be better
#632
#633
#634

I propose the following
1. combine the logic of `formatFloat` and `formatDouble` into `formatFloating :: FloatFormat -> a -> Builder` since they have the same logic and use classes to get their specific functions based on the floating type. Continuing exporting the `formatFloat` and `formatDouble` interface functions for compatibility.
1. Replace the constructor of `FloatFormat` to the constructors of `FormatMode` and remove the type `FormatMode` because the precision `(Maybe Int)` is not used and can be included as a parameter of the constructors
1. `FScientific` should have a `Char` for specifying a lower or upper E
1. `FStandard` should have a `Maybe Int` for the precision
1. `FGeneric` should have a Char for specifying a lower or upper E, and two Ints for the inclusive exponent range for printing the standard notation
1. Allow custom strings for special values +-Infinity +-0 NaN with `data SpecialStrings = {..}`
2. remove `specialStr` and use `toCharsNonNumbersAndZero` instead because they duplicate logic and it is faster to evaluate
4. I am unsure if this is optimized away but the case statement that selects the format should not be executed for every floating number to be printed. If not, the `\f -> ...` should be defined after the case statement and not before.

None of these changes should cause changes to the existing interface.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the Data.ByteString.Builder.RealFloat module and compare the existing formatFloat, formatDouble, FloatFormat, FormatMode, and special-value handling. Review PRs #632, #633, and #634 to understand the intermingled work. Done means the proposed formatting redesign is coherent while preserving the existing exported interface.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
performance
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.