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. * Expand the catalog types for defining nonscalar types so to add short-hand syntax for foreign key constraints and distributed keys et al. * Add virtual relvars aka virtual dbvar attributes, that resemble a type constraint or something, as per scalar possrep mapping functions. * Add transition constraints. * Add other kinds of triggered routines. * Add a system-defined function that will take a function name as a normal data argument and then turns around and invokes that function. This is the fundamental function over which the generic relational restriction operator or map operator or reduce operator et al works. Note that while the needs of those functions could be addressed as special catalog node syntax rather than an actual function, we go the function route so that users can define their own operators that invoke based on data. Similarly add a system-defined procedure, which is what try_catch et al works over for calling named procedures. * Add some automatic code completion to the two Tiny dialects or as a general function, mainly so that tuples comprising catalogs don't have to be written out in full; attributes may be omitted by the coders but will be automatically added with default attribute values at parsing time, when converting Muldis D source from the Tiny dialect to the actual catalog. As far as the Muldis D catalog is concerned, the users had always written them out in full. Specific use case example is that programmers can omit 'comment' attributes, or empty sets of expression nodes that aren't used. * Take advantage of the fact that a scalar possrep looks just like a tuple. We need to add at least 6 generic sys.std.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 a new extension, perhaps ext/Patterns.pod, which does pattern-sensitive search and/or replace in Text values, including both the full feature set of SQL's LIKE operator (not just the special case of matching a static substring once), as well as full regular expression support such as grep or Perl et al support, or simple transliterations. This new extension is meant to be algorithm-agnositic and can both be plugged with new algorithms or have multiple system-defined ones, as per Perl 5.10 now supports plugins that substitute for its builtin regexp engines. * Generalize the operator set for controlled character string degrading, of which upper/lower case folding is one example, and of which removing accents or combining characters with base characters is another, and of which trimming or normalizing runs of whitespace is another. Yet another is converting data from a larger character repetoire to a smaller one eg, anything to ASCII, where we want for example range-external characters to be either deleted or changed to certain other characters. Any features-to-be like case-insensitive or accent-insensitive comparisons (over which keys or indexes could be built) needs to be done this way; you don't simply treat non-identical things as being equal; you actually change them so they are. These features are possibly useable not just with user data, but also database entity names on underlying systems that are eg not case sensitive but case preserving and we want to retain those semantics for some reason of backwards compatibility. * 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. Both functional and imperative versions. * Define short-hand data definition procedures analagous to SQL's CREATE, ALTER, DROP etc. Note that these are not short-hand for inserting records into catalogs, at least when the code doing either is an updater or procedure. Rather, these procedures are mainly for making bootloaders work, since those can not directly invoke variables such as the catalogs in order to insert into them. Probably add new file Core/Routines_Catalog.pod at the same time, to house them. * Flesh out and add system service operators like random numbers or current dates or simple generic I/O. * Overhaul the temporal data types, provide operators for them. * Likewise with spatial data types. * Whatever else needs doing, such as, fixing bugs.