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
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
