[VPM] fyi, official terse Muldis D dialect for daily work

[Darren Duncan]

Note that this message is a follow-up to my 2008 January 8th post of 
subject "fyi, Muldis D core AST dialect example".

I have now started work on defining another official dialect of 
Muldis D which should be within the level of terseness of most 
typical high-level programming languages, and which is the one that 
is intended for regular use by programmers in their day to day code 
writing, or for writing code examples in.  Moreover, the Muldis DB 
Interface core API would take this new dialect natively, so even your 
wrapper modules could choose to ignore the verbose one if they want 
to.

See 
http://search.cpan.org/dist/Language-MuldisD/lib/Language/MuldisD/Hierarchical.pod 
(a new file with release 0.17.0) for what information exists on this 
new dialect so far.

That file just has a few paragraphs that outline the differences 
between that dialect, and the previous verbose Perl-Hosted Muldis D 
dialect that I previously gave an example in.  The main new features 
are introduced, and it should be apparent enough as to how they make 
the code a lot more terse, while still being easy (in fact, easier) 
to understand and self-documenting.

Here are a few bullet points abbreviated from Hierarchical.pod:

- Speaking in analogy, the new dialect's alphabet has 100 characters 
rather than the 10 of the verbose dialect, so you can express all the 
possible ideas using a smaller number of characters.

- Code is defined as trees of Perl Array|Hash, like PerlHosted.

- Literals like numbers and strings are formatted the same way as in 
PerlHosted; each is an array ref having a Perl literal payload plus 
meta-data.

- Expression trees are actually N-depth nested trees of nodes, rather 
than a flat list of named nodes (the tree isn't a fixed depth, but a 
variable depth).

- There are more kinds of AST nodes, each having fewer attributes, 
and in particular you don't have to define attributes that aren't 
used (the verbose dialect does, so to make all nodes the same shape). 
There is a node kind each for function|procedure declaration et al, 
rather than a generic Tuple node kind.

- System-defined types,routines,etc can be invoked using their 
unqualified names rather than fully qualified names, eg no 
'sys.Core.' prefix needed.

- A bunch of aliases are provided for built-in routines, including a 
full complement of the symbol-character usual suspects, like '=' for 
'is_equal' or '<' for 'is_ascending'.

- System-defined routine invocations can have positional arguments or 
named, your choice.

- Note that the name abbreviations and positional arguments option 
only apply to built-ins, not user-defined routines, since it must be 
possible to resolve these to their full or named equivalents when any 
user-defined routine is taken in isolation, and there is no 
information about earlier defined user-def to work with; also, the 
core AST only tracks params/args by name not position anyway.

I still have to work out the details of the new dialect, but here's 
an example of how Muldis D code in the terse dialect could look; 
compare this 'square' function with the other email:

     [ 'function', 'square', '', [
         [ 'inner_function', '', {
             'result_type' => 'UInt',
             'params' => {
                 'topic' => 'Int',
             },
             'root_expr' => '',
             'exprs' => {
                 '' => [ 'sys_func', 'Int.power', {
                     'radix' => [ 'param', 'topic' ],
                     'exponent' => [ 'Int', 'perl_int', 2 ],
                 } ],
             },
         } ],
     ] ]

That example did not use symbol-char aliases nor positional arg 
aliases, and is probably my preferred format; but if you want to use 
either of said options, the function could look like this instead:

     [ 'function', 'square', '', [
         [ 'inner_function', '', {
             'result_type' => 'UInt',
             'params' => {
                 'topic' => 'Int',
             },
             'root_expr' => '',
             'exprs' => {
                 '' => [ 'sys_func', 'Int.**', [
                     [ 'param', 'topic' ],
                     [ 'Int', 'perl_int', 2 ],
                 ] ],
             },
         } ],
     ] ]

Now, this may still look a bit fat, but some of that is standard 
overhead for any function definition, and for more complicated 
functions, that part wouldn't be any larger / would be proportionally 
smaller.

So fleshing out this new dialect is my current top priority in the 
language design, so hopefully the details will be published within 
1-2 weeks.

-- Darren Duncan

P.S.  In any event, those of you accustomed to Perl modules like 
SQL::Abstract should now find this Muldis D dialect a lot easier to 
translate to.  If you don't see that yet, then maybe by the next 
language spec release you will.