- Glasgow-haskell-users

TFP 2007: Registration and Program
by TFP 2007 22 Feb '07

22 Feb '07

Dear Colleagues, You may now resgister for TFP 2007! TFP 2007 will be held April 2-4, 2007 in New York City, USA. Our invited speaker is John McCarthy, Stanford University. Further details can be found at our homepage: http://cs.shu.edu/tfp2007/ . You may register at: http://cs.shu.edu/tfp2007/registration.html . The registration deadline is March 2, 2007 (11:59 p.m. EST). Accomodations information may be found at: http://cs.shu.edu/tfp2007/accomodations.html . We kindly remind you that the deadline to make a hotel reservation at the guaranteed rates offered to TFP 2007 participants is also quickly approaching. We are proud to announce our program of accepted talks: Unifying Hybrid Types and Contracts Jessica Gronski and Cormac Flanagan A Dual Semantics for the Data Description Calculus Yitzhak Mandelbaum, Kathleen Fisher, and David Walker A Metalanguage for Structural Operational Semantics Matthew Lakin and Andrew Pitts An Arrow Based Semantics for Interactive Applications Peter Achten, Marko van Eekelen, Maarten de Mol, and Rinus Plasmeijer Dependent Types: Easy as Pie Dimitrios Vytiniotis and Stephanie Weirich Constructing Correct Circuits -- Hardware Modelling with Dependent Types Edwin Brady, James McKinna, and Kevin Hammond Why Would Extensible Dependent Types Matter Pablo Nogueira and Bruno Oliveira Bytecode Verification for Haskell Robert Dockins and Samuel Z. Guyer UnreadTVar: Extending Haskell Software Transactional Memory for Performance Nehir Sonmez, Cristian Perfumo, Srdjan Stipic, Adrian Cristal, Osman S. Unsal, and Mateo Valero A New Functional Implementation of Grover's Fast Search Algorithm Justin Stallard and Murray Gross An Inference Algorithm for Guaranteeing Safe Destruction Manuel Montenegro, Ricardo Peña, and Clara Segura Hierarchical Master/Worker Skeletons Jost Berthold, Mischa Dieterle, Rita Loogen, and Steffen Priebe Property Directed Generation of First-Order Test Data Fredrik Lindblad Refactoring for Comprehension Gustavo Villavicencio Towards a Box Calculus for Hume Gudmund Grov and Greg Michaelson Scaled Regression: A Refinement of Primitive Recursion Daniel Leivant Equality-Based Uniqueness Typing Edsko de Vries, Rinus Plasmeijer, and David Abrahamson Lightweight Static Resources: Sexy Types for Embedded and Systems Programming Oleg Kiselyov and Chung-chieh Shan Space-Efficient Gradual Typing David Herman, Aaron Tomb, and Cormac Flanagan Use-Based Reference of Polymorphism Dave King and John Hannan Designing a Generic Graph Library Using ML Functors Sylvain Conchon, Jean-Christophe Filliatre, and Julien Signoles The SCIence Joint Research Activity Kevin Hammond, Dana Petcu, Phil Trinder, Abdallah Al Zain, Steve Linton, and Greg Michaelson Generic and Index Programming Jeremy Gibbons, Meng Wang, and Bruno C d. S. Oliveira The AHA Project Marko van Eekelen, Olha Shkaravska, Ron van Kesteren, Bart Jacobs, Sjaak Smetsers, and Erik Poll Studying Helium Program Bahaviour with the Neon Library Jurriaan Hage and Peter van Keeken Design and Implementation of JFP Hao Xu Hop Client-Side Compilation Florian Loitsch Adaptive High-Level Scheduling in a Generic Parallel Runtime Environment Jost Berthold, Abyd Al-Zain, and Hans-Wolfgang Loidl Bundles Pack Tighter than Lists Francisco Lopez-Fraguas, Juan Rodriguez-Hortala, and Jaime Sanchez-Hernandez Model-Based Testing of Thin-Client Web Applications and Navigation Input Pieter Koopman, Peter Achten, and Rinus Plasmeijer We look forward to seeing you at TFP 2007! Cheers, Marco ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

Re: ghc 6.6 for mac os x (intel)
by Kirsten Chevalier 20 Feb '07

20 Feb '07

[redirecting to the list] On 2/5/07, Ariel Apostoli <apostoli(a)cs.utexas.edu> wrote: > Hello Kirsten, > > Thanks so much for your time and help so far. However, I am still stuck > on the issue when I try to do this: > > ./configure --with-readline-includes=/usr/local \ > --with-readline-libraries=/usr/local > > I get: > checking build system type... i686-apple-darwin8.8.1 > checking host system type... i686-apple-darwin8.8.1 > checking target system type... i686-apple-darwin8.8.1 > Canonicalised to: i386-apple-darwin > checking for path to top of build tree... /Users/ariel/work/ghc/ghc-6.6 > checking for ghc... no > checking for ghc-pkg matching ... no > checking for ghc-pkg... no > checking whether ghc has readline package... no > checking for nhc... no > checking for nhc98... no > checking for hbc... no > configure: error: GHC is required unless bootstrapping from .hc files. > > Do you know what should I do to avoid this? > Do you already have a binary version of GHC installed? If you want to build GHC from source, you need a binary of GHC installed already, like the error message suggests. (Unless you want to bootstrap from .hc files, but I've never done that, so I don't know.) See: http://haskell.org/ghc/download_ghc_66.html#macosxintel You didn't say what version of Mac OS X you were using; if it's anything older than 10.3, you're probably SOL. Cheers, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "just thinking of a series of dreams" -- Bob Dylan

6 8

Re: [Haskell] Data.Hashtable operations in IO?
by Kirsten Chevalier 20 Feb '07

20 Feb '07

[redirecting to a more appropriate mailing list] On 2/20/07, ROBERT DOUGLAS HOELZ <hoelz(a)wisc.edu> wrote: > I was reading the docs for Data.Hashtable, and quickly noticed that operations on a hashtable are of the IO monad. Why is this? I should think that the operations would look like this: > > insert :: Hashtable -> key -> val -> Hashtable > lookup :: Hashtable -> key -> a If you read the source for Data.HashTable, you'll notice that the HashTable type is defined in terms of mutable arrays, which must be in the IO monad since side effects are involved. This is purely for performance reasons. If you want an analogous type whose operations are pure, look at Data.Map: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Map.html Cheers, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "Nuclear war can ruin your whole compile." -- Karl Lehenbauer

1 0

Thoughts on the design of External Core
by Aaron Tomb 20 Feb '07

20 Feb '07

Over the last few days, I've put some more thought into the overall design of External Core. I looked through some of the GHC code some more, and I'm leaning toward a preference for using IfaceSyn throughout the whole External Core processing path. Simon, feel free to digest this at your leisure when you return. I also welcome feedback from anyone else. I don't assume that either of the following lists is complete or fully correct, and would like to hear any comments or criticism. Now, on to what I see as the pros and cons of using the Iface infrastructure for all aspects of External Core. Pros: * The input segment of this path is largely complete already. It needs a little fixing up (some of which I've already done), but the general design seems sound. * The code in HscMain that calls emitExternalCore is in the middle of the Iface processing pipeline. So, full Iface information is already available. If I understand things correctly, this means that all of the code of the current module is already in scope in IfaceSyn format. Maybe I'm wrong, though, and only type signatures are fully present? * Though I hear that the Iface typechecker generally assumes the absence of errors, the best long-term design decision might be to beef it up to the point where it can really tell you what's wrong when given ill-typed input. It is an external representation, after all. Currently, it's only likely to have come from GHC itself. Perhaps in the future other tools will also manipulate .hi files, however. Using IfaceSyn for External Core would encourage us to improve the typechecker, which would make interfacing with such tools more viable. * It looks like it would be straightforward to pretty-print IfaceSyn in ExternalCore format directly. It has almost exactly the same set of data constructors as (the old) ExternalCore does. The conversion from Core -> Abstract ExternalCore -> Concrete ExternalCore seems unnecessary. We could just do IfaceSyn -> Concrete ExternalCore. Cons: * If the Iface typechecker is indeed less than helpful in the face of errors, it will need to be improved. * I may be missing complications that would make the picture less rosy than I've implied. * One approach to the architecture of GHC (which I had in mind originally) is that all "source code", in whatever format, should somehow go through the HsSyn portion of the compiler. Thus, this part of the compiler does all of the real error checking, whereas the rest can assume certain correctness properties. Using IfaceSyn for External Core would violate this architectural assumption. Aaron

3 4

Re: [Haskell] cabal-upload build problem
by Kirsten Chevalier 19 Feb '07

19 Feb '07

You might try asking this on GHC-users instead, rather than haskell, since it's a GHC-specific question. I took the liberty of CCing this there. Cheers, Kirsten On 2/19/07, Paul Johnson <paul(a)cogito.org.uk> wrote: > > I want to upload a package to Hackage. I tried installing cabal-upload, > but got the following error: > > ! Preprocessing executables for cabal-upload-0.2... > ! Building cabal-upload-0.2... > ! > ! src/CabalUpload.hs:7:7: > ! Could not find module `Distribution.Compat.FilePath': > ! it is hidden (in package Cabal-1.1.6) > > > I tried "ghc-pkg expose Cabal-1.1.6" without success. > > I have ghc-6.6 installed on Linux (Fedora Core 6), including Cabal-1.1.6. > > (BTW I know I will also need a user id and password. That was going to > be my next step). > > Paul. > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "Dare to be naive."--R. Buckminster Fuller

1 0

size of snapshot archive
by Bulat Ziganshin 19 Feb '07

19 Feb '07

Hello glasgow-haskell-users, i'm tried to download newer snapshot of 6.6 and found that now it's 74 mb! why it is so large and why it's so enlarged after 6.6 release? isn't it possible to reduce size of this package? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4

bad interface file - how to track error down?
by Marc Weber 19 Feb '07

19 Feb '07

How to track this error down? When not using cabal adding OldNew.hs to the include path everything is fine --- command run ------ $ rm -fr dist; cWC; cat MW/OldNew.hs; ghc --show-iface dist/build/MW/OldNew.hi; cd testapp/; cat test.hs; ghc -package mwutil --make test.hs' &> /tmp/f cWC does ./setup configure, build, install notice the cd testapp to ensure OldNew.hs is not in include path. -- output annotated in haskell style -------------- {- configuring and instaling succesfully: -} setup: No command given (try --help) setup: Warning: No license-file field. Configuring mwutil-0.1... configure: Dependency base-any: using base-2.0 configure: Dependency haskell98-any: using haskell98-1.0 configure: Using install prefix: /usr/local configure: Binaries installed in: /usr/local/bin configure: Libraries installed in: /usr/local/lib/mwutil-0.1/ghc-6.6 configure: Private binaries installed in: /usr/local/libexec configure: Data files installed in: /usr/local/share/mwutil-0.1 configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.6 configure: Using package tool: /usr/bin/ghc-pkg configure: Using ar found on system at: /usr/bin/ar configure: Using haddock found on system at: /usr/local/bin/haddock configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /usr/bin/runghc configure: Using runhugs found on system at: /usr/bin/runhugs configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: Using c2hs: /usr/bin/c2hs configure: No cpphs found configure: Using greencard: /usr/local/bin/greencard Preprocessing library mwutil-0.1... Building mwutil-0.1... [1 of 1] Compiling MW.OldNew ( MW/OldNew.hs, dist/build/MW/OldNew.o ) /usr/bin/ar: creating dist/build/libHSmwutil-0.1.a Installing: /usr/local/lib/mwutil-0.1/ghc-6.6 & /usr/local/bin mwutil-0.1... Registering mwutil-0.1... Reading package info from ".installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. {- the file causing the error -} module MW.OldNew where data Old a = Old a data New a = New a data OldNew a = OldNew a a; unOld :: Old a -> a unOld (Old o) = o unNew :: New n -> n unNew (New n) = n a=a+1 {- output of --show-iface -} interface mwutil:MW.OldNew 1 6060 where export mwutil:MW.OldNew OldNew|{OldNew OldNew} a Old|{Old Old} New|{New New} unOld unNew module dependencies: package dependencies: base orphans: base:GHC.Base base:GHC.ForeignPtr data OldNew a Variances [(True, False)] RecFlag NonRecursive Generics: no = OldNew a a Stricts: _ _ data New a Variances [(True, False)] RecFlag NonRecursive Generics: no = New a Stricts: _ data Old a Variances [(True, False)] RecFlag NonRecursive Generics: no = Old a Stricts: _ unOld :: Old a -> a unNew :: New n -> n a :: base:GHC.Num.Integer {- the test app -} module Main where import MW.OldNew main = do print "test" {- compiling test app with -package mwutil -} [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:2:0: Bad interface file: /usr/local/lib/mwutil-0.1/ghc-6.6/MW/OldNew.hi Something is amiss; requested module mwutil-0.1:MW.OldNew differs from name found in the interface file mwutil:MW.OldNew Marc

2 1

Re: hasktags - small patch
by Lennart Kolmodin 18 Feb '07

18 Feb '07

Marc Weber wrote: > This small patch introduces a now mywords function which recognizes a::b as words a,::,b > which is what we need here (?) It does work in the above example. > > Here is the diff. Is it worth applying? > > 154c154 > < let wordlines = map words aslines > --- >> let wordlines = map mywords aslines > 161a162,174 >> -- my words is mainly copied from Data.List. >> -- difference abc::def is split into three words instead of one. >> mywords :: String -> [String] >> mywords (':':':':xs) = "::" : mywords xs >> mywords s = case dropWhile {-partain:Char.-}isSpace s of >> "" -> [] >> s' -> w : mywords s'' >> where (w, s'') = myBreak s' >> myBreak [] = ([],[]) >> myBreak (':':':':xs) = ([], "::"++xs) >> myBreak (' ':xs) = ([],xs); >> myBreak (x:xs) = let (a,b) = myBreak xs >> in (x:a,b) Without really knowing in which context this function is going to be used, expected results and so on, I've cooked up another alternative. Naturally it's possible to remove the spaces too if it's really required. let wordlines = map (groupBy (\a b -> isVarChar a == isVarChar b)) aslines isVarChar x = any ($ x) [isDigit, isAlpha, (== '_'), (== '\'')] It parses data LogInController = LogInController {rLoggedIn::R Bool, rwUserName::RWE String, rwPasswd::RWE String} as ["data"," ","LogInController"," = ","LogInController"," {","rLoggedIn","::","R"," ","Bool",", ","rwUserName","::","RWE"," ","String",", ","rwPasswd","::","RWE"," ","String","}"] Cheers, Lennart K

2 2

RFC: termination detection for STM
by Michael Stahl 15 Feb '07

15 Feb '07

hello! last week i have implemented termination detection for the ghc runtime. my motivation was a parallel interpreter for a concurrent constraint language which i have implemented using STM. this interpreter has reached its successful final state iff none the stm transactions it has spawned make progress anymore, i.e. all threads are in state BlockedOnSTM. well, it turned out that this state is rather difficult to detect. it could be possible to use unsafePerformIO from within an atomically block with an idempotent io action such that there is some thread which counts the number of threads which are blocked on stm, but i could not come up with something that is free of race conditions. mainly this is because with stm, it is impossible to know (in haskell code) which threads are woken up by a committed stm transaction. well, there is something that would work: a wave-based distributed termination algorithm. but that would be very inefficient: every thread needs to be woken up, and there is still the issue of finding the right time to send out a detection wave: too late, and the user gets bored; too early, and there is even more overhead. of course, the ghc runtime knows which threads are woken up, so i thought it should be possible to implement the termination detection there. and also, this should be more reliable than the ugly hack i had before (a master thread with a timeout that is reset on every stm commit, by throwing an exception). so how can the ghc runtime detect termination? it is quite simple: we need to add a counter somewhere that is incremented every time a thread that is BlockedOnSTM is woken up, and decremented every time a thread goes into the BlockedOnSTM state (via retry). but just having a single counter has a drawback: it might become a scalability bottleneck. so i have extended the StgTSO struct with two fields: a counter, and a parent pointer. the parent pointer points to the TSO that spawned the thread. the counter field of a TSO counts the threads which are children of this thread (non-transitively!) and have not terminated yet. invariant: the counter is always >= 0, and == 0 iff the subtree rooted at this thread has terminated. conceptually, we have to modify the counter at the following events: - fork: the forking thread's counter is incremented the forked thread's counter is initialized to 1 - exit: the exiting thread's counter is decremented - retry: the retrying thread's counter is decremented - wakeup (stm): the counter of the woken thread is incremented increment means: add 1; if new value is 1: recursively increment parent decrement means: sub 1; if new value is 0: recursively decrement parent if there is no parent, signal termination of course, it has to be guaranteed that increments always arrive at the root before the corresponding decrements, otherwise termination may be detected prematurely. note that termination can only be signalled for a thread which has already exited, or which has called GHC.Conc.awaitTermination (described below). there are two added primitive operations: - counterDec# decrements the calling thread's counter and also sets the parent pointer to NULL (so the calling thread becomes the root of a thread tree for which termination will be detected) - counterInc# just increments the calling thread's counter (cancels the effect of counterDec) these primitives are meant to be called from a single place: awaitTermination, which is in GHC.Conc. it calls counterDec#, then waits for the exception with a delay. afterwards, it just calls counterInc#. the termination is signalled by throwing a Deadlock exception to the root of the thread tree. actually, i believe the termination condition is a livelock, but there is no constructor for that. note that there may be several independent subcomputations within a single haskell process for which termination can be detected with this approach. the main drawbacks of this code: - the locking overhead (counter updates) - because of the parent pointers, non-leaf threads will never be garbage collected if any child thread is still alive. this could be alleviated by only enabling the termination detection if the program specifically requests it, e.g. some global flag variable which is set by another primitive operation. i would welcome a review of the code; this is the first time i have hacked on ghc (and also the first non-trivial C code i have written in years), so there may be issues and interactions with other parts of the runtime that i have not anticipated. so far, i have tested it only with -threaded -debug, but it seems to work with -N32 (on a single processor, that is all i have). do you think that others might be interested in this functionality? could it be included in ghc? also, something that i really do not understand: in the counterDec# primitive, the stack_size field of the StgTSO struct is corrupted for no apparent reason, so i save it onto the stack and then restore it. none of the other primitive ops seem to do something similar. what am i doing wrong? patch is against ghc 6.6 (actually the debian package 6.6-3, but i hope those weird arm floating point endianness patches don't matter much :) ). michael stahl -- "I don't feel we did wrong in taking this great country away from them. There were great numbers of people who needed new land, and the Indians were selfishly trying to keep it for themselves." -- John Wayne

3 6

Re: [Haskell-cafe] Strange memory consumption problems in something that should be tail-recursive
by Kirsten Chevalier 13 Feb '07

13 Feb '07

On 2/13/07, Jefferson Heard <jeff(a)renci.org> wrote: > Thanks for the redirect. I haven't tried profiling yet, as I was hoping it > was obvious to the more seasoned user. In reference to your comment about > tail-recursion not working as you'd always expect, is there some document > somewhere that tells the wherefores of that? I'm using fully qualified types > and fully uncurried functions, so I wouldn't think that I should really see > this kind of recursion, coming from languages like Scheme and OCaml. Seasoned users know that nothing is obvious until you run the profiler. With that said, the discussion on haskell-cafe is good when it comes to the reasoning behind tail-recursion not working the way users of strict languages might expect. Perhaps it should be written up somewhere more permanent. But that's a point about Haskell in general. Cheers, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "Everyone's too stupid." -- _Ghost World_

1 0