Browse thread
precision not working properly for strings in Printf?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Quôc_Peyrot <chojin@l...> |
| Subject: | Re: [Caml-list] precision not working properly for strings in Printf? |
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