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
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
