caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Mattias Waldau <mattias.waldau@tacton.se>
Cc: caml-list@inria.fr
Subject: Re: Print arbitrary value
Date: Sun, 11 Feb 2001 10:15:01 +0100	[thread overview]
Message-ID: <20010211101501.B129@pauillac.inria.fr> (raw)
In-Reply-To: <AAEBJHFJOIPMMIILCEPBCEBOCEAA.mattias.waldau@tacton.se>; from mattias.waldau@tacton.se on Wed, Jan 31, 2001 at 01:00:37PM +0100

> Is there a simple way to print how a complex structure?
> Essentially I would like to use the toplevel print functionality within my
> program for debugging purposes.

The short answer is: no.  Here is a more detailed answer (this should
be addressed in the FAQ at some point).  

- It is easy to write a generic "print" function that simply decodes
the internal representation of its argument, using the same "tag"
information that the GC or the structural equality function (=) use.
The problem is that the internal representations contain much less
information than needed for printing.

For instance, integer, characters, booleans, and constant constructors
are all represented internally as integers; thus, the values 0,
'\000', false and [] would all be printed as "0".

Similarly, the names of sum constructors and record labels are lost:
constructors become integer tags and labels are encoded positionally.
So, the list [1;2] would be printed something like "C0(1, C0(2, 0))".
Totally useless.

- For better printing, it is necessary to have a run-time
representation of the static ML type of the value to print, in
addition to the value itself.  The ML type acts as a "decoder" for the
low-level representation of the value, allowing precise printing.
This is how the toplevel proceeds to print results of evaluations.

This works fine for the toplevel because it has easy access to all the
required typing information -- the toplevel integrates the
type-checker and compiler.  But normal programs do not: at run-time,
they do not have access to their static types and type environments.
This is just compile-time information that is not transmitted to
run-time.

Several schemes have been designed to allow some amount of run-time
type information to be available to running programs, such as
"dynamics" and the Weis-Furuse "generics".  The toplevel print
facility is hard to fit within these schemes, because it does not
suffice to have "some amount of RTTI": the full ML types plus the full
typing environment (with all type definitions, module signatures and
whatnot) are required, and this raises rather serious efficiency
issues.

So, it is unlikely that the exact equivalent of the toplevel generic
printer will ever be available at run-time.  Currently, one has to
write printing functions by hand for debugging purposes.  The
ocamlc/ocamlopt compilers, for instance, contain about 10
pretty-printers for the various intermediate representations.

Writing pretty-printers is a lot of boring work, but for complex
enough data structures, the output of the toplevel generic printer is
too verbose anyway (all the constructor names, record labels,
parentheses and braces clutter the output), and a hand-written printer
is useful to print the data in a more compact, problem-specific
notation.

- Xavier Leroy



  reply	other threads:[~2001-02-12 12:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-26 21:38 Consortium Caml Michel Mauny
2001-01-28 14:34 ` John Max Skaller
2001-01-31 12:00 ` Print arbitrary value Mattias Waldau
2001-02-11  9:15   ` Xavier Leroy [this message]
2001-01-31 20:34 ` Consortium Caml Joshua D. Guttman
2001-02-01 23:44   ` Michel Mauny
2001-02-03 16:33     ` Francisco Reyes
2001-02-04 21:03       ` Pierre Weis
2001-02-05 17:01       ` John Max Skaller
2001-02-05 17:21         ` Pierre Weis
2001-02-06 23:36           ` John Max Skaller
2001-02-07 13:12           ` Didier Remy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010211101501.B129@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=mattias.waldau@tacton.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).