Re: [kiama] rules formats and java interop

Dear Tony and Randall,
Many thanks for the detailed responses. i've been thinking about the issue and there's a diagram-chasing solution that has some promise. It turns out that e.e d3si9n is reviving the schema2src component of scala xml. This allows the following chain
EBNF Grammar -BNFC-> DTD -Trang-> XSD -schema2src-> Scala case classes -> Kiama rules format
There are lots of other nice offshoots from this, including interoperation with SOAP and LINQ-like storage solutions. So, i'm going to put effort into supporting this rather than a POJOrative solution.
Best wishes,
--greg

On Thu, Feb 4, 2010 at 4:34 PM, Tony Sloane <inkytonik@gmail.com> wrote:

On 05/02/2010, at 4:19 AM, Randall R Schulz wrote:

> On Wednesday February 3 2010, leithaus wrote:
>> ...
>>
>> Currently, it doesn't target Scala, specifically -- which should be
>> okay, because Scala interops with Java... And that's where i think i
>> run into a problem with using Kiama directly with the abstract syntax
>> i generate. i surmise (and i could be wrong) that the rule formats
>> require Scala case classes and will not work with Java classes (which
>> are effectively POJOs).
>
> Kiama's Rewriter works with any ProductN for which the concrete class's
> first constructor (from productClass.getConstructors()) will accept the
> N (transformed) arguments resulting from rewriting the class's
> constituents. (If that's clear.)
>
> I modified Kiama's Rewrite to allow an alternative, which is to allow
> decomposition and reconstitution of any instance that implements a new
> trait called "Constructable" whose members are "deconstruct" which
> produces an IndexedSeq of constituents / children and reconstruct which
> takes the original instance (the one to which deconstruct was applied)
> and an arbitrary array of transformed constituents (not necessarily of
> the same types or even the same arity as the original's) and build the
> transformed result (which need not be of the same type as the
> original). In addition to these flexibilities, this scheme avoids the
> use of reflection to find the (re-)constructor.
>
> Tony has reviewed this but chose not incorporate it into Kiama. He is
> working on breaking out of the ProductN restriction currently in place.
> I believe he also wants to acommodate XML transformations, which are
> not currently supported.

Yes, that's right.  We intend to leave the Product support there since
it provides an easy way to retrofit non-case classes (but tedious, I
agree).  This issue is the relevant one:

http://code.google.com/p/kiama/issues/detail?id=31

cheers,
Tony

--
You received this message because you are subscribed to the Google Groups "kiama" group.
To post to this group, send email to kiama@googlegroups.com.
To unsubscribe from this group, send email to 2Bunsubscribe [at] googlegroups [dot] com" rel="nofollow">kiama+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kiama?hl=en.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com