Thanks for your reply! "Denver Braughler" <[EMAIL PROTECTED]> wrote in the message: news:[EMAIL PROTECTED]
> > a just-in-time compiler into COS is required for performance reasons, > > because the expressions could be evaluated in 10 million objects. > I don't know whether that reason makes it required. > If $ZF(-6,...) is faster than native COS would you still say it is required? Interesting question: I don't believe that $ZF is a solution (for the evaluation of epressions), since the expressions need to get (and store) values from objects, that would require a lot of overhad for the binding of values using some kind of interface. Also, we need cross-platform compatibility, and I couldn't say that Java or any other cross-platform technology (which uses some kind of proxy objects to access data) is really faster than COS. If you mean $ZF for the launching of the parser, please read below: > > Regarding writing the utilities in COS, I have to ask why re-invent the wheel? For deployment reasons: we should create an installer for Windows, one installer for Linux, etc, take care of what Java virtual machine (if any) is already installed (in case the utilities are written , check that it doesn't conflict, prepare documentation about it, check it a number of time (lots of time spent) and (worse) support people who have troubles installing the utilities. In the past we had some trouble for example when an installer like that failed for some reason with Citrix/Terminal server, and we probably have lost a customer for that, being able to fix it not before two weeks (a dll conflict...what else ?). I think that instead of wasting time for this, we could just spend less time to use (if already inside) or implement a native compiler...maybe I'm wrong. > > As for getting yacc to output COS, that sounds reasonable. > Have you already written a COS grammar for yacc? That's what we are starting to do...any help is greatly appreciated! Is there any grammar around ? Max
