Benjamin Franksen wrote:

What, then, is the result of (addExtension "/" "x")? What, in general, is the behavior in case the first argument ends with a path separator?

Another example where the semantics is unclear (to me) is

takeBaseName :: FilePath -> String Source Get the base name, without an extension or path. takeBaseName "file/test.txt" == "test" takeBaseName "dave.ext" == "dave"

What is (takeBaseName "dir.ext/")? "dir"? Or ""? A general principle that would clarify this could be "An extension of a file path is always a suffix of the file path. It never contains a path (directory) separator." Ben

Hi

...

What, then, is the result of (addExtension "/" "x")? What, in general, is the behavior in case the first argument ends with a path separator?

Properties added: addExtension "/" "x" == "/.x" takeBaseName (addExtension (asDirectory x) "ext") == ".ext"

| What is (takeBaseName "dir.ext/")? "dir"? Or ""? A general principle that | would clarify this could be "An extension of a file path is always a suffix | of the file path. It never contains a path (directory) separator."

takeBaseName "" == "" takeBaseName "test" == "test" takeBaseName (asDirectory x) == "" Hopefully this makes things a bit clearer. Thanks for the comments Neil

Hi

isDirectory :: FilePath -> Bool isFile :: FilePath -> Bool asDirectory :: FilePath -> FilePath asFile :: FilePath -> FilePath

At the least, they are confusingly named, because

forall x. isDirectory (takeDirectory x) == False

(and I definitely don't suggest fixing this by making takeDirectory append a path separator).

The point is, the absence of a path separator at the end of a FilePath does not imply that the FilePath refers to a file rather than a directory.

If we must have these, then I suggest renaming them:

hasTrailingPathSeparator :: FilePath -> Bool addTrailingPathSeparator :: FilePath -> FilePath dropTrailingPathSeparator :: FilePath -> FilePath

Ok, that sounds entirely reasonable. I actually prefer the long names - it encourages people not to use them! I don't suspect these will be widely used, however some people found these were the single place where they needed to get into a FilePath and do string manipulation - something I'd really like to discourage.

Also, what's going on with System.FilePath.Windows and System.FilePath.Posix? Their documentation is empty. CPP shenanigans?

The documentation for System.FilePath.Windows and Posix are both identical to System.FilePath - they export exactly the same API and have exactly the same semantics, just tied to either Windows: or Posix: properties given in the main one. I'll update the text in these to modules to make this more clear. Thanks Neil

Hi

Yes, I understand what these modules do, I was just surprised that the documentation for both modules was empty. I expected to see the same interface as System.FilePath. Why the #ifdef __HADDOCK__ in System/FilePath/Posix.hs?

Rather than listing the similarities I found it easier to explain the differences, and where you should be using them. I can certainly revert to having the full interface shown.

Also, rather than having 3 copies of System.FilePath, we should have at most 2 (this is just an implementation issue, of course).

Agreed. For my standalone FilePath implementation I do have 3 genuinely different implementations - FilePath selects on the OS at runtime, Windows is one way, Posix is the other. This is done so that FilePath doesn't require cpp, so that people developing against the FilePath module in hugs (i.e. me!) don't have to preprocess it. That also means it has to use nasty CPP tricks, i.e. macro substitution, instead of just conditional compilation. Before actually submitting the code to base, I will move to a more standard base way of doing things, relying on CPP for all modules, and only including 2 actual modules. It's not too hard to do that, but it's probably easier to do it once at the end, hence I am waiting til a result is reached. Thanks Neil

Hi Bulat,

i think that the best way is to

module FilePath

import FilePath.Windows as Windows import FilePath.Unix as Unix

isProperPath = if weOnWindows then Windows.isProperPath else Unix.isProperPath

That results in an awful lot of boilerplate code (about 3 lines per function), plus reduces the amount of sharing between Windows and Unix - they are almost identical. If you look at the current method, FilePath has all the code, and Windows and Posix use clever CPP hacks to get it all working. Although these hacks are clever, I don't want them to go in base, its not good style.

then GHC can optimize it, throwing away unused branch at compile-time. and yhc will work just fine with its portable bytecode

As it stands currently, GHC can optimise and yhc can do it portably. Hugs can even use it without CPP - everyone should be happy ;) Thanks Neil

Hello Neil, Thursday, November 23, 2006, 4:26:50 PM, you wrote:

...

...

* Portability, Windows+Linux, GHC+Hugs+Yhc

functions, it should work. For Portability read "anywhere, any compiler". NHC does not work on Windows, so I have not had a chance to try it.

ok, you may write "Tested with ... Should work on any H98-compatible compiler"

...

if you spend your time working on it, it's better to work in right direction instead of playing ping-pong - now you are moving this module from FilePath library to the Base and in future someone will make just the opposite operation :)

Whatever happens in the future, I suspect FilePath won't become a single standalone library after the base library split happens.

why not start with the library containing single module? in the future other modules will be added here as well. following this path, you will not play in move-it move-it game nor make things worser than in current state so, i propose to include your lib in the core (or base) library set, bundle it with ghc and hugs, and host it on darcs.haskell.org like other ghc-bundled libs

Given that no one knows what will happen, or when, its best that when the base library splits the task is "split up the base library", not "integrate new modules into a new system which includes the base library and other stuff".

we want to split it just because it was inflated so much. so please don't add even more to this problem. i can only repeat that the problem lies in the GHC HQ decision which makes impossible to propose adding FilePath lib to the set of core libs so you are forced to propose adding it to the base library -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Neil, Thursday, November 23, 2006, 7:48:36 PM, you wrote: now i'm 100% agree with your position. if GHC HQ will be against adding FilePath library to the set of core libs, i'm vote for inclusion FilePath module to base lib exclusively for using in Cabal scripts. while for other purposes i propose to release separate FilePath library anyway, so it can evolve and be upgraded as user wish afaik, Hugs peoples (including you) just follows GHC decisions in this area

...

so, i propose to include your lib in the core (or base) library set, bundle it with ghc and hugs, and host it on darcs.haskell.org like other ghc-bundled libs

Ok, perhaps I can rephrase my position (in light of your currently ongoing discussion):

"I propose that this module is added to the set of modules which is guaranteed to be available in every Haskell implementation, and can be used by programs with a simple import statement."

Currently that means "is in base". If you can convince the GHC and Hugs people that for their next releases they will guarantee to bundle a set of libraries and treat them as though they were in base, then my proposal is asking to be included in that set. (The Yhc position on this is that its a really good idea, and we'll definitely do that!)

As a side note, I think that the process for getting a library into this set of guaranteed libraries should be exactly the same as the current process for getting a library into base. If these core libraries have the same status as base currently does, then they need the same level of scrutiny.

Thanks

Neil

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Again, see http://hackage.haskell.org/trac/ghc/wiki/PackageReorg for proposed termiology. What we currently call "core libs" we propose to rename GHC Boot Packages S | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Ian Lynagh | Sent: 24 November 2006 17:24 | To: Neil Mitchell | Cc: Haskell Libraries | Subject: Re: Re[2]: Proposal: Add System.FilePath to base | | On Thu, Nov 23, 2006 at 04:48:36PM +0000, Neil Mitchell wrote: | > | > "I propose that this module is added to the set of modules which is | > guaranteed to be available in every Haskell implementation, and can be | > used by programs with a simple import statement." | > | > Currently that means "is in base". | | For GHC that means "is a core lib"; I'm not sure of the policy for the | other implementations. Perhaps we should rename that "is a GHC core lib" | and define a list of global "core libs" (of which "GHC core libs" would | be a superset) somewhere? | | I haven't looked at the particular library, but have no problem with | some sort of file path manipulating library to be used by cabal | Setup.hs's being in the core libs set. | | | Thanks | Ian | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

Duncan Coutts wrote:

Unfortunately it is very difficult for most developers to test with NHC98 because it does not work with any recent version of Linux (specifically since Linux kernel version 2.6 some years ago) due to the 'high mem' bug.

I build nhc98 every night on Linux, Sparc, and MacOS X. It works here...

I admit that I've not tried building NHC98 for a while but I've not heard that the bug has been fixed.

The high-mem bug was fixed in March this year. So yes, nhc98 is long overdue for a refreshed release that includes this patch, along with more current versions of the library packages. I'll try to get to it before Christmas. Regards, Malcolm

Hello Malcolm, Thursday, November 23, 2006, 8:03:21 PM, you wrote:

I build nhc98 every night on Linux, Sparc, and MacOS X. It works here...

you should be interested in testing filepath module with nhc ;) at least i agree with Neil that this module is great for setup scripts -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com