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
_______________________________________________
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]
