[Dbix-class] abstract syntax (extract from a conversation)

[Darren Duncan]

At 4:01 AM +0100 7/21/07, Matt S Trout wrote:
<snip>
>  > * 2-pass system:
>>    * DWIM AST -> explicit AST
>>    * explicit AST -> backend
>>  * lol-only AST means no key collisions, complete control over ordering
>>
>>  >>> { foo => 1 }
>>
>>  [ -statement,
>>    [ -key => 'foo' ],
>>    [ -op => 'is' ],
>>    [ -value => 1,
>>  ]
>
>   [ -op, 'is', [ -ident, 'foo' ], [ -value, \1 ] ]
>
>(values should always be a ref so we can change 'em easily later)

As a follow-up to my earlier replies to this thread.

In the next few days I'm working on rewriting / majorly updating the 
input/output explicit AST format of Perl-hosted Abstract Muldis D, in 
concert with updating the internal meta-model of the language, whose 
previous version was a tree of objects.

The new version for my Perl-hosted I/O AST will allow one to just use 
a tree of Perl array refs to spec an explicit AST rather than 
requiring construction of a tree of objects.

An objects version will still be kept, for the purpose of letting one 
cache validated user input so it doesn't have to be revalidated if 
said objects are reused in multiple places.  That is assuming that 
the object's encapsulation is respected; they are supposed to be 
immutable.

The Perl array-ref tree option is provided partly because it should 
result in a lot more brevity for users, and it also may improve 
performance.

Moreover, this is also a means by which I am meeting our more general 
purpose explicit AST half-way, so there is less changes between the 
two to account for when mapping.

Moreover, it is possible that the array-ref tree version of my AST 
may also prove to satisfy our needs for a generic explicit AST as 
well, and could just be used as is.  And just being a spec for native 
Perl structures, its not like you're using any Muldis DB code when 
you use that structure, so this wouldn't add extra external 
dependencies for you.

Perhaps what I'm really saying here is that in our discussions for an 
explicit AST, we really just want to come out with a spec for a 
native Perl AoA... and that we don't have a common code module that 
is required to implement it and that we all have as a dependency.

P.S.  As per the other side of the coin, the DWIM AST, I don't 
anticipate having too much to say about that, as the DWIM thing is 
probably more dependent on use-case scenarios and every project using 
a common explicit AST may have their own DWIM AST that fits in with 
their own differences from each other ... eg, I don't anticipate that 
DBIx::Class and Rose::DB would have the same DWIM, but they should be 
able to share an explicit.

-- Darren Duncan