- Glasgow-haskell-users

Creating Loadable Dynamic Libraries in OSX
by Alfonso Acosta 22 Nov '06

22 Nov '06

Hi, I succesfully created dynamic loadable libraries (.so) with GHC6.6 under LinuxX86 using some C glue code and linking with -optl -shared. Now I would like to port my code to OSX but linking with "-optl -bunde" fails giving a "local relocation entries in non-writable section" error. I think that is becase under OSX, GHC calls gcc with -mdynamic-no-pic preventing my FFI stub object files to be linked. Does anyone know why is -mdynamic-no-pic used or a workaround? Thanks in advance, Alfonso Acosta

1 1

Re: Bad control characters in GHCi 6.6 (Mac OS X PPC)
by Björn Buckwalter 22 Nov '06

22 Nov '06

On 10/19/06, Simon Marlow <simonmar(a)microsoft.com> wrote: > See this page that I just created: > > http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX I tried these instructions, first by using my existing (darwinports) readline in /opt/local, and when that failed by first installing readline in /usr/local per the instructions. Neither fixed the problem. I don't know why but perhaps I failed to remove the traces of my initial install completely. In the end I gave up and installed Greg Heartsfield's binary package which remedied my problems (thanks Greg!). Thanks anyway Simon, -Bjorn Buckwalter

4 4

Request for testing help from ghc-6.6 users on Win9x
by Sigbjorn Finne 21 Nov '06

21 Nov '06

Hi, a couple of users have been reporting problems with ghc-6.6 on the line of OS editions that reached its pinnacle as Windows ME, in particular when invoking GHCi. An alleged fix is available, but we'd really appreciate if it could be tested more widely before declaring victory (and push the changes into the next GHC release). To try it out, download http://galois.com/~sof/ghc9x.zip and unpack its contents on top of the bin/ directory of your ghc-6.6 install. [To avoid any irreversible damage, you may very well want to move the original bin/ghc.exe out of the way first. ] If you could ping me with a yay/nay on whether that GHCi usage, that'd be very helpful. thx --sigbjorn

1 0

runtime fusion for Data.ByteString.cons ?
by Claus Reinke 21 Nov '06

21 Nov '06

I noticed that ByteString is drastically slower than String if I use cons a lot. according to the source, that is expected because of the memcpy for the second parameter. but it seems to me that construction should be able to play the dual trick to deconstruction (which does not copy the tail, but returns an indirection into the original list). roughly speaking: when constructing a ByteString via cons h t, we know the length of the result (1+length t), and instead of creating t in a separate storage location then copying it over to the result, we could try to create it inplace. or rather, we could delay construction of ByteStrings until we know whether we need to allocate fresh memory for them or whether they can be created by filling some context. this rough idea runs into a couple of issues in practice: - first of all, it seems to be a runtime fusion (unless we do whole program optimization, simplifier rewrites won't do, although unfolding recursions might still expose some opportunities for a static variant of this fusion) - if t is shared, we'd like to redirect these shared references to an indirection into the tail of cons h t ignoring the second point for now, if we look into the source for cons, we find something like: cons :: Word8 -> ByteString -> ByteString cons c (PS x s l) = unsafeCreate (l+1) $ \p-> ... poke p c; memcpy (p+1).. now, let's imagine a pre-ByteString as a not-yet allocated ByteString: data PreBS = PrePS l f so that createBS :: PreBS -> ByteString createBS (PrePS l f) = unsafeCreate l f consPre :: Word8 -> ByteString -> PrePS consPre c (PS x s l) = PrePS (l+1) $ \p-> ... poke p c; memcpy (p+1).. cons :: Word8 -> ByteString -> ByteString cons c bs = createBS (consPre c bs) then we could express our fusion as consPre c (create (PrePS l f)) = PrePS (l+1) $ \p-> ... poke p c; f (p+1).. in other words, in a typical map-like recursion scheme, we do not create, copy & release the tails recursively, but delay creation until we know where to embed our ByteString, at which point we do a sequence of pokes, no memcpy. but note that we are matching on a function application here, even though we are not in a simplifier rule, so this doesn't work as it stands.. this is as far as I got so far.. (see attached example for a manual use of pre-ByteStrings to speed up a map). now my questions for you:-) - does this make sense? - can it be made to work? as we probably cannot redirect shared references to t in (cons h t), can we identify the situations where t is not shared, as in a map, or can we just ignore any shared references (they will point to a "create (PrePS ..)" combination, and should just keep working, since we bypass those combinations instead of rewriting them)? a tentative idea would be to overload create so that it produces a proper, allocated ByteString where such is expected, but can also just pass through the PreBS where the context can handle it? class Create r where create :: PreBS -> r instance Create ByteString where create (PrePS l f) = unsafeCreate l f instance Create PreBS where create = id consPre :: Word8 -> ByteString -> PrePS consPre c (PS x s l) = PrePS (l+1) $ \p-> ... poke p c; memcpy (p+1).. cons :: Word8 -> ByteString -> ByteString cons c bs = create (consPre c bs) consPre' :: Word8 -> PrePS -> PrePS consPre' c (PrePS l f) = PrePS (l+1) $ \p-> ... poke p c; f (p+1).. so that "consPre c (create (PrePS ..))" works as normal, while "consPre' c (create (PrePS ..))" uses the fusion path. or something like that;-) Claus

5 15

First Call for Papers: TFP 2007, New York, USA
by TFP 2007 21 Nov '06

21 Nov '06

CALL FOR PAPERS Trends in Functional Programming 2007 New York, USA April 2-4, 2007 http://tltc.shu.edu/tfp2007/ OR http://cs.shu.edu/tfp2007/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2007 is co-hosted by Seton Hall University and The City College of New York (CCNY) and will be held in New York, USA, April 2-4, 2007 at the CCNY campus. The TFP symposium is the successor to the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh, Scotland in 2003 (co-located with IFL), in Munich, Germany in 2004, in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE), and in Nottingham, UK in 2006 (co-located with Types). For further general information about TFP please see the TFP homepage at http://cs.shu.edu/tfp2007/ . SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles leading-edge, previously unpublished research work Position Articles on what new trends should or should not be Project Articles descriptions of recently started new projects Evaluation Articles what lessons can be drawn from a finished project Overview Articles summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Articles on the following subject areas are particularly welcomed: o Dependently Typed Functional Programming o Validation and Verification of Functional Programs o Debugging for Functional Languages o Functional Programming and Security o Functional Programming and Mobility o Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications o Functional Languages for Telecommunications Applications o Functional Languages for Embedded Systems o Functional Programming Applied to Global Computing o Functional GRIDs o Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) o Interoperability with Imperative Programming Languages o Novel Memory Management Techniques o Parallel/Concurrent Functional Languages o Program Transformation Techniques o Empirical Performance Studies o Abstract/Virtual Machines and Compilers for Functional Languages o New Implementation Strategies o any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2007 program chair, Marco T. Morazan, at tfp2007(a)shu.edu. BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A prize for the best student paper is awarded each year. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of extended abstracts (6 to 10 pages in length) by the program committee. Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings and on-line. The submission must clearly indicate to which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate whether the main author or authors are research students. Formatting details can be found at the TFP 2007 website. Submission procedures will be posted on the TFP 2007 website as the submission deadline is reached. The papers in the draft proceedings will also be made available on-line under the following conditions, with which all authors are asked to agree: The documents distributed by this server have been provided by the contributing authors as a means to ensure timely dissemination of scholarly and technical work on a noncommercial basis. Copyright and all rights therein are maintained by the authors or by other copyright holders, notwithstanding that they have offered their works here electronically. It is understood that all persons copying this information will adhere to the terms and constraints invoked by each author's copyright. These works may not be reposted without the explicit permission of the copyright holder. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. All TFP authors will be invited to submit revised papers after the symposium. These will be refereed using normal conference standards and a subset of the best papers, over all categories, will be selected for publication. Papers will be judged on their contribution to the research area with appropriate criteria applied to each category of paper. Student papers will be given extra feedback by the Program Committee in order to assist those unfamiliar with the publication process. Important DATES Abstract Submission: February 1, 2007 Notification of Acceptance: February 20, 2007 Registration Deadline: March 2, 2007 Camera Ready Full Paper Due: March 9, 2007 TFP Symposium: April 2-4, 2007 PROGRAMME COMMITTEE John Clements California Polytechnic State University, USA Marko van Eekelen Radboud Universiteit Nijmegen, The Netherlands Benjamin Goldberg New York University, USA Kevin Hammond University of St. Andrews, UK Patricia Johann Rutgers University, USA Hans-Wolfgang Loidl Ludwig-Maximilians Universität München, Germany Rita Loogen Philipps-Universität Marburg, Germany Greg Michaelson Heriot-Watt University, UK Marco T. Morazán (Chair) Seton Hall University, USA Henrik Nilsson University of Nottingham, UK Chris Okasaki United States Military Academy at West Point, USA Rex Page University of Oklahoma, USA Ricardo Pena Universidad Complutense de Madrid, Spain Benjamin C. Pierce University of Pennsylvania, USA John Reppy University of Chicago, USA Ulrik P. Schultz University of Southern Denmark, Denmark Clara Segura Universidad Complutense de Madrid, Spain Jocelyn Sérot Université Blaise Pascal, France Zhong Shao Yale University, USA Olin Shivers Georgia Institute of Technology, USA Phil Trinder Heriot-Watt University, UK David Walker Princeton University, USA ORGANIZATION Symposium Chair: Henrik Nilsson, University of Nottingham, UK Programme Chair: Marco T. Morazan, Seton Hall University, USA Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Marco T. Morazan, Seton Hall University, USA SPONSORS The Department of Mathematics and Computer Science, Seton Hall University The Department of Computer Science, The City College of New York The Center for Algorithms and Interactive Scientific Software of The City College of New York The Grove School of Engineering of The City College of New York We are actively looking for additional TFP sponsors, who may, for example, help to subsidise attendance by research students. If you or your organisation might be willing to sponsor TFP, or if you know someone who might be willing to do so, please do not hesitate to contact the Program Chair, Marco T. Morazan, or the Symposium Chair, Henrik Nilsson. Your students will be grateful! ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

Re: ghc-testsuite-6.6 on Macs
by Thorkil Naur 21 Nov '06

21 Nov '06

Hello, On Tuesday 14 November 2006 11:34, Simon Marlow wrote: > Thorkil Naur wrote: > > ... I have > > produced an experimental darcs patch that solves some problems, while > > possibly introducing others: > > http://thorkilnaur.dk/~tn/GHC/testsuite/patch/barton_mangler_bug_patch_1.pa… . > > Comments to this would be most welcome. > > For those who haven't looked at Thorkil's patch: he proposes adding some code to > the testsuite driver to allow sample output specific to a particular way, and > used this to give sample output for one test (barton-mangler-bug) specific to > the 'opt' way on PPC. > > I would like it to be the case that any differences at all in the output from > one way to another are bugs, including floating point differences. It is a basic question of what varying circumstances we believe should be handled by the test framework. I tend to agree with you and, hence, to reject my own suggestion of extending the testsuite driver to allow different output for different ways.. > On x86_64, > we always generate the same results regardless of -fvia-C or -fasm, for example. > However, it might be that this isn't practical on all platforms. I feel rather sure that it isn't. > The question > is whether we should consider it a *bug* if a test doesn't give consistent > floating-point answers or not. Anyone have any thoughts on this? Let me put it in this way: It is well known that it is almost always bad to test whether two floating point numbers are exactly equal. So in this sense, a test whose outcome depends on testing whether two floating point numbers are exactly equal is a bad test. (Converting floating point numbers to decimal strings and comparing the strings which is what really happens seems to make matters even worse.) To be sure, if we are really testing the floating point operations, we are of course entitled to test equality. But if a test does not deal with floating point operations as such, but merely includes floating point numbers in its output incidentally, the test is probably bad. I cannot see that the Haskell report specifies precise properties of the floating point support, so even implementations that conform to the standard (Haskell 98) can be expected to differ. Hence, any test that involves output of floating point numbers might produce different output for reasons that are entirely unrelated to the test, not a particularly appetizing situation. Whether difference in floating point results between different ways should be considered a bug in GHC, I cannot say. I would tend towards "no", but that is probably because I don't have any particular intense interest in floating point numbers. Getting finally to something more specific, my impression until your question here had been that the barton-mangler-bug test involved floating point numbers incidentally: I imagined that someone (named Barton, perhaps?) ran this program at some point in time, discovered some unfortunate behaviour (such as the program crashing or producing wild results), that this behaviour was traced down to an error in some mangler (the gcc assembler language output "post processor"), and that the test was included and maintained in the testsuite to ensure that this bug was thouroughly stamped out. Based on your question, I realised that my impression could be entirely false and that the central property tested was precisely the floating point differences observed for some ways. I am still in doubt, so if anyone knows the story behind the barton-mangler-bug, I would be delighted to hear it. > > If it's a bug, then we just declare these tests to be expected failures. If > it's not a bug, then we have to allow per-way sample output, as per Thorkil's patch. > As I have already mentioned, I think my patch is a mistake. Depending on what anyone can tell me about the barton-mangler-bug, additional work would seem to go in one of two directions: If the floating point numbers are involved incidentally and the mangler bug still threatens, work should attempt to remove the floating point numbers from the output and produce a test case that exposes the bug more succinctly. I would certainly need some additional help to do this. On the other hand, if the floating point difference between, e.g., opt and normal is the real issue, it would still seem advantageous and quite possible to reduce the size of the test case, to make it easier to figure out the cause of the difference. > Cheers, > Simon > Best regards Thorkil

2 1

RTS -I switch
by Bulat Ziganshin 20 Nov '06

20 Nov '06

Hello glasgow-haskell-users, i still forget to ask: if my program is idle during long time, is GC will occur each 0.3 seconds or GHC is smart enough to check that no much memory was allocated after last GC? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 3

Major type-class overhaul
by Simon Peyton-Jones 20 Nov '06

20 Nov '06

Dear GHC users, For some time I have been promising an overhaul of GHC's type inference machinery to fix the interactions between type classes and GADTs. I've just completed it (or at least I hope so). This message is just to summarise the programmer-visible changes, and to encourage you to give them a whirl. Of course, you'll need to compile the HEAD to do this; or get a nightly-build snapshot in a day or two's time. Needless to say, if you are using the HEAD for mission-critical stuff, proceed with caution. I don't guaranteed bug-free-ness. Simon This major patch adds implication constraints to GHC's type inference mechanism. (The name "implication constraint" is due to Martin Sulzmann.) >From a programmer point of view, there are several improvements 1. Complete(r) type inference ~~~~~~~~~~~~~~~~~~ GHC's type inference becomes complete (or perhaps more complete!) Particularly, Karl-Filip Faxen's famous example in "Haskell and principal types" (Haskell workshop 2003) would type check when the program text was written in one order, and then fail when the text was re-ordered. Now it works regardless. The test is tc218. 2. Lifting the "quantified-here" restriction ~~~~~~~~~~~~~~~~~~~~~~~~~ The restriction that every constraint in a type signature must mention at least one of the quantified type variables is lifted. So you can write f :: C Int => ... or g :: forall b. Eq a => ... This may seem odd, but the former was recently requested by a Haskell user; see this message: http://www.haskell.org/pipermail/glasgow-haskell-users/2006-September/01113… 3. Dictionaries are packaged in data constructors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A very useful new feature is this. When a data type is declared in in GADT syntax, the context of the constructor is *required* when constructing *available* when matching For example data T a where T1 :: Num a => a -> T a T2 :: Bounded a => T a f :: T a -> a f (T1 x) = x+1 f T2 = maxBound Notice that f is not overloaded. The Num needed in the first branch is satisfied by the T1 pattern match; and similarly for the T2 pattern match. This feature has been often requested, becuase it allows you to package a dictionary into an ordinary (non-existential) data type, and be able to use it. NOTE: the Haskell 98 syntax for data type declarations data Num a => T a = T1 a behaves exactly as specified in H98, and *not* in the new way. The Num dictionary is *required* when constructing, and *required* when matching I think this is stupid, but it's what H98 says. To get the new behaviour, use GADT-style syntax, even though the data type being defined is does not use the GADT-ness. 4. Type classes and GADTs ~~~~~~~~~~~~~~~~~ The proper interaction between GADTs and type classes is now respected. For example: data GADT a where MkG :: Num a => a -> GADT [a] g :: forall b. Read b => GADT b -> String -> b g (MkG n) s = n : read s Inside the branch we know that b=[a], so the (Read b) dictionary is a (Read [a]) dictionary, which is why we can use the result of read in the tail of a cons. Functional dependencies and equality predicates ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The treatment of functional dependencies is still ad hoc and unsatisfactory. I do not promise that they will work nicely in conjunction with GADTs. Trac #345 has a good example. More generally, we want to add - indexed type synonyms (aka associated type synonyms) - equality constraints in contexts Both will require us to furher overhaul constraint handling. So this patch is just a (big) step on the way.

7 7

GHC 6.6 on Ubuntu
by Chad Scherrer 19 Nov '06

19 Nov '06

Is there a preferred way of getting this going? I tried the GHC instructions for Debian, but this seems to depend on 6.6 already being in the repository, which it's not, in Ubuntu (why?). I like Debian/Ubuntu's install system, and I assume that 6.6 will eventually make it into Ubuntu. I want to be sure whatever I do now doesn't later confuse the system. Thanks, Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

3 2

Re: [Haskell-cafe] Debugging partial functions by the rules
by Neil Mitchell 18 Nov '06

18 Nov '06

Hi > To see at a glance the various bug reports about fromJust you can > search the bug database: > http://bugs.darcs.net/issue?@columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassi… > > I count 7 bugs. > I would be interested to see the results of static analysis tools > (Catch?) or applying Oleg's strategy. Any volunteers? Unfortunately darcs is too big, and too unhaskell-98 to go through Catch as it currently stands. In reality the best strategy would probably be to use Catch on darcs, then where Catch is unable to automatically verify the program use Oleg's techniques and other rewritings until Catch can verify everything. Just taking a random example (the first fromJust I stumbled upon): http://abridgegame.org/repos/darcs-unstable/Population.lhs, cleanPop The requirement here is that the modifiedHowI field of the 2nd field of the Pop at the top must be not a removal. Figuring out in an existing code-base whether that is a general invariant for Pop, true in this specific case, or any other random combination is quite a hard problem! Thanks Neil

1 0