Dear friend,

I was actually studing your code today.
I am very happy to see that things are very clear to you.
I am ready to merge the code.

You do the parsing i will do the matching.
but before that assure me you are confident about  jjtree  parsing will do it.
let me explain you this with a simple example.

for a expression like this [CH4] or [CX2]
i have adapted fallowing logic.
           Element() [TotalHCount()|TotalConnectionAtom()] setProperty()

The element funtion will consume the element i.e C in setProperty method i do this(atom means lastatom that is consumed)

if(atom instanceof TotalHCountAtom || atom instanceof TotalConnectionAtom){
container.removeAtom(atom);
IQueryAtom Tatom = (IQueryAtom)container.getLastAtom();
container.removeAtom(Tatom);
atom.setSymbol( Tatom.getSymbol());
container.addAtom(atom);
previousAtom = atom;
}

In this way i have parsed the CH4 expression in the totalHydrogenCountAtom and set the symbol of that atom to "C".
I think this is the flxibility of javacc. You must be agree with this.
Now making the API stronger does not mean we should have 100 of classes representing the
atom of particular type.( I am justifying the use of TotalHCountAtom in this case and setting it's
sumbol is perfect design instead of having a new class. Also it is done so easily in parser)
SMARTS atom expression has 10 kind of atom and we already have those classess in
SMARTS bond expression has 6 kind we have 4 of them at present.
SMARTS operator are 6 we have 4 of then (excluding $ and .)
SMarts ( ) are not still implemented.
Also you can see how successfully i have parsed the operator atoms like
[Cl,Br,I,] or [!r6&r5] in a single function.

/////////////////////////////////////////////////////////////////////

void OperatorExpression():
{}
{
( Operator() (OperatorAtom() | ExpressionAtom()))*
AddOperatorExpression()
}
void FinalOperatorExpression():
{}
{
(OperatorAtom() | ExpressionAtom()) [OperatorExpression()]
AddFinalOperatorExpression()
}

//////////////////////////////////////////////////////////////
Can we have this much flexibility in jjtree.

If yes i am ready to fallow you.
if no you will have to fallow me.

that's a deal my friend.
what do you think?


 

 
 
 
 
 
 
 
 
 
 
 

 
On 4/25/07, Jiao, Dazhi <djiao@indiana.edu> wrote:

> 1) May be the code is parsing the smarts correctly but that does not
> mean anything unless we create the atomcontainer.
>    ( As we discuss previously)
Absolutely agree with you. In fact, I never claim my QueryAtomContainer
building is flawless. I have kept saying it's a prototype. Frankly I've
never tested it with UIT. Thanks for doing it and I am actually
surprised to see that it works for some smarts :) I'll definately take a
look at those not working.
I feel that make the parsing work is also important, since what we are
building is a smarts parser. Having a full picture of the Smarts
language and parser at the beginning could only benefit the design.
>
> 2) If this parser is also good for the simple expressions that even
> the oldest code could do then creating this code will be like
>     reinventing the wheel.
Well the wheel has been invented, I totally agree. I don't deem JJTree
is reinventing the wheel, but improving it. We could add optimization
for example. Besides, I think having the AST could be handy, and make
the process more modular. When something becomes modular, very often you
could find surprises, as proved by Object Oriented programming.
>
> 3)As jiao is running out of time with this progress in code only sure
> he will not be as active as today and progress in code
>   will stop somebody else will have to take over the code,which will
> be more difficult for cdk because understanding this design is not
>   that way easy for people already having their half hard disk full of
> chemistry.
>   (as javacc is design is easy to understand any body can easily learn
> and start coding)
>   (like for this query
> [$(c:cCl),$(c:c:cCl),$(c:c:c:cCl)]-[$(c:cCl),$(c:c:cCl),$(c:c:c:cCl)]
> present parser will say this is not valid smart
>   encounter $ so programmer will understand he has to write a simple
> expression like <$> atomExpression() and parse this kind of
>   SMARTS and create atom container as soon as a token is encounter.)
Thanks for speaking for me. That is not my plan though ;) This week is
the final week at my university. It only means I could be more active in
the future. Anyway, we are working on an open source project. I believe
all of us have to adjust our efforts according to our schedules.
For the recursive smarts, if you look at JJTree, you would see that
anybody could understand JavaCC and Tree structure can understand JJTree
very easily.
As to those Recursive parsing, JJTree parses it, but put in the log
message that these can't be processed. We need to improve the API to
handle recursive smarts, as mentioned before.
>
> 4) Adapting this design is not permanent solution and also not easy
> for other developer to adapt and code and contribute.
>    (And we have to remember we need other developer to contribute
> because it is not possible for one to make a full substructure
>     search and solution like jjtree will always tempting the admin to
> adapt something that will complete it quickly.)
On the contrary, I feel it could make collaboration smoother for all of
us. People don't need to go into JavaCC to edit java code. So we can use
Eclipse full functionality when writing Java code.
> 5) But as our friend has worked on it we have to give a justification
> to his effort.
Thanks. But I don't want anybody to feel obliged to justify my effort. I
just want to have some fun and contribute to the best open source
project in chem(o)informatics :)

Best regards,

David





--
********************************
sushil ronghe
Center of Pharmacoinformatics
India
*********************************