TODO for the Haskell Ports Library	             -*-text-*-
		  ==================================

* Conceptual problem: when the compiler floats access to a stream obtained by
  listening to a pointer earlier in the code, we may get a deadlock.  This
  happens if the access is in the same thread as the send operation that puts
  the accessed value into the port and the access floats before that send.

  This problem does not occur in Goffin as by default all operations are
  concurrent and sequentiality needs to be introduced explicitly.  However, in
  the IO monad all operations are sequential and concurrency needs to be
  introduced explicitly.  It is also hard to use the Goffin model in Haskell,
  as concurrency is Goffin is much cheaper.

  To work towards a a solution of this problem, the module `PortThreads'
  associates new threads with port stream consumers.  If the approach in
  `PortThreads' is generally workable, it should become the standard ports
  interface.

* The idea of just closing ports by way of finalisers is elegant, but appears
  to be quite fragile.  However, explict closing of ports is hard to
  coordinate when multiple concurrent threads write to a port.  Maybe we
  should have a kind of `forkPort' operation that allows for an additional
  closing of a port (to keep track of the number of input edges).  Then, a
  port could be forked as long as it has not been closed.

* As Qrczak correctly points out,

    IMHO processes should not be killed using killProcess (sigKILL).
    Better use softwareTermination (sigTERM).

  But in Take, we need to use sigKILL; so, we probably want to have an
  argument specifying the exact type of signal.

* `reader' in `Processes.proc' currently explicitly closes the stdout port.
  This is bad if the port is shared.  However, if we use a pipe GCing the port
  to close it doesn't work, but it isn't clear why it doesn't work.

* `Processes' has to be documented; also mention the `HPL' module

* Rename `SVars.V' to `SVars.SVar' and rename all functions similarly

* better docu

* Qrczak also proposes to have PortFilters of type [a] -> [a], which get the
  whole stream of incoming messages and filter on that.  Allows

    map adjustOne - to adjust all values independently,
    map head . group - to remove duplicates,
    filter2 . filter1 - to compose two filters,
    filter condition - to accept only certain messages.

  Problem: Impl without a background thread waiting for new elements in the
  stream generated by the port filter, to update the port.

* When a port is closed, it should either be removed from all buddy lists, or
  writes *via the buddy list* to a closed port should be silently ignored.

* Shall we have filtering proxy ports?  The main problem is that they
  require a careful design of the implementation to avoid overheads and have a
  clear semantics.

* Should proxy ports get another method that they call when they are closed
  (possibly to shutdown the associated object)?

* external ports

* Warnings should go to stderr