[Dbix-class] ANNOUNCE - Language::MuldisD v0.15.0 released

[Darren Duncan]

All,

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

   http://search.cpan.org/dist/Language-MuldisD/

--------

All the important changes since release 0.14.0 were in the file Core.pod:

1.  Added a heap of catalog data types, and updated a few existing 
ones, with the result that it is now possible to specify user-defined 
routines.  To summarize, there are 3 kinds of user-defined routines, 
which are: functions, multi-update operators, and procedures.

A function is pure functional, having zero or more read-only 
parameters and resulting in a value; it has zero side-effects; it can 
not see global variables.  It is comprised entirely by a single 
value-expression, which is allowed to be self-referential/recursive. 
Higher-order functions are also supported, which can be passed as 
arguments and be defined in-line in other functions (in fact, some 
built-ins depend on this).  A function is implicitly atomic, and 
implicitly auto-parallelizable for higher performance.  A function 
may only invoke functions, not other routine types.

A multi-update operator is like a glorified assignment operator, that 
can update 1..N target variables or pseudo|virtual-variables at once. 
It has 1..N subject-to-update parameters and 0..N read-only 
parameters.  The collection of updates in a multi-update are 
implicitly atomic, and these updates conceptually happen 
concurrently.  A multi-update operator consists of a single statement 
which updates its own subject-to-update parameters, and it otherwise 
consists of value-expressions as per a function.  A multi-update 
operator has zero side-effects save for those that are a consequence 
of updating its parameters; it can not see global variables.  A 
multi-update operator may only invoke its own kind and functions. 
Whole database constraints are immediate, and will apply between 
boundaries of multi-update-operator invocations, essentially being 
part of the invocation it follows.

Note that a virtual variable (generalization of a SQL "view") is 
essentially an abstraction over a function when reading from it, and 
over an update operator when writing to it.  Often the latter is 
implied by the former, assuming the DBMS is smart enough to invert 
the function (automatically updateable view), or you can write the 
update operator explicitly to help it along if necessary.

A procedure is imperative, consisting of a sequence of 0..N 
statements that conceptually execute in sequence, one at a time.  A 
procedure is the only kind of routine that has (non-parameter) 
variables, and it is the only kind that can see global variables.  A 
procedure may invoke any kind of routine.  A procedure is not 
implicitly atomic, and each of its statements will auto-commit on 
success.  You use explicit lexical-scoped transactions when you want 
a sequence of actions courser-grained than an update operator call to 
be atomic, and explicit transactions can be nested.

All routine kinds have named arguments only.  Where applicable, 
routine definitions can be / are nested within other routine 
definitions, which is helpful for refactoring what is conceptually 
one routine.  Generally speaking, when using a database, your main 
program always invokes a Muldis D procedure first (since only that 
can actually reference the global/database), and that in turn invokes 
multi-update/functional inner routines or routines of itself, where 
most of your actual code likely is.  Functions are never invoked 
directly by procedures, but only indirectly by way of update 
operators.

While functions and update operators don't have actual variables, 
they do have named expression nodes, analagous to "with" clauses in 
SQL and other languages, and in fact their use is mandatory due to a 
language design decision (the abstract syntax tree is actually fixed 
depth rather than N-depth, even if it is conceptually the latter), so 
it is very easy to reuse an expression result in multiple places, and 
so visually it is like you were using variables, but you aren't 
really any more than you use them in a functional langauge, and this 
makes lots of Muldis D code easy to auto-parallelize or otherwise 
optimize.

Note as far as concurrency issues go, the database state should 
always implicitly be consistent during the execution of a 
multi-update operator (or function), but when there are multiple 
concurrent processes updating a database, any that commit 
successfully will have their changes visible to other processes as 
soon as the latter's current multi-update statement has finished. 
This is assuming no explicit locks are used to keep others off our 
lawn for a longer period.  Put another way, Muldis D has serializable 
isolation within update operators and functions, but read-committed 
(?) isolation within procedures in general.  Note that everything I 
just said in this paragraph is more of a brainstorm and is subject to 
revision.  In fact, a lot of these details may be 
implementation-dependent for awhile, and not something I concern 
myself with too closely, except that isolation should be serializable 
in the general case.

Here is a list of basically all the catalog data types used 
specifically to define routines, and 80-90% of them are new as of 
this release.

Scalar types:

     sys.Core.Cat.E_ENK
     sys.Core.Cat.E_PSAK

Tuple types:

     sys.Core.Cat.ExprNode
     sys.Core.Cat.InnerFunc
     sys.Core.Cat.Func
     sys.Core.Cat.UpdateStmt
     sys.Core.Cat.InnerUpdateOper
     sys.Core.Cat.UpdateOper
     sys.Core.Cat.ProcStmtArg
     sys.Core.Cat.ProcStmt
     sys.Core.Cat.InnerProc
     sys.Core.Cat.Proc

Relation types:

     sys.Core.Cat.NameTypeMap
     sys.Core.Cat.NameExprMap
     sys.Core.Cat.ExprSet
     sys.Core.Cat.ExprTree
     sys.Core.Cat.InnerFuncSet
     sys.Core.Cat.InnerFuncTree
     sys.Core.Cat.MultiUpdateStmt
     sys.Core.Cat.InnerUpdateOperSet
     sys.Core.Cat.InnerUpdateOperTree
     sys.Core.Cat.ProcStmtArgSet
     sys.Core.Cat.InnerProcTree
     sys.Core.Cat.SetOfNameExprMap
     sys.Core.Cat.SetOfNameChain
     sys.Core.Cat.SeqOfProcStmt

2.  Added a bunch of (ordered) sequence-specific operators.

3.  Added generic 'reduce' functions, so now you too can easily make 
N-ary user-defined functions, such as group-by or aggregators.

See the "Changes" file ( 
http://search.cpan.org/src/DUNCAND/Language-MuldisD-0.15.0/Changes ) 
for more details of what changed for this release.

--------

Still to do:

1.  Overhaul and expand the catalog types for defining data types.

2.  Add catalog types for defining whole schemas, whole database 
constraints, views, triggers, etc.

3.  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).

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

4.  Define short-hand data definition operators analagous to CREATE, 
ALTER, DROP etc.

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

--------

Thank you. -- Darren Duncan