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 WAA04447; Mon, 29 Sep 2003 22:48:10 +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 WAA14261 for ; Mon, 29 Sep 2003 22:48:08 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h8TKm2H03891; Mon, 29 Sep 2003 22:48:02 +0200 (MET DST) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA16827; Mon, 29 Sep 2003 22:48:02 +0200 (MET DST) From: Pierre Weis Message-Id: <200309292048.WAA16827@pauillac.inria.fr> Subject: Re: [Caml-list] Printing text with holes In-Reply-To: from Brian Hurt at "Sep 29, 103 01:22:25 pm" To: bhurt@spnz.org (Brian Hurt) Date: Mon, 29 Sep 2003 22:48:02 +0200 (MET DST) Cc: jeanmarc.eber@lexifi.com, martin_jambon@emailuser.net, caml-list@inria.fr X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; pierre:01 weis:01 pierre:01 weis:01 caml-list:01 printf:01 printf:01 well-typed:01 constants:01 escapes:01 constants:01 type-check:01 familiarity:01 ioctl:01 malloc:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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