The fields package
Using records, especially nested records, in Haskell can sometimes be a bit of a chore. Fortunately, there are several libraries in hackage that make working with records easier. This library is my attempt to build on top of these libraries to make working with records even more pleasant!
In most imperative languages, records are accessed
using the infix dot operator. Record fields can be
read simply by suffixing a record value with
.field and they can be modified by simply
assigning to that location. Although this is not
the only way to access records (indeed, Haskell
does not use it), many people (including myself)
like it. This library attempts to support this
style for Haskell records in the following manner:
record.field.subfield becomes record .# field # subfield record.field = value becomes record .# field =: value
Of course, the infix assignment in Haskell is pure and doesn't actually mutate anything. Rather, a modified version of the record is returned.
In addition, the following features are supported:
Accessing several fields simultaneously using tuples. Example:
record .# (field1, field2, field3)
Accessing records inside a
recordInFunctor <.#> field
Composing fields with
record .# applicativeField <#> subfield
Pattern matching using
case record of (match field -> 1) -> ...
Easy comparisons etc. using
sortBy (compare `onField` field#subfield) records
For a detailed description of usage, see Data.Record.Field.
This library is a work-in-progress. Some limitations, deficiencies, points of interest and possible future improvements include:
instance is only provided for
"fclabels"lenses, since that is what I have personally used. However, there should be nothing in principle that would prevent adding instances for
"lenses". However, doing this would make this package depend on several record libraries at once, which might not be the best approach. Perhaps this package should be split into several packages?
method currently returns an
"fclabels"lens. To fully decouple this package from
method probably has to be split into
modFieldor something similar.
For monad transformers,
"monads-fd"are used, since those are what
"fclabels"uses. This might be a problem for a program that uses
To avoid lots of parentheses,
"fields"uses high-precedence operators at three operator precedence levels. The goal was to make field accesses directly usable in arithmetic expressions (e.g.
r1.#int + r2.#int). Unfortunately, since Haskell has a finite number of precedence levels, this goal was not properly met, since
(and all higher-precedence arithmetic operators have conflicting precedence levels.
Performance has not been analyzed at all. To my knowledge, GHC doesn't do type class specialization or method inlining by default, so needlessly generic code might be generated, even if all types are statically known. I'm hoping that this can be addressed using
INLINEpragmas if it turns out to be an issue.
|Dependencies||array (>=0.3.0.0), base (==4.*), containers (>=0.3.0.0), fclabels (>=0.9.1), monads-fd (>=0.1.0.1), transformers (>=0.2.0.0) [details]|
|Uploaded||Wed Aug 11 11:15:52 UTC 2010 by JussiKnuuttila|
|Downloads||563 total (8 in the last 30 days)|
|Rating||(no votes yet) [estimated by rule of succession]|
|Status||Docs uploaded by user
Build status unknown [no reports yet]
Hackage Matrix CI
For package maintainers and hackage trustees