- Haskell - Haskell.org

a breaking monad
by Hal Daume 01 Aug '03

01 Aug '03

i've noticed in a lot of my imperative-looking monadic code, i have lots of stuff that looks like: > ... = do > q <- some test > if q > then return some constant > else do > major code body here lots of these things embedded makes the code hard to read and introduces way too much indentation (i'm one of those who doesn't like curly braces). one solution to this is to write it as: > ... = do > q <- some test > if q then return some constant else do > major code body here but this is ugly, IMO :). my solution was to fashion a monad transformer that supports a break statement. basically, it looks like: > data Break b m a = Break { runBreak :: m (Maybe b, a) } > > instance MonadTrans (Break b) where > lift x = Break $ do a <- x; return (Nothing, a) > > instance Monad m => Monad (Break b m) where > return a = Break $ return (Nothing, a) > b >>= k = Break $ runBreak b >>= \ (broken, a) -> > case broken of > Nothing -> runBreak (k a) > Just br -> return (Just br, undefined) > > breakable :: Monad m => Break a m a -> m a > breakable b = runBreak b >>= \ (broken, a) -> > case broken of > Nothing -> return a > Just br -> return br > > break :: Monad m => b -> Break b m a > break b = Break (return (Just b, undefined)) essentially you introduce code blocks with the "breakable" function and then can break with the break function. a useful combinator i've found is: > breaksTo :: Monad m => m Bool -> b -> Break b m () > breaksTo k b = lift k >>= \x -> if x then break b else return () using this, you can write stuff which looks like: > test1 :: IO [String] > test1 = breakable $ do > lift $ putStrLn "Enter something, or nothing to quit:" > l <- lift $ getLine > when (null l) $ break [] > rest <- lift test1 > return (l:rest) > > test2 :: IO () > test2 = breakable $ repeatM $ do > x <- lift $ getLine >>= passThrough putStrLn > when (null x) $ break () > > test3 :: Handle -> IO [String] > test3 h = breakable $ do > hIsEOF h `breaksTo` [] > lift $ do > l <- hGetLine h > rest <- test3 h > return (l:rest) where passThrough and repeatM are: > repeatM :: Monad m => m () -> m () > repeatM x = x >> repeatM x > > passThrough :: Monad m => (a -> m b) -> a -> m a > passThrough f a = f a >> return a so, my questions are: does this exist in some other form I'm not aware of? is there something fundamentally broken about this (sorry for the pun)? any other comments, suggestions? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

3 3

Submission deadline SNPD03 approaching
by Annette Stümpel 01 Aug '03

01 Aug '03

============================================================== CALL FOR PAPERS Fourth International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD03) October 16-18, 2003 Luebeck, Germany http://www.isp.uni-luebeck.de/snpd03/index.htm ============================================================== Scope and Topics ================ The conference provides an international forum for scientists to present research results in the areas of software engineering, artificial intelligence, networking and parallel/distributed computing. The conference particularly welcomes contributions at the junction of theory and practice disseminating basic research with immediate impact on practical applications. The conference will cover a broad range of topics including theory, methods, applications, and tools. The conference concentrates on software issues and is structured into the following tracks: Software Engineering and Information Engineering Component-Based Software Engineering Internet Technology and Applications Information Management Systems Software Engineering Education Parallel and Distributed Computing Communication Systems and Networks Mobile and Wireless Computing Visual and Multimedia Computing Artificial Intelligence, Data Mining, Knowledge Discovery Neural Networks and Genetic Algorithms Economic and Financial Systems Control Systems Image, Acoustic, Speech and Signal Processing Venue ===== After Reims (2000), Nagoya (2001) and Madrid (2002) this years SNPD conference will be held at the Moevenpick Hotel in Luebeck. The Hanseatic town of Luebeck is located in Northern Germany close to the Baltic Sea with frequent train connections to major airports. The medieval town was appointed as world cultural heritage by the United Nations. Important Deadlines =================== Full Paper Submission: August 15, 2003 Notification of Acceptance: September 10, 2003 Camera-ready Papers: September 24, 2003 Conference Proceedings & Journal ================================ Accepted papers limited to 8 pages will be published in the conference proceedings with ISBN. After the conference a selection of excellent papers will be published in a special issue of the International Journal of Computer and Information Science. For further details, please visit the conference web page http://www.isp.uni-luebeck.de/snpd03/index.htm.

1 0

Text I/O library proposal, first draft
by Ben Rudiak-Gould 01 Aug '03

01 Aug '03

[Crossposted to Haskell and Libraries. Replies to Libraries.] {- Good things about this text library design: * Efficient implementation should be straightforward * Character coder interface is public, so users can supply their own encodings, or write coder transformers (there are some in the proposal) Bad things: * There's no way to implement fgetpos/fsetpos type functionality, because coders don't expose their internal state. (In fact, there would need to be a way to explicitly copy the state, since it may well include IORefs, Ptrs, etc.) Is this a serious problem? -} module System.TextIOFirstDraft (...) where -- A BlockRecoder takes source and destination buffers and does some sort -- of translation between them. It returns the number of values (not -- bytes!) consumed and the number of values produced. It does not have to -- empty the input buffer or fill the output buffer on each call, but it -- must do something (i.e. it's not acceptable to return (0,0)). Coders -- will in general have internal state which is updated on each call. type BlockRecoder from to = Ptr from -> BlockLength -> Ptr to -> BlockLength -> IO (BlockLength,BlockLength) type TextEncoder = BlockRecoder Word32 Octet type TextDecoder = BlockRecoder Octet Word32 -- IO TextEncoder and IO TextDecoder below denote "coder factories" which -- produce a new coder in its initial state each time they're called. compatibilityEncoder :: IO TextEncoder -- "mod 256" currentLocaleEncoder :: IO TextEncoder iso88591Encoder :: IO TextEncoder latin1Encoder = iso88591Encoder utf8Encoder, utf16BEEncoder, utf16LEEncoder, utf32BEEncoder, utf32LEEncoder :: IO TextEncoder compatibilityDecoder :: IO TextDecoder currentLocaleDecoder :: IO TextDecoder iso88591Decoder :: IO TextDecoder latin1Decoder = iso88591Decoder utf8Decoder, utf16BEDecoder, utf16LEDecoder, utf32BEDecoder, utf32LEDecoder :: IO TextDecoder -- An attempt at supporting setlocale-type locale strings. lookupEncoder :: String -> Maybe (IO TextEncoder) lookupDecoder :: String -> Maybe (IO TextDecoder) -- prependBOM takes an existing UTF encoder and causes it to prepend -- a BOM (byte-order mark) to its output. autodetectUTF takes an existing -- decoder and modifies it to check for a BOM, switching to the -- appropriate type of UTF decoding if one is found. prependBOM :: IO TextEncoder -> IO TextEncoder autodetectUTF :: IO TextDecoder -> IO TextDecoder -- Attaches a TextInputChannel to the supplied InputChannel. After -- this operation the InputChannel should be considered owned by the -- TextInputChannel; any attempt to use it directly will cause -- unpredictable results. This takes a decoder factory rather than a -- decoder to prevent the error of attaching the same decoder to more than -- one channel. icAttachTextDecoder :: InputChannel -> IO TextDecoder -> IO TextInputChannel ticGetChar :: TextInputChannel -> IO Char ticGetLine :: TextInputChannel -> IO String ticLazyGetContents :: TextInputChannel -> IO String ocAttachTextEncoder :: OutputChannel -> IO TextEncoder -> IO TextOutputChannel tocPutChar :: TextOutputChannel -> Char -> IO () tocPutStr :: TextOutputChannel -> String -> IO () tocPutStrLn :: TextOutputChannel -> String -> IO () -- ... etc ... -- Ben

2 1

RE: Text I/O library proposal, first draft
by Hal Daume 31 Jul '03

31 Jul '03

Hi Ben, > Bad things: > > * There's no way to implement fgetpos/fsetpos type functionality, > because coders don't expose their internal state. (In fact, there > would need to be a way to explicitly copy the state, since it may > well include IORefs, Ptrs, etc.) Is this a serious problem? Yes! This is an enormously serious problem. At least for me. It's not a problem for writing files, but I really really really need this functionality when reading files. Reason: I'm often tooling around in very large (1gb or greater) files which happen to be sorted on some sort of index and I need to do binary search in them. To load all the file into Haskell or to do linear search is impossible. Other than that, I rather like the design. - Hal

2 1

RE: a breaking monad
by Hal Daume 31 Jul '03

31 Jul '03

> This looks like a bizarre rendition of the Error/Exception monad. Yes, of course. *Hal slaps himself* Thanks. > Also, your motivating example is ambiguous. I think you mainly care > about the case where the test is testing for some "exceptional" > condition. I personally wouldn't want to use this style every place I > would use an if. Definitely not! :) - Hal

1 0

Raw I/O library proposal, second (more pragmatic) draft
by Ben Rudiak-Gould 31 Jul '03

31 Jul '03

[Crossposted to Haskell and Libraries. Replies to Libraries.] -- More comments, please. Bad names? Important missing functionality? -- Still unimplementable? module System.RawIOSecondDraft (...) where data File -- now essentially a file handle data InputChannel -- renamed for less confusing function prefixes data OutputChannel -- | A Moniker is a slight generalization of a pathname. In principle this -- could be extended to support URIs, host:port SSL connections, memory -- buffers, and so on, though it might be better to give them their own -- functions. -- "Compatibility" refers to compatibility with existing Haskell -- implementations, which treat Char values like octets. RawPathname is -- there to avoid an octet -> string -> octet translation in cases where -- that's undesirable. This is slightly problematic on Win32, where -- pathnames really *are* strings. type Moniker = Pathname String | CompatibilityPathname String | RawPathname [Octet] {- if supported, maybe: | DirectoryEntry Directory String | ResourceFork Moniker | NamedFork String Moniker -} -- * File and channel creation functions -- I still use "lookup" rather than "open" to emphasize that there's an -- irreversible and time-dependent translation going on here. lookupFileRO :: Moniker -> IO File lookupFileRW :: Moniker -> IO File lookupInputChannel :: Moniker -> IO InputChannel lookupOutputChannelAppend :: Moniker -> IO OutputChannel createOutputChannel :: Moniker -> IO OutputChannel -- * File access functions -- | Indicates that a File value will never be used again. Calling -- fRelease is not mandatory, but it assists the implementation in -- closing file handles as early as possible. It is an error to use the -- argument in any way after making this call. fRelease :: File -> IO () -- | Returns a new File value which is identical to the argument except -- that calling fRelease on one does not affect the other. fDup :: File -> IO File -- | Returns True if fRelease has not been called on the File value. fIsValid :: File -> IO Bool -- | Reads from a file to a memory buffer. If the read extends beyond the -- end of the file, the extra buffer space is filled with zeroes and the -- return value is the number of octets which actually came from the file. -- Otherwise the return value is the same as the length argument. fReadBuf :: File -> FilePos -> BlockLength -> Ptr Word8 -> IO BlockLength -- | Writes to a file from a memory buffer. fWriteBuf :: File -> FilePos -> BlockLength -> Ptr Word8 -> IO () -- | Returns the current size of the file. fGetSize :: File -> IO FilePos -- | If the size argument is less than the current file size, the file size -- is reduced, destroying any octets beyond the new end of the file. If the -- size argument is greater than the current file size, the file may or may -- not be increased in length. If it is increased, the contents of the file -- beyond the old end of file are undefined. fSetSize :: File -> FilePos -> IO () fIsReadable :: File -> IO Bool fIsWritable :: File -> IO Bool -- * Layering channels on files -- | Opens an input channel (octet source) which reads from the specified -- file, starting at the specified offset. Effectively fDups the File -- argument, so the original File value may be released at any later time -- without affecting the channel. fInputChannelFrom :: File -> FilePos -> IO InputChannel -- | Opens an output channel (octet source) which writes to the specified -- file, starting at the specified offset. Because input and output -- channels may be buffered, the result of an fRead call on a file region fOutputChannelFrom :: File -> FilePos -> IO OutputChannel -- | Like fInputChannelFrom, but stops after reading the octet which -- immediately precedes the second FilePos argument, or at end of file, -- whichever comes first. fInputChannelFromTo :: File -> FilePos -> FilePos -> IO InputChannel -- * Standard channels stdin :: InputChannel stdout, stderr :: OutputChannel -- * Input channel access functions -- | Indicates that no more octets will be read from the InputChannel. -- It is not necessary to call this function if all available octets -- have already been read. icRelease :: InputChannel -> IO () icGet :: InputChannel -> IO Octet icGetBuf :: InputChannel -> Ptr a -> BlockLength -> IO BlockLength icAtEnd :: InputChannel -> IO Bool -- | Returns the File associated with its argument, if any. May fail even -- on a channel created with fInputChannel, since the channel is permitted -- to release its internal File value on reaching end-of-input. May succeed -- on a channel not created with fInputChannel, such as stdin. The caller -- is responsible for releasing the returned File. icTellFile :: InputChannel -> IO Maybe File -- | Returns the current read offset in the underlying file, if any. May -- succeed even if icTellFile fails. Always succeeds if the channel was -- created on top of a File. icTellPos :: InputChannel -> IO (Maybe FilePos) icPeek :: InputChannel -> IO Octet icReady :: InputChannel -> IO Bool icGetBuffering :: InputChannel -> IO BufferMode icSetBuffering :: InputChannel -> BufferMode -> IO () icIsTerminal :: InputChannel -> IO Bool -- | Read an InputChannel lazily as a list of octets. It is an error to -- read from the InputChannel directly after this is called. icLazyGetContents :: InputChannel -> IO [Octet] -- * Output channel access functions ocRelease :: OutputChannel -> IO () ocPut :: OutputChannel -> Octet -> IO () ocPuts :: OutputChannel -> [Octet] -> IO () ocPutBuf :: OutputChannel -> Ptr a -> BlockLength -> IO () ocTellFile :: OutputChannel -> IO (Maybe File) ocTellPos :: OutputChannel -> IO (Maybe FilePos) ocGetBuffering :: OutputChannel -> IO BufferMode ocSetBuffering :: OutputChannel -> BufferMode -> IO () ocFlush :: OutputChannel -> IO () ocIsTerminal :: OutputChannel -> IO Bool -- Ben

1 0

New Haskell and FP merchandise logos for review
by Fritz K Ruehr 31 Jul '03

31 Jul '03

John Peterson recently handed over control of the Haskell Merchandise area of haskell.org to me and, in celebration, I've created a bunch of provisional designs for new Haskell, FP and types-related "swag". The logos include the original and new haskell.org logos and about 15 others, designed around traditional T-shirt logo aesthetics (puns, strident dogmatic posturings and mild sexual suggestion). I've tried to represent a range of Haskell community viewpoints, from pure/theory to systems/"hacker". (A couple of the designs will likely appeal to a very limited audience, for example the catamorphism evaluation law expressed with *real* banana brackets ... ). For now the logos are just graphic files in PNG format, available from this URL, linked from thumbnails and accompanied by a few comments: <http://www.willamette.edu/~fruehr/logos/intro.html> My intent is to convert them, as called for, into products on the CafePress site and link them in via the Haskell Merchandise page (see the docs at the URL for more details). I'm not sure exactly what the protocol for selecting logo/product combinations should be, but for now I will just take e-mails from people (if this becomes laborious maybe a Wiki page would be better). I am open to suggestions for changes or additions, or to other peoples' designs. Note that neither I nor haskell.org will make any profit, but there is some possibility of using a modest charge to off-set a more convenient CafePress set-up (again, go to the URL for details). -- Fritz Ruehr PS: replies to haskell-cafe please! PPS to whomever requested the new haskell.org logo: sorry for the delay, I will consider your request as first in the queue and open a new store presently. But write me with your specific interest for a product (i.e., white t-shirt, grey t-shirt, tank-top, etc.).

2 1

RE: Ann: HAllInOne bug fix release
by Simon Peyton-Jones 31 Jul '03

31 Jul '03

Something very odd is going on. GHC does not generate programs than run 3x faster between GHC versions. If, perhaps, you compiled both without -O, no cross-module inlining takes place. That would account for a big slow down when using separate compilation. I see you use -O2 this time. I don't know why the all in one version might go slower though S | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Hal Daume | Sent: 31 July 2003 00:23 | To: Wolfgang Jeltsch; The Haskell Mailing List | Subject: RE: Ann: HAllInOne bug fix release | | Ah, apparently it is not (at least not the Cygwin version). | | I recompiled NHC with GHC -O2, both the separate compilation version and | the all-in-over version. Averaged over five runs, we see that the | separate compilation version is actually *faster* than the ai1 version: | | standard nhc compiled with ghc: | | real 0m27.167s | user 0m9.991s | sys 0m1.304s | | nhc all-in-one: | | real 0m31.411s | user 0m10.007s | sys 0m1.299s | | | | i am completely unable to explain this. someone want to hazard a guess? | | - hal, who is a bit disappointed now :( | | -- | Hal Daume III | hdaume(a)isi.edu | "Arrest this man, he talks in maths." | www.isi.edu/~hdaume | | | > -----Original Message----- | > From: haskell-admin(a)haskell.org | > [mailto:haskell-admin@haskell.org] On Behalf Of Wolfgang Jeltsch | > Sent: Wednesday, July 30, 2003 2:59 PM | > To: The Haskell Mailing List | > Subject: Re: Ann: HAllInOne bug fix release | > | > | > On Wednesday, 2003-07-30, 23:36, CEST, Hal Daume III wrote: | > > [...] | > | > > A few people have asked me for speed-up results from | > All-In-One-ifying code, | > > so here's a good one. We take two versions of NHC. One is | > the original | > > binary distribution and the other is the All-In-One-ified | > version, compiled | > > by GHC. | > | > Hi, | > | > is the original binary distribution compiled with GHC? If | > not, the speed-up | > may also be the result of using a different compiler (i.e., GHC). | > | > > [...] | > | > Wolfgang | > | > _______________________________________________ | > Haskell mailing list | > Haskell(a)haskell.org | > http://www.haskell.org/mailman/listinfo/haskell | > | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 1

RE: Ann: HAllInOne bug fix release
by Graham Klyne 31 Jul '03

31 Jul '03

At 08:44 31/07/03 +0100, Simon Peyton-Jones wrote: >I don't know why the all in one version might go slower though Virtual memory thrashing? (Hal did say something about needing lots of RAM.) #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

Ah, apparently it is not (at least not the Cygwin version). I recompiled NHC with GHC -O2, both the separate compilation version and the all-in-over version. Averaged over five runs, we see that the separate compilation version is actually *faster* than the ai1 version: standard nhc compiled with ghc: real 0m27.167s user 0m9.991s sys 0m1.304s nhc all-in-one: real 0m31.411s user 0m10.007s sys 0m1.299s i am completely unable to explain this. someone want to hazard a guess? - hal, who is a bit disappointed now :( -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of Wolfgang Jeltsch > Sent: Wednesday, July 30, 2003 2:59 PM > To: The Haskell Mailing List > Subject: Re: Ann: HAllInOne bug fix release > > > On Wednesday, 2003-07-30, 23:36, CEST, Hal Daume III wrote: > > [...] > > > A few people have asked me for speed-up results from > All-In-One-ifying code, > > so here's a good one. We take two versions of NHC. One is > the original > > binary distribution and the other is the All-In-One-ified > version, compiled > > by GHC. > > Hi, > > is the original binary distribution compiled with GHC? If > not, the speed-up > may also be the result of using a different compiler (i.e., GHC). > > > [...] > > Wolfgang > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 1