[Dbix-class] ANNOUNCE - Muldis D v0.27.0 released

[Darren Duncan]

All,

I am pleased to announce the release of Muldis D official/unembraced 
version 0.27.0 on CPAN.  You can see it now, with nicely HTMLized 
documentation, at:

   http://search.cpan.org/dist/Muldis-D/

--------

Also, the reference implementation of Muldis D is now named Muldis Rosetta, 
not Muldis DB, and it is currently at CPAN version 0.7.0; but you can 
ignore that for now as it doesn't do anything yet; it will be updated to 
work within a few weeks probably.

But today's email is all about the Muldis D language spec itself.

--------

The Muldis D language spec had a large number of improvements and changes 
since my last announcement email about version 0.15.0 on Dec 31st, and I 
will summarize some of the important ones below:

1.  Split up the Core.pod file, which had most of the system defined types 
and routine definitions, into about 13 files, where 4 are named 
lib/Muldis/D/Core/*.pod and 9 are named lib/Muldis/D/Ext/*.pod.  So the 
collection of core entities has been reduced to a reasonable minimum, one 
that is relatively easy to implement/manage, while still being a superset 
of what is needed to satisfy "The Third Manifesto", meaning a complete 
truly relational DBMS (and meets an ORDBMS definition also).  The core 
includes the scalar types [boolean, integer, text, blob], plus tuple and 
relation and database constructors, plus a full system catalog by which 
users can define arbitrarily complex types and routines (well, type 
constructors are still missing, but they would be in the core), plus a 
standard complement of boolean and relational algebra operators, plus the 
equality test and assignment ops for all types, and store/retrieve ops. 
The collection of extension entities includes the scalar types 
[rational/float, temporals, spatials], plus their operators, plus most of 
the standard operators for [integer, text, blob], plus generic ordinal 
operators, plus more collection operators, plus (to come) pattern matching 
/ replacing operators.  Essentially we've moved out of the core whatever we 
could without it getting stupid.  And the docs should be much easier to read.

2.  The actual Muldis D standard grammars/dialects have been further 
formalized and fleshed out, as well as renamed into 
lib/Muldis/D/Dialect/*.pod.  There are currently 2 standard dialects, whose 
names are "PTMD_Tiny" (Tiny Plain Text Muldis D) and "HDMD_Perl_Tiny" (Tiny 
Perl Hosted Data Muldis D).  They are named Tiny because their grammars are 
very simple and so a parser grammar capable of handling them could be tiny; 
in fact, PTMD_Tiny includes an actual grammar as Perl 6
rules which is less than 7K in size.  Note that Muldis D is a homoiconic 
language (one of its most important features in fact), so the fundamental 
way to write Muldis D code is to write Muldis D data, and you compile that 
code by assigning said data to catalog dbvars, a process analogous to 
inserting records into the INFORMATION_SCHEMA of SQL, as if SQL even 
allowed that.  Therefore, like Perl or Lisp or various languages, you can 
make your own language dialect as it suits you, for writing your own code 
in.  The standard language comes with the two Tiny dialects, which are 
hopefully good and terse enough for many people to just use directly, so 
you can just start writing in it right away, but if people find these too 
verbose, well they are empowered for other options.  PTMD_Tiny is for 
people that want to write and run Muldis D directly like a normal Turing 
Complete programming language (which it is, though specialized for 
databases); I foresee a Parrot compiler for it some time, or a shell like 
SQL*PLUS et al.  HDMD_Perl_Tiny is for people that want to write Muldis D 
code using trees of Perl Arrays, like they do with SQL::Abstract et al, and 
this option is best when you're dynamically building database commands in 
Perl at runtime.  For static database commands (which still are 
parameterized), you can use both dialects in Perl programs.  The 2 Tiny 
dialects map to each other 1:1, more or less.  They are essentially complete.

NOTE:  ANOTHER EMAIL WILL SOON FOLLOW THIS ONE WHICH CONTAINS SOME CODE 
SAMPLES IN ACTUAL "TINY" MULDIS D CODE, AND NOT JUST PSEUDO-CODE.

3.  The standard rational numeric type and its literal syntax make it 
capable of exactly representing any rational number, in any numeric base 
and in any magnitude (limited only by system memory or resource limiters or 
subtype constraints).  Like the standard integers, these are "big".  This 
rational type also includes the functionality of floating-point types but 
that all digits are significant.  All Muldis D numerics are also 
radix-independent, so base 2 or base 10 or base N you don't lose accuracy 
anywhere except when you explicitly choose to.  Note that the standard 
numerics don't include special values like infinities or NaNs, but some 
extension could provide those.  And Complex et al doesn't exist yet.

4.  Although Muldis D explicitly is 2-valued-logic (true|false only) and 
not N-valued-logic (true|false|missing|inapplicable|...), the collection 
types Maybe|Nothing|Single and their special syntax let you design your 
database and code as if a 3+VL NULL actually existed.  To explain, the 
Muldis D analogy of a SQL nullable value is a set value that can contain 
either zero or one element; if the set is empty, the value is NULL, if it 
has an element, the value is NOT NULL, and the set's element is the value; 
in contrast, the Muldis D analogy of a SQL not-nullable value is simply the 
value that was the non-empty set element, but without having to be wrapped 
up in a set.  So Maybe is a set with 0 or 1 element, Nothing is a set with 
no elements, and Single is a set with 1 element; the latter 2 are 
complementary subtypes of the first.

5.  Formalized the process for naming versions of the Muldis D language 
spec (and formatting those names), taking into account multiple authorities 
and dialects et al, like Perl 6 long package names but somewhat different. 
  See the VERSIONING pod section in D.pm for that.  Any Muldis D code 
should begin with a statement stating explicitly what 
authority+version+dialect it is, so to prevent ambiguity by machine or 
human readers.  This is analogous to the "use 5.008" et al that Perl files 
often start with.  The main purpose of this is to future-proof Muldis D 
code, so that either I or others can be free to modify the language in 
backwards-incompatible ways, but interpreters for the new versions can 
still work without ambiguity problems with code in older versions if they 
so choose.  Also a good guard against the consequences of "embrace and 
extend and extinguish" by third parties.

6.  Overhauled the namespace hierarchy for in-DBMS entities.  So standard 
language types and routines are in the sys.std.* namespace (note that most 
the docs on builtins don't reflect the 'std' parts yet, but will), while 
implementation-specific extensions are in the sys.imp.* namespace, the 
latter being further subdivided by authority.  This feature permits the 
standard designer to add or rename things without worrying about stepping 
on some implementers add-ons, and different implementers likewise with each 
other.  Also the system catalog is no longer under cat.*, but is rather 
split up and located by what it describes, such as at sys.cat 
(system-defined entities), fed.cat (details of all connected 
depots|databases), dep.cat (details of context-current depot|database), 
sdp.cat (details of context-current subdepot|schema), pkg.cat (details of 
context-current package, like an Oracle package).  Similarly, the 
context-local types and routines are under eg dep.lib, and the user's data 
relvars|tables under eg dep.data.

7.  The system catalog, and Tiny dialects, now can capture and store code 
comments along with the code itself.  So translating code from one dialect 
to another, or to/from SQL, can carry across the code comments.  This 
feature, storing comments as normal AST elements, is also part of the 
FoxPro language as I recall, though I don't know if any other languages do 
it; SQL only accomplishes that because it stores SQL routines as source 
code text, not the same thing as we do.

8.  Rewrote the catalogs / catalog types for defining routines (functions, 
updaters, procedures), and added catalog types for defining whole depots, 
packages, namespaces, etc.  Still to do, rewrite/add ability to define new 
types (next release I hope), and by extension, database relvars|tables and 
constraints.

9.  Added bushels more relational and other operators.

10.  Added notice that the word MULDIS is a trademark of mine (invented by 
me as a contraction of MULTIVERSE OF DISCOURSE, that specific term also 
invented by me), and also that I offer commercial support et al 
specifically by way of the business Muldis Data Systems.

See the "Changes" file ( 
http://search.cpan.org/src/DUNCAND/Muldis-D-0.27.0/Changes ) for more 
details of what changed for the last several releases.

--------

Still to do:

1.  Overhaul and expand the catalog types for defining data types, whole 
database constraints, views, triggers, etc.  This one in a few days hopefully.

2.  Overhaul and expand 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).

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

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

5.  Add operators for pattern matching, search/replace etc, eg both regular 
expressions and SQL's "LIKE" (not just "is substring" that already exists).

6.  Overhaul date and time types, add operators for them.

--------

Thank you. -- Darren Duncan