June 2003 - Haskell - Haskell.org

Typesafe MRef's
by George Russell 16 Jun '03

16 Jun '03

Keith wrote (snipped) > But George Russell's implementation relied on looking up something in > one map with a key obtained from another map. I thought type-safe > MRefs should disallow this. However if you disallow lookup up in one map with a key from another, then Ralf Hinze's solution of putting the value inside the key uses no type extentions and works perfectly well (though is probably not quite what was intended).

3 6

hiddencode
by Steffen Mazanek 16 Jun '03

16 Jun '03

Hello, I am using literate programming with \begin{code}...\end{code}. But there is one problem. I want to hide some code of a module in my documentation. Therefore another environment, e.g. called hiddencode, would be very useful. To make things more general: Is there the possiblity to add other code environments? If not I would prefer a command line option. What do you think about this? Ciao, Steffen -- Steffen Mazanek - www.steffen-mazanek.de - GPG: 791F DCB3 Haskell, that's where I just curry until fail, unwords any error, drop all undefined, maybe break, otherwise in sequence span isControl and take max $, id: (d:[])

3 3

RE: Typesafe MRef with a regular monad
by Simon Peyton-Jones 16 Jun '03

16 Jun '03

| If you use Simon PJ's type signatures, you can't really disallow using | a key from one map with another map. Yes, that's a good point. So there are really three issues: a) single-threaded-ness b) making sure you look up in the right map c) making sure the thing you find has the right type Even if you have typed keys, (Key a), then if you look them up in the wrong map, any guarantee that it maps to a value of type 'a' is out of the window. I can think of two solutions i) Guarantee that keys are unique across all maps, so that a key from one map is never in the domain of another. ii) Use the (ST s) and (STRef s) trick, to connect the key with the map. This seems cleaner, but demands more of the programmer. But my main point remains: that some form of typed finite map ought to exist that does no dynamic type checks, because none are necessary. This must be a terribly old problem; and unsafeCoerce seems like a rather brutal "solution". Simon

2 1

problems with working with Handles
by Niels Reyngoud 15 Jun '03

15 Jun '03

Hello, We're two students from the department of computer science at the University of Utrecht (the Netherlands), and we're havind some severe difficulties in working with file handles in Haskell. Consider for example the following program: main = do --let inputfile = "input.txt" let inputtext = "testit" let outputfile = "output.txt" writeFile outputfile "" handle2 <- openFileEx outputfile (BinaryMode WriteMode) hPutStr handle2 (inputtext ++ " extra") handle3 <- openFileEx outputfile (BinaryMode ReadMode) inputtext2 <- hGetContents handle3 handle4 <- openFileEx outputfile (BinaryMode WriteMode) hPutStr handle4 (inputtext ++ " extra2") The text which should be in the outputfile is "testit extra extra2", instead "testit extra2" is written in. Another strange problem is with the following program: ------------- main = do putStr "Give inputfile for use of Super encoding\n" inputfile <- getLine handle <- openFileEx inputfile (BinaryMode ReadMode) text <- hGetContents handle putStr "Give outputfile for use of Super encoding\n" outputfile <- getLine encode text outputfile encode :: String -> String -> IO() encode text outputfile = do outputhandle <- openFileEx outputfile (BinaryMode WriteMode) bwt (runlengthEncode text) outputhandle bwthandle <- openFileEx outputfile (BinaryMode ReadMode) bwttext <- hGetContents bwthandle tracer' bwttext mtfhandle <- openFileEx outputfile (BinaryMode WriteMode) hPutStr mtfhandle (arithmeticEncode (runlengthEncode (movetofront bwttext))) tracer' :: String -> IO() tracer' x = writeFile "temp.txt" x ------------- This only seems to work when we're calling 'tracer' ', so if we're actually doing somewhing with "bwttext" before using it... Also, we're wondering when you can close a handle. Personally we thought you could close it if you are "done" with it, yet if you've captured the contents of a file like this: handle <- openFileEx inputfile (BinaryMode ReadMe) text <- hGetContents handle hClose handle putStr text no text appears on the screen; "text" seems empty. We're testing on a Windows machine by the way. Regards, Niels Reyngoud and Richard Nieuwenhuis

7 8

main modules in GHC, deriving differences between GHC and Hugs
by Graham Klyne 13 Jun '03

13 Jun '03

GHC seems to require a 'main' module in a file in order to generate an exe file. This makes it awkward to create unit test programs, because I generally create one (to run stand-alone) for each major module. Now I want to create a "master test" module that runs all the individual module tests. But if the module tests are all "main" modules it seems I cannot bring them all together into a larger program. Have I overlooked any way to create an executable program from any module containing a main function of the appropriate type? There also seems to be a difference in the way that GHC and Hugs handle deriving clauses. I haven't pinned this down, but I can try to provide more information if this is something the compiler developers not already aware of. #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

4 3

Re: Typesafe MRef with a regular monad
by cwitty＠newtonlabs.com 13 Jun '03

13 Jun '03

Keith Wansbrough <Keith.Wansbrough(a)cl.cam.ac.uk> writes: > > In article <v4j7k7qsp5c.fsf(a)newtonlabs.com>, > > cwitty(a)newtonlabs.com (Carl R. Witty) wrote: > > > > > Here's a hand-waving argument that you need either Typeable (or > > > something else that has a run-time concrete representation of types) > > > or ST/STRef (or something else, probably monadic, that can track > > > unique objects) to do this. > > > > George Russell already showed this, didn't he? You can implement > > Typeable given type-safe MRefs, and you can implement type-safe MRefs > > given Typeable. > > But George Russell's implementation relied on looking up something in > one map with a key obtained from another map. I thought type-safe > MRefs should disallow this. If you use Simon PJ's type signatures, you can't really disallow using a key from one map with another map. Carl Witty

1 0

Re: problems with working with Handles
by Tomasz Zielonka 13 Jun '03

13 Jun '03

On Fri, Jun 13, 2003 at 10:57:21AM -0400, Dean Herington wrote: > Tomasz Zielonka wrote: > > > One can also use Strategies module that comes with GHC (in package > > concurrent), for example: > > Could you tell me more specifically where to find the Strategies module in > GHC? I couldn't find it in the documentation. [tomekz@green load]$ ghci -package concurrent ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package concurrent ... linking ... done. Prelude> :m + Strategies Prelude Strategies> :m + IO Prelude Strategies IO> h <- openFile "/etc/termcap" ReadMode Prelude Strategies IO> cs <- hGetContents h Prelude Strategies IO> putStrLn "hmm" `demanding` rnf cs hmm Prelude Strategies IO> hClose h Prelude Strategies IO> length cs 737535 Prelude Strategies IO> Note that you have to use -package Strategies option. I couldn't find this module in the hierarchical libraries. The same works in GHC 5.04.3 To GHC developers: What is the status of this module? Can I assume that future versions of GHC will have it? > Thanks. > Dean Best regards, Tom -- .signature: Too many levels of symbolic links

1 0

a dream of databases
by John Meacham 13 Jun '03

13 Jun '03

so, I have been wanting to implement serialize to database functionality for haskell in a certain way which may or may not be possible.. what would be nice is if I could dump an entire complex haskell data structure (perhaps cyclic, but not infinite) to a hash-table database (like berkeley db). pointers would be swizzled into hash keys and each haskell thunk would become an entry in the database. loading the database would return the haskell structure just as it was put into the database but it would be demand loaded. meaning that evaluating a data thunk will actually grab that entry out of the database (like with lazy file reading) and entries that have not been accessed in a while would be transparently reclaimed by the garbage collector (and reloaded later if needed) And of course, these haskell data structures should be albe to be arbitrary and would look no different from other haskell data structures. they would just have appropriate instances derived for them by DrIFT (or perhaps template haskell). now. I am pretty sure I can do the demand loading bit with some goddawful code (inspired by HOODs internals) using unsafePerformIO and Weak pointers in truly nefarious ways. The dumping to the database bit is straightforward when working with trees. but I can't figure out a way to do it for potentially complex datastructures. perhaps someone out there has an idea? perhaps some template haskell tricks can be pulled to make it happen? I realize that any solution will be quite hacky and unlikely to be very portable. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

3 2

Re: what dreams may come ...
by Jon Awbrey 13 Jun '03

13 Jun '03

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o john, with no particular reference to haskell, but just generically speaking, this sounds vaguely similar to what i worked on all through the 80's in lisp and pascal, when ut-lisp used to pull a hal 9k about cyclic d-structures so i had to start redoing everything from scratch on my own recognizance in turbo pascal, no really. vide my recent, very slow attempts to document this work at my inquiry list: http://stderr.org/pipermail/inquiry/ http://stderr.org/cgi-bin/mailman/listinfo/inquiry here are the anchors of some pertinent threads: http://stderr.org/pipermail/inquiry/2003-March/000100.html -- exposition http://stderr.org/pipermail/inquiry/2003-March/000115.html -- source code http://stderr.org/pipermail/inquiry/2003-March/000120.html -- commentary http://stderr.org/pipermail/inquiry/2003-March/000141.html -- motivation it may be another year or so before i can finish (or even get back to) the te deums of documentality, but if anybody is remotely tantalized i will do my level best to explain what's going on there. jon awbrey o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o > Message: 10 > Date: Thu, 12 Jun 2003 19:02:55 -0700 > From: John Meacham <john(a)repetae.net> > Subject: a dream of databases > To: haskell(a)haskell.org > > so, I have been wanting to implement serialize to database functionality > for haskell in a certain way which may or may not be possible.. > > > what would be nice is if I could dump an entire complex haskell data > structure (perhaps cyclic, but not infinite) to a hash-table database > (like berkeley db). pointers would be swizzled into hash keys and each > haskell thunk would become an entry in the database. > > loading the database would return the haskell structure just as it was > put into the database but it would be demand loaded. meaning that > evaluating a data thunk will actually grab that entry out of the > database (like with lazy file reading) and entries that have not been > accessed in a while would be transparently reclaimed by the garbage > collector (and reloaded later if needed) > > And of course, these haskell data structures should be albe to be > arbitrary and would look no different from other haskell data > structures. they would just have appropriate instances derived for them > by DrIFT (or perhaps template haskell). > > now. I am pretty sure I can do the demand loading bit with some > goddawful code (inspired by HOODs internals) using unsafePerformIO and > Weak pointers in truly nefarious ways. The dumping to the database bit > is straightforward when working with trees. but I can't figure out a way > to do it for potentially complex datastructures. perhaps someone out > there has an idea? perhaps some template haskell tricks can be pulled to > make it happen? I realize that any solution will be quite hacky and > unlikely to be very portable. > > John > > --------------------------------------------------------------------------- > John Meacham - California Institute of Technology, Alum. - john(a)foo.net > --------------------------------------------------------------------------- o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

1 0

ANNOUNCE: GHC version 6.0
by Simon Marlow 13 Jun '03

13 Jun '03

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 6.0 ============================================================ We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 6.0. As with all ".0" releases, this release should be considered beta-quality; if you want real stability, then stick with 5.04.3 for the time being. Highlights of this release include: * Template Haskell, a new metaprogramming extension. * More hierarchical libraries. * Conformance with the latest FFI specification. * Sweeping internal changes to switch the evaluation model from "push/enter" to "eval/apply". See the release notes for a full list of the changes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998, and revised in December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

5 7