[Dbix-class] fyi, official terse Muldis D dialect for daily work

Darren Duncan darren at DarrenDuncan.net
Mon Jan 14 08:55:31 GMT 2008


Matt, thanks for your feedback.

At 7:49 AM +0000 1/14/08, Matt S Trout wrote:
>On Sun, Jan 13, 2008 at 06:40:21PM -0800, Darren Duncan wrote:
>>  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 ],
>>                  } ],
>>              },
>>          } ],
>>      ] ]
>
>Uint function square (Int topic) {
>   Int.power (topic, Int 2);
>}
>
>That's terse. Yours is not. So far as I can tell mine is pretty much
>equivalent.

Yes, you are right, the examples seem equivalent and yours is much more terse.

Mine was intended more to be terse in comparison to abstract syntax 
trees composed from basic Perl collection types that have a fairly 
simple grammar and can handle arbitrarily complex expressions.  I'm 
sure you'd agree, though larger than yours, my code size here is 
about 1/10 of my previous example's size.

As per SQL::Abstract's inputs et al, the AST I describe is intended 
to be targeted by data-driven et al code generators such as 
DBIx::Class' internals, as well as be easy enough to reverse 
engineer, since user code doesn't have to stitch or escape strings, 
or parse or unescape them.

>  With a bit of perl optree parsing (and Devel::Declare) you
>could perl-host this as
>
>Uint function square (Int $topic) {
>   Int->power($topic, Int 2);
>};
>
>which isn't quite as elegant but is definitely parseable :)
>
>Food for thought, anyway.

This is all a good idea, and something the likes of which I would like to see.

See also DBIx::Perlish by Anton Berezin, well worth a look.

Something that lets users essentially just write Perl code, though 
with extra metadata tags if necessary, and then parses that into a 
Muldis D AST.

Such would be the ultimate in cross-language connectivity for Perl 5.

However, I personally lack the tuits to do something like that, and 
prefer to just focus with starting with an AST and working from there 
towards the database end of things.

If anyone else has the tuits to make such Perl integration 
extensions, then please do and I'll give you what support I can.

Thank you. -- Darren Duncan



More information about the DBIx-Class mailing list