uchicago-library / attachment-converter

Attachment Converter: tool for batch converting attachments in an email mailbox
GNU General Public License v2.0
8 stars 3 forks source link

21 create minimal executable #25

Closed nmmull closed 2 years ago

nmmull commented 2 years ago

Decided just to make this a pull request, in part because I'm excited about polymorphic variants. I realized they can be used to abstract out any decision Cormac might make about representing errors for acopy and amap.

The executable is very minimal, no command line arguments, it takes a single email at stdin and does a conversion with a so-far unwritten function for email conversion full_covert_email, which depends on the eventual implementation of acopy_email (and could potentially be replaced with it).

Let me know if there were other features you all had in mind.

Note: this code naturally branches off from the work in issue 9.

nmmull commented 2 years ago

Based on our discussions on Slack, I've set up error handling using polymorphic variants in a way that maintains the ability to have an ERROR signature. A note about how I think this should be used:

The ERROR signature describes the interface of errors that we want to expose to users of the Lib module. All internal modules can implement an Error module however they want, but if they want to be correctly handled by users of Lib they have to be checked to implement ERROR, which can be done in the ErrorHandling module separately, so as to keep the local code clean (see the case for Configuration.ParseConfig.Error), and the Lib.Error module has to be expanded to include the new internal Error module you want to handle. Note that, one of the great benefits of this is as you're hacking along, if you ever find you want a new kind of error case, you can just make a polymorphic tag. Once you're done hacking, you can collect together all the tags you used into an Error module, implement the ERROR signature, add a couple lines to the high level Lib.Error module, and then the rest of the code will be happy with the new kinds of errors you created. You can even use errors from other modules without much fuss because they're just polymorphic variant tags. Kinda neat.

It's not a perfect system, but I think it's pretty clean all things considered. There may be some issues with exposing the internal error modules which we may want to deal with later, but for now I think the concept is fairly solid.