Status Report

This month has been incredibly busy. I have been accumulating many things to blog about, but I have not had time to write. Perhaps it is time for a status report.

TTC

TTC is a Haskell library that provides type classes for conversion between data types and textual data types (strings). The library has some fundamental constraints. One significant constraint is that ByteString representations are encoded as (valid) UTF-8. This constraint is by design, to make the API easier to use for common cases. The library should simply not be used when working with other encodings.

Another significant constraint is that the Textual type class, which manages conversion between textual data types, only supports a fixed set of textual data types. It is not possible for users to add support for additional textual data types. This constraint arose as a limitation imposed by the design, in order to have Render and Parse type classes that do not require conversion via a fixed type.

This constraint makes it difficult to support new textual data types such as linear-builder and os-string types. Support for these types cannot be added to TTC without significantly narrowing the range of supported GHC versions, and support cannot be added via separate packages due to the above limitation.

While recently working on a presentation that explains the design of TTC, I thought of a different design that does not have this unwanted limitation! It is possible through use of type families and flexible contexts. I have since implemented the full TTC API using the new design, as well as ported the examples and tests. The API with the new design is very similar in spirit, but there are significant differences in the types used.

At this time, I am thinking of releasing the new design as a separate package, not as a second version of TTC. This would allow users to select one based on their needs.

• TTC uses simple types and builds quickly, at the expense of not being able to add support for additional textual data types.
• The new design uses more complicated types. Users have to use type families to create Render and Parse instances. Error messages are a bit more difficult than TTC error messages. It takes noticeably longer to build. It is possible, however, to add support for additional textual data types by defining new instances. Separate packages could provide support for linear-builder and os-string types without sacrificing the extensive support of the core library.

The idea that makes the new design possible can also be generalized. I have a proof-of-concept library that implements the generalized idea, and I hope to find time to develop it fully. I am not sure if it will be worth releasing to Hackage; that is yet to be determined. The generalized library could even be used instead of TTC, but I do not think that the code would be near as readable. One benefit of a special-purpose API like TTC is that it is easy to read and understand.

Food

We have started to harvest summer vegetables, including corn and cucumber! My youngest daughter is now a huge fan of fresh corn.

We harvested many potatoes this year. They are almost gone, and I think I will make one more shepherd’s pie.

Hiking

This month has been stressful, and I have been too busy to hike as often as I would like. I was able to get a good hike in earlier this week, however. I saw only one other person on the trails. Perhaps there are few people out hiking due to the high humidity during the rainy season. I also saw one live snake, one dead snake, and a really impressive centipede.