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
next prev parent 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).