                             Language::MuldisD
---------------------------------------------------------------------------

Following is a summary of things that still need doing.  It is specific to
the Muldis D specification distribution only, and doesn't talk about things
that would go in other distributions, including implementations.  (But,
look at lib/Language/MuldisD/SeeAlso.pod for a list of actual or possible
implementations.)

Alternately, this list deals with possible ideas to explore, which may or
may not be good ideas to pursue.

The following list is loosely ordered by priority, but list items may
actually be addressed in a different order.  There is no specific time
table for these items; they are simply to be done "as soon as possible".

* Generally speaking, make a new release to CPAN once every week, assuming
the progress is non-trivial, so there are regular public snapshots with
nicely rendered documentation.

* Consider changing the keywords in system-defined routine signatures,
specifically [result, params, update, read], to something better sounding.

* Overhaul and expand the catalog types for defining data types.

* Add catalog types for defining whole packages, subdepots, depots, whole
database constraints, virtual relvars, triggered routines, etc.

* Take advantage of the fact that a scalar possrep looks just like a tuple.
We need to add at least 6 generic sys.Core.Scalar.\w+ functions.  The first
2 respectively extract all possrep attrs at once as a tuple, or select a
scalar value where the selector has a single tuple-typed parameter to
specify all the possrep attrs.  Another 2 will respectively extract or
update a single possrep attr, as per the Tuple.\w+ functions 'attr',
'update_attr'.  Another 2 will extract|update an arbitrary subset of
possrep attrs as per the Tuple.\w+ functions 'project', 'multi_update'.
For that matter, add an analogue to Tuple.substitution_in_default as well.

* Add relational operators for sorting and quota queries; that is,
analogues to SQL's ORDER BY and LIMIT tasks, as well as order-significant
aggregate operations on relation attributes (eg, catenate).  Consider
overhauling the nature of the Ordered role and/or generic comparison or
sorting operators.

* Define more flow control operators like IF/ELSE, GIVEN/WHEN, etc.

* Define short-hand data definition operators analagous to SQL's CREATE,
ALTER, DROP etc.

* Flesh out and add system service operators like random numbers or current
dates or simple generic I/O.

* Consider consolidating the core generic data types into fewer / new
packages, leaving the current root-type specific packages to just contain
their operators.  Maybe group the mains under 'Scalar', 'Nonscalar' etc, or
come up with some new name for those.

* Overhaul the temporal data types, provide operators for them.

* Likewise with spatial data types.

* Whatever else needs doing, such as, fixing bugs.
