[HAPI-devel] RE: RE: new feature (making the PipeParser able to r ecover from errors)

[Guevara, A. <Ale...@uh...>]

        in green now, I guess I'm in a sort of ecological  mood today =
...
=20
          and I=92d like to emphasize that this is a core feature of =
all
parsers, error recovery. =20

My understanding of error recovery in language parsers is that they =
only
exist so that additional errors can be correctly identified (e.g. so =
you can
produce a whole list of compile errors rather than just one).  Correct =
me if
I'm wrong about this.  What you are proposing allows passing erroneous =
input
by changing it in some way.  To me this seems analogous to a Java =
parser
that finds !+ and decides what was probably meant was !=3D, and then =
compiles,
setting a flag somewhere that the code was changed.  That's the part I =
was
objecting to anyway -- if I've misunderstood please let me know.  =20

=20

In the long term, error recovery would be great, but I think it should =
only
be used to create a complete list of problems that can be returned to =
the
sending system in the rejection message.=20

=20

In the short term, I agree that we do need a way to work around the =
problem
you identified, and your proposal will certainly do it.     =20

=20

    that is definitely the way error recovery is implemented in most
parsers, in this case we have particular situation. One that is very =
similar
to the one happening in eclipse, they have an incremental =
parser/compiler,
meaning that even when there are errors in some methods in a class, the
parser/compiler will still parse the whole source file and will =
generate
bytecodes for whichever methods are correct. In the case of HAPI, we =
have a
known lack of compliance with the HL7 std. by many products, and it =
will be
a real shame to stop the whole parsing process only because of one =
promitive
type was not valid ..... mmmmmmmm, actually now I see your point =
clearly,
maybe we should just let the parser continue and mark that component as
Unable To Parse (maybe we can have an impl. of Primitive specifically
created for this). Actually this was my original idea, but I guess I =
got
"too flexible" ;)

=20



 we   should include it as soon as we can, maybe right after the 0.4
release, in some sort of 0.4.1 version .. bla bla bla ;) =20

=20

Perfect, let's come back to this right after the 0.4 release.  =20

=20

sounds like the best way to go!

=20

=20

Bryan=20

=20



This e-mail may contain confidential and/or privileged information

for the sole use of the intended recipient. Any review or distribution

by anyone other than the person for whom it was originally intended is
strictly

prohibited. If you have received this e-mail in error, please contact =
the
sender and

delete all copies. Opinions, conclusions or other information contained =
in

this e-mail may not be that of the organization.



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003


HYPERLINK "http://www.mailfiler.com"MailFiler [HAPI-devel]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
=20


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact =
the
sender and
delete all copies. Opinions, conclusions or other information contained =
in
this e-mail may not be that of the organization.