From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA25070; Wed, 26 May 2004 12:34:57 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA25009; Wed, 26 May 2004 12:34:56 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4QAYrEV020599; Wed, 26 May 2004 12:34:54 +0200 Received: from [192.168.1.200] (ppp114-11.lns1.syd3.internode.on.net [150.101.114.11]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i4QAYok2070195; Wed, 26 May 2004 20:04:51 +0930 (CST) Subject: Re: [Caml-list] unix.chop_extension From: skaller Reply-To: skaller@users.sourceforge.net To: Xavier Leroy Cc: caml-list In-Reply-To: <20040526110508.A17806@pauillac.inria.fr> References: <1085429093.6065.336.camel@pelican.wigram> <20040526110508.A17806@pauillac.inria.fr> Content-Type: text/plain Message-Id: <1085567689.25587.202.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 26 May 2004 20:34:50 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 40B472CD.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 chop:01 sourceforge:01 2004:99 chop:01 bug:01 bug:01 work-arounds:01 basename:01 stdio:01 stdio:01 api:01 extlib:01 distro:01 apis:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 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