Plans for the Future
====================

This is just a simple bullet list of things that are on my (long term) TODO
list. Comments are welcome, as usual.

* Check whether it makes sense to let users specify the communication
  (request) type. This is currently baked-in to be inferred from the
  variable's type as specified in the program text. 
  Another twist would be to allow to use the native type and convert
  on the seq side. The question is if this
  brings any actual benefit, considering that sequencer and database
  typically run on the same IOC. It might be convenient, sometimes.

* Add "pv" as a prefix type constructor. This is now implemented in my
  working branch for version 2.3. Sketch::

    int pv x = 0;                         /* single anonymous scalar pv */
    int pv x = pv "name";                 /* single named scalar pv */
    int (pv x)[2] = {1,2};                /* single anonymous array valued pv */
    int (pv x)[2] = pv "name";            /* single named array valued pv */
    int pv x[2];                          /* array of 2 anonymous scalar pvs */
    int pv x[2] = pv {"n1", "n2"};        /* array of 2 named scalar pvs */
    int (pv x[2])[100];                   /* array of 2 anonymous array valued pvs */
    int (pv x[2])[100] = pv {"n1", "n2"}; /* array of 2 named array valued pvs */

  This now also works for structs whose members can be of pv type etc.

* Raw ideas:

  - Allow parameterized state sets (like a function). Then allow to "jump"
    from one state set to another one. The "caller" i.e. the original state
    set must wait for the "callee" to finish. The idea here is to avoid
    dynamic creation of threads, as this could be implemented as a simple
    procedure call. Needs more thought.

  - Better support for enumerations i.e. PVs with native request type DBR_ENUM.
    The idea is that the programmer can use identifiers to name the choices,
    but does not have to know in advance which integer value corresponds
    to which choice.

    Maybe something very simple suffices, like a built-in function ::

      int pvChoice(var, char *choice_name);

    This requires support for DBR_GR_ENUM in the pv layer.

  - Better syntax for assign, monitor, sync, etc. The idea is to provide an
    alternative to the usual macros. Every SNL programmer uses her own
    self-made macros to simplify declaration blocks like ::

      int x;
      assign x to "bla";
      monitor x;
      sync x to ef_x;

    The challenge here is to come up with something that is light-weight,
    can be easily specialized, and seamlessly fits into the existing syntax.
    
    My current favorite candidate is to extend the pv initialization syntax.
    The idea is that a pv init expression (i.e. an initializer prefixed with
    the "pv" keyword) can get extra arguments with defaults::
    
      int pv x = pv "name";             /* just assigned to "name" */
      int pv x = pv ("name");           /* same */
      int pv x = pv ("name", 1);        /* also monitor */
      int pv x = pv ("name", 1, ef);    /* also sync to ef */
      int pv x = pv ("name", 0, ef);    /* no monitor, but sync to ef */
      int pv x = pv ("name", 1, 0, 20); /* monitor, no sync, queued (size 20) */
      int pv x[2] = pv ({"n1", "n2"},1);/* both pvs are monitored */
      struct two {
        int pv x;
        int pv ys[2];
      };
      struct two s = pv {"n1", {"n2", "n3"}}; /* no monitors */
      struct two s = pv {("n1",1), ({"n2", "n3"}, 1, ef)}; /* x monitored, ys also synced */
      etc...

    The "pv" outside of an aggregate "{ ... }" should be the same as
    prefixing all elements with it. Aggregates in a pv argument position
    are allowed only for the pv name and mean expand all elements with the
    other arguments.

* Convert everything under test to use epicsUnitTest. Add more regression tests.

* Need to go over the introductory chapters in the docs, remove out-dated
  information. Partly done.

* Götz suggested to allow the monitor clause inside a state set, even if
  the variable is global. This would mean automatic variable updates affect
  only those state sets which contain the monitor clause, while others do
  not get updates. (Perhaps: combine this with state set local event flags
  and sync clauses.)

  This could be useful in situations where one state set writes to the variable
  and others only read. The writer would not monitor, thus would not fall
  victim to the modify but not publish fallacy.

  Experimental implementation in version 2.3 branch done. State local
  assign, monitor, etc got in the way, which is why I removed them in 2.3
  (deprecated in 2.2). They aren't too useful anyway.

* Add some sort of built-in macro language. Something that nicely integrates
  with the existing SNL syntax would be nice, e.g. ::

    define macro (arg, ...) {
      definition
    }
    include "headerfile";

  Use of CPP could then be deprecated. What about token catenation and
  stringification as in CPP?

  Implementation would have to be an intermediate step between lexing and parsing.
