Custom Query (117 matches)
Results (22 - 24 of 117)
|#1539||fixed||A Haskell Server Pages case study||nibro|
Haskell Server Pages (HSP) is a framework for writing dynamic web pages, with support for both server-side and client-side pages, including Ajax functionality. One of the key features is support for literal XML syntax in Haskell source code.
Currently, HSP is very much bare bones and little fluff. All the basic machinery is in place, but has only been tested for small toy examples. What we need is a larger application written in HSP, for instance a wiki engine, blog engine, web forum etc. By this we hope to stress test the core functionality, but also gain a better understanding of what "fluff" is needed on top of the bare bones. In terms of output, that could mean (suggestions for) libraries to work on top of the HSP core, for instance a library for user handling (logins and passwords, sessions etc).
This project could likely be combined to good effect with the project for integrating HSP with HAppS.
|#1545||fixed||Parser and pretty printer framework for C||dons|
The c2hs library implements a fairly complete parser for gcc C, and there exist various smaller pretty printers for subsets of the language.
This project would aim to consolidate the support for parsing and generating C code from Haskell, providing a single library, under Language.C.
It would reuse c2hs' infrastructure where necessary.
More details here http://haskell.org/pipermail/haskell-cafe/2007-April/024703.html
Benedikt Huber <benedikt.huber@…>
|#1552||fixed||Cabal 'make-like' dependency framework||duncan|
This project aims to prototype a make-like dependency system to use in Cabal.
Currently Cabal's building style is imperative and it relies on ghc --make or hmake to rebuild Haskell modules.
All the Cabal hackers agree that ideally almost all of the building code in Cabal should be done in a dependency style. There are many features we cannot currently add and bugs we cannot currently fix because they need a dependency system and for Cabal to do it's own module chasing rather than using ghc --make.
For Cabal-2.0 we aim to move to a dependency framework, this project is to prototype that system.
The cabal hackers already have quite a few ideas about the requirement and about how it could be done. Any student interested in this project should talk to the Cabal hackers to make sure they understand the issues and to help improve their project proposal.
One way the prototype project might work might be to implement module dependency analysis for yhc which is currently not supported by Cabal at all (or perhaps nhc98). This would allow the code to be included in the main Cabal development repo without destabilising the ghc support. From there we could move to using the dependency stuff for pre-processors, which would be very useful as it'd allow proper support for c2hs (which is what is holding back Cabalisation of gtk2hs).