Re: [Caml-list] Fatal error: exception Pcre.Error(0)

[Abdallah Saffidine <abdallah.saffidine@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]

2011/12/22 oliver <oliver@first.in-berlin.de>

> On Thu, Dec 22, 2011 at 11:35:41PM +0100, Stéphane Glondu wrote:
> > Le 22/12/2011 22:39, oliver a écrit :
> > >>> where is there a documentation about these kind of errors from
> pcre-lib?
> > >>> I'm using Pcre.pmatch, which should just give me a bool.
> > >>
> > >> See pcre.mli. Pcre.Error(0) is the raw representation of Partial (i.e.
> > >> string only matched the pattern partially).
> > > [...]
> > >
> > > In my pcre.mli this error is not mentioned.
> > >
> > > There is a
> > >
> > >
> > > type error =
> > >   | Partial  (** String only matched the pattern partially *)
> >       ^^^^^^^
> >
> > There.
> >
> > > Which also mentioned a partial-match error.
> > > But Pcre.Error(0) looks somehow cryptical
> > > and strange to me.
> >
> > Pcre.Error(0) is cryptical but not strange: it is the same as
> > Pcre.Error(Pcre.Partial). Whatever gives you the error message
> > mentioning Pcre.Error(0) does not have access to type information, so it
> > cannot give you more than Pcre.Error(0). You didn't tell where the error
> > message came from.
>
>
> So, (0) stands for the first entry in the list I assume.
> BadPartial-exception then would be Pcre.Error(1). ?
>
> That there is only returned an int, instead of the type information,
> where does that come from?
> Why is that not available?
> Does it coming from working together with the *.c stuff?
>

In OCaml no type information is preserved at runtime and the internal
representation of an algebraic data type constructor without body like
Partial, BadPartial, Nil, Empty etc. is the same as that of an int, the
specific int corresponding to the constructor depends on the position of
the constructor in the type declaration as you guessed.

The reason for lack of runtime type information is that the typechecker
ensures at compile time that you're program is well behaved with regard to
types, so there is no need to keep type information at runtime. Keeping
type information at runtime would result in a higher memory footprint and
as a result possibly worse performance.

Another way to look at it is : if it was possible to check at compile time
that all array access are within bounds, then you would not need costly
runtime checks (or risking segfaults), but this is a very hard problem. For
the types on the other hand, the situation is easier and checks can be made
at compile time, so there is no need for runtime type information.

Ciao,

Abdallah

[-- Attachment #2: Type: text/html, Size: 3073 bytes --]