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 MAA15386; Sat, 5 Jul 2003 12:26:52 +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 MAA06503 for ; Sat, 5 Jul 2003 12:26:51 +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 h65AQof13763; Sat, 5 Jul 2003 12:26:50 +0200 (MET DST) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA02389; Sat, 5 Jul 2003 12:26:49 +0200 (MET DST) From: Pierre Weis Message-Id: <200307051026.MAA02389@pauillac.inria.fr> Subject: Re: [Caml-list] Printf and format In-Reply-To: <20030703163804.GA1207@gallu> from Sylvain LE GALL at "Jul 3, 103 06:38:05 pm" To: sylvain.le-gall@polytechnique.org (Sylvain LE GALL) Date: Sat, 5 Jul 2003 12:26:49 +0200 (MET DST) Cc: 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 caml-list:01 printf:01 gall:01 scanf:01 type-check:01 kprintf:01 printf-like:01 systematic:01 hacks:01 fun'':01 implemented:01 compiler:01 cristal:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Hello, > > I am sorry to ask a so silly question, but i need it for my personnal > work, and i could not find it in the archive. > > Is there a way to transform string to ( 'a, out_channel, unit, unit) > format. I need this function to use it with something like : > > Printf.printf (my_fun "X, Y") "coucou";; > > I look at the code and see a function scan_format, but it seems to be > forbid to use it. > > Any idea ? > > Thanks > Sylvain LE GALL As once announced on this list, the new release of Objective Caml will introduce a lot of novelty on the format type. Besides new convertion specifiers that you could find in the Printf and Scanf documentation (C, S, B, F, !, ...), there are now several different new functionalities provided by the new compiler which are relevant to your question: 0) converting arbitrary format string to a regular strings 1) converting CONSTANT strings to the corresponding constant format string 2) concatenating format strings (very often feature 0 and 1 are used in conjonction just to implement format strings concatenation). Those primitives are provided with respective names string_of_format, format_of_string, and binary infix operator ( ^^ ). I think they are useful and powerful: those new features should leverage the need for using Obj.magic and type constraints inside programs that directly manipulate format strings. However, this introduction of new format strings primitives has necessitated the addition of a new type variable to the format type that now get 4 variables instead of 3: this extra variable is mandatory to adequately type-check the kprintf function and to give an appropriate type to the new format concatenation operator (appropriate here just meaning correct, i.e. safe). This is normally completely transparent to programs that just use printf-like functions: the printf functions get a type using the new format type constructor, its format string get also the extra type variable in its typing, the type-checker hapilly handles the application and you will not even notice the modification. However, this new type variable indeed introduces a backward incompatibility, if you ever used the format type constructor into your programs, as part of the type constraints appearing either in the interface files or directly into your programs (to force an expression to get a format type). In this case, the modification of your program is easy and as follows: Just duplicate the last variable of the format type constructor argument. This systematic way to correct programs that mentioned the format type constructor is a minor inconvenience for the sake of the useful additions described above. If the users on this list feel it too complex and way too boring to modify their programs like that, we may try to implement various hacks to leverage the burden. I should mention that, even if I'm not enthusiastic at all to have been obliged to introduce such a backward incompatibility into the compiler, I would be ashame to add such (not so clean) hacks into it as well. In particular, because in this case, the modification of programs is almost trivial. Back to your problem: the features described here may your for some ``my_fun'' functions, but the general case is not properly covered by them. What we need is a general function that reads a format from within a string that is NOT a constant. This is a kind of dynamic convertion reminiscent of int_of_string or float_of_string, that checks that the string can be indeed considered as an integer of floatting point number. I propose (and have implemented for my own programming of a general translation function) a new function [read_format], such that [read_format pat s] returns the string [s] as a format string that has the same type (hence the same ``printf meaning'') as [pat], the first format string argument. For instance, read_format "The number %d is odd" "Le nombre %d est impair" returns "Le nombre %d est impair" as a format string with the same type as "The number %d is odd". This function is more general that the one above since now in [read_format pat s] the string [s] is not mandatorily an immediate string constant: it can be obtained from an arbitrary computation, as read from a file. The Typechecking of read_format would be: read_format : ('a, 'b, 'c, 'd) format -> string -> ('a, 'b, 'c, 'd) format If considered useful, this function could be added, for instance as part of a new internationalization module. Hope this helps, Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/ ------------------- 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