June 2006 - Libraries

RE: Idea to allow people to comment on Haskell docs
by Simon Peyton-Jones 09 Jan '07

09 Jan '07

| I've had a go at patching Haddock to put a link on the page for each | module. It's controlled by an optional --wiki=URL flag. | | As an example, I used this with the (devel version of the) Gtk2Hs docs: | | http://haskell.org/gtk2hs/docs/devel/ | | For example this page: | | http://haskell.org/gtk2hs/docs/devel/Graphics-Rendering-Cairo-SVG.html It looks great! But I'd never have found the link if you hadn't pointed me at it. Rather than "Wiki" say "User comments". And I think the per-entry [User comment] link is essential. Typically people are going to be looking at a particular thing. For example, here http://haskell.org/gtk2hs/docs/devel/Graphics-Rendering-Cairo-SVG.html#v %3AsvgRenderFromString is where I'd look for the link for svgRenderFromString. Does MediaWiki support anchors in the middle of a page? That's essential here -- we want one Wiki page for one Haddock page. On a closely related matter, Benjamin Pierce told me how often he wished that there was a link from the Haddock documentation to the source code for a function. Especially for Prelude functions, he's dead right. So another really useful Haddock enhancement would be the ability to add links to the source code from the Haddock docs --- again on a per-function basis. Do you feel like adding that too? Where should the code live? I'd suggest snap-shoting it at the moment that the Haddock docs are generated, and putting the files with the Haddock docs. Simon

12 15

[RFC] Network.Socket: change get/setSocketOption
by Bertram Felgenhauer 27 Jul '06

27 Jul '06

Hi, (This mail is related to http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/3788 ) What I'm proposing is to make SocketOption a proper ADT and change get- and setSocketOption to functions that take type constructors instead of tags as arguments, i.e. getSocketOption :: Socket -> (a -> SocketOption) -> IO a setSocketOption :: Socket -> (a -> SocketOption) -> a -> IO () To make that work, the two functions are implemented in a type class. I'll attach a patch bundle (in darcs send -o format) of two patches: 1) implement the infrastructure for this change. it is mostly backward compatible: As long as code doesn't explicitely mention the SocketOption type, it should work without modifications. 2) give the options more sensible types. -- this breaks existing code. For example, setSocketOption sock ReuseAddr 1 becomes setSocketOption sock ReuseAddr True (the patch includes the necessary fixes for the network package) What's missing is a solution for the problem that prompted this change, namely setting struct time_val values. To do that, I'd need some Storable type that maps to struct time_val. I think Network.* is not the proper place to implement that. Where should it go? - Foreign.C.Types - not generally useful enough, I think. - System.Time - not portable enough? - System.Posix.* - seems to be the right place to me. related stuff: http://cryp.to/hsdns/System/Posix/GetTimeOfDay.hsc -- quite close to what I'd like to have; conversions to, say, System.Time.ClockTime would be useful though. http://www.haskell.org/~simonmar/time/NewTime.hsc -- looks like a new System.Time to me; the CTimeVal handling seems to be identical to System.Time though Comments, questions and suggestions are welcome. Bertram P.S. thanks to heatsink on #haskell for the suggestion of passing constructors to the functions. That simplified the code a lot at a small loss of safety, and made the interface more similar to the old one.

2 3

QDBM / Hyper Estraier bindings for haskell
by Jun Mukai 28 Jun '06

28 Jun '06

Hello all, I pleased to announce the QDBM and Hyper Estraier bindings for haskell. If you are interested in, they can be obtained from http://www.city5.org/haskellprog/qdbm/ http://www.city5.org/haskellprog/hstraier/ These are darcs repository, so you can obtain them via darcs. These bindings are already cabalized, you have to type only as follows to install them: % runghc ./Setup.hs configure % runghc ./Setup.hs build # runghc ./Setup.hs install the online API documentation generated by haddock is also shown at http://www.city5.org/doc/qdbm/ http://www.city5.org/doc/hstraier/ * What is QDBM? QDBM, stands for Quick DBM, is a database module similar to GDBM or NDBM or Berkeley-DB, but the specific feature is performance and simple API. By now, my QDBM binding supports only Depot, Curia, Villa, and a part of Cabin. QDBM can handle several kinds of DBM, and Depot and Curia and Villa is a name of each DBM. Depot is a basic DBM. Curia is a `large' DBM and bundles many Depot files for its internal implementation. Curia also can store `large objects' as a file. Villa is B+Tree DBM and uses a function to compare keys. Villa also has faculty of cursors and transactions. Vista, `large' version of Villa, is not supported. Odeum, inverted index, is also not supported. Cabin is auxiliary functions collection module and contains a kind of utility functions of string operation such as Base64 encode/decode, URL encode/decode, quoted printable encode/decode, mime analysis, csv reading and so on. These functions will be useful for many Haskellers, and run faster. If you are interested in QDBM itself, see http://qdbm.sourceforge.net/ * What is Hyper Estraier Hyper Estraier is a full-text search system using QDBM. You can search documents according to the keywords specified and so on. My Hyper Estraier binding supports only `core' API. Core API can handle document object, conditionals, and full-text search DB. Hyper Estraier itself has `node' API, which invokes search queries to remote servers using HTTP. Node API is not supported yet in my binding now. If you are interested in Hyper Estraier itself, see http://hyperestraier.sourceforge.net/ Any comments are welcome. Thanks, Jun Mukai mukai(a)jmuk.org

2 2

Streams 0.2 - beta testing started. Good replacement for NewBinary and System.IO?
by Bulat Ziganshin 27 Jun '06

27 Jun '06

Hello all i'm going to beta testing of Streams 0.2 library. compared to previous version, it works several times faster, supports memory-mapped files, has more orthogonal API and numerous internal changes. moreover, it can be a great replacement for NewBinary and System.IO modules (more on this below) === For users of Streams 0.1 library === new version is not yet documented, and that is not big problem, because at this moment i'm mostly interested in testing it as replacement of previous library version. if you already use Streams, please check that with new version everything is still ok comparing to Streams 0.1, there a few API changes: - with* stream transformers renamed to add*: withEncoding should be changed to addEncoding withLocking -> addLocking bufferBlockStream -> "addBuffering >>= addInlining" bufferMemoryStream -> addInlining - with* functions now has more regular names: withEncoding' -> withEncoding withLocking' -> withLocking withBuffering -> "withBuffering $ \h -> withInlining h" withMemBuffering -> withBuffering - in binary i/o, upper-case LE/BE suffixes now used in all functions: putWord16be -> putWord16BE getWord64le -> getWord64LE and so on - custom serialization routines for arrays, lists and strings now has more regular names, look at comment titled "Serialization for arrays of different types" in Data.AltBinary.Custom.Array module - Stream class now split into the Stream, BlockStream, MemoryStream, ByteStream and TextStream classes; MemoryStream interface is slightly changed if i missed something that breaks backward compatibility - please let me know. and please, find the time and try new library version with your code before the library will be released === As replacement for NewBinary library and various Binary modules === Streams 0.2 includes full emulation of NewBinary library API. If you already use one of these modules in your program, just replace "import NewBinary.Binary" with "import Data.AltBinary" and enjoy! all the differences i know is: - argument order in "putBits" are different, my order is more convenient for partial application - format of written data is incompatible between libraries. on the other side, data format used in my lib is CPU-independent, so you can write data on 32-bit CPU and then read them back on 64-bit one One of most pleasing features of this emulation is that it works from several to several tens times faster than original :) === As (particular) replacement for System.IO module === If you are interested in getting several times speed improvement, you can try to replace "import System.IO" in your program with "import System.Stream.IO" depending on how you are lucky, this may or may not work. Currently this emulation don't supports LineBuffering and NoBuffering, and several functions (hLookAhead, hTellPos...). Support for stdin/stdout/stderr and appropriate functions are also disabled due to lack of LineBuffering support. if you really need to use them, do it through the regular Streams interface (read Example/wc.hs for details) === Downloading and installation === To install the library, you first need to install ArrayRef library: Download: http://www.haskell.org/library/ArrayRef.tar.gz Installation: run "make install" - Optionally, you can also add support for ByteStrings: - Download FPS 0.7 from repository (it's not yet released): - darcs get --partial http://www.cse.unsw.edu.au/~dons/code/fps - Compile and install it: - runhaskell Setup.hs configure - runhaskell Setup.hs make - runhaskell Setup.hs install Download: http://www.haskell.org/library/StreamsBeta.tar.gz - If you installed FPS library, rename Streams.cabal.fps into the Streams.cabal Installation: run "make install" OLD version docs: http://haskell.org/haskellwiki/Library/Streams -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

RE: Reflection API for Haskell.
by Simon Peyton-Jones 22 Jun '06

22 Jun '06

I'm all for this. But I think the design needs a bit of work. Firstly, remember that TypeReps at the moment are designed for *ground types*, that is types with no free type variables. A ground type always starts with a type constructor. So one can start with typeOf to get a TyCon. The TyCon might not be an algebraic data type; that's why the DataType type in Data.Generics.Basics has a DataRep thing. You could add that. (You'd want to add FunRep.) I think you could probably get rid of dataTypeOf entirely, incidentally. When it comes to the types of data constructors, they have *quantified* types, so you need a way to bind the type variables. I don't see that in your design. [This relates to another missing feature of the current design which is that it can't represent higher rank types, e..g typeOf f where f :: (forall a. a->a) -> Int But allowing this would required not only a higher-rank TypeRep, but having instances of Typeable at for-all types, which is an entirely un-explored area. Let's leave that aside.] So for data constructors you have type variables in their types, and I think you' have to represent that explicitly, which would in turn mean that a TypeRep is not simply an application of a TyCon. (I'm not keen on "tycoon tyvars", which I guess is your fix. The water seems deeper here. Are you sure you could not get away without representations of the constructor argument types? After all, SYB has already shown how to write serialisers and deserialisers. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Krasimir | Angelov | Sent: 30 March 2006 12:30 | To: Haskell Libraries | Subject: Reflection API for Haskell. | | Hello Guys, | | I am interested in having better Reflection API for Haskell. Currently | we have Typeable and Data classes which provide some pieces of | information about the data types at runtime. The (typeOf :: Typeable a | => a -> TypeRep) method provides runtime information about the type of | a given variable. The (dataTypeOf :: Data a => a -> DataType) provides | almost the same information but with some extras. There is some | overlap between the TypeRep and DataType types. Some pieces of | information you can get from the TypeRep, other from the DataType and | some other from both of them. There is also an information which is | inaccessible from either TypeRep and DataType. Here is a list of the | differences: | | - TypeRep contains both the TyCon and the arguments given to it. | DataType contains only the name of the TyCon. The TyCon name is | duplicated in TypeRep and in DataType. | - DataType contains the DataRep structure which gives us an | information about the available data structures. This is the only way | to access them. | - The Constr type represents data constructors at runtime. It has | information about the constructor name, the record selectors and the | fixity (prefix/infix). Unfortunately there isn't any information about | the types of its arguments. | | What I would like to see is a better Reflection API with clear | interface. My proposal is: | | -- * Type representations | TypeRep -- abstract, instance of: Eq, Show, Typeable | TyCon -- abstract, instance of: Eq, Show, Typeable | DataCon -- abstract, instance of: Eq, Show, Typeable | | -- * Construction of type representations | mkTyCon :: String -> Arity -> [DataCon] -> Fixity -> TyCon | mkTyConVar :: Int -> Arity -> TyCon | mkTyVar :: Int -> TypeRep | mkTyConApp :: TyCon -> [TypeRep] -> TypeRep | mkDataCon :: String -> [TypeRep] -> TypeRep -> [String] -> Fixity -> DataCon | | -- * Fixity representation | Fixity(..) -- instance of: Eq, Show, Typeable | defaultFixity :: Fixity | | -- * Observation of type representations | typeRepTyCon :: TypeRep -> TyCon | typeRepArgs :: TypeRep -> [TypeRep] | | -- * Observation of type constructors | tyConString :: TyCon -> String | tyConArity :: TyCon -> Int | tyConDataCons :: TypeCon -> [DataCon] | tyConFixity :: TyCon -> Fixity | | -- * Observation of data constructors | dataConString :: DataCon -> String | dataConArgs :: DataCon -> [TypeRep] | dataConResult :: DataCon -> TypeRep | dataConFields :: DataCon -> [String] | dataConFixity :: DataCon -> Fixity | | The above API is just a reorganization of the existing API but with | some extensions: | | - In the existing API there is no way to get the TyCon fixity and | arity. In the new one there are the tyConFixity and tyConArity | functions. | - The data constructors are available from the tyConDataCons function. | There isn't need for the separated DataType and DataRep types. | - The DataCon arguments and the result type are available from the | dataConArgs and dataConResult functions. | - Since the type can be polymorphic we need to have representation for | type variables. For that reason there are the mkTyVar and mkTyConVar | functions. | | The new API can be used for both the Dynamic data type implementation | and for the generic programming API. The additional information can be | used for many kinds of serialization libraries where you would like to | be sure that you are deserialising data with the same structure as | those used in your program. In addition if you have stored the data | type meta information you can have many kinds of generic tools that | can read/write the data without need to have the same types defined in | the application. | | What do you think about this kind of generalization of the existing | API in the standard package? | | Cheers, | Krasimir | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

3 2

darcs patch: add Control.Monad.STM to package.conf.in
by Bertram Felgenhauer 20 Jun '06

20 Jun '06

Mon Jun 19 09:33:02 CEST 2006 Bertram Felgenhauer <int-e(a)gmx.de> * add Control.Monad.STM to package.conf.in

2 1

Restructured version of the Streams library
by Takano Akio 15 Jun '06

15 Jun '06

Hi, I wrote an IO library, inspired by, and partly based on, Bulat Ziganshin's Streams library. The main aim of the library is to experiment with different design choices, especially emphasizing the following: * Many small classes * Iconv-friendly interface The source code and documentation can be found at: http://yogimo.sakura.ne.jp/ssc/ == Type structure The library tries to assign a different class for a different concept. For example, it distinguishes read-only streams from write-only ones, and seekable streams from non-seekable ones. As a result, the library provides a small and clean interface, so it ensures more type safety, and type signatures of stream-operating functions are able to carry more information. == Iconv friendliness Although Unicode is quickly becoming popular, there are still many widely-used, character-set-specific encodings. Therefore i18n-aware applications may have to handle a locale-specific encoding, which is not statically known. Then, using an external conversion routine, such as iconv, will be virtually the only possible way to go. The library's interface intaracts well with iconv and other c runtines. This also means that adding zlib functionality can be easy, for example. == Performance The library is currently not very fast. For example, typical repitition of putStr/getLine is 1.5x slower than the corresponding standard Handle operations. When you omit locking, the library performs roughly equally well to the standard Handle. == Any comments are welcome. Regards, Takano Akio

3 6

Partial Relax NG Compact support for HXT
by Samuel Bronson 13 Jun '06

13 Jun '06

Attached is partial support for Relax NG Compact for HXT. I haven't been working on this much in the last week and a half or so, so I thought I better send it before I forget about it entirely. (After all, unlike many of my other projects, this one actually seems to do most of what it is intended to do!) Among other things, it is missing: * Include support (couldn't figure out how to get this to work without changing the simplifier, which I am not comfortable doing without a repository) * Full annotation support -- I got frustrated with qualified names... I should really rework that part. * Nice code: the code is very ugly, especially that which relates to names It is not very tested, partly because HXT's RelaxNG validator doesn't seem to support the XML Schema Datatypes, which are very important to Relax NG Compact. (They have their own default namespace prefix xsd.) I might have done a better job if I'd looked at the section of the happy manual that relates to monadic parsers before going very far, but oh well... Comments are welcome and I'd really like to see someone try to do better -- which shouldn't be too hard. The formal grammar at the end of the spec actually looks an awful lot like a computer program... unfortunatey, it uses a slightly different flavour of XML library :-(. Another neat thing that uses Relax NG Compact is James Clark's nxml-mode and rng-validate-mode for emacs, which validates your XML as you write it, tells you what is missing as well as what you can insert. All in Emacs Lisp.

1 0

newbie question: suppressing dos window
by Maarten 13 Jun '06

13 Jun '06

Dear all, Is it somehow possible to suppress the dos window (in windows), for example to run tasks in the background? Couldn't find it anywhere in the documentation. Any suggestions appreciated. Thanks. Regards, Maarten

3 3

FW: [GHC] #794: System.Random: StdGen's genRange doesn't match its next
by Simon Peyton-Jones 13 Jun '06

13 Jun '06

Would someone who knows and cares about random numbers like to fix this bug in the Random library? Many thanks Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of GHC Sent: 12 June 2006 23:28 To: glasgow-haskell-bugs(a)haskell.org Subject: [GHC] #794: System.Random: StdGen's genRange doesn't match its next #794: System.Random: StdGen's genRange doesn't match its next -------------------------------------+-------------------------------------- Reporter: rturk(a)science.uva.nl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.4.2 Severity: normal | Keywords: Os: Unknown | Difficulty: Easy (1 hr) Architecture: Unknown | -------------------------------------+-------------------------------------- {{{ > g <- getStdGen > length $ filter (<0) $ take (10^6) $ unfoldr (Just . next) g 0 > genRange g (-2147483648,2147483647) }}} Apparently, {{{StdGen}}}'s {{{next}}} only returns non-negative values. Also, {{{StdGen}}} doesn't override de default method {{{genRange}}}. However, the System.Random docs (http://haskell.org/ghc/docs/latest/html/libraries/base/System- Random.html#v%3Anext) promise: ''The next operation returns an Int that is uniformly distributed in the range returned by genRange (including both end points), and a new generator.'' Thus, {{{StdGen}}}'s {{{next}}} violates the uniform distribution requirement. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/794> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0