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 668AFBC6B for ; Wed, 27 Jun 2007 11:53:38 +0200 (CEST) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5R9rbeu009300 for ; Wed, 27 Jun 2007 11:53:38 +0200 Received: from [192.168.0.104] (12-208-242-210.client.mchsi.com[12.208.242.210]) by sccmmhc92.asp.att.net (sccmmhc92) with SMTP id <20070627095336m9200d9bs3e>; Wed, 27 Jun 2007 09:53:36 +0000 In-Reply-To: <20070627083401.GA32745@snarc.org> 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> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <961FE40A-1574-4146-B9C2-DA56904E0939@valdosta.edu> Cc: Caml List Content-Transfer-Encoding: 7bit From: Jonathan Bryant Subject: Re: [Caml-list] precision not working properly for strings in Printf? Date: Wed, 27 Jun 2007 05:53:27 -0400 To: Vincent Hanquez X-Mailer: Apple Mail (2.752.3) X-Miltered: at discorde with ID 468233A1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; printf:01 printf:01 ocaml:01 pointer:01 ocaml:01 specifier:01 oversight:01 cheers:01 beginner's:01 bug:01 opportune:98 curt:98 polymorphic:01 beginners:01 clearer:01 > > 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 some, so I'll clarify what I meant: The reasons for not following standard *nix conventions is a choice of the language/library designer, so I cannot speak on their behalf. I'd assume, though, that since the library was implemented from scratch, the conventions were not followed because it was, in some cases, opportune not to follow them. For example, some glibc conventions do not work for OCaml (such as pointer conversions), and the existing conventions did not handle things such as polymorphic values. In these cases, the designer simply took advantage of an opportunity to "fix" printf for OCaml. There's nothing wrong with glibc's implementation, except that it's designed for C. In other cases, such as the string conversion specifier, there is no contradiction, so maybe it's an oversight, maybe it's for consistency with numeric conversions, maybe it's easier to implement that way, or maybe it's just how the designer thought it should work. In any case, that's the way the library was designed and documented and it's the designer's prerogative to implement it how they see fit. The OCaml version is only based on glibc's printf while being designed specifically for OCaml, probably with the knowledge that String.sub is a simple function to use. In light of the above, I think that unfortunately the answer to the question of "why" is actually moot in this case because it is highly unlikely to change given that changing it could break existing code (in very subtle ways, none the less). > What about reading before replying ? > Your "explanation" certainly doesn't answer his question. > whether or not it's the same *implementation* doesn't answer why ocaml > printf choosed a different *convention* (specially on this case > which I > don't see any contradiction in the way ocaml works). I'm sorry if my reply seemed curt and unclear: I was not trying to be rude in my response, but only succinct. I'll try to be clearer in the future. --Jonathan > > Cheers, > -- > Vincent Hanquez > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs