August 2004 - Libraries

Pairs of identifiers
by Lemming 25 Aug '04

25 Aug '04

As a guideline for future libraries I would like to have some agreed list of common pairs of identifiers. This can be useful both for designing function names and for easy guessing of the counterpart of some function. E.g. I think the names 'read' and 'show' aren't a good choice because they are a natural pair but this isn't reflected by their names. Even more 'read' and 'show' sound like some I/O operations which they are not. The choice for the Modula-3 libraries (Lex and Fmt) seems to be more suitable. I've collected some pairs of identifiers I stumbled on in AmigaOS, MUI, Modula-3, Haskell libraries, and C++ STL. This could be a basis for further discussion. I could also make a HaWiki page of this list to simplify the discussion. It would be nice if one could throw out some of the duplicates. Create Delete New Dispose Construct Destruct Alloc Free Obtain Release Attempt Lock UnLock Procure Vacate Forbid Permit Disable Enable Put Get Set Get Write Read Poke Peek Open Close Save Load Load UnLoad Init Exit Setup Cleanup Show Hide Insert Remove Add Rem Push Pull Push Pop Start Stop Size Begin End Length First Last Number Head Tail Front Back Top Bottom Fmt Lex Input Output

1 0

RE: Remaining bugs in Cabal under Windows
by Simon Marlow 18 Aug '04

18 Aug '04

On 18 August 2004 11:05, Krasimir Angelov wrote: > --- Simon Marlow <simonmar(a)microsoft.com> wrote: > >> While writing docs for getHomeDirectory / >> getAppUserDataDirectory, it >> occurred to me that we should probably have >> getUserDocumentsDirectory >> too. Thoughts? > > This is easy for Windows but I don't know the right > Linux convention. Mandrake uses > /home/<user name>/Documents. $HOME is fine. It would be used as the default directory in a "Save As..." dialog box, for example. Cheers, Simon

1 0

RE: Remaining bugs in Cabal under Windows
by Simon Marlow 18 Aug '04

18 Aug '04

While writing docs for getHomeDirectory / getAppUserDataDirectory, it occurred to me that we should probably have getUserDocumentsDirectory too. Thoughts? Cheers, Simon

2 1

RE: Filename handling
by Graham Klyne 17 Aug '04

17 Aug '04

At 14:04 17/08/04 +0100, Simon Marlow wrote: >On 17 August 2004 12:44, Graham Klyne wrote: > > > Anyway, I'd like to see the common library functions provide at least > > minimal capabilities to allow multi-platform applications to do the > > right > > thing when handling filenames. I'm pretty agnostic about what they > > actually look like, but as an example I've found the Python and/or > > Java > > libraries to be pretty usable in this respect. > >I think there's general agreement that this would be a good thing, but >discussion never seems to reach a conclusion. Anyone like to whip up a >concrete proposal? This may be a bit radical, but I'll float it anyway: pathToUri :: String -> String -- convert filename to a file: URI according to local system conventions uriToPath :: String -> String -- convert a file: URI to filename according to local system conventions Hmmm... to preserve referential transparency, I suppose that should be: pathToUri :: String -> IO String uriToPath :: String -> IO String The rationale here is that these two functions can be used to get any filename on any system into a form with well-defined syntax and properties and back again, allowing the other filename processing requirements (splitting apart, putting together, relative path evaluations, etc.) to be performed with the common form. Of course, this doesn't deal with operations that need to actually access the file system (directory scanning, etc.), but many of these seem pretty well catered for in any case (cf. Directory library functions). ... Failing this, I'd say that Isaac's module [1] has some pretty reasonable functions. I'd pick out: splitLastComp :: FilePath -> (FilePath,FilePath) isAbsolute :: FilePath -> Bool splitExt :: FilePath -> (FilePath, String) The next function would be useful, but I'd be reluctant to include it until we're confident of having consistent regex support on all platforms: matchPath :: String -- ^RegExp -> IO [FilePath] -- ^IO because it must look to see what exists An alternative, avoiding regex dependence, might be: matchPath :: (FilePath -> Bool) -> IO [FilePath] And a very important (IMO) function that I don't see in Isaac's module would be something like: relativeTo :: FilePath -> FilePath -> FilePath In my URI processing code, I've also added a complementary function: relativeFrom :: FilePath -> FilePath -> FilePath which returns a relative path such that: (path `relativeFrom` base) `relativeTo` base == path noting that the result relativeFrom is not always uniquely determined. Maybe it's better to leave this out. I think that a function like: isDirectory :: FilePath -> IO Bool may also be needed when performing directory scanning operations. [1] http://www.syntaxpolice.org/darcs_repos/OS.Path/Path.hs ... Some related questions to consider: - should we take seriously the point I make above about using IO so that referential transparency is rigorously preserved? If so, all of the above functions should return IO values, as the result may vary depending on the environment in which the program runs. - do we care about legacy operating systems like VAX/VMS? (that would require version number support, and doesn't work well with interfaces that assume a single path separator character). - how does the interface work with forthcoming systems like Microsoft's Longhorn. I hear that the directory tree concept is being replaced by file "attributes". Which leads me to think of... - how does the interface work with WebDAV, which builds a file system like interface over HTTP, and adds property lists to the resources identified. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Filename handling (was: Remaining bugs in Cabal under Windows)
by Simon Marlow 17 Aug '04

17 Aug '04

On 17 August 2004 12:44, Graham Klyne wrote: > Anyway, I'd like to see the common library functions provide at least > minimal capabilities to allow multi-platform applications to do the > right > thing when handling filenames. I'm pretty agnostic about what they > actually look like, but as an example I've found the Python and/or > Java > libraries to be pretty usable in this respect. I think there's general agreement that this would be a good thing, but discussion never seems to reach a conclusion. Anyone like to whip up a concrete proposal? Cheers, Simon

2 1

RE: Remaining bugs in Cabal under Windows
by Simon Marlow 17 Aug '04

17 Aug '04

On 16 August 2004 19:20, Krasimir Angelov wrote: > There still exists some bugs in Cabal when it is > used under Windows. > > - The platform dependent places in the code are > marked with #ifdef mingw32_TARGET_OS but this macro is > never defined ever under Windows. You must add > -Dmingw32_TARGET_OS to the command line while building > setup.exe and also add -Dmingw32_TARGET_OS to > options-ghc field in Setup.description. I'll fix this. Isaac: is it ok for me to commit fixes to the repository? I have a couple of other things I found when building Cabal on Windows recently, and Krasimir has sent me a large patch to fix a number of problems. > - When Cabal is used to build library package then > it fails to find ar.exe in the path. This isn't a > problem when in the build is run from cygwin or mingw > environment but is painful on plain Command prompt. Agreed - one of the goals of Cabal is that it should work with a plan GHC installation, no cygwin required. I think ar.exe should be packaged with GHC in the same directory as ghc.exe, so that it'll be available in the PATH. This is easier than providing ar functionality from GHC itself, which would perhaps be nice but is more work and is GHC-specific, you still have to invoke ar for other compilers. > - The package uses (getEnv "HOME") to get the path > to home directory. The variable isn't present in plain > Command prompt under Windows. Agreed. I need to know the equivalent of $HOME for GHC too, so that GHC can keep a per-user package database. > - The default installation prefix under Windows is > "C:\Program Files" but it is known that some times GHC > doesn't work very well with paths which have spaces. I > don't know whether this can be fixed or this depends > from gcc and ld GHC itself doesn't have problems with pathnames with spaces in; GHC's build system does, though. I claim: it should be a goal to make everything work for pathnames containing spaces. > To fix third bug I tried to use > SHGetFolderPathAndSubDir function to retrieve the > "Application Data" folder for current user. > This is: > > "C:\Documents and Settings\kr_angelov\Application > Data" > > on my PC. The trouble here is that to do that I need > to add shell32 to extra-libs field in package > description. I don't have a way to preprocess > Setup.description so I can't add shell32 > conditionally. > I would like to have a collection of functions like: > > getCurrentDirectory we already have that > getAppUserDataDirectory > getHomeDirectory Maybe - although the conventions still differ between Unix and Windows. On Unix, to store per-user data you would use <homedir>/.<app> whereas on Windows you use <homedir>/<app>. So I think the win32 library should provide access to getAppUserDataDirectory, and the app code still needs to be conditionally compiled. Cheers, Simon

4 3

RE: Remaining bugs in Cabal under Windows
by Simon Marlow 17 Aug '04

17 Aug '04

On 17 August 2004 13:44, Krasimir Angelov wrote: > {-# OPTIONS -cpp #-} > #ifdef mingw32_TARGET_OS > {-# OPTIONS -#include "shlobj.h" #-} > #endif > > #ifdef mingw32_TARGET_OS > import Foreign > import Foreign.C > #else > import System.Environment > #endif > > getHomeDirectory :: IO FilePath > getHomeDirectory = > #ifdef mingw32_TARGET_OS > allocaBytes 1024 $ \pPath -> do > r <- c_SHGetFolderPath nullPtr 0x28 nullPtr 0 > pPath > if (r < 0) > then c_SHGetFolderPath nullPtr 0x05 nullPtr 0 > pPath > else return 0 > peekCString pPath > #else > getEnv "HOME" > #endif > > getAppUserDataDirectory :: String -> IO FilePath > getAppUserDataDirectory appName = do > #ifdef mingw32_TARGET_OS > allocaBytes 1024 $ \pPath -> do > r <- c_SHGetFolderPath nullPtr 0x1A nullPtr 0 > pPath > s <- peekCString pPath > return (s++'\\':appName) > #else > path <- getEnv "HOME" > return (path++'/':'.':appName) > #endif I'm happy for these functions to go into System.Directory, unless anyone disagrees. Instead of using the manifest constants (0x28, 0x05, 0x1A) use another method to get the constants in - for libraries/base the technique we use is to define an inline function in HsBase.h. If you commit the code, I'll add Haddock comments. Cheers, Simon

1 0

RE: Remaining bugs in Cabal under Windows
by Graham Klyne 17 Aug '04

17 Aug '04

At 10:20 17/08/04 +0100, Simon Marlow wrote: > > - The package uses (getEnv "HOME") to get the path > > to home directory. The variable isn't present in plain > > Command prompt under Windows. > >Agreed. I need to know the equivalent of $HOME for GHC too, so that GHC >can keep a per-user package database. On my Windows XP system, its: HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Graham #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Remaining bugs in Cabal under Windows
by Krasimir Angelov 16 Aug '04

16 Aug '04

There still exists some bugs in Cabal when it is used under Windows. - The platform dependent places in the code are marked with #ifdef mingw32_TARGET_OS but this macro is never defined ever under Windows. You must add -Dmingw32_TARGET_OS to the command line while building setup.exe and also add -Dmingw32_TARGET_OS to options-ghc field in Setup.description. - When Cabal is used to build library package then it fails to find ar.exe in the path. This isn't a problem when in the build is run from cygwin or mingw environment but is painful on plain Command prompt. - The package uses (getEnv "HOME") to get the path to home directory. The variable isn't present in plain Command prompt under Windows. - The default installation prefix under Windows is "C:\Program Files" but it is known that some times GHC doesn't work very well with paths which have spaces. I don't know whether this can be fixed or this depends from gcc and ld Each of these bugs have many solutions. From the message: Log: Define <arch>_TARGET_ARCH and <os>_TARGET_OS by default when CPP'ing. This avoids the main reason for needing to #include config.h into Haskell source, so most files that previously just #include "config.h" can now #if __GLASGOW_HASKELL__ < 603 #include "config.h" #endif from cvs-ghc(a)haskell.org it looks like the first bug is already solved for GHC but I don't know whether this will be adopted from other implementations too. Most of platform dependent code deals with filepaths and .exe .so/.dll extensions. Similar code already exists in many other tools in fptools repository. Maybe it is a time to collect such code in the standard library. The easiest way to fix second bug is to distribute ar.exe with GHC much like it already comes with gcc and ld. GHC can automatically invoke ar.exe when the --make option is given and the source doesn't provide Main.main. To fix third bug I tried to use SHGetFolderPathAndSubDir function to retrieve the "Application Data" folder for current user. This is: "C:\Documents and Settings\kr_angelov\Application Data" on my PC. The trouble here is that to do that I need to add shell32 to extra-libs field in package description. I don't have a way to preprocess Setup.description so I can't add shell32 conditionally. I would like to have a collection of functions like: getCurrentDirectory getAppUserDataDirectory getHomeDirectory in the System.Directory module. This can make some applications more portable. I would like to hear other suggestions to find the best way to make Cabal working under Windows. Cheers, Krasimir __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

DData AscList
by John Meacham 13 Aug '04

13 Aug '04

So, pursuient to discussion on the various other haskell lists and some talk about DData recently, I was wondering whether adding an ordered list type might be useful. Often, when one knows a list is ordered, many algorithms (like building a tree-based set, or a map) become more efficient, however it is up to the programmer to ensure an ordered list is used where one is expected or obscure bugs might occur. I was thinking... (off the top of my head) module Data.OrdList(OrdList,toList,fromList,unsafeFromAscList) where newtype Ord a => OrdList a = OrdList { toList :: [a] } fromList = OrdList . sort unsafeFromAscList xs = OrdList xs with some appropriate instances which make an OrdList behave pretty much exactly like a list, except maintaining the ordered invarient... then we can safely convert between the various container types in O(n) time without the posibility of messing up... comments? where is the current proposed DData library anyway? John -- John Meacham - ⑆repetae.net⑆john⑈

1 0