From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 572C97EEBF for ; Wed, 19 Aug 2015 07:35:56 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.173 as permitted sender) identity=mailfrom; client-ip=209.85.223.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-io0-f173.google.com) identity=helo; client-ip=209.85.223.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAQCzFNRVm63fVdFdgzo1aQaDH6oqkjAKhXsCgTQHTAEBAQEBARIBAQEBAQYLCwkhLoQkAQEEAQIPEQQZARsSCwEDDAYFCwMKAgIJHQICIQEBEQEFAQoSBhMSCAiHdgEDEg2sZoEvPjGLQIFsgnmLAQoZJwMKV4UAAQEBAQYBAQEBGAEFDoEUijGCT4I7B4JpgUMFhWwMhmiIQ4UEhXyBbYFKRpBqg0+CHBIjgRcXgk6BQDwzgkwBAQE X-IPAS-Result: A0BFAQCzFNRVm63fVdFdgzo1aQaDH6oqkjAKhXsCgTQHTAEBAQEBARIBAQEBAQYLCwkhLoQkAQEEAQIPEQQZARsSCwEDDAYFCwMKAgIJHQICIQEBEQEFAQoSBhMSCAiHdgEDEg2sZoEvPjGLQIFsgnmLAQoZJwMKV4UAAQEBAQYBAQEBGAEFDoEUijGCT4I7B4JpgUMFhWwMhmiIQ4UEhXyBbYFKRpBqg0+CHBIjgRcXgk6BQDwzgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,707,1432591200"; d="scan'208";a="143113493" Received: from mail-io0-f173.google.com ([209.85.223.173]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Aug 2015 07:35:55 +0200 Received: by iodv127 with SMTP id v127so199315648iod.3 for ; Tue, 18 Aug 2015 22:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wBmetpy9Rl0DH09KLt1TMOVU3dJcLh6cWi4ieVWW9bA=; b=MfpcBci3qLErA8MmYvMZIZYSXFN1vmDQK2rOz7Uc2ze5o5599DltmlbKEBm/HYPiQJ xS8siF0JItfm63arJ7IW4AlbhphsliGXOdMTKGegk7Ih0mPCuFUXm7stjrhpAaX0oBnP vfYp2QcKoACVHGZR90SBQWwtB6E+nbtjtu7+CCnRUNbQVnNmXg//gY8DB4YTPGRYB8gh YgcowlKLTXPjFRvFOq2X3iWOJ4Z2WkMZUmEfuWnJ3ukdxZ1+a+qhwv+PshItInpV57d4 fpWi1oxd7I9XR9T51hYq4dfcHw8pqrS2V4yNbJc8SL3twQC6+8rmcIIrWU6raD+fjLst 4gyg== X-Received: by 10.107.19.94 with SMTP id b91mr9989636ioj.144.1439962553320; Tue, 18 Aug 2015 22:35:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.132 with HTTP; Tue, 18 Aug 2015 22:35:13 -0700 (PDT) In-Reply-To: References: <20150819004103.Horde.gmnxtcrVOwNtWht0UpT4DzE@webmail.in-berlin.de> <00A7715E-A042-4847-89F4-BA6F8AF20662@metastack.com> From: Gabriel Scherer Date: Wed, 19 Aug 2015 07:35:13 +0200 Message-ID: To: Arthur Wendling Cc: David Allsopp , Oliver Bandel , "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Simple exception - different behaviour between toplevel and compiled To Arthur's excellent answer, one can add that you can register user-defined exception printers to batch programs (this does not affect the toplevel): $ cat test.ml exception Foo of (int * int) let () = Printexc.register_printer (function | Foo (a, b) -> Some (Printf.sprintf "Foo (%d, %d), with best regards" a b) | _ -> None ) let v = (1, 2) let () = raise (Foo v) $ ocamlc -o test test.ml && ./test Fatal error: exception Foo (1, 2), with best regards On Wed, Aug 19, 2015 at 2:06 AM, Arthur Wendling wrote: >> exception A of int * int > > This is an exception with two arguments. > >> exception B of (int*int) > > This is an exception with a single argument, which is a product of two > values. So the parenthesis actually matters: > > # fun x -> A x ;; > Error: The constructor A expects 2 argument(s), > but is applied here to 1 argument(s) > # fun x -> B x ;; > - : int * int -> exn = > > I agree that the syntax is a bit surprising, since we are used to ignore > extra parenthesis. > > Anyway, now, regarding the output of the interpreter/compiler: > - A of int * int is printable by both, because the runtime can guess that > the two arguments are integers (because they aren't pointers.) > - B of (int * int) is only printed correctly by the interpreter, because it > keeps the source information. The compiler erases all that, so the runtime > only sees a single argument, that contains two ints, but it doesn't know how > to display it: it could be something else than a tuple from the point of > view of the user (like a record { x : int ; y : int }, but the names x,y > have been forgotten, so the runtime representation is identical to (int * > int)). > > > On Wed, Aug 19, 2015 at 1:32 AM, David Allsopp > wrote: >> >> > On 19 Aug 2015, at 00:41, Oliver Bandel >> > wrote: >> > >> > Hello, >> > >> > >> > using the attached files (executing testexc,bash) >> > I got different results between toplevel and compiled: >> > >> > ===================================================== >> > Testcase A >> > exception A of int * int >> > let _ = raise ( A(3,4) ) >> > Exception: A (3, 4). >> > Fatal error: exception Exca.A(3, 4) >> > Fatal error: exception Exca.A(3, 4) >> > Testcase B >> > exception B of (int*int) >> > let _ = raise ( B(3,4) ) >> > Exception: B (3, 4). >> > Fatal error: exception Excb.B(_) >> > Fatal error: exception Excb.B(_) >> > ===================================================== >> > >> > So just adding parantheses in a definition of an exception >> > yields in these differing results, with not-shown exception-values. >> > >> > IMHO looks like a case for the bugtracker... >> >> There's no requirement for the toplevel and the compilers to behave the >> same way for reporting the exception. The output, for example, also differs >> in the way the exception message is formatted, there's no 'Fatal error:' and >> so on - do you want that to be a bug too? >> >> The toplevel has access to typing information which is not available to >> ocamlc/ocamlopt (the runtime only knows the name of the exception - beyond >> that, it's just presented with a standard variant block). I haven't got a >> compiler to hand, but I think you'll also see differences if you use a >> variant instead of numbers (ocaml will display the constructor name, the >> compilers will display its constructor number) and I think you'll also see >> the same output as the compilers if you compile excb.cmo and then #load it >> in the toplevel. >> >> It's not normal to want to terminate your compiled program with an >> uncaught exception, hence the simpler default exception printer in compiled >> code. If you really want the exception printed accurately, you can register >> a printer (see Printexc.register_printer). >> >> >> David >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > >