* More board definition modules other than Nano and Uno. Need hardware to
  test.

* The Nano board definition has not been tested on actual hardware,
  and we wonder if eg pin10 can really handle PWM. Some documentation seems
  to say not. It would be good to check it's basically working.

* Serial input/output can support types other than the current Int8.
  For example, here's an implementation for Word8:
  https://github.com/tom-hoffman/copilot-looper/blob/main/Word8IO.hs

* analogReference()
  Takes one of a set of defines, which vary depending on board,
  so how to pass that through Copilot? Could write a C
  switch statement, on an int, and have the board modules define
  effectively enums.

* ADC is a raw ADC value; add a stream function to convert that
  to a floating point actual voltage, given also a stream that contains
  the reference voltage.

* advanced IO (pulses, tones, and shiftin, shiftout)

* Wire library

* EEPROMex supports writing individial bits of a byte, but the haskell
  library does not expose it. What would be a good haskell interface to
  that, a Stream (Array 8 Bool)?

* Factor out Range from EEPROMex, and use it to also implement RAM ranges.
  Maybe redundant with Copilot's support for Array, but Copilot's
  facilities for operating on Array are limited so it could be useful to
  have a Range interface too.

* liftB and liftB2 imply liftB[3..5] at least ought to exist.

  Really, want something like Applicative. But apparently TypedBehavior
  is not a Functor, and so cannot be Applicative. There might be some
  way to use type classes to do arbitrary arity lifting. Take a look
  at QuickCheck and printf for ideas. Also see
  https://www.seas.upenn.edu/~sweirich/papers/aritygen

  Alternative might be to wrap all of Copilot DSL's functions like (>)
  with ones that operate on TypedBehavior and Event. 
  (Then rename TypedBehavior to Behavior and make everything produce
  and consume that, rather than the underlying Stream?)

  Alternativly, copilot could be improved, see
  https://github.com/Copilot-Language/copilot/issues/56
  https://github.com/Copilot-Language/copilot/issues/59

* using whenB with an input' makes the interpretation see
  each value from the list, even when the whenB is supposed to prevent the
  input' from having run, and the value should be whatever was input
  previously. This may not be fixable w/o Copilot DSL support
  for limiting when inputs happen, at least as far as what the interpreter
  displays as values of the input goes. But, it should be fixable
  as far as the value that is input, at least in theory, by ignoring
  the input values that should not have been input. The  Copilot
  DSL code used to do that may increase the size of the C program
  unncessarily though.

* The way serial output works is somewhat unsatisfying, because
  it does not take a Stream FormatOutput. So the Copilot DSL can't be used
  to adjust the output format as the arduino runs; it's fixed at compile
  time. While Serial.byte does operate on a Stream, it would be hard to do
  eg, an interactive program using it.

  It might be possible, using Copilot's support for C structs, to allow
  Stream FormatOutput to be accepted by Copilot. However, this issue
  seems like it would probably get in the way of actually constructing such
  a stream: https://github.com/Copilot-Language/copilot/issues/36

  The workaround, for now, is to use ifM_ etc to switch between different
  sketches for the different output formats.