summaryrefslogtreecommitdiff
path: root/libraries/base/Data/Char.hs
Commit message (Collapse)AuthorAgeFilesLines
* [project @ 2002-05-09 13:16:29 by simonmar]simonmar2002-05-091-1/+1
| | | | Rename libraries/core to libraries/base in the module headers.
* [project @ 2002-04-26 13:34:05 by simonmar]simonmar2002-04-261-2/+0
| | | | | Remove \$Id\$ from all files: it isn't particularly useful (see previous discussion on cvs-ghc@haskell.org), and it confuses Haddock.
* [project @ 2002-04-24 16:31:37 by simonmar]simonmar2002-04-241-2/+2
| | | | | Add the single character '|' to the header comment of each module so that Haddock will parse it as the module documentation.
* [project @ 2002-04-11 12:03:43 by simonpj]simonpj2002-04-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------- Mainly derived Read ------------------- This commit is a tangle of several things that somehow got wound up together, I'm afraid. The main course ~~~~~~~~~~~~~~~ Replace the derived-Read machinery with Koen's cunning new parser combinator library. The result should be * much smaller code sizes from derived Read * faster execution of derived Read WARNING: I have not thoroughly tested this stuff; I'd be glad if you did! All the hard work is done, but there may be a few nits. The Read class gets two new methods, not exposed in the H98 inteface of course: class Read a where readsPrec :: Int -> ReadS a readList :: ReadS [a] readPrec :: ReadPrec a -- NEW readListPrec :: ReadPrec [a] -- NEW There are the following new libraries: Text.ParserCombinators.ReadP Koens combinator parser Text.ParserCombinators.ReadPrec Ditto, but with precedences Text.Read.Lex An emasculated lexical analyser that provides the functionality of H98 'lex' TcGenDeriv is changed to generate code that uses the new libraries. The built-in instances of Read (List, Maybe, tuples, etc) use the new libraries. Other stuff ~~~~~~~~~~~ 1. Some fixes the the plumbing of external-core generation. Sigbjorn did most of the work earlier, but this commit completes the renaming and typechecking plumbing. 2. Runtime error-generation functions, such as GHC.Err.recSelErr, GHC.Err.recUpdErr, etc, now take an Addr#, pointing to a UTF8-encoded C string, instead of a Haskell string. This makes the *calls* to these functions easier to generate, and smaller too, which is a good thing. In particular, it means that MkId.mkRecordSelectorId doesn't need to be passed "unpackCStringId", which was GRUESOME; and that in turn means that tcTypeAndClassDecls doesn't need to be passed unf_env, which is a very worthwhile cleanup. Win/win situation. 3. GHC now faithfully translates do-notation using ">>" for statements with no binding, just as the report says. While I was there I tidied up HsDo to take a list of Ids instead of 3 (but now 4) separate Ids. Saves a bit of code here and there. Also introduced Inst.newMethodFromName to package a common idiom.
* [project @ 2001-06-28 14:15:04 by simonmar]simonmar2001-06-281-0/+51
First cut of the Haskell Core Libraries ======================================= NOTE: it's not meant to be a working snapshot. The code is just here to look at and so the NHC/Hugs guys can start playing around with it. There is no build system. For GHC, the libraries tree is intended to be grafted onto an existing fptools/ tree, and the Makefile in libraries/core is a quick hack for that setup. This won't work at the moment without the other changes needed in fptools/ghc, which I haven't committed because they'll cause breakage. However, with the changes required these sources build a working Prelude and libraries. The layout mostly follows the one we agreed on, with one or two minor changes; in particular the Data/Array layout probably isn't final (there are several choices here). The document is in libraries/core/doc as promised. The cbits stuff is just a copy of ghc/lib/std/cbits and has GHC-specific stuff in it. We should really separate the compiler-specific C support from any compiler-independent C support there might be. Don't pay too much attention to the portability or stability status indicated in the header of each source file at the moment - I haven't gone through to make sure they're all consistent and make sense. I'm using non-literate source outside of GHC/. Hope that's ok with everyone. We need to discuss how the build system is going to work...