Custom Query (117 matches)
Results (7 - 9 of 117)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #29 | fixed | Concurrent disk-based data structures | none | paolo |
| description |
Implement B+tree or a variant supporting concurrent updates using STM, serialize updates into a write ahead log and provide for serialization. Bind the whole thing with a nice HaskellDB like API. Variations on the theme possible. Interested Mentors
Interested Students
|
|||
| #34 | fixed | Implement back-end dependent SQL generation in HaskellDB | none | paolo |
| description |
Currently HaskellDB uses the same SQL generator for all database systems. Unfortunately different database systems support different SQL dialects. The project is to make it possible to use different SQL generators for different back-ends, and implement generators for common database systems such as for example MySQL, PostgreSQL and SQLite. The project could also include adding support for back-end specific SQL extensions (such as various string and date functions, non-standard field types etc.) to the HaskellDB query language. Interested Mentors
Interested Students
|
|||
| #44 | fixed | Port Haddock to use the GHC API | none | simonmar@… |
| description |
Haddock currently uses its own Haskell parser. It lacks supports for some GHC extensions, and it requires its own implementation of the Haskell module system, has its own format for interface files, and so on. It can't produce documentation for functions that have no type signatures, because it has no type system and can't infer the types. If Haddock were built on top of the new GHC API, these shortcomings would be fixed, and Haddock would get a lot shorter (although the binary might be larger :-). GHC's parser would need to be adapted to handle Haddock-style documentation annotations, and the abstract syntax would have to carry these around. Interested Mentors
Interested Students
|
|||
