Xavier Leroy wrote:

> Concerning the Str interface, I received several complaints about it,
> to which I replied "why don't you propose an alternate functional API?",
> to which I never got any reply.  So, if you have ideas, go ahead.  If
> you can get some peer reviewing on your design, that would be much better.
> Good APIs aren't easy to design (witness the lengthy discussion on I/O
> on this list), so it's unlikely that you can find a good one all by
> yourself in 30 minutes.

Actually, I'm a happy user of Str, but I find the absence in Ocaml of a 
functional "canonical" regexp feature striking.


>>There's one extra thing I'd like to point out. We have the 
>>chop_extension function. Why in the world is there no find_extension 
>>function?
>>find_extension "foo.bar" --> "bar"
> 
> 
> Why in the world would that be generally useful?  Remember, we don't
> shoot for completeness (it's unattainable anyway), just for
> usefulness.

find_extension would be no more and no less general than chop_extension. 
It's actually the dual of the latter, in a way. Again, it's no big deal, 
but it seems to me that the lack of a find_extension function in 
Filename is an involuntary omission rather than a well thought out 
design decision.

***

Are the following two pieces of code not dual of each other? Is this not 
a good enough reason to include the former?

let file_extension name =
   try
     let index = String.rindex name '.' + 1 in
     let ext_len = String.length name - index  in
       String.sub name index ext_len
   with Not_found ->
     invalid_arg "Xcaml.file_extension"

let chop_extension name =
   try
     String.sub name 0 (String.rindex name '.')
   with Not_found ->
     invalid_arg "Filename.chop_extension"

Duality is a property I consider of paramount importance in a formal 
model. Ocaml is a modeling language for algorithms. Duality is central 
to Ocaml, in my opinion. For this very same reason I once asked why such 
a crucial operator as ++ had not been included in Pervasives.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners