(no subject)

[jeanmarc.eber]

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 "<printer %a raised an exception>" 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

[Caml-list] Re: improvements for the OCaml toplevel

[Xavier Leroy]

> 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