caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Pierre Weis <pierre.weis@inria.fr>
To: bhurt@spnz.org (Brian Hurt)
Cc: jeanmarc.eber@lexifi.com, martin_jambon@emailuser.net,
	caml-list@inria.fr
Subject: Re: [Caml-list] Printing text with holes
Date: Mon, 29 Sep 2003 22:48:02 +0200 (MET DST)	[thread overview]
Message-ID: <200309292048.WAA16827@pauillac.inria.fr> (raw)
In-Reply-To: <Pine.LNX.4.44.0309291311360.3771-100000@localhost.localdomain> from Brian Hurt at "Sep 29, 103 01:22:25 pm"

> On Mon, 29 Sep 2003, Jean-Marc EBER wrote:
> 
> > With "old" printf approach, you write something like:
> > let _ =
> >    printf "Hello %s %s! It is %i o'clock.\n" first_name last_name time
> 
> It also allows you to do:
> 
> let _ = printf "Hello %s %s! It is %i o'clock.\n" name time

This is not well-typed and the error is properly spotted by the compiler:

# Printf.printf "Hello %s %s! It is %i o'clock.\n" name time;;
                                                        ^^^^   
This expression has type int but is here used with type string

> To detect this is a problem, the compiler has to not only parse Ocaml, it 
> also has to parse printf format strings.

Absolutely. This exactly similar to what the compiler does when
reading string constants in order to properly look for escapes, or
when it reads strings of digits to decide if it means an integer or a
floating point number.

As long as you realize that format strings are yet another kind of
primitive constants you easily admit that the compiler has to
type-check them. It is the usual compiler stuff, although a bit more
complex, since format string constants have complex types.

> The one advantage that printf has is familiarity.  All of us who are old C 
> programmers (and I fall into this category) know printf.  But that doesn't 
> make it a good interface.
> 
> Brian

You are absolutely right: good old C functions have not automatically
good old interfaces (for a counterexample just consider ioctl, malloc
and free, compared to their void equivalent in Caml, or longjump and
setjump compared with the nice try raise constructs). Conversely, we
must admit that good old C functions do not necessarily have a bad
interface, isn't it ?  (May I mention as an example the basic
arithmetic operators ?)

However, concerning printf, you should realize that the Caml printf
facility (or scanf, to mention another facility that uses format
strings) are not mere transpositions of their C equivalent. They have
powerful additional features (%a, %C, %S, %t for instance), their
typechecking is entirely static, their interface is much more in the
spirit of functional programming, and last but not least the kprintf
or kscanf versions of the basic primitives have no equivalent in C.

May I also mention specifically for printf the additional facility of
the Format module with its associated high-level pretty-printing
facilities that are completely and smoothly integrated into the format
strings mechanism ?

Concerning these powerful additions, I'm not sure that good old C
programmers always have a fluent knowledge of the kind of features our
Caml printf and scanf primitives provide.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/

PS: As an example, I should mention that the Caml scanf function is
powerful enough to allow the definition of a polymorphic list scanner
generator, that can be apply to any element specific scanner to
provide a scanner for lists of those elements' type: this is indeed
polymorphic higher-order scanning, well in the spirit of functional
programming, and I doubt you can easily obtain that with the C scanf
(nor program the Caml polymorphic list scanner with your good old C
scanf knowledge)...

-------------------
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


  reply	other threads:[~2003-09-29 20:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-29 13:16 Martin Jambon
2003-09-29 14:10 ` Christian Lindig
2003-09-29 16:25 ` Benjamin Geer
2003-09-29 16:39 ` Brian Hurt
2003-09-29 17:45   ` Jean-Marc EBER
2003-09-29 18:22     ` Brian Hurt
2003-09-29 20:48       ` Pierre Weis [this message]
2003-09-29 21:52         ` Richard Jones
2003-09-29 22:07           ` Fred Yankowski
2003-09-29 22:14             ` Daniel M. Albro
2003-09-29 22:19               ` Richard Jones
2003-09-29 22:23             ` Matthieu Sozeau
2003-09-30  3:56             ` Brian Hurt
2003-09-30  4:40         ` Brian Hurt
2003-09-30  6:11           ` David Brown
2003-09-29 18:57     ` Martin Jambon
2003-09-29 21:25       ` Pierre Weis
2003-09-30 12:52       ` skaller
2003-09-30 17:48         ` Martin Jambon
2003-09-29 18:16   ` Richard Jones
2003-09-29 17:00 ` Pierre Weis
2003-09-29 17:03 ` Karl Zilles
2003-09-29 21:47   ` Pierre Weis
2003-09-30  7:20     ` Jean-Christophe Filliatre

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=200309292048.WAA16827@pauillac.inria.fr \
    --to=pierre.weis@inria.fr \
    --cc=bhurt@spnz.org \
    --cc=caml-list@inria.fr \
    --cc=jeanmarc.eber@lexifi.com \
    --cc=martin_jambon@emailuser.net \
    /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).