                                 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, and is organized into
groups by approximate subject area, 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.

----------

* Update the development status of the Muldis D language spec to "alpha"
from "pre-alpha" and truncate the "Changes" file (but don't set the version
to 1.0.0 yet) only when the spec is complete enough that the Muldis Rosetta
Example Engine reference implementation has fully implemented the language
core, or a significant and computationally complete working subset thereof,
and so the language spec is then considered sufficiently complete with
corner cases exposed; Muldis Rosetta would also be updated to "alpha"
status et al simultaneously.  There are no other preconditions to consider
either project "alpha" status.  Curr est circa Mar..Jun of 2010 for this.

* Preconditions for considering the Muldis D language spec to be either
"beta" or "released" status or "1.0" incl:  A significant, computationally
complete working core or subset thereof as a Parrot hosted language, a
TAP speaking test suite with significant feature coverage, a serious level
of post-alpha-status design input solicited of other interested parties,
implementations over multiple SQL DBMSs.

----------

* FIRST PRIORITY ...
Flesh out the concrete Muldis D syntax for defining whole routines and
types et al.  Arguably, "recipe" is the single most important to do first,
since that is what normal database queries/DM/DD are by default and
entirely if we just use system-defined types, then "function" is the next
most important for higher-order functions, then a subset of "tuple" and
"relation" are the next most for defining database schemas; that subset
just being the list of attributes, and a slightly larger subset adding key
constraints, and then subset constraints, and then "subset-type" is next
most important type, etc; when doing "recipe", we'd get "updater" for free.

----------

* Create the following mixins and group types and ops under them:
    - Collective :
        - tps: Set, Array, Bag, SPInterval, MPInterval
        - ops: in/∈, has/∋
And these types have these similar ops:
    - Relation :
        - ops: r-has/r∋
        - ops: in-r/∈r

* Update the mixins feature to add support for mixins that define
attributes that types can compose, whereby we support some approximation of
"specialization by extension" while still actually being just
"specialization by constraint".
Maybe also it could be said ...
A primary purpose of mixins is to help with managing software reuse, mainly
when multiple types have a number of attributes in common, a mixin can
define these and then the multiple types can compose that mixin.  A mixin
or type that composes a mixin can both add additional attributes of its own
to what the mixin defines, and the composer can add extra constraints over
the composed attributes like forcing a subtype.
Maybe also do ...
Support delegation / 'handles'; for example:
    - TAIDuration explicitly delegate to Rat attr,
        and so all operators declared for 'Rat' simply work with
        TAIDuration also as if all their sigs were
        s/Rat/TAIDuration/ etc
    - Name explic delegate to Text attr
    - maybe Blob, Text explic delegate to String attr
    - a ColoredCircle would delegate to both Color and Circle attrs?
This will all take some work to get right; not /all/ Rat/etc can be subst.
Probably *only* those operators that Rational/etc explicitly declares can
be delegated to Rat/etc by TAIInstant/etc.

* Actually, all the temporal stuff just needs to be refactored now, as TAI
no longer holds a privileged position.  Moreover, TAI can't actually
reasonably delegate all of the Rat methods, since for example it doesn't
make sense to multiply or divide a duration by another one, though you
can multiply or divide a duration by a rat.

----------

* 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 new "material" kinds that define state constraints (address as simple
nlx.*.data.*), like type constraints but ref in reverse.

* Add new "material" kinds that define
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 new "material" kinds that def stimulus-response rules / triggered
routines.  The material kind has 2 main attributes, where the "stimulus"
defines what to look out for and "response" defines what to do when the
former is sighted.  Some possible keywords for the first are "stimulus",
"cause", "when"; for the latter, "response", "effect", "invoke".

* Document that a Muldis D DBMS should have command-line parameters
regarding the initial "main program" depot it is mounting that correspond
to each of the "MountControlSet" attributes; at the very least, the boolean
parameters "allow_auto_run" and "we_may_update" must be provided, in
addition to any params for, say, picking filename/etc of the initial depot;
for security purposes, the booleans are false when not given, meaning users
have to *always* say --allow_auto_run in order to run a pure MD program, so
it is quite clear up front what they are risking.

* Add new "material" kinds that define descriptions of resource locks that
one wants to get, starting with basic whole dbvar, relvar locks (address as
simple fed.data.foo.*, as well as simple relvar tuple locks (addr as prior
plus lists of values to match like with a semijoin); leave out generic
predicate locks at first but note they will be added later.
Update the system catalog concerning managing shared|exclusive locks or
looking for consistent reads between statements, etc.

* Large updates to docs concerning transactions and resource locking.
Note:  Supposedly PostgreSQL and MySQL use read-committed isolation by
default while SQLite provides serializable.
Add catalog types that represent thrown exceptions.  Prob non-dh tuple.
Also study SQL concept of conditions and handlers, looks sort of like
something between exception handling, signals; or it is their exceptions.

* Use a conceptual framework for database transactions that is strongly
inspired by how distributed source-code version control systems (VCSs)
work, in particular drawing on GIT specifically.  The fundamental feature
of the framework is that the DBMS is managing a depot consisting of 1..N
versions of the same database, where every one of these versions is both
consistent and durable.  Each version is completely defined in isolation,
conceptually, and so any versions in a depot may be deleted without
compromising each of the other versions' ability to define a version of the
entire database.  It is implementation-dependent as to how the versions are
actually stored, such as each having all of the data versus most of them
just having deltas from some other version; what matters is that each
version *appears* to be self-contained.  Every version is created as a
single atomic action, and it is never modified afterwards, though it may be
later deleted (also an atomic action).  Every in-DBMS user process,
henceforth called "user", has its own concept of the current state of the
database, which is one of the depot's versions that is designated a "head".
A user's current head is never replaced during the course of the in-DBMS
process unless the user explicitly replaces it, such as by either
performing an update or requesting to see the latest version (the latter
done such as with an explicit "synchronize" control statement).  Therefore,
each user is highly isolated from all the others, and is guaranteed
consistent repeatable reads and no phantoms; they will get repeatable reads
until they request otherwise.  The framework has no native concept of
"nesting transactions" or "savepoints" or explicit "commit" or "rollback"
commands.  Rather, every single DBMS-performed parent-most multi-update
statement (which is the smallest scope where TTM requires the database to
be consistent both immediately before and immediately after its execution),
is a durable atomic transaction all by itself.  The effect of a successful
multi-update statement is to both produce a new (durable) version in the
depot and to update the executing user's "head" to be that new version (the
prior version may then be deleted automatically depending on
circumstances); a failed multi-update statement is a no-op for the depot,
and the user gets a thrown exception.  A depot's versions are arranged in a
directed acyclic graph where each version save the oldest cites 1..N other
versions as its parents, and conversely each version may have 0..N
children.  A child version has exactly 1 parent when it was created as the
result of executing a multi-update statement in the context of the parent
version; the parent version is the pre-update state of the database and the
child is the post-update state of the database.  A child version has
multiple parents when it is the result of merging or serializing the
changes of multiple users' statements that ran in parallel.  One main
purpose of tracking parents like this is for reliable merging of parallel
changes, so that the intended semantics of each change can be interpreted
correctly, and potential conflicts can be easily detected, and effectively
resolved.  More on how this works follows below.  Note that versions simply
have unique identifiers to be referenced with and there is no implied
ordering between them if they are generated as serial numbers or using date
stamps, though versions with earlier date stamps are given priority in the
case of a merge conflict.  So a multi-update statement is the only native
"transaction" concept, and it is ACID all by itself.  Now, the
multi-statement "transactions" or concepts of nested transactions or
savepoints would all be syntactic sugar over the native concept, and
basically involve keeping track of versions prior to the head and
optionally making an older one the head.  This framework uses the VCS
concept of "branching" (which is something that GIT strongly encourages the
use of, as GIT makes later "merging" relatively painless) as the native way
to manage concurrent autonomous database updates by multiple users.  By
default, when no users have made any changes to the database, a depot just
has a "trunk", and its childmost or only version is called "master"; every
database user process' "head" starts off as the "master" version when that
process starts.  Each (autonomous) user process that wants to update the
database will start by creating a new branch off of the trunk, and
subsequent versions of theirs will go into that, rather than into the trunk
or some other branch.  The trunk is shared by all users while each user's
branch is just for that user, as their private working space.  Note that,
unlike a VCS in general where branches can become long-lived and interact
with each other independently of the trunk, the framework instead follows
the typical needs of an RDBMS, which espouses a single world view as being
dominant over any others, and expects that any branches will be very
short-lived, not existing for longer than a conceptual "database
transaction" would; only the trunk is expected to be long-lived.  (This
isn't to say that a DBMS can't maintain them long term, but one that acts
like a typical RDBMS of today wouldn't.)  Note that the final action on a
branch that involves merging into the trunk, this would be perceived by all
other DBMS users as all of the changes wrought by the branch being a single
atomic update, though the user performing it may see several steps.

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

----------

* Add to Routines_Catalog.pod and other files
definitions of any remaining routines, eg String routines, that would be
needed so that for all system-defined types all the necessary
system-defined routines would exist that are necessary for defining said
types, especially their constraint or mapping etc definitions.  So in
String.pod we need [catenation, repeat, length, has_substr] etc.
Also add "is_coprime" or GCD or LCM or etc which are used either in the
constraint definition of Rat or in a normalization function for Rat; see
also "the Euclidean algorithm" as an efficient way to do the calculations.

* Consider adding type introspection routines like: is_incomplete() or
is_dh() or is_primitive|structure|reference|enumerated etc.  Or don't
since one could look that up in the system catalog.  But more tests on
individual values might be useful, or maybe we have enough already.

* 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.

----------

* Add concept of shallowly homogeneous / sh- relation types to complement
the deeply version, and named maximal types like SHRelation, SHSet,
SHArray, etc to complement the DH/etc, and sh_set_of/etc to complement
dh_set_of/etc; but not sh-scalar or sh-tuple as the concept doesn't make
sense there.  Then update functions like Relation.union/etc to take
sh_set_of.Relation rather than set_of.Relation, which more formally defines
some of their input constraints.

* 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.

----------

* Add a round-rule param to rat division, I suppose, since in general we'll
need it if we want to maintain a rational radix through every op (+,-,*
will already do so when all their args are in the desired radix).

* Add explicit support for +/- underflow, +/- overflow, NaNs, etc.
I'm inclined to think +/- zero is unnecessary when we have underflow and
can be confusing anyway (just a single normal number zero is better).
I'm not sure if +/- overflows are useful or if infinities cover them for
our purposes.  How this would work is that we define a set
of scalar singleton types, one for each of the special values.  Then we
define extended versions of the Int, Rat, etc types where the extended
types are defined in terms of being union types that union the regular
numeric types with the special singleton type values.  This approach also
means just one each of +Underflow, -Overflow, etc is needed and is a member
of extended Int or Rat etc.  Consider using the existing names "Int"/"Rat"
with the versions that include these special values, and make new names for
the current simpler versions that don't, such as "IntNS" (int no specials),
"RatNS", etc.  Either way, it is useful to support the full range of values
that a Perl 6 numeric can support, or that an IEEE float can support,
without users necessarily having to define it themselves.
IDEA:  Maybe make all normal math/etc ops work with the extended versions
(those with NaNs, infinities, etc) and in situations where users don't want
those special values they just use a declared type excluding them, and then
the normal type constraints will take care of throwing exceptions when one
divides by zero for example.

* Flesh out Interval.pod to add a complement of functions for comparing
multiple intervals in different ways, such as is-subset, is-overlap,
is-consecutive, etc, as well as for deriving intervals from a
union/intersect/etc of others, as well as for treating intervals as normal
relations in some contexts, such as for joining or filtering etc, as well
as a function or 3 to do normalization of Interval values.
Maybe the type name 'Range' can be used for something.
Maybe the type name 'Span' or 'SpanSet' can be used for something;
there are Perl modules with those names concerning date ranges.
Input is welcome as to what interval-savvy functions Muldis D should have.

* IN PROGRESS ...
Add Bool-resulting relational operators EXISTS and FORALL, that provide
"existential quantification" and "universal quantification" respectively,
these being useful in constraint definitions.  See TTM book p168, pp394-5
for some info on those.  Also add analogies to Perl 5's List::MoreUtils
operators any(), all(), notall(), none(), true(), false(); some of those
may be the same as EXISTS/FORALL.  Also add an EXACTLY operator like the
Tutorial D language has, and a one() op that is between any() and none().
Maybe some pure boolean ops can be added analogous to the above also; eg
any() an alias for or() and all() an alias for and().
is_(any|all|one|none|notall|etc)_of_(restr|semijoin|semidiff|etc)
$source is any|etc matching|where|etc $filter|etc
ADD RELATIONAL OPERATORS THAT COMBINE BOOL OPS ADDED IN 0.80.0 WITH
RELATIONAL MAP/RESTRICTION/ETC AND ... The new functions are modelled after
some in Perl 5's List::MoreUtils module.

* Consider adding 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.

* Consider analogy to SQL's "[UNION|EXCEPT|INTERSECT] CORRESPONDING BY
(attr1,attr2,...)", which is a shorthand for combining projection and
union, that takes a list of attributes and unions the projections of those
attributes from every input relation; so this means, as with join(), that
the input relations don't need to have the same headings.

* Update the definition of the "Instant" type to account for updates to the
Perl 6 spec on 2010.02.23 (r29809), where "Instant" was made opaque and is
no longer specifically a count of seconds from the TAI epoch but rather
there can be multiple epochs where an epoch is simply an Instant value, and
an Instant's internals are implementation defined.  Since Muldis D has no
opaque types save Int, its analogy could perhaps have multiple possreps,
one per each epoch of common interest, which counts seconds from that?  See
also the Temporal-concerning perl6-language thread immed preceding r29809.
It seems that, like with Text and the thing about NFD vs NFKD or Unicode vs
non-Han-unifying alternatives, there isn't really any one representation
option for Instants that is overwhelming more correct or normal than others
to be used as a default or internal representation everywhere.

----------

* Consider updating PTMD_STD only to add more precedence levels.  For
example by splitting math into exponentiative, multiplicative, additive,
these being crossed with dyadic-infox, reducing-infix.  Or for example by
making 'and' higher than 'or', 'join' higher than 'union', etc.  Or for
example making most ops higher than comparison ops, which are in turn
higher than logical connectives.  On the other hand, it is possible that
some code may be more readable when we have more parenthesis in the
expressions anyway, and the current rules are fairly simple.  Of course,
the Perl-STD grammars are not affected by all this, as they effectively
always use parenthesis to force desired precedence.

* IN PROGRESS ...
Update the STD 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.

* IN PROGRESS ...
Update the STD 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.

* IN PROGRESS ...
Update the STD dialects to support inline definition of basic
routines (and types?) right in the expressions/etc where they are used,
such as filter functions in restriction() invocations, so many common cases
look much more like their SQL or Perl counterparts, or for that matter, a
functional language's anonymous higher order functions.  This syntax would
be sugar over an explicit material definition plus a FooRef val selection,
which means the inner def effectively is an expression node, and users can
choose to name or not name the FooRef selecting node as normal with value
expressions.  It is expected that the materials could be decl anonymously
and names for them (the inn.foo, not the FooRef's lex.foo) would be
generated as per inline expression nodes etc.  Presumably also add some new
keyword for a routine to invoke itself without using a name like normal;
this would be sugar for normal functional call syntax, using gen name.

* Further to the previous item, add some special syntax, similar to how one
references a parameter to get its argument's value, which can see into the
caller's lexical scope.  This would be sugar over declaring parameters with
the same name and having the caller explicitly pass arguments to it,
without having to explicitly write that.  Generally this syntax would only
be used with inline-declared routines.  But similarly, add some special
syntax allowing one to essentially just write the body of a routine without
having to explicitly write its heading / parameter list, which is useful
for routines invoked directly from a host language, where said parameters
are attached to host bind variables.  Now one still has to say what the
expected data type is for these bind variables, but then the explicit
syntax for such Muldis D routines is more like that of a SQL statement you
plug into DBI or whatever, without the explicit framing.  May not work
anywhere, but should help where it does.  Maybe use $$foo rather than $foo
to indicate that the 'foo' wasn't explicitly declared in the current
lexical scope and we are referring to the caller or a bind variable.  Or
rather than $$foo, have something like "(param $foo : Bar)" for an
expression-inline parameter definition and use, where the part after the
"param" has all the same syntax as an actual param list; this is the one
for host language bind parameters.  Actually that might be useful by
itself.  Similarly "(caller $foo)" would be the look to parent Muldis D
lexical scope, or $$foo would just do that maybe, unless this should have
an explicit type declaration still.  Note, if same inline-declared host
param used more than once, you just need "(param $foo : Bar)" form once and
other uses can just say $foo as per usual; in fact, it must be this way.

* Consider in PTMD_STD using a token similar to the Perl 6 "<ws>" concept
of something that is treated as insignificant whitespace as
far as interpreting the code is concerned, but that may contain #-delimited
comments.  The idea of this is to make it easier to sprinkle comments
almost anywhere without making the grammar a lot more verbose for it.  It
is expected that any use of such comments beside "<value>" nodes would only
be allowed under a "<depot>", and under plain "<value>" would be rejected.
Mind that such a token would not be used everywhere in place of a current
PTMD_STD "<ws>" or "<ws>?" (means \s+ or \s*), but only in specific places
repr a node that would turn into a system catalog tuple with a "comment".
Essentially it comes in 2 flavors whose definitions are
"<_ms_oc> ::= <ws> [<non_value_comment> <ws>]?" and
"<_os_oc> ::= <ws>? | <ws> <non_value_comment> <ws>" or such.

* Consider in all STD adding a new pragma that concerns whether data in
delimited character string literals is ASCII or Unicode etc.
Example PTMD_STD grammar additions:
            <ws>? ',' <ws>? str_char_repertoire <ws>? '=>' <ws>? <str_cr>
    <str_cr> ::=
        '{' <ws>?
            [<str_cr_describes> <ws>? '=>' <ws>? <str_char_reper>]
                ** [<ws>? ',' <ws>?]
        <ws>? '}'
    <str_cr_describes> ::=
        all | text | name | cmnt
    <str_char_reper> ::=
          ASCII
        | Unicode_5.2.0_canon
        | Unicode_5.2.0_compat
Example PTMD_STD code additions:
    str_char_repertoire => { text => Unicode_5.2.0_canon,
        name => Unicode_5.2.0_compat, cmnt => Unicode_5.2.0_compat },
    str_char_repertoire => { all => ASCII },
Of particular interest is the Unicode canonical vs compatibility, that is
NFC|D vs NFKC|D; it is generally recommended such as by the Unicode
consortium to use canonical for general data but to use compatibility for
things like identifiers or to avoid some kinds of security problems; see
http://www.unicode.org/faq/normalization.html.  Note that compatibility is
a smaller repertoire than canonical, so converting from the latter to the
former will lose information.  The text|name|cmnt affect how delimited char
strs that are Text|Name|Comment are interpreted, and the effects are
orthogonal to whether characters are specified literally or in escaped
(eg "\c<...>" form); canonical will preserve exactly what is stated (but
for normalization to NFD) and compatibility will take what is stated and
fold it so semantically same characters become the same codepoints (like as
normalizing to NFKD).  The suggested usage is compatibility for Name to
help avoid security or other problems, and canonical for Text; as for
Comment, I currently don't know which is better.  If ASCII is chosen, the
semantics are different; with both Unicode any input is accepted but folded
if needed; for ASCII, it is more likely an exception would be raised if
there are any codepoints outside the 0..127 range in character strings.
The 'all' is a shorthand for giving the same value to all 3 text|name|cmnt
and is more likely to occur with ASCII but it might happen otherwise.
An additional reason to raise this feature is to setup support for other
char sets in future, such as Mojikyo, TRON, GB18030, etc which go beyond
Unicode eg no Han-unification (see http://www.jbrowse.com/text/unij.html +
http://www.ruby-forum.com/topic/165927) but type system also needs update.

* Update HDMD_Perl6_STD.pod considering that a 2010.03.03 P6Syn update
eliminated the special 1/2 literal syntax for rats and so now one writes
<1/2> instead (no whitespace allowed by the '/'); now 1/2 could still work
but now it does so using regular constant folding and so having a higher
precedence op nearby affects its interpretation.

* Update HDMD_Perl6_STD.pod considering names of Perl collection types,
such that "Enum" is the immutable "Pair" and "EnumMap" was renamed from
"Mapping", and "FatRat" is now the "Rat" of unlimited size, etc.

* Consider using postcircumfix syntax for extracting single relation
attrs into Set or Bag etc, meaning wrap_attr; eg "$r.@S{a}", "$r.@B{a}".
Now that might not work for Array extraction, unless done like
"($r.@A{a} ordered ...)" or some such, which isn't pure postcircumfix,
but that may be for the best anyway.

* Consider adding concrete syntax that is shorthand for multiple
single-attribute extractions where each goes to a separate named expression
node (or variable) but the source is a single collection-typed expr/var.
Or the source could be a multiplicity as well, or mix and match.
The idea here is to replicate some common idioms in Perl such as
"($x, $y) = @xy[0,1]" or "($x, $y) = %xy{'x','y'}", this being more useful
when the source is an anonymous arbitrary expression.
Proposed syntax is that, on each side of the "::=" or ":=", the source and
target lists are bounded in square brackets, indicating named items assign
in order, and syntax for collections supplying/taking multiple items are
ident to single-attr accessors (having a ".") but that a list is in the
braces/brackets; for example: "[$x, $y] ::= [3, 4]",
"[$a, $b] ::= $t.%{a,b}", "[$c, $d] ::= $ary.[3,5]".  This syntax would
resolve into multiple single-attr accessors when app in system catalog.

* In PTMD_STD, consider loosening the grammar regarding some of the normal
prefix or postfix or infix operators so that rather than mandating
whitespace be present between the operators and their arguments, the
whitespace is optional where it wouldn't cause a problem.  On the other
hand, is "! $foo" really such a problem?  People might often write "not
$foo" there anyway as that is a preferred form for boolean ops.  In
particular, while someone may want to write say "$foo++" or "$foo--", the
latter is problematic since "-" are allowed in bareword identifiers and
that could mis-parse, and someone would probably prefer to then write
[$foo --] rather than [$"foo"--] anyway.

----------

* Restore the concept of public-vs-private entities directly in sub|depots.

* Restore the concept of "topic namespaces" (analogous to SQL DBMS concept
of "current database|schema" etc) in some form if not redundant.

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

----------

* IN PROGRESS ...
A Muldis D host|peer language can probably hold lexical-to-them variables
whose Muldis D value object is External typed, and so they could
effectively pass around an anonymous closure of
their own language.  Such a value object would be a black box to the host
and can't be dumped to Muldis D source code.

* IN PROGRESS ...
Fully support direct interaction with other languages, mainly either peer
Parrot-hosted languages or each host language of the Muldis D
implementation.  Expand the definition of the "reference" main type
category (or if we need to, create a 5th similarly themed main category) so
that it is home to all foreign-managed values, which to Muldis D are simply
black boxes that Muldis D can pass around routines, store in transient
variables, and use as attributes of tuples or relations.  These
of course can not be stored in a Muldis D depot/database, but they can be
kept in transiant values of Muldis D collection types which are held in
lexical variables by the peer or host language; that language is then
really just using Muldis D as a library of relational functions to organize
and transform its own data.  We also need to add a top level namespace by
which we can reference or invoke the opaque-to-us data types and routines
of the peer or host language.  This can not go under sys.imp or
sys.anything because these are supposed to represent user-defined types and
routines, which in a dynamic peer language can appear or disappear or
change at a moment's notice, same as in Muldis D; on the other hand, types
or routines built-in to the peer/host language that we can assume are as
static as sys.std, could go under sys.imp or something.  This also doesn't
go under fed etc since fed is reserved for data under Muldis D control and
only ever contains pure s/t/r types.  Presumably this namespace will be
subdivided by language analogously to sys.imp or whatever syntax Perl 6
provides for calling out into foreign languages co-hosted on Parrot.  Since
all foreign values are treated as black boxes by Muldis D, it is assumed
that the Muldis D implementation's bindings to the peer/host language will
be providing something akin to a simple pointer value, and that it would
provide the means to know what foreign values are mutually distinct or
implement is_identical for them.  One thing for certain is that every
foreign value is disjoint from every Muldis D value, and by default every
foreign value is mutually distinct from every other foreign too, unless
identity is overloaded by the foreign, like how Perl 6's .WHICH works.
The foreign-access namespace may have a simple catalog variable
representing what types and routines it is exposing, but to Muldis D this
would be we_may_update=false.

* IN PROGRESS ...
About External type ... update Perl5_STD and
Perl6_STD to add a new selector node kind 'External' which takes any Perl
value or object as its payload; this is treated completely as a black box
in general within the Muldis D implementation.  For matters of identity
within the Muldis D envirnment, it works as follows:  Under Perl 6, the
Perl value's .WHICH result determines its identity.  Under Perl 5, if the
value is a Perl ref ('ref $obj' returns true) then its memory address is
used, and this applies to all objects also (since all refs are mutable,
this seems to be the safest bet); otherwise ('ref $obj' is false) then the
value's result in a string context, "$obj", is used as the identity; the
mem addr and stringification would both be prefixed with some constant to
distinguish the 2 that might stringify the same.  By default, an
External supports no operators but is/not_identical.

----------

* Add new "FTS" or "FullTextSearch" extension which provides weighted
indexed searching of large Text values in terms of their component tokens,
such as what would be considered "words" in human terms.  This is what
would map to the full text search capabilities that underlying SQL DBMSs
may provide, if they are sufficiently similar to each other, or there might
be distinct FTS extensions for significantly different ones?

* Add new "Perl5Regex" extension which provides full use of the Perl 5
regular expression engine for pattern matching and transliteration of Text
values.  Maybe the PCRE library can implement this on other foundations
than Perl 5 itself if they are sufficiently alike; otherwise we can also
have a separate "PCRE" extension.  Or the same extension can provide both?

* Add new "Perl6Rules" extension which provides full use of the Perl 6
rules engine for pattern matching and transliteration of Text values.

* Add new "PGE" or "ParrotGrammarEngine" extension, or whatever an
appropriate replacement is, for pattern matching and transliteration of
Text values.  This and "Perl6Rules" may or may not be sufficiently similar
to combine into one extension.

* Add functions for splitting strings on delimiters or catenating them with
such to above extensions or to Text.pod as appropriate.

* Update or supplement the order-determination function for Text so that it
compares whole graphemes (1 grapheme = sequence starting with a base
codepoint plus N combining codepoints, or something) as single string
elements, rather than say comparing a base char against a combining char.

* Add new "Complex" extension which provides the numeric "complex" data
types (each expressed as a pair of real numbers with at least 2 possreps
like cartesian vs polar) and operators.  Note that the SQL standard does
not have such data types but both many general languages as well some
hardware CPUs natively support them.  Probably make "Complex" a mixin type
and have the likes of "RatComplex" and "IntComplex" composing it.  Note
that a complex number over just integers is also called a Gaussian integer.
A question to ask is whether a distinct "imaginary" type is useful; some
may say it is and Digital Mars' "D" has it, but I don't know if others do.
In any event, complex numerics should most likely not be part of the core,
even though their candidacy could be considered borderline; for one thing,
I would expect that most actual uses of them would work with inexact math.

* Add other mathematical extensions, such as ones that add trigonometric
functions et al, or ones that deal with hyperreal/hypercomplex/etc types,
or ones with variants of the core numeric types that propagate NaNs etc.

* 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.

* Add multiplication and division operators to the Duration types; these
would both be dyadic ops where the second op is a Numeric.

* Consider changing the default values of the Instant and Duration mixins
to those of the UTC subtypes (or something) rather than the TAI subtypes.

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

* Consider adding a Temporal.pod type specific to representing a period in
time, maybe simply as an alias for 'interval_of.*Instant' or some such.
See also the PGTemporal project and its 'Period' type.

* Flesh out "Spatial" extension; provide operators for the spatial data
types, maybe overhaul the types.

----------

* Add one or more files to the distro that are straight PTMD_STD code like
for defining a whole depot (as per the above) but instead these files
define all the system entities.  Or more specifically they define just the
interfaces/heads of all the system-defined routines, and they have the
complete definitions of all system-defined types, and they declare all the
system catalog dbvars/dbcons.  In other words these files contain
everything that is in the sys.cat dbcon; anything that users can introspect
from sys.cat can also be read from these files in the form of PTMD_STD
code, more or less.  The function of these files is analogous to the Perl 6
Setting files described in the Perl 6 Synopsis 32, except that the Muldis D
analogy explicitly does not define the bodies of any built-in routines.  An
idea is that Muldis D implementations could take these files as is and
parse them to populate their sys.cat that users see; of course, the
implementations can actually implement the routines/types as they want.
Note that although this Muldis D code would be bundled with the spec, it is
most likely that the PTMD_STD-written standard impl test suite will not.
Note that these files will not go in lib/ but in some other new dir.  Note
that it is likely any implementation will bundle a clone of these files
(suitably integrated as desired) rather than having an actual external
dependency on the Muldis::D distro.  Note that some explicit comment might
be necessary to say there are no licensing restrictions on copying this
builtins-interfaces-defining code into Muldis D implementations, or maybe
no comment is necessary.  Probably a good precedent is to look at what
legalities concern existing tutorial/etc books that have sample code.

* Create another distribution, maybe called Muldis::D::Validator, which
consists essentially of just a t/ directory holding a large number of files
that are straight PTMD_STD code, and that emit the TAP protocol when
executed.  The structure and purpose of this collection is essentially
identical to the official Perl 6 test suite.  A valid Muldis D
implementation could conceivably be defined as any interpreter which runs
this test suite correctly.  This new distro would be a "testing requires"
external dependency of both Muldis::Rosetta and any Parrot-hosted language
or other implementation, though conceivably either could bundle a clone of
Muldis::D::Validator rather than having an actual external dependency.
This test suite would be LGPL licensed.  This new distribution would have a
version number that is of X.Y.Z format like Muldis::D itself, where the X.Y
part always matches that of the Muldis D spec that it is testing compliance
with, while the .Z always starts at zero and increments independently of
the Muldis D spec, as often there may be multiple updates to ::Validator
for awhile between releases of the language spec, and also since .Z updates
in the language spec only indicate bug fixes and shouldn't constitute a
change to the spec from the point of view of ::Validator.

----------

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