Version franaise
Home About Download Resources Contact us
Browse thread
precision not working properly for strings in Printf?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Quc_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,
Quc