- Libraries - Haskell.org

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 23 Jun '06

23 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 14 Jun '06

14 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 14 Jun '06

14 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

Cabal package feature request [was: Streams 0.1e released]
by Robert Dockins 09 Jun '06

09 Jun '06

[thread hijacked and moved to libraries] On Jun 8, 2006, at 11:00 AM, Bulat Ziganshin wrote: > Hello > > I released Streams library version 0.1e. Changes are: > > - Fixed bug: "openFD name WriteMode" don't truncated files on unixes > * Full library now released under BSD3 license, thanks to John Goerzen > + Now cabalized, thanks to Jeremy Shaw > > Download: http://freearc.narod.ru/Streams.tar.gz > Docs: http://haskell.org/haskellwiki/Library/Streams > > > btw, my cabal file contain line: > > Build-Depends: base, Win32, template-haskell > > if i correctly understand, this will not work on unix systems, while > without Win32 package program can't be compiled on my windows box. > what i can do here? only provide two separate cabal files - one for > unix, one for windows and give to user text instructions about > manual renaming of appropriate file? This brings up a feature I have sometimes wanted from Cabal. I'd like to be able to say the following: "Cabal, find and use package X if it exists. Furthermore, when CPPing source code, set a #define HAS_PACKAGE_X so I can do conditional compilation based on the (non-) avaliablility of package X". Is this possible? Difficult? It seems like a nice way to handle a number of problems, including platform- dependencies (as here) and optional features with external dependencies. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 1

error vs Maybe in Collections package
by Jean-Philippe Bernardy 08 Jun '06

08 Jun '06

Good idea. I added a ticket. http://cvs.haskell.org/trac/ghc/ticket/792 If there is no taker I'll try to do it this weekend. Cheers, JP. On 6/6/06, Robert Dockins <robdockins(a)fastmail.fm> wrote: > > On Jun 6, 2006, at 9:57 AM, David F. Place wrote: > > > It bothers me that the functions findMin, findMax, deleteFindMin > > and deleteFindMax are error when applied to the empty set in > > various types of collections. Shouldn't they return Maybe? > > > FYI, Edison has operations that generalize 'deleteFind*' (named > viewMin/viewMax) which call 'fail' in an arbitrary monad when applied > to an empty collection; obviously, these can be instantiated at type > 'Maybe'. > > http://www.eecs.tufts.edu/~rdocki01/docs/edison/Data-Edison- > Coll.html#v%3AminView > > > > -------------------------------- > > David F. Place > > mailto:d@vidplace.com > > > Rob Dockins > > Speak softly and drive a Sherman tank. > Laugh hard; it's a long way to the bank. > -- TMBG > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

2 1

error vs Maybe in Collections package
by David F. Place 07 Jun '06

07 Jun '06

It bothers me that the functions findMin, findMax, deleteFindMin and deleteFindMax are error when applied to the empty set in various types of collections. Shouldn't they return Maybe? -------------------------------- David F. Place mailto:d@vidplace.com

2 1