Greetings,
I am pleased to announce that version 0.140.0 of the specification of the Muldis
D language, for object-relational databases, has been released on CPAN.
http://search.cpan.org/dist/Muldis-D/
Between this release and release 0.139.0 (not separately announced), there have
been the following main improvements since release 0.138.0:
1. In Basics.pod and Types_Catalog.pod, a consolidation of the system catalog
and associated revised conceptions of Muldis D's language structure, such that
all the system defined materials plus all non-special system-defined namespaces
are now organized in the same way as user-defined materials, which is into
"packages"; a "depot" is a pure Muldis D package loaded by the DBMS in user
space, often updateable as "the database", while a "module" is a typically
mixed-language package loaded by the DBMS readonly in system space. So "Core"
and each official or unofficial Muldis D language extension is now a named
module and it is now normal for all entities within each such system module to
reference each other in the "nlx" relative path namespace rather than "sys", and
so "sys" is now more like "fed", mainly just used to reference entities outside
the referencer's own package using an absolute path. This also means it is now
more or less official that one can define a system package using exactly the
same Muldis D dialects/syntaxes as to define user packages. (This release
didn't actually tweak the concrete syntaxes themselves, but that could be done
later, and they're still correct as is regarding depots.)
2. Muldis D no longer has the core concept of a "transition constraint", which
was an assertion on whether a variable is allowed (according to current business
rules) to transition directly from one state to another. So the routine kind
"transition-constraint", its associated syntaxes, and the catalog data type
"TransConstrFunc" were all removed. The rationale for this change is that
transition constraints would be better off as a user-definable concept (that
could also be provided as a Muldis D language extension module) which is defined
instead as a "state constraint" associated with a database schema that
explicitly stores multiple versions of data in an auditing fashion, such as
"temporal/historical databases" do. These matters may be arbitrarily complex
and seem best suited to be user-definable rather than in core. At the very
least, the previous "transition constraint" concept was flawed in significant
ways, such as that: 1. It couldn't take any other states into account other than
the immediately last and next one, where in real life what is a valid transition
can depend on multiple prior states; 2. When what looks like multiple successive
distinct transactions to one user would look like a single larger transaction to
another user due to how the MVCC or serializability etc works, what are the
consistent semantics for a constraint saying a status must go A->B->C and not
A->C?; 3. Reverting certain user mistakes could require circumventing /
temporarily disabling a direction-enforcing constraint.
3. Renamed the 2 functions "is[|_not]_identical" to "is[|_not]_same"; also
updated the first one's description to focus on mutual substitutability being
the key in considering their arguments to be "same". The term "same" is better
by being a little more abstract in its meaning and should be interpreted as any
or all of ["same", "equal", "identical", "substitutable", etc]; moreover, "same"
is better by being terser and by being more like related functions "before" and
"after_or_same" etc.
4. In PTMD_STD.pod, made nonquoted DBMS entity names subject to the
"op_char_repertoire" pragma such that the old limited-to-ASCII format of such
names is now just the case when the pragma is "basic"; now when the pragma is
"extended", such names may include any characters that Unicode considers
alphabetic or alphanumeric. Also restricted both formats of nonquoted entity
names to require each hyphen to be followed by an alphabetic character. And so,
extended names are now exactly the same as Perl 6 identifiers except for not
also allowing apostrophes.
5. In all 3 STD.pod, formally deprecated the "rtn_inv_alt_syn" catalog
abstraction level, which had mainly served to add alternate syntaxes for
function calls, so for example you could write some in infix or postcircumfix
format rather than as foo() format. This is likely to be replaced in the future
by maybe 3 abstraction levels, where the lowest adds just postcircumfix
syntaxes, the next up adds a small number of infix syntaxes that are about the
least common denominator in programming languages, and the highest adds a whole
bunch more, akin to the current deprecated level. But for that matter, pending
enhancements to the system catalogs should boost what the foo() format itself is
capable of so there would be less reliance on the higher levels; you would be
able to say "+"() for example, using prefix notation for various symbolic ops.
6. In PTMD_STD.pod, updated all the monadic postfix operators that are symbolic
so the whitespace between them and their argument is now optional. This is a
stopgap (and prefix was done previously) until more flexibility is gained in
general for whitespace around symbolic operator calls like of a typical language.
7. The absolute-value operator no longer has the additional "||" prefix op
spelling, where "|| x" means the "|x|" of math, since this could confuse people
and everything else seems to spell it "abs" instead. I did however keep the
"|-|" absolute-difference infix op where "x |-| y" means "|x-y|" of math as that
didn't seem so confusing and seems more useful. (I consider that providing
actual circumfix operators in Muldis D to be unwieldy, at least in the general
case where the inner expression could be long.)
8. In D.pod and SeeAlso.pod, now spell author personal names as "Edgar Codd
(E.F. Codd)" and "Chris Date (C.J. Date)" rather than as "Edgar F. Codd" and
"Christopher J. Date", respectively.
There were some other changes too.
Now considering that in the last couple months my release rate of Muldis D spec
or other changes has slowed, I have still accumulated quite a list of TODO
items, or brainstorming for near future enhancements, a bunch of them I fully
intend to spec out prior to moving to implementation. Some are in the TODO file
and many aren't, to keep it from growing too large. When I have more time I'll
get to specifying those. One of the first items is expected to be externalizing
most of the details of character data types from the language core, such as
everything related to Unicode, similarly to how I externalized nearly all dates
and times details, so the core is more pure and lacks such immense and
time-variant complexities.
Good day. -- Darren Duncan
_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
