@hackage fields0.1.0

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 Functor. Example: recordInFunctor <.#> field

• Composing fields with Applicative functors and Monads. Example: record .# applicativeField <#> subfield

• Pattern matching using ViewPatterns. Example: case record of (match field -> 1) -> ...

• Easy comparisons etc. using onField. Example: 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:

• Currently, a Field 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 "data-accessor" and "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?

• Similarly, the field method currently returns an "fclabels" lens. To fully decouple this package from "fclabels", the field method probably has to be split into getField, setField and modField or something similar.

• For monad transformers, "transformers" and "monads-fd" are used, since those are what "fclabels" uses. This might be a problem for a program that uses "mtl" instead.

• 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 SPECIALIZE and INLINE pragmas if it turns out to be an issue.