An amount of a commodity: a CommodityType, a UnitOfMeasure, and a plain amount. Marshalled as a flat triple rather than a wrapper type (per the Money-as-tuple convention) -- and, unlike CommodityUnitCost below, its three inspectors are just tuple projections, so they need no binding at all. c2hs's & tuple-splitter only ever consumes two C arguments (confirmed against its source, not just by trial), so every function below that takes or returns a Quantity marshals it as three flat CommodityType/UnitOfMeasure/Double arguments instead of one combined tuple.

A commodity's unit cost: a cash amount (a (Double, Currency) pair, standing in for QuantLib's Money) per UnitOfMeasure. A plain tuple, like Quantity -- it carries no calculation of its own upstream.

A date range, inclusive of both ends. No C++ call is needed for either operation below -- Day (from Data.Time.Calendar) already has the Ord instance QuantLib's own comparisons rely on, so both are plain Haskell functions rather than shim calls.

A DateInterval over which a fixed Quantity is priced, paid on pricingPeriodPaymentDate. Named fields keep the value readable across energy-swap APIs.

Construct a custom commodity type identified by its code (e.g. "HO") and descriptive name (e.g. "Heating Oil"). QuantLib has no fixed enum of commodity types -- every instance is user-registered by code, the same way a custom customCurrency is.

The fixed placeholder commodity type QuantLib itself uses where no real commodity type applies (e.g. in unit-of-measure-only conversions).

Construct a custom unit of measure from its descriptive name (e.g. "Barrels"), code (e.g. "BBL"), and type (massvolumeenergy/quantity).

The lot, a dimensionless 'UnitOfMeasure::Quantity' unit.

Barrels (BBL), the base petroleum volume unit.

Metric tonnes (MT).

Thousand barrels (MB).

US gallons.

Litres.

Kilolitres.

Tokyo kilolitres.

Construct a payment term: a named offset (in calendar-adjusted days) from either the trade date or the pricing-period end date.

Construct a PricingPeriod, enforcing upstream's DateInterval invariant that the end date is not before the start date.

Construct a conversion factor between two units of measure for a given commodity type: a unit of source is worth conversionFactor units of target.

Register a conversion with the global unit-of-measure conversion repository, replacing any existing conversion between the same commodity type and pair of units.

Reset the unit-of-measure conversion repository back to its built-in set of known petroleum conversion factors, discarding anything added via addUomConversion.

Set the global commodity currency setting.

Set the global commodity unit-of-measure setting.

Round a quantity's amount per its unit of measure's rounding convention. The commodity type and unit of measure are unaffected by rounding, so they're carried straight through in Haskell rather than round-tripped through the C++ call.

Whether two quantities are close to within n ULPs (default 42 upstream), after converting the second to the first's unit of measure if their units differ (which throws unless a conversion is reachable -- see lookupUomConversion).

As closeQuantity, but using QuantLib's relative (rather than absolute) closeness test.

Whether a date falls within the interval, optionally excluding either end.

The overlap of two date intervals, or Nothing if they don't overlap at all (upstream returns a default-constructed, both-dates-null DateInterval in this case; a Maybe is the natural Haskell equivalent).

Apply the conversion factor to a quantity, converting it from the conversion's source to its target unit of measure (or vice versa). Throws if the quantity's unit of measure is on neither side of the conversion.

Combine two conversions sharing a common unit of measure into a derived conversion between their other two units. Throws if the conversions don't share a common unit.

The commodity code, e.g. "HO".

The descriptive name, e.g. "Heating Oil".

Whether this is a usable instance (as opposed to one built via a default constructor).

The descriptive name, e.g. "Barrels".

The code, e.g. "BBL", "MT".

The unit's type (massvolumeenergy/quantity).

Whether this is a usable instance (as opposed to one built via a default constructor).

The payment term's name, e.g. "Pricing end + 5 days".

Whether the offset is measured from the trade date or the pricing date.

The number of (calendar-adjusted) offset days.

The calendar used to adjust the payment date.

Whether this is a usable instance (as opposed to one built via a default constructor).

Applies the term's offset (and calendar adjustment) to a trade or pricing-period-end date to get the actual payment date.

The source unit of measure.

The target unit of measure.

The commodity type this conversion applies to.

Whether the conversion was given directly, or derived by chaining two other conversions.

The conversion factor: a unit of the source is worth this many units of the target.

A code identifying the conversion, e.g. "Heating OilMTBBL".

Look up a (possibly derived, via triangulation) conversion between two units of measure for a given commodity type. Throws if none can be found. Pre-populated with a set of known petroleum conversion factors even before any addUomConversion call.

The global commodity currency setting (defaults to USD).

The global commodity unit-of-measure setting (defaults to barrels).