                                 Muldis::D
---------------------------------------------------------------------------

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/Muldis/D/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.

* Add ext/TAP.pod, which is a partial port of Perl 5's Test::More / Perl
6's Test.pm / David Wheeler's pgTAP to Muldis D; assist users in testing
their Muldis D code using TAP protocol.  The TAP messages have type Text.

* UP NEXT ...
Reorganize the type hierarchy so that quasi-scalar|tuple|relation are now
the main supertypes and the non-quasi scalar|tuple|relation supertypes are
now proper subtypes of those.  That also means that the system-defined
'Tuple' and 'Relation' types are then enumerated types rather than
primitive types; the quasi- versions would be the only primitives.  Rename
the types QuasiFoo to just QFoo.  The name-spaces .Tuple etc, both under
core and under extensions, will remain named for the non-q types, but they
will actually close over the quasi types; however, when their arguments are
appropriate non-q types, they effectively are as they were before.  Same
principle as how the .Int namespace has some routines only valid for NNInt
or PInt etc.  Or actually no, we should rename the namespaces to be QFoo
also, to avoid deception/confusion.  After the change, there will only
exist the Nothing type, QNothing won't exist.  Generally speaking, if a
scalar|tuple|relation has zero attributes, there is no difference at all
between a quasi-foo and a foo, and likewise with a relation having zero
tuples, there is no diff.  No QDatabase type will be added.  The catalog
facilities will still huffmanize for non-q types; one still has to turn an
is-quasi flag on to get that, else the more restrictive behaviour will be
default.  Any documentation referring to plain scalar|tuple|relation will
be updated to refer to "q/scalar"|"q/tuple"|"q/relation" etc, when the
quasi-versions are also applicable there (I have to examine every example
case by case), but the emphasis would still be on the non-q versions.
As for relational operators that would consider arguments to be
incompatible with non-q relation context etc, such as join or union of 2
different-degree RVA with same attr name, the q-savvy operators would
succeed but can offer a warning if the declared types of the arguments are
plain Relation etc, same as one can have warnings for certain is_identical.
In the general case even ungroup/unwrap is defined for quasi-foo also; it
would only die if the specific attributes asked to be ungr/wr are quasis.

* Add a feature affecting namespaces where one can refer to "the current
depot|subdepot|etc" as defined by a global variable of sorts.  The idea is
that code existing outside of a depot can refer to that depot or its
contents without having to say "fed.<depot>", but rather "cur.dep" or some
such.  An example use case is that the relvar create statements and tuple
insert statements that comprise a database dump don't have to embed
"fed.<depot>"; code that would load a database from the dump would just
precede the dump's execution with a statement to set that global variable.
In other words, support what is common with the likes of Postgres and MySQL
where one can just set the "current database|schema" and then subsequent
entity references by statements don't have to be qualified with said.

* Reorganize the Tiny dialects docs so that plain-text-Tiny now has most of
the detail info and is standalone, and hosted-data-Perl-Tiny is just
defined as being the same as the former but for specified format
differences.

* Update the plain-text Tiny dialect to support more Perl 6 isms directly,
such as "0(b|o|d|x)" prefixes rather than "max-col-val:" prefixes (and the
same can be done for Blob but just b|o|x opts); still up for debate is
supporting numbers with no prefix at all, which would then be interpreted
as base-10.  Also reconsider use of colon as value def separator, possibly
going with different separators between first and rest/other element, and
in front of any elements beyond the second.  For example, maybe just use
colon after first element, and then semicolon between any 2nd/3rd etc.  Or
use a delimiter pair such as <> following the first element and surrounding
all remaining ones, any multiple remaining being semicolon delimited.

* IN PROGRESS ...
Split up the 1 HDMD_Perl_Tiny dialect into the 2 HDMD_Perl(6|5)_Tiny
dialects, and don't be afraid to let them grow apart.  For example, the
Perl 6 version can use Pair objects as the basis for most nodes, eg
":Text<Foo>" or ":Int(:3<21>)", rather than Array/Seq, and the p6v can
avoid providing the 3-part number syntax to match the plain-text dialect,
simply requiring use of Perl 6's own multi-radix support (plain-text
parsers in Perl 6 would do more than just output tokens as text), and
Bool|Order|Int|etc nodes would require payloads as only native Perl 6
Bool|Order|Int|etc objects and not accept text forms or number forms for
bool etc (once again, parsers in Perl 6 can do more than just tokenize).
For example, the Perl 5 version can ignore mentioning all the named
variants in Perl 6, and just say "string" rather than Str|etc and array-ref
rather than Array|Seq etc.

* Update the Tiny dialects with special syntax for declaring whole depots
in a single expression, catalog+data.  This can be useful for example with
a simple Muldis D implementation that wants to represent a persisted depot
on disk as a single file that is Muldis D source code.  This would mostly
be like a bootloader definition except that details related to the name
that a depot is mounted with aren't given as they would with an
application-side bootloader.

* Update the Tiny dialects with special syntax for some nonscalar catalog
types, particularly definitions of routines and types, so that both doing
this can be made even more like a normal language, and also the missing
pieces to support more appropriate syntax coloring and routine locating in
text editors looking at Muldis D source, eg a 'function' keyword at the
start of each function.  Here are some keywords that can then be added:
function, updater, procedure, type, param, ro_param, upd_param, expr, stmt,
subtype, key, possrep, etc; they apply to both 'outer' and 'inner'
types/routines; also keywords for declaring whole packages or something.
Also consider that some pragmas can go away, their actions made always-on
or 'lexical'.

* Add catalog types that represent thrown exceptions.

* Also study SQL concept of conditions and handlers, looks sort of like
something between exception handling, signals; or it is their exceptions.

* Update the virtual attributes maps so there is a way to manually specify
a reverse function, as meanwhile all the virtuals don't have to be either
read-only or updatable due to an automatically generated reverse function,
which might vary by implementation, which may be considered broken.  Note
that the reverse functions might have to be defined as per-tuple
operations, separately for insert/substitute/delete.

* Add transition constraints.  The initial version would simply take a
'before' and an 'after' state argument.  But it may be good to provide an
alternative where arguments show the delta since often that is what
constraint writers want to know anyway.

* Add other kinds of triggered routines.

* Enhance the catalog so that one when defining values like
(Tup|Rel)LitExprNodeSet, one can tag such values with the data type the
value is supposed to be in, so they can auto-complete missing attributes as
per the treat_as_type lexical-scope pragma of the Tiny dialects; this would
also work for when a definition isn't a valid relation since the actual
Node value is valid.  In the absense of or in addition to auto-complete,
this feature could be used as treat-like operators to help with code
validation or allow more at-compile-time validation.

* Update Text.pod (or add other extensions) to add general search and
replace or transliteration or regular expression et al functionality,
besides the bare minimum SQL-LIKE-alike currently provided.  Also add
functions for splitting strings on delimiters or catenating them with such.

* Add functions for comparing or processing continuous ranges or intervals
as per is_inside_range ... the tests are for eg if 2 ranges do or don't
overlap, or whether an overlap is specifically between the start of one and
the end of another, or whether ranges simply touch, or whether a range is
entirely within another or not, etc ... some are analagous to set
operations, but not so much as they talk about continous intervals, or as
continuous such as the type in question supports ... useful particularly
for use with date data types.  as for supporting non-continuous ranges,
which are probably represented by sets of continuous ranges, that might be
simple enough to support here too ... or some range stuff might go off to
another extension perhaps or perhaps not.

* Consider supplementing the current generic infinite-loop-until-leave
statement with alternatives that use boolean control variables, such as
'while' or 'repeat-while'.

* Consider adding an imperative for-each looping statement; the main
question here is whether it should work on any (unordered) relation or just
on an Array (in which case it iterates through the tuples in sequence by
index); the question is what tasks the for-each would be used for; perhaps
both versions are useful; presumably the main reason to have for-each at
all is when I/O is involved and some derivative needs to be output either
where order matters or where order does not matter; but perhaps only a
routine is needed here such as a catenate function plus normal I/O output.

* Consider converting the try-catch routine into a statement node, an
optional part of which is to make the insides of the try/catch blocks part
of the same lexical scope as the invoking routine.  But there is still a
lot to like about having each of the try/catch blocks being a separate
(inner) routine with its own lexical scope, such as in predicting what a
rollback would affect, and it might be easier to implement as-is.

* Add sequence generator updaters|procedures in Integer.pod.

* Consider adding random value generators for data types other than integer
and rational numerics, such as for character strings or binary strings.

* Make further updates to Temporal.pod to improve correctness or
normalization, particularly with durations, maybe add some duration
subtypes.  Also expand the selection of routines to allow more control over
semantics.  Seek advice from the Perl DateTime people about this stuff.

* Consider updates to Temporal.pod that let one record time zones etc
attached to instant values; this would be a non-central feature.

* Provide operators for the spatial data types, maybe overhaul the types.

* Update the system catalog concerning managing shared|exclusive locks or
looking for consistent reads between statements, etc.

* Update the system catalog to deal with database users and privileges etc.

* Flesh out matters related to starting or communicating between multiple
autonomous in-DBMS processes, in general, besides the special case about
sequence generators.

* Consider some more elegant solution about matters of closures et al.

* UP NEXT ...
Add Ext/Quasi.pod or multiple such language extensions that contain
routines for system-defined quasi-scalar and quasi-nonscalar types, which
are analagous to the system-defined routines for their non-quasi
counterparts.  There won't necessarily be a counterpart for all non-quasi
generic routines, and probably not even for most of them, but rather just
enough counterparts to be useful.

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