From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA04299; Tue, 12 Jun 2001 16:53:23 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA03692 for ; Tue, 12 Jun 2001 16:53:22 +0200 (MET DST) Received: from imp.pro.proxad.net (imp1-1.pro.proxad.net [212.27.35.86]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5CErLj19688 for ; Tue, 12 Jun 2001 16:53:21 +0200 (MET DST) Received: by imp.pro.proxad.net (Postfix, from userid 33) id 5771F78198; Tue, 12 Jun 2001 16:53:21 +0200 (MEST) To: caml-list@inria.fr Message-ID: <992357601.3b262ce14db42@imp.pro.proxad.net> Date: Tue, 12 Jun 2001 16:53:21 +0200 (MEST) From: jeanmarc.eber@lexifi.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4-Online X-Originating-IP: 213.228.25.249 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I just began to play seriously with Ocaml's toplevel and have the following remarks and suggestions: 1. Standard use of the .ocamlinit file: You have the possibility of "customising" the toplevel by a suitable '.ocamlinit' file that is "#use"d before going in interactive mode. Unfortunately, the '.ocamlinit' file isn't "#use"d in script mode, making it impossible to create a *symmetric* environment for interactive and script mode. I would suggest to "#use" also the ".ocamlinit" file in script mode (the result being that it is put in front of your script file). 2. Type of user-defined printers: The printing formatter system under OCaml is now everywhere in the compiler and the standard libraries unified toward the "Format.formatter -> ('a, Format.formatter, unit) format -> 'a type" approach, where all output functions receive a formatter and a format string, giving everywhere these nice "fprintf ppf "@[...@]" printo o ..." calls. This of course abstracts away the destination of your output, that has to be parameterised by the choice of a suitable formatter. Unfortunately, user defined printers aren't of type Format.formatter -> ('a, Format.formatter, unit) format -> 'a, but must be of type ('a, Format.formatter, unit) format -> 'a. It seems (its not very clear from the manual) that user-defined printers always have to print on Format.std_formatter. Why ? I don't see any other explanation than historical reasons... :-) I nethertheless suggest to unify also this last part of the formatting system in OCaml. I don't think *many* OCaml users are using industrially user defined printers and those who do could, I think, accept this minor (and type tracked by the compiler!) change in their source. Look at the relevant code in genprintval.ml (comments are mine): let install_printer path ty fn = (* fn is the user defined printer *) let print_val ppf obj = (* we have a ppf here *) try fn obj with (* but we don't use it here !!!! *) | exn -> fprintf ppf "" Printtyp.path path in printers := (path, ty, print_val) :: !printers 3. Consequence: a minor subtle bug in OCaml's toplevel: The following case isn't treated correctly under OCamls toplevel: - you use "script" mode. - your script raises an exception. - your exception type contains one or more values that are printed by a custom printer. In this case, OCaml uses Format.err_formatter for its output (only for exceptions, as other results aren't printed, of course), look at topmain.ml: let file_argument name = exit (if Toploop.run_script Format.err_formatter name Sys.argv then 0 else 2) the exception will be printed on err_formatter, but calls recursively your custom formatter that outputs on std_formatter... resulting in a not beautiful "error message". This shows how urgent it is to standardise *everywhere* on the same (powerful and practical) formatting technology :-). Jean-Marc Eber LexiFi Technologies ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr