caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Yaron M. Minsky" <yminsky@CS.Cornell.EDU>
To: Oliver Bandel <oliver@first.in-berlin.de>
Cc: Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] view types in ocaml?
Date: 21 Jan 2003 09:42:46 -0500	[thread overview]
Message-ID: <1043160165.17408.1612.camel@dragonfly.localdomain> (raw)
In-Reply-To: <20030121134608.GA495@first.in-berlin.de>

On Tue, 2003-01-21 at 08:46, Oliver Bandel wrote:

> 
> Well, I think that it is very good to have the values printed
> always.
> 
> I like that.
> 
> The toplevel is very good for testing code and doing
> experiments - and therefore it is very good to have
> the values printed always.

For the record, my suggestion is only that let-bound value printing
should be suppressed.  You could always see the result by just not
binding it (e.g., typing "foo x y z" instead of "let a = foo x y z".) 
And you can always get the contents of any variable printed by typing
it's name on the command line (e.g. "a;;" to see the contents of
variable a).

> If I don't need such helpers and code my code directly,
> I can write it into a file and let ocamlc or
> ocamlopt do its work.

But if you're doing interactive work with data of non-trivial size, the
constant printing is real pain.  I do an enormous amount of work
interactively at the command line, and more often than not, the data
structure print-outs are so long that I can't see the line I just typed
into the interpreter. 

> But maybe it makes sense to have options in the toplevel
> to disable such printings.

Making the suppression controllable by command-line options is
sensible.  But I do think that it should be the default.  There's a
reason that most language interpreters have this suppression, and I
don't think there's anything special about ocaml that makes it different
in this regard.

Another useful extension to the ocaml toplevel which has been proposed
in the past is to have some kind of default "this" variable which stores
unbound variables.  That would make the supression of let-bound easier
to use, since if you wanted to see how something printed out, you could
refrain from let-binding it, and still get access to the result using
the "this" variable.

> But it is no good idea to disable it hardcoded.
> 
> I prefer the possibility to have such printings,
> but think optionally turining it off would be ok.
> 
> Ciao,
>    Oliver

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2003-01-21 14:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-21  1:14 Ed L Cashin
2003-01-21 12:54 ` Yaron M. Minsky
     [not found]   ` <20030121134608.GA495@first.in-berlin.de>
2003-01-21 14:42     ` Yaron M. Minsky [this message]
2003-01-21 16:40       ` Gérard Huet
2003-01-21  3:13 Ed L Cashin
2003-01-21 11:48 ` Remi VANICAT
2003-01-21 12:55   ` Ed L Cashin

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=1043160165.17408.1612.camel@dragonfly.localdomain \
    --to=yminsky@cs.cornell.edu \
    --cc=caml-list@inria.fr \
    --cc=oliver@first.in-berlin.de \
    /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).