May 2006 - Libraries - Haskell.org

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

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

ANN: Edison 1.2RC4
by Robert Dockins 03 Jun '06

03 Jun '06

Fellow Haskellers! I am pleased to announce the 4th (and with any luck, final) release candidate for Edison 1.2. Edison is a library of efficient data structures for Haskell. Changes from RC3 include: * introduce strict/strictWith operations for all APIs * add Ord* instances for PatriciaLoMap and TernaryTrie * add David F. Place's EnumSet implementation * complete the FiniteMap unit test coverage and fix a bunch of bugs in finite map implementations * add 'symmetricDifference' to Collection and Associated Collection APIs * add Ord instances for data structures * add Monoid instances for data structures * Edison now requires Cabal 1.1.4 to build The project homepage is located at: http://www.eecs.tufts.edu/~rdocki01/edison.html API docs are located at: http://www.eecs.tufts.edu/~rdocki01/docs/edison/index.html And the darcs repository is located at: http://www.eecs.tufts.edu/~rdocki01/edison/ As before, comments are welcome, particularly comments relating to the API. However, barring major disasters I may have overlooked, I hope to release RC4 as 1.2, essentially unchanged. Thanks, Rob Dockins

4 8

xml in fptools?
by Isaac Jones 01 Jun '06

01 Jun '06

Greetings, I'm wondering if we've ever discussed putting an XML parser into fptools. I'm asking because cabal-install would like to use xml-rpc, but it drags in a bunch of dependencies that aren't in fptools. What do other languages do: * Python seems to have XML and XML-RPC as standard libraries * Same with ruby * Not java (shocking): http://java.sun.com/j2se/1.3/docs/api/ I guess that HaXml probably can't get into fptools because of license incompatibilities, but hxml and HXmlToolbox both have MIT licenses, and so could probably be put into fptools: http://www.flightlab.com/~joe/hxml/ http://www.fh-wedel.de/~si/HXmlToolbox/ What do others think? peace, isaac

13 28

Cabal 1.1.4 + Haddock 0.7 + GADT = Headache
by Robert Dockins 29 May '06

29 May '06

Hello all, I've got a problem with a package I maintain. I have a Cabal package which contains one module which uses GADTs. This module is hidden. Now, Haddock barfs if you try to generate Haddock docs from a module containing GADTs. With Cabal 1.1.3, hidden modules (apparently...) are not parsed by Haddock at all, so it has no opportunity to barf on my GADTs, and I could get useable docs out. However, with 1.1.4, Cabal now tells Haddock to parse this file, but also gives it the -- hide option. Haddock subsequently refuses to generate any documentation. I can remove the hidden modules from the "other modules" section, but then the object code doesn't end up in the libraries and programs won't build. Aggh! Is there any way to fix this problem? Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

3 3

Parsing Packets with House
by Dominic Steinitz 29 May '06

29 May '06

Now that I have the Haskell libpcap binding working, I want to be able to parse the packets that I capture. How feasible would it be to use the modules in House (programatica/hOp/kernel/Net) standalone? For example, here is a capture of a packet showing the 14-byte ethernet header followed by the IP packet which in this case is an ICMP echo request. I assume I can somehow use Net.Ethernet, Net.IPv4 and Net.ICMP to parse the packet? Dominic. [0,16,220,204,93,240,0,48,5,177,121,178,8,0, 69,0,0,84,104,184,0,0,255,1,9,54,192,168,100,55,192,168,100,50, 8,0,136,151,164,247,0,0, 68,120,161,81, 0,0,249,163,8,9,10,11,12,13,14,15,16,17,18,19, 20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35, 36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51, 52,53,54,55]

3 4

Experimental Support to build OpenAL package separately from GHC.
by shelarcy 25 May '06

25 May '06

Hello. I know Ross Paterson added Setup file to Win32 paclage, and added files that is used by configure for ALUT and OpenAL by these messages. http://www.haskell.org//pipermail/cvs-libraries/2006-May/005006.html http://www.haskell.org//pipermail/cvs-libraries/2006-May/005029.html http://www.haskell.org//pipermail/cvs-libraries/2006-May/005032.html So I try to add Setup file and build OpenAL package, separately from GHC. Of course, autoreconf command success alone package, and can build OpenAL package. I send patch to build OpenAL package separately from Compliter and Interpreter. This patch includes Mac OS X platform support - I sent previous mail - but I changed two points from this mail. http://www.haskell.org//pipermail/libraries/2006-March/005102.html 1. Darcs HEAD OpenAL package's Sound.OpenAL.ALC.Capture can be bult under Mac OS X platform. So, I remove unnecessary #ifdef. 2. This patch add [AC_REQUIRE([AC_CANONICAL_TARGET]) same as other packages - ALUT, OpenGL, GLUT. But OpenAL didn't use this, so forgot that configure.ac's AC_SUBST([CALLCONV]) doesn't set CALLCONV=ccall on Windows - if configure.ac works correctly. And break this convention, by previouse patch. So I commented out *-mingw32) case for that OpenAL uses ccall, even on Windows. http://www.haskell.org//pipermail/libraries/2005-October/004488.html If you applied this patch by darcs apply comannd - like this; $ darcs apply openal-separate-build.patch then you can build and install OpenAL package separately, by below command. $ autoreconf $ runhaskell Setup.lhs configure $ runhaskell Setup.lhs build $ runhaskell Setup.lhs install I tested to build on Windows and Mac OS X platform. And If you copy Setup.lhs for ALUT package, then you can also build and install by that. I think OpenGL and GLUT, too. But ALUT also require to use ccall, I think. If you build ALUT without any chage, to build example cause undefined reference error. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 1

Interfacing to OLE/COM: HaskellDirect the only game in town?
by Alistair Bayley 25 May '06

25 May '06

I want to use some MS Windows OLE/COM libraries from Haskell, and this page: http://www.haskell.org/haskellwiki/Libraries_and_tools/Interfacing_other_la… and Google suggest that HaskellDirect is the only game in town. Is this the case? And, does anyone have recent experience of it? Is it still usable, or has it bit-rotted? Alistair

3 2

System.Time
by Ashley Yakeley 25 May '06

25 May '06

Now that the "time" package is in current, can I get rid of System.Time, or should I deprecate it in some way? -- Ashley Yakeley, Seattle WA

3 2

(no subject)
by Bjorn Bringert 22 May '06

22 May '06

I'm moving this thread over to the libraries list. For those new to the thread, it is about replacing the current Network.CGI module with the NewCGI library. On May 22, 2006, at 8:06 AM, Lemmih wrote: > On 5/22/06, Simon Marlow <simonmar(a)gmail.com> wrote: >> On 5/22/06, Lemmih <lemmih(a)gmail.com> wrote: >> >> > NewCGI already supports POST data. >> > http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/doc/ >> >> Slightly off-topic, but maybe NewCGI should take over as Network.CGI? >> The current implementation isn't maintained, AFAIK. > > I volunteer to do the actual bone work if consensus is reached. I'd also be happy to do whatever work is needed for this. I'm still actively maintaining NewCGI. Here is a list of current features: - Access to CGI parameters (e.g. form input) from both GET and POST requests. - Access to CGI environment variables. - Ability to set arbitrary response headers. - Support for HTTP cookies. - An efficient implementation of multipart/form-data using Data.ByteString. This allows for efficient handling of file uploads. - Wrapper functions for compatibility with the existing Network.CGI module. - A CGI monad transformer. - Basic exception handling and logging (these should be improved) - Low-level run functions that allow using NewCGI programs with protocols other than CGI, for example FastCGI (http:// www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/) /Björn

1 1