caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Quôc Peyrot" <chojin@lrde.epita.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] precision not working properly for strings in Printf?
Date: Wed, 27 Jun 2007 13:08:49 +0200	[thread overview]
Message-ID: <85C1CD9B-C2C0-4DB8-BA98-A2860F3F0092@lrde.epita.fr> (raw)
In-Reply-To: <961FE40A-1574-4146-B9C2-DA56904E0939@valdosta.edu>


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

Of course I do realize that OCaml's printf is not glibc's printf, nor  
it is simply a wrapper. I did try to read the code to see if I could  
spot any comments/specific code which would explain this difference  
of behavior. It's not like I'm a complete noob who doesn't realize  
that you can't always follow every single convention/feature. But  
this module is still called "Printf", with function such as printf,  
sprintf, fprintf... So it's not like the designers didn't really try  
to follow/get inspiration from the C version either, thus I don't  
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  
can I do that" type of question, but it was a design question. To me  
it looks like an overlook, but I learned multiple times that OCaml  
can be quite subtle about what you can and can't do, and that most of  
the time, there often is a good reason why a specific feature is  
missing. And here, we are talking about Printf, which is quite subtle  
by itself anyway because of the type checking involved (for example,  
one could wonder why he cannot build format strings at runtime as in  
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  
background behind this choice?

I don't mean to be rude either, but I would have posted in  
ocaml_beginner if I just wanted to know I could use String.sub  
instead of this feature (ExtString.String.slice is probably more  
appropriate if you don't want to deal with out of bound problems).

Thanks,

-- 
Best Regards,
Quôc





  reply	other threads:[~2007-06-27 11:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-27  3:18 Quôc Peyrot
2007-06-27  3:38 ` [Caml-list] " Jonathan Bryant
2007-06-27  3:48   ` Quôc Peyrot
2007-06-27  4:11     ` Jonathan Bryant
2007-06-27  8:34       ` Vincent Hanquez
2007-06-27  9:53         ` Jonathan Bryant
2007-06-27 11:08           ` Quôc Peyrot [this message]
2007-07-03  1:14           ` David Thomas
2007-06-27 10:46         ` Quôc Peyrot

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=85C1CD9B-C2C0-4DB8-BA98-A2860F3F0092@lrde.epita.fr \
    --to=chojin@lrde.epita.fr \
    --cc=caml-list@inria.fr \
    /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).