Richard Robinson wrote:

On Sun, Apr 25, 2004 at 09:41:27PM +0100, Neil Jennings wrote:


Rubbish. To be useful, the parser should be a procedure with an API which
can be called from a standard
executable program. If you produce an acsii file, you have just replaced one
problem with another.



Well; if someone wants to wrap the parser with something to produce XML-ish output, that's not a problem. So long as the parser API is clear, and properly separated from the output-generating code.



I had more pictured a Java-esq api than a parser that writes out something that would itself have to be parsed...

I call a function in the parser with some bit of abc, and depending on what I asked it to do (which function I called), it returns some 'expected' output. At the same time, there would be methods I could call on the object, and in an exception handler to see if there were additional useful bits of information, or errors that I can choose to ignore, or try to make some use of.

For this reason, multi threading would be a must, and having the parser not exit after each query (like someone was suggesting with a STDIN=>STDOUT command line program). It would need to stay loaded with the state of the last query (or possibly every query until a command to end the session (and dump the state)) available for reference.

For instance, perhaps I want to ram a bit of ABC through the parser in my program and display the output errors and all. It would be enough that the parsed information was returned for me to display, and a simple error flag. If I don't want to tell the end user that there's x, x, and x wrong with their abc, then there's no reason for the added overhead of the parser sending that information back to me to dump or display. Perhaps I could do something like Phil's Smiley face in in BarFly in my software to let the user know that the error flag was returned... Then if the user commands the program to tell them what the parser was unhappy with, my program can then query the errors from the last session and my program can display that information.

--

 //Christian

Christian Marcus Cepel            | And the wrens have returned &
[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
371 Crown Point, Columbia, MO     | that oak where his heart once
65203-2202 573.999.2370           | had been; And he lifts up his
Computer Support Specialist, Sr.  | arms in a blessing; For being
University of Missouri - Columbia | born again.    --Rich Mullins

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to