From: Jonathan Bryant <jtbryant@valdosta.edu>
To: Vincent Hanquez <vincent@snarc.org>
Cc: Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] precision not working properly for strings in Printf?
Date: Wed, 27 Jun 2007 05:53:27 -0400 [thread overview]
Message-ID: <961FE40A-1574-4146-B9C2-DA56904E0939@valdosta.edu> (raw)
In-Reply-To: <20070627083401.GA32745@snarc.org>
>
> 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
next prev parent reply other threads:[~2007-06-27 9:53 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 [this message]
2007-06-27 11:08 ` Quôc Peyrot
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=961FE40A-1574-4146-B9C2-DA56904E0939@valdosta.edu \
--to=jtbryant@valdosta.edu \
--cc=caml-list@inria.fr \
--cc=vincent@snarc.org \
/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