* 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.
* 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.