Re: [Caml-list] unix.chop_extension

[skaller <skaller@users.sourceforge.net>]

On Wed, 2004-05-26 at 19:05, Xavier Leroy wrote:
> John Skaller writes:
> 
> > # Filename.chop_extension "x.y/z";;
> > - : string = "x"
> > 
> > Oh come on. This is correct according to the specs,
> > but no one would believe this function is chopping
> > off the extension here :)
> 
> Care to submit a bug report for that?

Well it isn't a bug .. it actually does what the 
documentation says it does. It isn't clear if changing
the semantics to a more 'sensible' interpretation
won't break work-arounds etc.. so perhaps a 'feature request'?

Does anyone have code that would break if the chop_extension
function semantics were changed?

> > Also 
> > let y = (concat (directory x) (basename x)) in
> > assert x = y
> > is not guarranteed, only that x,y are 'equivalent'.
> > What does that mean?
> 
> That both names (x and y) refer to the same file.  You access the same
> file if you open one or the other.

What if neither denotes a file?
For example:

#include <stdio.h>

Woops. stdio.h doesn't denote a file. Neither does ./stdio.h.
Neither does 'foobar'. But either all are equivalent
(in which case I'd argue Filename is useless) or Filename
doesn't have defined semantics (in which case its utility
is limited and depends on the actual filesystem present).

The actual implementation is useful however, at least
on Unix: I don't want that leading ./ but I can remove
it and I know when to.. however the code that does that
isn't platform independent, and even on Unix the doco
doesn't guarrantee it: I'm not sure dirname "" = "."
rather than say "" or perhaps ./. :)

> 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.  

Part of the reason may be that people don't feel encouraged that
a proposal would make it into the core distribution.

Designing a good interface can be quite difficult and a lot
of work, particularly because one really needs to have multiple
people consider it, and also actually implement it.

In the past I spent years of my life and a thousands of dollars
doing this where there was actually a full formal process for
making proposals, and I myself had considerable political power.

If INRIA people would offer just a little encouragement and direction
in this area it might go a long way. Some comments on the content
of Extlib would be nice .. that project quite specifically
*intends* to be incorporated into the main distro (and I'd sure
like to see a variable length array make it ..)

> 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.

Total agreement!

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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