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 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. * 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. * 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 generic I/O routines. * 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. Also add sys.std.Core.Cat.Order_reverse function in that new file; or that function best goes elsewhere? * 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. * Consider rewriting the Temporal.pod again, as the current version still appears to have some serious issues. One problem is the combinatorial explosion of types and routines, due to desire to have a wall between different precisions. Another problem concerns interaction of plain 'time' types and time zones, such as what semantics their operators should have. * Consider providing special literal syntax in the Tiny dialects for values of temporal data types. Or don't, since many users of temporal data types would probably want to define them component-wise (using generic scalar value selectors), or want to use a different terse format than any the Tiny could pick. It's better to leave special temporal value syntax to non-Tiny dialects. Also, it reduces bias away from third-party temporal extensions. * 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. * Whatever else needs doing, such as, fixing bugs.