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 NAA22085; Tue, 3 Jul 2001 13:18:25 +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 NAA22070 for ; Tue, 3 Jul 2001 13:18:24 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f63BIMj16444; Tue, 3 Jul 2001 13:18:22 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA22065; Tue, 3 Jul 2001 13:18:21 +0200 (MET DST) Date: Tue, 3 Jul 2001 13:18:21 +0200 From: Xavier Leroy To: jeanmarc.eber@lexifi.com Cc: caml-list@inria.fr Subject: [Caml-list] Re: improvements for the OCaml toplevel Message-ID: <20010703131821.A21673@pauillac.inria.fr> References: <992357601.3b262ce14db42@imp.pro.proxad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <992357601.3b262ce14db42@imp.pro.proxad.net>; from jeanmarc.eber@lexifi.com on Tue, Jun 12, 2001 at 04:53:21PM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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). I can see other situations where it is desirable to start a script in a known, empty state, regardless of what the users put their .ocamlinit files. The convention on which ".something" files to read on start-up seems to vary widely between Unix shells, for instance. So, I don't quite know what to do. > 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. Minor correction: the user-defined printers themselves (for a type t) have type "t -> unit", and with your suggestion would have type "formatter -> t -> unit". > 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... :-) You are correct on the "historical" bit. > 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. Being reluctant to break old code (as usual), I implemented a backward-compatible solution whereas the function given to #install_printer can either have type "t -> unit" (as before) or type "formatter -> t -> unit" (as you suggest). In the latter case, the function receives as argument the formatter where it should output its results. The documentation will encourage the latter form, and mark the former as deprecated. Thanks for your input, - Xavier Leroy ------------------- 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