[VPM] ANNOUNCE - Muldis D v0.27.0 released
darren at darrenduncan.net
Mon Apr 28 23:01:04 PDT 2008
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
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
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
More information about the Victoria-pm