From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBN3Zc0a026268 for ; Fri, 23 Dec 2011 04:35:38 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAHf1807RVda2imdsb2JhbABDhQ+nGwgiAQEBCgkNBxIGIYFyAQEBAwESAg8dARsdAQMBCwYFBAcNKgICIgERAQUBHAYTIodYmjwKix1IgmuEaz+IcQIFC4pugRYEiDeMSo17PYQa X-IronPort-AV: E=Sophos;i="4.71,396,1320620400"; d="scan'208";a="124390720" Received: from mail-tul01m020-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Dec 2011 04:35:32 +0100 Received: by obbwd18 with SMTP id wd18so8424474obb.27 for ; Thu, 22 Dec 2011 19:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8dqVn58aLn0IaRosMuxyZCXs7vfElT24uJcDjnb99E8=; b=EAZttEcHL66/ski+1Bp+6VVJPp01kWg4d8BNEghVRIITfVLpZn/Y4PgCzxYGgrNl/K LX6P6PyajsHLjNbmabvvo3NFfk8Z1cttb40ayfUrYaBjmklFVYO5D2ZhAIF/e/e1piI9 V3kQl6qpBrQy1r/uZ+iT+5g/n29rQOXMT59Qc= Received: by 10.182.2.136 with SMTP id 8mr11220271obu.71.1324611331656; Thu, 22 Dec 2011 19:35:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.46.196 with HTTP; Thu, 22 Dec 2011 19:35:10 -0800 (PST) In-Reply-To: <20111223001358.GA12304@siouxsie> References: <20111222183914.GA6185@siouxsie> <4EF38AD4.10608@glondu.net> <20111222213956.GA8513@siouxsie> <4EF3B0BD.7040900@glondu.net> <20111223001358.GA12304@siouxsie> From: Abdallah Saffidine Date: Thu, 22 Dec 2011 20:35:10 -0700 Message-ID: To: oliver Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=f46d04451863e38db104b4ba1b4d X-Validation-by: abdallah.saffidine@gmail.com Subject: Re: [Caml-list] Fatal error: exception Pcre.Error(0) --f46d04451863e38db104b4ba1b4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2011/12/22 oliver > On Thu, Dec 22, 2011 at 11:35:41PM +0100, St=C3=A9phane Glondu wrote: > > Le 22/12/2011 22:39, oliver a =C3=A9crit : > > >>> 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 =3D > > > | 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 --f46d04451863e38db104b4ba1b4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2011/12/22 oliver <= oliver@first.in-berlin.de&= gt;
On Thu, Dec 22, 2011 at 11:35:41PM +0100, St=C3=A9phane G= londu wrote:
> Le 22/12/2011 22:39, oliver a =C3=A9crit :
> >>> where is there a documentation about these kind of errors= from pcre-lib?
> >>> I'm using Pcre.pmatch, which should just give me a bo= ol.
> >>
> >> See pcre.mli. Pcre.Error(0) is the raw representation of Part= ial (i.e.
> >> string only matched the pattern partially).
> > [...]
> >
> > In my pcre.mli this error is not mentioned.
> >
> > There is a
> >
> >
> > type error =3D
> > =C2=A0 | Partial =C2=A0(** String only matched the pattern partia= lly *)
> =C2=A0 =C2=A0 =C2=A0 ^^^^^^^
>
> 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 interna= l representation of an algebraic data type constructor without body like Pa= rtial, BadPartial, Nil, Empty etc. is the same as that of an int, the speci= fic int corresponding to the constructor depends on the position of the con= structor 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 regar= d to types, so there is no need to keep type information at runtime. Keepin= g 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 t= ime 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. Fo= r the types on the other hand, the situation is easier and checks can be ma= de at compile time, so there is no need for runtime type information.

Ciao,

Abdallah
--f46d04451863e38db104b4ba1b4d--