- Libraries - Haskell.org

Re: [Haskell-i18n] SourceForge Project Active
by Martin Norbäck 01 Sep '02

01 Sep '02

tor 2002-08-29 klockan 04.20 skrev Ashley Yakeley: > A SourceForge project for the internationalisation effort is active at > <http://sourceforge.net/projects/haskell-i18n/> Searching for "haskell" att sourceforge gave me these: hfl (Andrew Bromage) Haskell Foundation Library "The future of the Haskell standard library is here." CVS contains edison and some Monads hbase (Ashley Yakeley) "Common Haskell code for other semantic.org projects, and other useful things." CVS contains a number of good-looking modules (Org.Org.Semantic.*), among other things HBase.Text.UTF8. haskell-libs Haskell User-Submitted Libraries "Haskell User-Submitted Libraries includes anything we can get our hands on and clean up for general use, as well as new libraries that would be useful to the general Haskell community. Submit your libs, or join the project to create needed libs!" CVS contains Imap.hs haskell-i18n (the latest addition :) Perhaps we should try and merge these, is there any point in having multiple projects and repositories when we have hierarchical libraries? Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

4 4

Re: [Haskell-i18n] SourceForge Project Active
by Ashley Yakeley 29 Aug '02

29 Aug '02

At 2002-08-29 02:31, Martin Norbäck wrote: >Perhaps we should try and merge these, is there any point in having >multiple projects and repositories when we have hierarchical libraries? Mine's a bit "experimental" and probably won't play all that well with others, since it is intended to replace the Prelude. It's intended to be very precise and pedantic, as well as a bit more general in places. I'm even considering replacing the "Monad" class. -- Ashley Yakeley, Seattle WA

1 0

RE: Adding replicateM / replicateM_ to Control.Monad
by Simon Marlow 29 Aug '02

29 Aug '02

> > The following is what I intend to commit. There's a gratuitious > > foldM_ as well. > > You forgot to include the diffs for the documentation :-) No he didn't, the diffs were empty since that module has no documentation yet... 0.5 * :-) (unless you count the library report, but that's not subject to change, and it describes the Monad library which is different from Control.Monad). If anyone requires a diversion tactic from what they are currently doing, spending an afternoon taking documentation from the Library Report and Haddock-ising it into the sources in fptools/libraries/base would be incredibly useful. I made a start on the Prelude, but didn't get very far. Cheers, Simon

1 0

Adding repeatM / repeatM_ to Control.Monad
by Volker Stolz 29 Aug '02

29 Aug '02

Are there any objections to adding abbreviations for repeatM = sequence.replicate and repeatM_ = sequence_.replicate to Control.Monad? I think they are convenient in the same way many others are. Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME

3 4

RE: [Haskell-i18n] SourceForge Project Active
by Simon Marlow 29 Aug '02

29 Aug '02

> Where should a UTF-8 module be put? Text.UTF8? See http://www.haskell.org/~simonmar/lib-hierarchy.html (I really ought to put this in the repository somewhere). Text encodings are in Text.Encoding at the moment. I think we should start with lazy steam encoders/decoders, and later add monadic versions and ones that work with arrays. For GHC, we'll want some really low-level ones that work on ByteArray# for use in the I/O libraries, but that can come later (maybe use libiconv?). Cheers, SImon

1 0

Re: [Haskell-i18n] SourceForge Project Active
by Martin Norbäck 29 Aug '02

29 Aug '02

tor 2002-08-29 klockan 04.20 skrev Ashley Yakeley: > A SourceForge project for the internationalisation effort is active at > <http://sourceforge.net/projects/haskell-i18n/> > > I've added my Unicode character properties code. Check it out (cvs co). Nice. Who will supply good UTF-8 code? I have some at http://www.dtek.chalmers.se/~d95mback/gettext/ but it is not in good shape. Where should a UTF-8 module be put? Text.UTF8? something like (just drafting here): Text.UTF8.encodeChar :: Char -> [Word8] -- (or Array?) Text.UTF8.encodeString :: String -> [Word8] -- (or Array?) Text.UTF8.decodeChar :: [Word8] -> Either (Char, [Word8]) Error Text.UTF8.decodeString :: [Word8] -> (String, [Word8], [Error]) Another thing, why not use the hierarchy even more, and put the sub-modules of Text.Unicode in Text.Unicode.UnicodeDefs and so on? > Feel free to contribute more useful functionality, such as encodings. Let > me know if you want to be added as a developer. I've been making everyone > an admin, I don't know if that's a good idea or not... Trust everyone until they give you a reason not to... Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

1 0

RE: Word8-Based IO
by Simon Marlow 22 Aug '02

22 Aug '02

> At 2002-08-21 02:34, Simon Marlow wrote: > > >I'd go for hGetWord8, hLookAheadWord8 and so on, but it's not a big > >deal. > > Yeah you're right. Plus I got confused with lists and arrays. > > >> hLazyGetArray :: Handle -> IO [Word8] > > > >Other suggestions: hGetContentsRaw, hGetWord8Contents > > hGetContents is the only lazy IO function isn't it? I don't really > approve of lazy IO and I was hoping to stigmatise the name > with "lazy" much as the unsafe functions have "unsafe". hGetContents, getContents, and readFile are the lazy functions. Actually I think lazy I/O is highly unsavoury myself, but I'm guessing there would be strong opposition to changing these names to include the word "lazy". Cheers, Simon

1 0

RE: Word8-Based IO
by Ashley Yakeley 22 Aug '02

22 Aug '02

At 2002-08-21 02:34, Simon Marlow wrote: >I'd go for hGetWord8, hLookAheadWord8 and so on, but it's not a big >deal. Yeah you're right. Plus I got confused with lists and arrays. >> hLazyGetArray :: Handle -> IO [Word8] > >Other suggestions: hGetContentsRaw, hGetWord8Contents hGetContents is the only lazy IO function isn't it? I don't really approve of lazy IO and I was hoping to stigmatise the name with "lazy" much as the unsafe functions have "unsafe". -- Ashley Yakeley, Seattle WA

1 0

RE: Word8-Based IO
by Simon Marlow 21 Aug '02

21 Aug '02

> Was there any kind of consensus emerging on this? Leaving aside what > might be done with the Char-based functions (and people seem to think > they're fine as is) I'd like to suggest the following: > > * System.IO: addition of new Word8-based functions > > hGetOctet :: Handle -> IO Word8 > hLookAheadOctet :: Handle -> IO Word8 > hPutOctet :: Handle -> Word8 -> IO () I'd go for hGetWord8, hLookAheadWord8 and so on, but it's not a big deal. > hPutArray :: Handle -> [Word8] -> IO () There are currently these two functions in Data.Array.IO: hGetArray :: Handle -> IOUArray Int Word8 -> Int -> IO Int hPutArray :: Handle -> IOUArray Int Word8 -> Int -> IO () turning an IOUArray Int Word8 into [Word8] is accomplished by Data.Array.IArray.elems. > hLazyGetArray :: Handle -> IO [Word8] Other suggestions: hGetContentsRaw, hGetWord8Contents > ...as per hGetChar, hLookAhead, hPutChar, hPutStr and hGetContents. > > hGetArrayBlock :: Handle -> Int -> IO [Word8] > hGetArrayReady :: Handle -> Int -> IO [Word8] > > hGetArrayBlock would read so many octets from the handle, up > to the EOF. > hGetArrayReady would read so many octets from the handle, up > to the EOF > or octets not ready. The semantics would be something like this: We used to have hGetBuf and hGetBufFull in IOExts, which are analogous to your hGetArrayReady and hGetArrayBlock respectively. I forget why exactly, but we removed hGetBufFull and made hGetBuf behave as the blocking version. Hmm, I'm not sure about these functions returns lists. Arrays seem more natural to me, also given that we have nice overloaded support for arrays which makes conversion to/from lists painless. > ...but I expect they should be implemented natively. > > hSetFileSize :: Handle -> Integer -> IO () > > There's currently no way to set the size of a file. > hSetFileSize would truncate the file or pad with zero octets. Yes, we should have this too. > * Network.Socket > > The send & receive functions don't do any kind of character > interpretation do they? I suggest these functions be given > new types (and > probably new names, as I suppose we'll need the old ones for > compatibility): > > sendTo :: Socket -> [Word8] -> SockAddr -> IO Int > recvFrom :: Socket -> Int -> IO ([Word8], Int, SockAddr) > send :: Socket -> [Word8] -> IO Int > recv :: Socket -> Int -> IO [Word8] Yes, sounds fine. Cheers, Simon

1 0

Word8-Based IO
by Ashley Yakeley 21 Aug '02

21 Aug '02

Was there any kind of consensus emerging on this? Leaving aside what might be done with the Char-based functions (and people seem to think they're fine as is) I'd like to suggest the following: * System.IO: addition of new Word8-based functions hGetOctet :: Handle -> IO Word8 hLookAheadOctet :: Handle -> IO Word8 hPutOctet :: Handle -> Word8 -> IO () hPutArray :: Handle -> [Word8] -> IO () hLazyGetArray :: Handle -> IO [Word8] ...as per hGetChar, hLookAhead, hPutChar, hPutStr and hGetContents. hGetArrayBlock :: Handle -> Int -> IO [Word8] hGetArrayReady :: Handle -> Int -> IO [Word8] hGetArrayBlock would read so many octets from the handle, up to the EOF. hGetArrayReady would read so many octets from the handle, up to the EOF or octets not ready. The semantics would be something like this: hGetArrayBlock h 0 = return []; hGetArrayBlock h n = do { eof <- hIsEOF h; if eof then return [] else do { first <- hGetOctet; rest <- hGetArrayBlock h (n - 1); return (first:rest); }; }; hGetArrayReady h 0 = return []; hGetArrayReady h n = do { ready <- hReady h; if not ready then return [] else do { first <- hGetOctet; rest <- hGetArrayReady h (n - 1); return (first:rest); }; }; ...but I expect they should be implemented natively. hSetFileSize :: Handle -> Integer -> IO () There's currently no way to set the size of a file. hSetFileSize would truncate the file or pad with zero octets. * Network.Socket The send & receive functions don't do any kind of character interpretation do they? I suggest these functions be given new types (and probably new names, as I suppose we'll need the old ones for compatibility): sendTo :: Socket -> [Word8] -> SockAddr -> IO Int recvFrom :: Socket -> Int -> IO ([Word8], Int, SockAddr) send :: Socket -> [Word8] -> IO Int recv :: Socket -> Int -> IO [Word8] -- Ashley Yakeley, Seattle WA

2 1