January 2008 - Libraries

Re: Integrating editline with ghc
by Thorkil Naur 17 Jan '08

17 Jan '08

Hello, On Wednesday 16 January 2008 22:05, Judah Jacobson wrote: > Hi all, > > I have managed to build ghc using the initial release of the editline package: > > Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 > Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ > > As I've mentioned before, there are two independent modules: > - System.Console.Editline is a very basic (and experimental) interface > to the native editline APIs. > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). Excellent! > > Currently I'm using just the latter as a drop-in replacement for > System.Console.Readline in ghci. I have added a --with-editline flag > to ghc's configure script, which has no effect if it's not specified, > and otherwise does the following: > > - Throw an error (at configure time) if editline isn't present (as > $hardtop/libraries/editline) That's the way. > - Use the editline package instead of readline when building ghc stage 2 > - Use CPP to make InteractiveUI.hs (the main ghci loop) import > System.Console.Editline.Readline instead of System.Console.Readline. > > Does that sound like the right way to handle this? If so, I'll send a > darcs patch. An alternative that would make the GHC configure script more symmetric with respect to command line editor would be to have --with-line-editor=editline, --with-line-editor=readline and also, perhaps, --with-line-editor=none (or even --with-line-editor=). All of these with, hopefully, obvious meanings. On top of this, one could have --with-edit-line=automatic with some automatic selection taking place. And the default? I'm sure that my favorite --with-line-editor=none will not be considered practical, so I will leave this most difficult choice to others. > > Also, should editline be made a boot-package or an extra-package (or neither)? > > Thanks, > -Judah > ... Thanks a lot again. Best regards Thorkil

1 0

darcs patch: bugfix: allow multi-word token-type usin... (and 2 more)
by Isaac Dupree 16 Jan '08

16 Jan '08

Proposal: put Happy and Alex discussion/patches/etc under the libraries(a)haskell.org domain, even though they're not technically libraries. (their purpose is very similar to Parsec's, for example, which is a library; and GHC depends on them, though from the end-user's point of view it's not quite as strong a dependency as the boot-libs) This patch is bugfixes for Happy that I discovered when trying to make GHC's code more portable (so I was testing using happy without -agc for the first time) (I sent this first to cvs-ghc(a)haskell.org but I figured I should really ask the community anyway). (I have a more controversial topic/patch to propose for Alex and Happy later...) ~Isaac Thu Dec 27 07:57:38 EST 2007 Isaac Dupree <id(a)isaac.cedarswampstudios.org> * bugfix: allow multi-word token-type using parentheses everywhere needed Thu Dec 27 11:54:46 EST 2007 Isaac Dupree <id(a)isaac.cedarswampstudios.org> * refactor HappyReduction-generating code (no semantic change) Thu Dec 27 12:04:54 EST 2007 Isaac Dupree <id(a)isaac.cedarswampstudios.org> * self-expand HappyReduction for more Haskell98 compliance It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? To: cvs-ghc(a)haskell.org From: Isaac Dupree <id(a)isaac.cedarswampstudios.org> Subject: darcs patch: bugfix: allow multi-word token-type usin... (and 2 more) X-Mail-Originator: Darcs Version Control System X-Darcs-Version: 1.0.9 (release) DarcsURL: http://darcs.haskell.org/happy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_" --=_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thu Dec 27 07:57:38 EST 2007 Isaac Dupree <id(a)isaac.cedarswampstudios.org> * bugfix: allow multi-word token-type using parentheses everywhere needed Thu Dec 27 11:54:46 EST 2007 Isaac Dupree <id(a)isaac.cedarswampstudios.org> * refactor HappyReduction-generating code (no semantic change) Thu Dec 27 12:04:54 EST 2007 Isaac Dupree <id(a)isaac.cedarswampstudios.org> * self-expand HappyReduction for more Haskell98 compliance It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? --=_ Content-Type: text/x-darcs-patch; name="bugfix_-allow-multi_word-token_type-using-parentheses-everywhere-needed.dpatch" Content-Transfer-Encoding: quoted-printable Content-Description: A darcs patch for your repository! New patches: [bugfix: allow multi-word token-type using parentheses everywhere needed Isaac Dupree <id(a)isaac.cedarswampstudios.org>**20071227125738] { hunk ./src/ProduceCode.lhs 85 +> token =3D brack token_type hunk ./src/ProduceCode.lhs 148 -> . str "happyInTok :: " . str token_type . str " -> " . bhappy_item +> . str "happyInTok :: " . token . str " -> " . bhappy_item hunk ./src/ProduceCode.lhs 151 -> . str "happyOutTok :: " . bhappy_item . str " -> " . str token_type +> . str "happyOutTok :: " . bhappy_item . str " -> " . token hunk ./src/ProduceCode.lhs 177 -> . str "\n\t=3D HappyTerminal " . str token_type +> . str "\n\t=3D HappyTerminal " . token hunk ./src/ProduceCode.lhs 232 -> token =3D brack token_type hunk ./src/ProduceCode.lhs 707 -> . str token_type +> . token hunk ./src/ProduceCode.lhs 720 -> . str token_type . str " -> " = +> . token . str " -> " = } [refactor HappyReduction-generating code (no semantic change) Isaac Dupree <id(a)isaac.cedarswampstudios.org>**20071227165446] { hunk ./src/ProduceCode.lhs 201 -> str "type HappyReduction m =3D \n\t" -> . str " " -> . intMaybeHash -> . str " \n\t-> " . token -> . str "\n\t-> HappyState " -> . token -> . str " (HappyStk HappyAbsSyn -> " . tokens . result -> . str ")\n\t" -> . str "-> [HappyState " -> . token -> . str " (HappyStk HappyAbsSyn -> " . tokens . result -> . str ")] \n\t-> HappyStk HappyAbsSyn \n\t-> " -> . tokens -> . result -> . str "\n\n" +> happyReductionDefinition . str "\n\n" hunk ./src/ProduceCode.lhs 206 -> . intMaybeHash -> . str " -> HappyReduction (" . str monad_tycon . str ")\n\n" +> . intMaybeHash . str " -> " . happyReductionValue . str "\n\n" hunk ./src/ProduceCode.lhs 211 -> . str " :: " . str monad_context . str " =3D> HappyReduction (" . st= r monad_tycon . str ")\n\n" = +> . str " :: " . str monad_context . str " =3D> " +> . happyReductionValue . str "\n\n" hunk ./src/ProduceCode.lhs 222 -> result =3D (str "m HappyAbsSyn") +> happyReductionDefinition =3D +> str "type HappyReduction m =3D " +> . happyReduction (str "m") +> happyReductionValue =3D +> str "HappyReduction " +> . brack monad_tycon +> happyReduction m =3D +> str "\n\t " +> . intMaybeHash +> . str " \n\t-> " . token +> . str "\n\t-> HappyState " +> . token +> . str " (HappyStk HappyAbsSyn -> " . tokens . result +> . str ")\n\t" +> . str "-> [HappyState " +> . token +> . str " (HappyStk HappyAbsSyn -> " . tokens . result +> . str ")] \n\t-> HappyStk HappyAbsSyn \n\t-> " +> . tokens +> . result +> where result =3D m . str " HappyAbsSyn" } [self-expand HappyReduction for more Haskell98 compliance Isaac Dupree <id(a)isaac.cedarswampstudios.org>**20071227170454 It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? ] { hunk ./src/ProduceCode.lhs 223 -> str "type HappyReduction m =3D " +> str "{- to allow type-synonyms as our monads (likely\n" +> . str " - with explicitly-specified bind and return)\n" +> . str " - in Haskell98, it seems that with\n" +> . str " - /type M a =3D .../, then /(HappyReduction M)/\n" +> . str " - is not allowed. But Happy is a\n" +> . str " - code-generator that can just substitute it.\n" +> . str "type HappyReduction m =3D " hunk ./src/ProduceCode.lhs 231 +> . str "\n-}" hunk ./src/ProduceCode.lhs 233 -> str "HappyReduction " +> str "({-" +> . str "HappyReduction " hunk ./src/ProduceCode.lhs 236 +> . str " =3D -}" +> . happyReduction (brack monad_tycon) +> . str ")" } Context: [update following recent Cabal changes Simon Marlow <simonmar(a)microsoft.com>**20071026150947] = [TAG 1.17 RELEASE Simon Marlow <simonmar(a)microsoft.com>**20071023145501] = Patch bundle hash: 7b85a9d0b16a315f2996831afcf214299b4bd4cb --=_-- .

1 0

darcs patch: Data.List.sort: force elements from start to end.
by Bertram Felgenhauer 16 Jan '08

16 Jan '08

Hi, the patch below is a trivial change to the merge helper function of Data.List.sort. Its effect is that the first argument of merge is evaluated before the second argument instead of vice versa. I think it's obviously correct. Also, sort is necessarily strict in the whole list, so there can be no loss of laziness. Rationale: The change helps to avoid a stack overflow in the common case where each element of a list depends on the previous one. Examples for such lists are '[1..]' or uses of 'iterate f' where f is a strict function. I believe this case is far more common than the opposite case where each element of the list depends on the next one, so the patch below is an improvement. See also http://thread.gmane.org/gmane.comp.lang.haskell.cafe/30598 Bertram Wed Nov 21 11:14:58 CET 2007 Bertram Felgenhauer <int-e(a)gmx.de> * Data.List.sort: force elements from start to end. this prevents a stack overflow on sort (take 10^6 [1..])

2 1

Re: Copyright for readline/editline packages
by Thorkil Naur 14 Jan '08

14 Jan '08

Hello, Indeed an interesting question. Although I am no licensing expert, I guess that the intention of the GPL is that if you copy the Haskell readline code which is under the GPL and modify it, then the result will also be under the GPL. Independent development is a possibility, unless you can get hold of the copyright holder. Best regards Thorkil On Saturday 12 January 2008 01:19, Judah Jacobson wrote: > Hi all, > > As mentioned before, I'm putting together an editline package which > will provide a subset of the APIs from the readline package, but be > BSD-compatible since it links against libedit. > > The licensing for the readline package itself is a little strange -- > it's licensed under the GPL (because it links with libreadline), but > there's no copyright holder information; and Readline.hsc from that > package lists "Copyright: (c) unknown". > > I'd like to put the Haskell editline package under BSD3, but most of > the code will be copied verbatim from the readline package. How > should this be attributed/copyrighted? > > Thanks, > -Judah > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

3 5

can't build plugins-1.0 with ghc-6.9
by Valery V. Vorotyntsev 14 Jan '08

14 Jan '08

Hi, (The message below contains bunch of "preformatted" sections. I hope it's still readable, otherwise, please, let me know.) My quest is to install lambdabot (for the sake of offline `@hoogle' and `@pl' commands), and the one depends on `plugins'. 1) plugins.cabal should be updated ---------------------------------- A patch to .cabal file[1] is needed to get rid of config-time warning[2] and resolve build-time errors[3]. [1] vvv:~/src/plugins-1.0$ diff -u plugins.cabal{.orig,} --- plugins.cabal.orig 2008-01-06 22:23:44.657177486 +0200 +++ plugins.cabal 2008-01-06 22:25:45.160728537 +0200 @@ -33,6 +33,6 @@ src/Language/Hi/hschooks.c includes: Linker.h extensions: CPP, ForeignFunctionInterface -Build-Depends: base, Cabal, haskell-src +Build-Depends: base, Cabal, haskell-src, array, containers, directory, random, process ghc-options: -Wall -O -fasm -funbox-strict-fields -fno-warn-missing-signatures -hs-source-dir: src +hs-source-dirs: src [2] vvv:~/src/plugins-1.0$ runhaskell Setup configure --prefix=$HOME --user Warning: The field "hs-source-dir" is deprecated, please use "hs-source-dirs" Configuring plugins-1.0... [...] [3] vvv:~/src/plugins-1.0$ runhaskell Setup build Preprocessing library plugins-1.0... Building plugins-1.0... src/Language/Hi/Binary.hs:90:7: Could not find module `Data.Array.Base': it is a member of package array-0.1, which is hidden 2) it doesn't build with Cabal-1.3.2 ------------------------------------ `InstalledPackageInfo' is a type alias in GHC's Cabal[4], not a data constructor; `plugins' library[5] gets confused[6]. [4] vvv:~/src$ diff -u cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs --- cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs 2007-11-01 17:02:35.000000000 +0200 +++ ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs 2007-12-17 17:53:21.691532864 +0200 @@ -46,7 +46,7 @@ -- This module is meant to be local-only to Distribution... module Distribution.InstalledPackageInfo ( - InstalledPackageInfo(..), + InstalledPackageInfo_(..), InstalledPackageInfo, ParseResult(..), PError(..), PWarning, emptyInstalledPackageInfo, parseInstalledPackageInfo, @@ -72,8 +72,8 @@ -- ----------------------------------------------------------------------------- -- The InstalledPackageInfo type -data InstalledPackageInfo - = InstalledPackageInfo { +data InstalledPackageInfo_ m + = InstalledPackageInfo_ { -- these parts are exactly the same as PackageDescription package :: PackageIdentifier, license :: License, @@ -87,8 +87,8 @@ category :: String, -- these parts are required by an installed package only: exposed :: Bool, - exposedModules :: [String], - hiddenModules :: [String], + exposedModules :: [m], + hiddenModules :: [m], importDirs :: [FilePath], -- contain sources in case of Hugs libraryDirs :: [FilePath], hsLibraries :: [String], @@ -107,9 +107,11 @@ } deriving (Read, Show) -emptyInstalledPackageInfo :: InstalledPackageInfo +type InstalledPackageInfo = InstalledPackageInfo_ String + +emptyInstalledPackageInfo :: InstalledPackageInfo_ m emptyInstalledPackageInfo - = InstalledPackageInfo { + = InstalledPackageInfo_ { package = PackageIdentifier "" noVersion, license = AllRightsReserved, copyright = "", [5] vvv:~/src/plugins-1.0$ sed -n 64,66p src/System/Plugins/PackageAPI.hs updImportDirs f pk@(InstalledPackageInfo { importDirs = idirs }) = pk { importDirs = f idirs } updLibraryDirs f pk@(InstalledPackageInfo { libraryDirs = ldirs }) = [6] vvv:~/src/plugins-1.0$ runhaskell Setup build Preprocessing library plugins-1.0... Building plugins-1.0... [ 1 of 24] Compiling System.Plugins.Process ( src/System/Plugins/Process.hs, dist/build/System/Plugins/Process.o ) [ 2 of 24] Compiling System.Plugins.Parser ( src/System/Plugins/Parser.hs, dist/build/System/Plugins/Parser.o ) [ 3 of 24] Compiling System.Plugins.ParsePkgConfCabal ( src/System/Plugins/ParsePkgConfCabal.hs, dist/build/System/Plugins/ParsePkgConfCabal.o ) [ 4 of 24] Compiling System.Plugins.PackageAPI ( src/System/Plugins/PackageAPI.hs, dist/build/System/Plugins/PackageAPI.o ) src/System/Plugins/PackageAPI.hs:64:20: Not in scope: data constructor `InstalledPackageInfo' src/System/Plugins/PackageAPI.hs:66:21: Not in scope: data constructor `InstalledPackageInfo' I would like to hear your suggestions. Should I try harder[7] installing Cabal-1.2.2.0? Or is this a bug of GHC's Cabal? In this case I've just reported it. :) [7] vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user Configuring Cabal-1.2.2.0... Setup: At least the following dependencies are missing: base <3, filepath -any vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user -f small_base Configuring Cabal-1.2.2.0... Setup: At least the following dependencies are missing: base >=3, pretty -any, directory -any, old-time -any, process -any, containers -any, filepath -any vvv:~/src/cabal-1.2.2.0$ ghc-pkg list /home/vvv/lib/ghc-6.9.20080104/package.conf: Cabal-1.3.2, array-0.1, base-3.0, bytestring-0.9, containers-0.1, directory-1.0, filepath-1.1, (ghc-6.9.20080104), haskell98-1.0.1, hpc-0.5, old-locale-1.0, old-time-1.0, packedstring-0.1, pretty-1.0, process-1.0, random-1.0, readline-1.0.1, rts-1.0, template-haskell-2.2, unix-2.2 /home/vvv/.ghc/i386-linux-6.9.20080104/package.conf: X11-1.4.1, binary-0.4.1, haskell-src-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, parsec-2.1.0.0, xmonad-0.5, xmonad-contrib-0.5 Thanks a lot. Happy hacking! -- vvv

2 3

Proposal: Add --with-libedit flag to the readline package
by Judah Jacobson 14 Jan '08

14 Jan '08

It would be useful for the readline package to support compiling against the libedit library (which provides a subset of the readline APIs): - libedit is available by default on OS X. - since libedit is BSD-licensed, there are no problems statically linking ghc with it. (This may be useful on Windows.) I propose adding a --with-libedit flag to the readline autoconf script. Without that flag, the package will behave exactly as before, refusing to link against libedit. With that flag, the following behavior occurs: - GNUreadline.framework (OS X - only) is ignored, if present - We try to link with -lreadline, and don't fail if readline is actually libedit. - If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including ghci.) Otherwise, if we're linking against GNU readline, we support all the available APIs. Suggested deadline: Jan. 23, 2008. A patch is attached to the trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2028 Thoughts? -Judah

5 11

Copyright for readline/editline packages
by Judah Jacobson 12 Jan '08

12 Jan '08

Hi all, As mentioned before, I'm putting together an editline package which will provide a subset of the APIs from the readline package, but be BSD-compatible since it links against libedit. The licensing for the readline package itself is a little strange -- it's licensed under the GPL (because it links with libreadline), but there's no copyright holder information; and Readline.hsc from that package lists "Copyright: (c) unknown". I'd like to put the Haskell editline package under BSD3, but most of the code will be copied verbatim from the readline package. How should this be attributed/copyrighted? Thanks, -Judah

2 1

PROPOSAL: Some more 'Applicative' combinators
by Iavor Diatchki 11 Jan '08

11 Jan '08

Hello, I propose that we add the following combinators to the 'Control.Applicative' module: skipMany :: (Alternative f) => f a -> f () skipMany p = skipSome p <|> pure () skipSome :: (Alternative f) => f a -> f () skipSome p = p *> skipMany p endBy :: (Alternative f) => f a -> f b -> f [a] endBy p s = many (p <* s) endBy1 :: (Alternative f) => f a -> f b -> f [a] endBy1 p s = some (p <* s) sepBy :: (Alternative f) => f a -> f v -> f [a] sepBy p s = sepBy1 p s <|> pure [] sepBy1 :: (Alternative f) => f a -> f v -> f [a] sepBy1 p s = (:) <$> p <*> many (s *> p) Any objections? Deadline for discussion is 2 weeks from now, which would be the 20th of Jan. -Iavor

7 10

Proposal: new version of getModificationTime
by Felix Martini 11 Jan '08

11 Jan '08

Hello all, Function getModificationTime in System.Directory returns ClockTime. ClockTime is part of the old-time package. The (new) time package has UTCTime, so i propose a new version of getModificationTime that returns UTCTime instead. I am not sure what a good name for the new version would be, perhaps getModificationUTCTime? Regards, Felix

2 3

Announcement: Typeful [x]html combinators -- pre-release 0
by Jon Fairbairn 10 Jan '08

10 Jan '08

... or, "whoops! I've writtten another html combinator library." History: I was surprised to find that all the Haskell html generating stuff I've tried allowed one to construct invalid HTML. I thought to myself that this might make an undergraduate project, but then I thought "maybe it's too hard? I'd better write some of it to see how hard it is." After a while I decided that it was probably a bit too big for an undergraduate project, but by that time I'd written too much of it to throw away, and just had to keep going so here it is. I'm announcing it here because I hope the audience is fairly small but discerning, and I'm announcing it at all because I've run out of steam for the moment. This is the first code above the size of a nonce-programme that I've written since I got ill years ago, so don't go too hard on me! I still am ill, so don't expect swift responses either. I'm mainly interested in opinions on the questions below, and in test cases that fail validation. You can get it with darcs get --partial http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs and the documentation (such as it is) is at <http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs/Documentation…> Here's the announcement (which might better be called the release note, except that I'm not sure this counts as a relase). ------ Typeful HTMLs library Library of types and combinators to produce valid xhtml 1.0 (and eventually html 4.01) -- if you use this library (and if it's not faulty), you won't need to run the validator over the output of your code. Types prevent invalid nesting of elements (including the prohibitions of appendix B of the xhtml standard) and ensure an attribute is only passed to elements that has it. Most attributes are given types that reflect their content rather than just being strings (although some are just wrappers around strings for the moment). Includes full set of xhtml character entity names Includes type with names for all IANA-registered character sets. Provides the option of generating output in a choice of character sets (currently with the wide choice of utf_8, us_ascii, latin1 or iso_8859_5 (cyrillic)). Provides the option of generating xhtml without an xml version declaration (to avoid putting IE into quirks mode). It's generated by TemplateHaskell, but otherwise Haskell98. Questions: * I want to add a function to produce HTML 4.01. Unfortunately there are trivial differences (body takes a nonempty list in HTML but an ordinary list in xhtml, and similar). One approach (and the one I'd choose if left to my own devices) would be to restrict the document tree to the common subset, so the types would be constrained by whichever language was the more restrictive in any given case. An alternative would be to transform the xhtml tree by adding empty div elements. Which do people prefer? * Having a monad inside the result types of the *_allowed_in classes complicates the types, complicates programmatic generation of elements and makes some error messages much worse. It wouldn't be necessary if we simply wrote Haskell lists instead of using the +++ operator, ie instead of body << (h1 << ... +++ p << ... +++ p << ...) we had to write body << [h1 << ..., p << ..., p << ...] Admittedly, it is rather more awkward for nonempty lists: ul << (li <<... +++ li<< ... +++ li<<...) would have to be written ul << (li<<... +:[li<<...,li<<...]). Would anyone really be bothered by that? (Either that, or can someone come up with a way of rearranging the types so that +++ works without the monad in the result types of elements?) * What should I do about REQUIRED attributes? Some alternatives are listed in the TODO file. * The preference carrying monad used for Render is backwards; I tried making it go forwards, but the Laziness test programme took about 1.7 times as long to run. I'd like to put some state in there, which can't be done backwards. Can I do this somehow without the performance hit? * This pre release has a very restrictive license (barely falling short of "You may not use this!") My preference is, I think, to release it under LGPL. Is that going to cause people undue grief? -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

5 14