- Libraries - Haskell.org

inits
by Spencer Janssen 13 Apr '06

13 Apr '06

Earlier today on the #haskell IRC channel, Tim Toorop (bolrod on #haskell) pointed out that Data.List.inits is rather slow, and proposed an alternative. After some collabrative tweaking, we came up with the following: > inits xs = [] : (zipWith take [1..] $ map (const xs) xs) This function seems to perform significantly better. For example, the program below takes about 15 seconds with the old inits, and only 3 seconds with the new version (tested with GHC 6.4.1 and -O2). > main = print $ sum $ map sum $ inits [1..7000] As this version performs much better and will work as a drop in replacement, I suggest that it be included in the hierarchical libraries. Spencer Janssen

15 55

Re: [Haskell] QuickCheck revival and Cabal
by Jean-Philippe Bernardy 11 Apr '06

11 Apr '06

Hello, I think Cabal supports versioning. If QuickCheck2 is a superset of QuickCheck1, one can expect people won't use both at a time. Therefore it seems natural to just re-use the package name, module names, etc. and just use cabal's versioning. My 2 cents, JP. On 4/11/06, Frederik Eaton <frederik(a)a5.repetae.net> wrote: > Hi, > > Why not just call it, say, Test.QuickCheck2? > > I think module names should reflect only their functionality. I don't > see how "External" or "Contrib" or "Chalmers" would say anything > useful about the functionality of the modules. > > A while ago I sent a proposal for "package mounting", which I think > would let us avoid this whole issue: > > http://www.haskell.org//pipermail/libraries/2005-June/004009.html > > I am opposed to a situation such as Java's, in which every module is > permanently fixed somewhere in a huge module hierarchy, for the > reasons I describe in the proposal (namely, in part because I don't > think that global-name-choosing should be such a fundamental part of > coding - as you said, it is a source of agony). The proposal was an > attempt to describe an alternative approach. > > I think the ideal solution would be: > > - Your code is released in a package with modules named "Batch", > "Poly", "Utils", etc., i.e. with no qualification. > > - The package has a default mount point of Test.QuickCheck. If people > want the old version, then they can specify the old package instead of > the new package on the compiler/interpreter command line. > > The response to my proposal was semi-positive, but I don't think any > work has gone towards implementing it (certainly not by myself). > > Cheers, > > Frederik > > On Tue, Apr 11, 2006 at 01:02:51PM +0200, Koen Claessen wrote: > > Dear all, > > > > For the past couple of years, I have been quietly hacking on a brand new > > version of QuickCheck with lots of cool features. I have been > > distributing copies to some friends, but have not released any official > > package. > > > > Now, after lots of peer pressure, the time has come that I want to > > release the current version as a Cabal package. > > > > I have been agonizing however over where in the module hierarchy the new > > QuickCheck package should be. > > > > There is currently an old QuickCheck version in the standard hierarchy > > in Test.QuickCheck. As the new QuickCheck is incompatible with the old > > one, I do not want to override that place. Rather, I would like to > > create my own little space in the hierarchy where the new version can > > sit and develop. > > > > It feels to me that there should be a convention that people use to add > > their own contributions to the module hierarchy without the danger of > > clashing with other packages. > > > > Proposals: > > > > Contrib.Chalmers.QuickCheck > > External.Chalmers.QuickCheck > > Chalmers.QuickCheck > > Contrib.Test.QuickCheck > > Contrib.QuickCheck > > > > The first three I like -- but not the last one; I don't want to rule out > > anyone else (except for my own colleagues :-) making their own version > > of QuickCheck and releasing it somewhere in the tree. > > > > What does one think? > > > > Regards, > > /Koen > > > > PS1. Previously discussions about this were referred to the libraries > > mailing list but I feel that this is of interest to the larger crowd too. > > > > PS2. I welcome myself back to the Haskell mailing list after years of > > inactivity :-) > > > > _______________________________________________ > > Haskell mailing list > > Haskell(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > -- > http://ofb.net/~frederik/ > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

Parsec parser for Java?
by Punyashloka Biswal 10 Apr '06

10 Apr '06

Hi Haskellers, I'm writing a program-analysis tool in Haskell to operate on Java source code, and I need a parser. Parsec provides javaStyle to help with lexical analysis, but I was wondering if there are any full-fledged Java parsers out there. Thanks, Punya

2 1

windows cabal bug?
by Isaac Jones 08 Apr '06

08 Apr '06

Can anyone with windows please take a look at this cabal bug report and provide a patch? This is reportedly a new problem in 6.5: http://hackage.haskell.org/trac/hackage/ticket/68 peace, isaac

1 0

Edison RC3
by Robert Dockins 06 Apr '06

06 Apr '06

Fellow Haskellers, The 3rd release candidate for Edison 1.2 is now avaliable. URLs to the project will appear at the end of this message. As with previous pre-releases, I am requesting comments on the API in particular. I believe I am approaching the point where I will feel comfortable freezing the 1.2 API, and I hope this will be the last release candidate before a 1.2 final. Major changes in 1.2rc3 are: * introduce the ambiguous/unambiguous concept and document all API operations * factor out methods which "mirror" superclass methods and make them alises instead * add lookupAndDelete* methods to associated collections * change the type of adjustOrDelete* in associated collections * rename subset/subsetEq to properSubset/subset * add matching Read and Show instances for all concrete datastructures * add properSubmap{By} submap{By} and sameMap{By} to the associated collection API * add Eq instances for concrete associated collections * break out the test suite into a separate sub-package The major remaining API issues I wish to request comments about have to do with class instances: 1) RC3 introduces Read and Show instances for all native Edison datastructures. However, StandardMap and StandardSet are just type aliases for Data.Map and Data.Set -- thus I can't provide Read and Show instances that are similar. So the question is, should I instead newtype these implementations so I can provide class instances which are consistent (as well as any other class instances I end up providing)? 2) Regarding Typeable and Data, what are your thoughts about the best way to provide Typeable and Data instances over abstract data types? I've considered playing the same trick that I do for Read/Show (which is internal conversions to/from lists). What do you think? 3) Are there any other class instances that are important to supply? And one final meta-API question; what are your thoughts about portability in general? I would like to support as many implementations as possible, but I'm already relying on MPTC, fundeps and undecidable instances (which may or may not be in H'), and I'm considering the following: -- instances of Typeable/Data (listed as non-portable) -- assertions (for checking preconditions) -- newtype deriving Anyway, I'm interested in your thoughts about how important portability is. ---------------------------------------- How to get Edison: Project page: http://www.eecs.tufts.edu/~rdocki01/edison.html Docs: http://www.eecs.tufts.edu/~rdocki01/docs/edison/index.html Source tarball: http://www.eecs.tufts.edu/~rdocki01/projects/edison-1.2rc3-source.tar.gz Darcs repo: http://www.eecs.tufts.edu/~rdocki01/edison/ Thanks! Rob Dockins

4 10

Fast Sequences
by Jim Apple 04 Apr '06

04 Apr '06

The proposed Data.Sequence ( http://www.soi.city.ac.uk/~ross/software/html/Data.Sequence.html ) has O(n) reverse. Section 6 of http://citeseer.ist.psu.edu/560336.html claims that it can be faster. Also, according to http://citeseer.ist.psu.edu/kaplan96purely.html , there is a sequence type with (><) of O(log log n). The latter one of these doesn't support the stated time bounds for different versions of the same structure. Do 2-3 finger trees support that? Jim

3 10

Reflection API for Haskell.
by Krasimir Angelov 30 Mar '06

30 Mar '06

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

1 0

Hexdump
by Dominic Steinitz 29 Mar '06

29 Mar '06

All, I finally got around to putting a "hexdump" function into a module. Any suggestions as to where it should live in the hierarchy? Dominic. module Hex( ppHex ) where import Data.List import Codec.Utils import Numeric import Text.PrettyPrint split :: Int -> [a] -> [[a]] split n xs = unfoldr (g n) xs g :: Int -> [a] -> Maybe ([a],[a]) g n [] = Nothing g n y = Just (splitAt n y) sh x | x < 16 = '0':(showHex x "") | otherwise = showHex x "" type OctetsPerLine = Int ppHex :: OctetsPerLine -> [Octet] -> Doc ppHex n = vcat . map hcat . map (intersperse colon) . map (map (text . sh)) . split n

5 6

Lists in haskell
by iliali16 26 Mar '06

26 Mar '06

people pls help me i have this weekend to finish my assignment on haskell.thats questuion1 of my assignment if somebody can help pls do so 10x in advance The aim of this assignment is to build a simulator of a programming language. The programming language contains variables (referred to by their name, given as a string), which can store an integer value: type Data = Integer type Variable = String The variable values are to be stored in a lookup table relating variable names and values, using the data synonym Store: type Store = [(Variable, Data)] (a) Define the empty Store, which contains no information about variables. (b) Define a function getVal, which takes a Store and a variable name, and returns its value. You may assume that the variable is defined in the Store. getVal :: Store -> Variable -> Data (c) Define a function setVar, which takes a Store, a variable name and a value, and returns an updated Store with the variable value updated. setVal :: Store -> (Variable, Data) -> Store -- View this message in context: http://www.nabble.com/Lists-in-haskell-t1341747.html#a3588096 Sent from the Haskell - Libraries forum at Nabble.com.

3 2

ANN: monadLib 2.0
by Iavor Diatchki 24 Mar '06

24 Mar '06

Hello everyone, There is now a new version of 'monadLib': a library of monad transformers for Haskell. 'monadLib' is a descendent of 'mtl', the monad template library that is distributed with most Haskell implementations. The library web page is at: http://www.csee.ogi.edu/~diatchki/monadLib Comments and feedback are very welcome! -Iavor

6 14