Possible future thoughts for spigot
===================================

This file is spigot's informal to-do list. I don't necessarily intend
to actually do all of these things; they're just thoughts and
ponderings, with discussion of the implementation strategy and/or
difficulties that I didn't want to lose having thought of them.

Ubiquitous suspendability
-------------------------

It's currently possible for a spigot-based computation to hang
indefinitely without returning to the main loop. _Usually_ that won't
happen once a spigot is fully set up in the form of some Source class
returning data to a Core, because the function-call structure ensures
that the Source returns just one matrix and then the Core gets the
chance to return to _its_ caller and say 'no progress yet'. But the
setup functions - doing things like range reduction and preliminary
divisions of the domain into regions where different strategies are
useful - can still hang if given an input causing an inherent
exactness hazard.

(And some kinds of Source, like MonotoneHelper, can still hang once
they're in the main stage because they're constantly constructing
sub-spigots which have to go through _their_ setup phase.)

It would be good to reorganise all of this so that _all_ stages of
spigot computation guarantee to return to their caller regularly, even
if it's only to report that no progress has yet been made. That would
enable more than one alternative mode of use.

Interactive mode
----------------

spigot's command-line invocation is all very well if you want to pipe
lots of its output into something, but if you're using it for
interactive computation, it is a bit unwieldy, because it plays so
badly with Unix shell syntax and Unix command-line conventions - you'd
like to just type the expression you want to evaluate, but instead you
keep having to remember that some of them need to be single-quoted or
prefixed with '--' or both.

So it would be nice to also support an interactive mode, with a nice
readline-based command prompt, and some means of controlling infinite
streams of output, along the lines of printing one line of digits by
default and permitting some keystroke like Tab at the command prompt
to go back and add more data to the previous computation. Then you
could just type spigot-syntax expressions directly at the command
line, with no surrounding quoting hassle.

There'd also need to be some sort of syntax available at the internal
command line to set all the same output and rounding options as are
available on the external command line, of course. And that syntax
would have to be impossible to confuse with an expression to be
evaluated.

[Ubiquitous suspendability is a prerequisite for this feature.]

Graph plotting mode
-------------------

I keep thinking it would be kind of cute to write a spigot-based graph
plotter. The idea would be that you tell it your x range and your
function; it promptly instantiates one spigot for each x value
corresponding to a horizontal pixel position, and then it evaluates
all the spigots 'in parallel' (well, really just interleaved), getting
each one to make progress if possible.

So each vertical column of pixels would correspond to a single output
spigot, and would contain a range of black pixels covering the
_current known bounds_ on the output value of the function. If one of
the spigots throws a domain error, that can be clearly marked on the
plot; if one of the spigots suffers an exactness hazard which prevents
it ever finding out what the function looks like, then that column of
pixels will just stay black forever and the rest of the graph will
still plot itself.

(If that happened, you'd have to hit the interrupt key at some point
to avoid wasting too much CPU time - the same as you do now if spigot
delivers tentative output getting more and more certain that your
answer is something simple like zero. But if the whole graph was
plotted successfully, then spigot-plot should stop computing
automatically, because once a column narrows down to a single pixel,
that column's spigot has done its job and can be discarded.)

The point, of course, is the unlimited precision; I envisage that this
would be a useful tool if you were trying to plot a function that led
to a lot of rounding errors in a conventional floating-point based
system like gnuplot. One example is if you're trying to plot the
difference between a special function and some polynomial you've
designed to approximate it to the limits of IEEE double precision.

[Ubiquitous suspendability is a prerequisite for this feature.]

Waiting for input files to lengthen
-----------------------------------

Currently, the only two options when encountering EOF on an input file
are to bomb out with an exception, or to assume that means the number
represented is exactly accurate.

One could imagine finding uses for a third option, similar to 'tail
-f': if we see EOF, wait for more data to be added to the end of the
file, then read that and continue. Could be used in a situation where
another instance of spigot (or some other program) is in the process
of appending to the file in parallel with the one reading it.

Not sure how best to set it up, though; one would like to use some
kind of inotify-type facility, if available, to avoid the need to poll
tediously. And that's likely to involve a load of faff with
autoconf...
