Hi all,
Currently the unix package is a mishmash of different solutions to the
portability problem. Here are all the ones I've found, along with what I
think the best action would be. If this sounds reasonable then I'll
start making patches and proposals as appropriate.
(for POSIX/SUS, see http://www.opengroup.org/onlinepubs/009695399/)
1) Values outside of the scope of the package, conditionally available:
* System.Posix.Signals.Exts.*
Propose: Moving modules into a new package, unix-exts perhaps.
2) Things that fall back to probably-reasonable alternatives:
* unsetEnv, setEnv
* PATH_MAX
Propose: Leave as they are.
3) Things falling back to functionality which can cause problems:
* The Haskell usleep uses the C usleep (marked Obsolescent) if
nanosleep (a Timer extension) isn't available. C's usleep interacts
badly with GHC's threaded RTS.
Propose: Leave as it is.
4) Things that raise errors at runtime if they are not available,
but there is something we could fall back to:
* getGroupEntryForID (getgrgid_r, thread-safe extension)
* getGroupEntryForName (getgrnam_r, thread-safe extension)
Propose: Write fallback code.
5) Things that raise errors at runtime if they are not available,
but as far as I can see are required to be available anyway:
* _PC_* in System/Posix/Files.hsc
* getUserEntryForID (getpwuid)
* getUserEntryForName (getpwnam)
* grBufSize (sysconf, _SC_GETGR_R_SIZE_MAX)
* pwBufSize (sysconf, _SC_GETPW_R_SIZE_MAX)
* sysconfWithDefault (sysconf)
Propose: Change to using them unconditionally and see if any platforms
break.
6) Things depending on optional functionality, conditionally available:
* setSymbolicLinkOwnerAndGroup depends on lchown, an XSI extension
http://www.opengroup.org/onlinepubs/009695399/functions/lchown.html
* RLIMIT_AS (ResourceTotalMemory), RLIM_SAVED_MAX, RLIM_SAVED_CUR
(all of the rlimit stuff actually appears to be an XSI extension).
Propose: Move to unix-xsi package.
7) Things that raise errors at runtime if they are not available:
* getAllGroupEntries (getgrent, XSI extension)
* getAllUserEntries (getpwent, setpwent, endpwent, XSI extensions)
* Various in DynamicLinker.Prim
Propose: Move to unix-xsi package.
(for both 6 and 7, an alternative would be to just make them
unconditionally used in the unix package; I'm not sure what platforms,
if any, this would break on).
8) Things that are implemented only for certain compilers:
* forkProcess (GHC-only)
Propose: Write implementations for other compilers/interpreters.
Thanks
Ian
Chers amis of functionaλ cooking,
aujourd'hui, le maître de cuisine is going to criticize
System.FilePath.Find
http://darcs.serpentine.com/filemanip/dist/doc/html/
/FileManip/System-FilePath-Find.html
Is it seasoned too much with Curry and Monads? Pure or diluée with side
effects? Apfelmus will tell you! And like every serious cooking critic,
le maître thinks no end of himself so he can judge the haddock without
eating the compiled meal.
Who did not yet have to scan the file buffet for data of his gusto? This
is what System.FilePath.Find helps you to do. It basically offers a function
find :: RecursionPredicate
-> FilterPredicate
-> FilePath
-> IO [FilePath]
to lazily traverse a directory tree filtering out files that do not
match the FilterPredicate. The RecursionPredicate decides whether to
recurse into or a sub-directory or not (it could be mentioned explicitly
that the predicate is only invoked on directories). A variant of find
includes user-defined error handling.
How to define predicates? Mon dieu! They are to be obtained from a monad
FindClause a
type FilterPredicate = FindClause Bool
which offers operations like
extension :: FindClause FilePath
(==?) :: Eq a => FindClause a -> a -> FindClause Bool
(||?) = liftM2 (||)
One example predicate would be
(extension ==? ".hs") ||? (extension ==? ".lhs")
Cette soupe is much too monadic! In particular, we have the isomorphism
(FileInfo -> a) ≅ FindClause a
witnessed by the function pair
(f,g) = ((`liftM` fileInfo), evalClause)
Of course, the encapsulation was made to allow a formulation like
extension ==? ".hs"
which does not mention the FileInfo parameter. But alas, this can also
be achieved more naturally by appealing to the
instance Control.Applicative ((->) a)
Abstracting the concrete representation away into FindClause hinders
reuse of already existing functionality from System.FilePath, although
the name "extension" is arguably more succinct than "takeExtension".
The monad could make sense if the predicate might involve not only the
file status but also looking inside the file. Returning all files with a
certain magic number would be such a use case but System.FilePath.Find
currently does not offer zis possibilité.
Un autre point is that the library offers a function fold that is
almost a foldl' over all files in a directory tree, but not quite: here,
the fold goes over FileInfos but the list is a simple list of FilePaths.
One has to foldM over the latter and get the file infos again to achieve
the same effect.
Le maître de cuisine thinks that these quirks stem from the fact that
the file system lacks a purely functional design. The observation is
that given persistence, reading does not need to be monadic. In other
words, directory tree traversal might well return a list of files
data File = File { contents :: String, status :: FileStatus }
with contents and status. More generally, the traversal could be a
side-effect-free traversal of a pure data structure.
Of course, a purely functional file system needs further research, also
due to performance requirements.
Another direction of généralisation is that XML data is in principle
similar to a file system. Shouldn't both have a common traversal interface?
Last but not least, every modern cooking critic includes a
Rating: λλλ
Le maître awards three λ since the library uses a monad where none
should be, but acknowledges that this was for the ability to formulate
queries without plumbing the FileInfo-parameter everywhere.
Bon appetit,
apfelmus
