From darren at darrenduncan.net Tue Apr 1 23:18:25 2008 From: darren at darrenduncan.net (Darren Duncan) Date: Tue, 01 Apr 2008 23:18:25 -0700 Subject: [VPM] OSCON 2008 schedule is posted (and I'm on it for the first time) Message-ID: <47F32531.7070405@darrenduncan.net> All, For those of you who are interested in such things, today is the first day that the OSCON 2008 (Jul 21-25) registration is open, and event schedule is posted. You can see it at: http://en.oreilly.com/oscon2008/ In addition, I am pleased to announce that my proposed 45 minute talk, which introduces my Muldis D language for DBMS programming, has been accepted. This marks the first time that I'll be speaking on anything at a major conference. I have been scheduled for 17:20-18:05 on Wednesday in room D137/138. You can see it listed at: http://en.oreilly.com/oscon2008/public/schedule/presentations/Databases http://en.oreilly.com/oscon2008/public/schedule/detail/2700 http://en.oreilly.com/oscon2008/public/schedule/grid?date=2008-07-23 I also intend to do earlier (practice) runs of the talk at smaller venues, such as self-local interest groups. Maybe also at OSCON PostgreSQL Day on Jul 20 ( http://pugs.postgresql.org/taxonomy/term/53 ) if that works out; I will be in attendance anyway. So now I really have a lot of work remaining to do in preparation for that. -- Darren Duncan From darren at darrenduncan.net Mon Apr 28 23:01:04 2008 From: darren at darrenduncan.net (Darren Duncan) Date: Mon, 28 Apr 2008 23:01:04 -0700 Subject: [VPM] ANNOUNCE - Muldis D v0.27.0 released Message-ID: <4816B9A0.10808@darrenduncan.net> 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