From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 26AA0BC6B for ; Wed, 27 Jun 2007 13:08:52 +0200 (CEST) Received: from smtp2a.orange.fr (smtp2a.orange.fr [80.12.242.138]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5RB8pIo024960 for ; Wed, 27 Jun 2007 13:08:51 +0200 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a28.orange.fr (SMTP Server) with ESMTP id 9ABEB7000092 for ; Wed, 27 Jun 2007 13:08:51 +0200 (CEST) Received: from [192.168.1.162] (ALagny-153-1-98-23.w90-3.abo.wanadoo.fr [90.3.145.23]) by mwinf2a28.orange.fr (SMTP Server) with ESMTP id 703347000091 for ; Wed, 27 Jun 2007 13:08:51 +0200 (CEST) X-ME-UUID: 20070627110851459.703347000091@mwinf2a28.orange.fr Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <961FE40A-1574-4146-B9C2-DA56904E0939@valdosta.edu> References: <0AC5F6BF-D076-4561-B015-70E41954D248@lrde.epita.fr> <7A72D27B-4FF3-4483-8D42-B9904FA734E2@valdosta.edu> <86507DD0-1BCB-4BF9-A058-0809022E564C@lrde.epita.fr> <8503CBAB-EF9E-4CF0-89A8-2F6E454CF4DC@valdosta.edu> <20070627083401.GA32745@snarc.org> <961FE40A-1574-4146-B9C2-DA56904E0939@valdosta.edu> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <85C1CD9B-C2C0-4DB8-BA98-A2860F3F0092@lrde.epita.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Qu=F4c_Peyrot?= Subject: Re: [Caml-list] precision not working properly for strings in Printf? Date: Wed, 27 Jun 2007 13:08:49 +0200 To: caml-list@inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at discorde with ID 46824543.003 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lrde:01 printf:01 printf:01 ocaml:01 pointer:01 ocaml:01 specifier:01 oversight:01 ocaml's:01 sprintf:01 fprintf:01 runtime:01 2007,:98 opportune:98 polymorphic:01 On Jun 27, 2007, at 11:53 AM, Jonathan Bryant wrote: >> I was just expecting it to work like the printf from the glibc: > >>>> Any clue why the same convention has >>>> not been followed? >>> > > Apparently my implication in my first response was not clear to =20 > some, so I'll clarify what I meant: > > The reasons for not following standard *nix conventions is a choice =20= > of the language/library designer, so I cannot speak on their behalf. > > I'd assume, though, that since the library was implemented from =20 > scratch, the conventions were not followed because it was, in some =20 > cases, opportune not to follow them. For example, some glibc =20 > conventions do not work for OCaml (such as pointer conversions), =20 > and the existing conventions did not handle things such as =20 > polymorphic values. In these cases, the designer simply took =20 > advantage of an opportunity to "fix" printf for OCaml. There's =20 > nothing wrong with glibc's implementation, except that it's =20 > designed for C. > > In other cases, such as the string conversion specifier, there is =20 > no contradiction, so maybe it's an oversight, maybe it's for =20 > consistency with numeric conversions, maybe it's easier to =20 > implement that way, or maybe it's just how the designer thought it =20 > should work. In any case, that's the way the library was designed =20 > and documented and it's the designer's prerogative to implement it =20 > how they see fit. The OCaml version is only based on glibc's =20 > printf while being designed specifically for OCaml, probably with =20 > the knowledge that String.sub is a simple function to use. Of course I do realize that OCaml's printf is not glibc's printf, nor =20= it is simply a wrapper. I did try to read the code to see if I could =20 spot any comments/specific code which would explain this difference =20 of behavior. It's not like I'm a complete noob who doesn't realize =20 that you can't always follow every single convention/feature. But =20 this module is still called "Printf", with function such as printf, =20 sprintf, fprintf... So it's not like the designers didn't really try =20 to follow/get inspiration from the C version either, thus I don't =20 think my question is that stupid (but maybe it is...). Sorry if I wasn't very clear, but my question was not a general "how =20 can I do that" type of question, but it was a design question. To me =20 it looks like an overlook, but I learned multiple times that OCaml =20 can be quite subtle about what you can and can't do, and that most of =20= the time, there often is a good reason why a specific feature is =20 missing. And here, we are talking about Printf, which is quite subtle =20= by itself anyway because of the type checking involved (for example, =20 one could wonder why he cannot build format strings at runtime as in =20 C. But in this case, there is a very good reason for this...) Hence my question: is it an overlook and if not, what is the =20 background behind this choice? I don't mean to be rude either, but I would have posted in =20 ocaml_beginner if I just wanted to know I could use String.sub =20 instead of this feature (ExtString.String.slice is probably more =20 appropriate if you don't want to deal with out of bound problems). Thanks, --=20 Best Regards, Qu=F4c