[Dbix-class] fyi, Muldis D core AST dialect example

[Darren Duncan]

As I have probably mentioned before, the Muldis D syntax examples I 
was giving in previous emails were representative rather than actual, 
and also that it is expected that multiple Muldis D dialects will be 
in use.

FYI, following is a short Muldis D code snippit that is written in 
what is probably the least abstracted of all dialects, and would 
directly map to tuple|relation definitions that are composed into the 
actual system catalog relvars.

First, this pseudo-code illustrates what the code snippit represents:

   function square returns Int (Int topic) {
     return topic ** 2;
   }

And so here that code is (possibly having bugs) in the Perl-Hosted 
Muldis D (PHMD) format of the fundamental/core dialect of Muldis D; 
specifically, you should read this as if it were a relational tuple 
literal:

   [ 'Tuple', 'sys.Core.Cat.Func', {
     'name' => [ 'Cat.Name', 'square' ],
     'root_inner_func' => [ 'Cat.Name', '' ],
     'inner_funcs' => [ 'Relation', 'sys.Core.Cat.InnerFuncTree', [
       {
         'name' => [ 'Cat.Name', '' ],
         'result_tk' => [ 'Cat.E_TK', 'scalar' ],
         'result_type' => [ 'Cat.NameChain', 'sys.Core.Int.UInt' ],
         'is_recursive' => [ 'Bool', 'perl_any', 0 ],
         'params' => [ 'Relation', 'sys.Core.Cat.NameTypeMap', [
           {
             'name' => [ 'Cat.Name', 'topic' ],
             'type' => [ 'Cat.NameChain', 'sys.Core.Int.Int' ],
           },
         ] ],
         'root_expr' => [ 'Cat.Name', 'squared_topic' ],
         'expr' => [ 'Relation', 'sys.Core.Cat.ExprTree', [
           {
             'name' => [ 'Cat.Name', 'squared_topic' ],
             'tk' => [ 'Cat.E_TK', 'scalar' ],
             'type' => [ 'Cat.NameChain', 'sys.Core.Int.UInt' ],
             'kind' => [ 'Cat.E_ENK', 'func' ],
             'scal_lit' => [ 'Bool', 'perl_any', 0 ],
             'coll_lit' => [ 'Set', 'sys.Core.Cat.SetOfNameExprMap', [] ],
             'param' => [ 'Cat.Name', '' ],
             'func' => [ 'Cat.NameChain', 'sys.Core.Int.power' ],
             'func_args' => [ 'Relation', 'sys.Core.Cat.NameExprMap', [
               {
                 'name' => [ 'Cat.Name', 'radix' ],
                 'expr' => [ 'Cat.Name', 'arg_topic' ],
               },
               {
                 'name' => [ 'Cat.Name', 'exponent' ],
                 'expr' => [ 'Cat.Name', 'lit_2' ],
               },
             ] ],
           },
           {
             'name' => [ 'Cat.Name', 'arg_topic' ],
             'tk' => [ 'Cat.E_TK', 'scalar' ],
             'type' => [ 'Cat.NameChain', 'sys.Core.Int.Int' ],
             'kind' => [ 'Cat.E_ENK', 'param' ],
             'scal_lit' => [ 'Bool', 'perl_any', 0 ],
             'coll_lit' => [ 'Set', 'sys.Core.Cat.SetOfNameExprMap', [] ],
             'param' => [ 'Cat.Name', 'topic' ],
             'func' => [ 'Cat.NameChain', '' ],
             'func_args' => [ 'Relation', 'sys.Core.Cat.NameExprMap', [] ],
           },
           {
             'name' => [ 'Cat.Name', 'lit_2' ],
             'tk' => [ 'Cat.E_TK', 'scalar' ],
             'type' => [ 'Cat.NameChain', 'sys.Core.Int.PInt' ],
             'kind' => [ 'Cat.E_ENK', 'scalar' ],
             'scal_lit' => [ 'Int', 'perl_int', 2 ],
             'coll_lit' => [ 'Set', 'sys.Core.Cat.SetOfNameExprMap', [] ],
             'param' => [ 'Cat.Name', '' ],
             'func' => [ 'Cat.NameChain', '' ],
             'func_args' => [ 'Relation', 'sys.Core.Cat.NameExprMap', [] ],
           },
         ] ],
       },
     ] ],
   } ]

All the detail info necessary to compose the above is in the 2 files 
Core.pod and PerlHosted.pod of the Muldis D spec.

Possible bugs aside, that is what you would feed to Muldis DB for 
Perl as the user-definition of a stored function routine named 
'square', which itself invokes the system-defined/built-in 'power' 
function; no user-defined types are used.

The tuple that the above PHMD defines would be added to the 
appropriate catalog relvar, and an implementation can then be 
generated, whether as Perl code or as SQL for some other DBMS, or 
whatever.  Although the above structure will scale to a function of 
arbitrary size and complexity, with expression trees of N levels 
deep, including quasi higher order functions, the actual node tree 
depth will never exceed the current maximum depth of 4 levels.

(Note that in the process of writing the above, I realized a few 
details that were missing in the version 0.16.0 Muldis D spec and/or 
ought to be modified, and will be in version 0.17.0, but the above is 
over 90% to the current published spec.)

Now, I'm sure the above example looks damningly verbose for code that 
one would write day to day, and indeed it is.  Which is why the above 
is only recommended as an intermediate representation, and that 
alternate Muldis D dialects (most from third parties I suppose) that 
are a lot more DWIMmy and terse should be used instead for day to day 
writing in, which are then converted to/from the above when needed by 
some translator or wrapper module.  Alternate dialects can look like 
whatever people want, even resemble Perl or Haskell or Tutorial D or 
SQL or what have you.  And alternate dialects can add any features 
they want as long as those can be translated to/from the core dialect.

Either way, hopefully the above PHMD example can give a better idea 
of why some of the language design aspects are the way they are, eg 
why parameters/arguments are always named in the core.

-- Darren Duncan