- Glasgow-haskell-users

ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
by Judah Jacobson 21 Nov '08

21 Nov '08

On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh <igloo(a)earth.li> wrote: > > Although another option would be to make GHCi a separate (GPL) frontend > to the (BSD) GHC API. The only downside is that (with static linking) we > have another large binary. Another upside is that other GHC API users > don't get an editline dependency. I've actually been experimenting with something similar: darcs get http://code.haskell.org/~judah/ghci-haskeline/ If you have ghc-6.10.1, 'cabal install'ing inside that repo will give you a version of ghci which uses Haskeline as its backend. Basically, I copied 4 modules from the GHC source tree (GhciMonad, InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; the rest of GHC is obtained through the API. Current benefits over the readline/editline versions: - Works on Windows - Tab completion of quoted filenames within Haskell expressions - Tab completion of Unicode identifiers (trac #2058) - Internally, eliminates the need for some GLOBAL_VARs The only real regression I'm aware of is that Haskeline doesn't yet provide a way to "bind" custom key commands as in an inputrc or editrc file. The recent discussion has indicated how important that feature is for some users, so it's next on my TODO list. -Judah

5 5

Crash in garbage collector
by Colin Paul Adams 21 Nov '08

21 Nov '08

I managed to get calling a Haskell function from an Eiffel program working with one Eiffel compiler, but when I compiled the program with a different Eiffel compiler, and ran it, I get a crash, apparently in the GHC garbage collector: (gdb) backtrace #0 0x0000000000452fc0 in evacuate () #1 0x000000000043b7f8 in scavenge_static () #2 0x0000000000439ea4 in GarbageCollect () #3 0x00000000004351df in scheduleDoGC () #4 0x00000000004353da in exitScheduler () #5 0x00000000004345a2 in hs_exit_ () #6 0x000000000041900c in T21f3 (C=0x1971f80, a1=7) at fib1.c:1200 #7 0x00000000004191a8 in T21c10 () at fib1.c:1000 #8 0x0000000000419356 in main (argc=<value optimized out>, argv=<value optimized out>) at fib1.c:11616 Can you suggest how I should go about investigating this problem further? -- Colin Adams Preston Lancashire

3 7

Ghci for Mac OSX?
by Colin Adams 21 Nov '08

21 Nov '08

I installed the 6.10.1 .pkg on my MacBook Air, and ghci works fine, but if I type ghci, I get program not found. Is it supposed to be available for Mac?

3 2

ANNOUNCE: GHC version 6.10.1
by Ian Lynagh 21 Nov '08

21 Nov '08

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Some new language features have been implemented: * Record syntax: wild-card patterns, punning, and field disambiguation * Generalised quasi-quotes * Generalised list comprehensions * View patterns * Type families have been completely re-implemented * Now comes with Haddock 2, which supports all GHC extensions * Parallel garbage collection * Base provides extensible exceptions * The GHC API is easier to use * External core (output only) now works again * Data Parallel Haskell (DPH) comes as part of GHC The full release notes are here: http://haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is 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 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/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ 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/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

10 22

Lazy minimum
by Dave Bayer 21 Nov '08

21 Nov '08

Compare these two lines in ghci (if you have at least 4 GB of memory): > let a = replicate (2^26) 2 in minimum [[1],a,a] > let a = replicate (2^26) 2 in minimum [a,a,[1]] The first finishes much faster than the second. This comes up for example in isomorphism testing of graphs embedded in surfaces, which is much easier than the general case: A choice of a directed edge determines a walk of the vertices and edges of the graph, from which the graph can be recovered. A minimal walk can be used to determine a canonical form for the graph, making for a nice Haskell one-liner: > normal graph = unwalk $ minimum $ map (walk graph) $ edges graph However, this code suffers from the same issue as the toy ghci lines above. Even though the walks are lazy, the minimum function wastefully explores them. It's clear how to fix this, comparing lazy lists: Play rounds of "Survivor", peeling off the heads of the lists at each iteration. One inevitably evaluates all of each minimal list, if there is more than one. This is familiar. For my example, the automorphisms of a graph show up in the complexity of any isomorphism algorithm; they manifest themselves here as the set of minimal walks. What I'm wondering, however, is if there is a way to code "minimum" efficiently in general, > minimum :: Ord a => [a] -> a where one knows absolutely nothing further about the type "a", but one believes that lazy evaluation will run afoul of the above issue. It would seem that this would require compiler support, allowing code to access approximations to lazy data generalizing the head of a lazy list. I'm reminded of working with power series by working mod x^n for various n. Here, I'd like a bounded version of "compare", that returned EQ for data that agreed to a specified lazy evaluation depth. Did I miss that class? Is there a construct in GHC that would allow me to write "minimum" efficiently for lazy data?

4 5

pseq strictness properties
by Duncan Coutts 21 Nov '08

21 Nov '08

I don't think I'm just speaking for myself when I say that pseq is confusing and the docs similarly. Given the type a -> b -> b we would assume that it is lazy in it's first arg and strict in the second. (Even in the presence of seq we know that it really really must be strict in it's second arg since it returns it or _|_ in which case it's still strict). Of course we know of the seq primitive with this type that is strict in both. However we also now have pseq that has the _opposite_ "static" strictness to the original expected strictness. Statically, pseq claims that it's strict in the first but lazy in the parameter that it _returns_. At runtime of course it is strict in both parameters. Given the need for pseq I would have expected pseq to statically be lazy in it's first argument (and actually be strict at runtime). I expected it'd statically be strict in the second arg. So I'm wondering if there is a good explanation for pseq having the opposite strictness properties to that which I expected. At first, even after reading the docs I assumed that it was just a typo and that it really meant it was lazy in the first arg (statically). I was just recording a patch to "fix" the documentation when I checked the underlying code and found to my surprise that the original docs are correct. I also think the docs need to be clarified to make this distinction between the actual strictness behaviour and what the compiler thinks it is during strictness analysis. Since they are different I think it's an important distinction to make. Now that I look at it, par has the same property, of statically being lazy in the second parameter that it returns (and thus is really strict). Again, this is not documented. Summary: why is it that way round, and can we think of a way to explain it better. Duncan

5 8

mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64
by Rahul Kapoor 21 Nov '08

21 Nov '08

I cannot get GHC to work on a fresh ubuntu hardy machine: On installing using the package manager I get an error when running ghci: "R_X86_64_32S relocation out of range:" - similar to http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is FreeBSD specific. I decided to install the binary distribution: after which running ghci fails with error: GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I Added issues #2779 to Trac for the second case. Are there any possible work arounds for these problems? Rahul

3 13

GHC 6.10.1 type puzzler
by Dave Bayer 19 Nov '08

19 Nov '08

Here is an example illustrating a type problem I've having with GHC 6.10.1: > module Main where > > newtype Box a = B a > > make :: a -> Box a > make x = B x > > val :: Box a -> a > val (B x) = x > > test1 :: Box a -> a -> [a] > test1 box x = go box x > where > go :: Box a -> a -> [a] > go b y = [(val b), y] > > test2 :: Box a -> a -> [a] > test2 box x = go x > where > -- go :: a -> [a] > go y = [(val box), y] > > main :: IO () > main = do > print $ test1 (make 1) 2 If I uncomment the commented type declaration, I get the familiar error > Couldn't match expected type `a1' against inferred type `a' On the other hand, the earlier code is identical except that it passes an extra argument, and GHC matches the types without complaint. This is a toy example to isolate the issue; in the actual code one wants a machine-checkable type declaration to help understand the function, which is local to save passing an argument. To the best of my understanding, I've given the correct type, but GHC won't make the inference to unify the type variables. I wonder if I found a GHC blind spot. However, it is far more likely that my understanding is faulty here. Any thoughts? Thanks, Dave

4 4

language features in 6.10.1
by Serge D. Mechveliani 19 Nov '08

19 Nov '08

The GHC team writes > The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 > [..] > There have been a number of significant changes since the last > major release, including: > > * Some new language features have been implemented: > * Record syntax: wild-card patterns, punning, and field disambiguation > * Generalised quasi-quotes > * Generalised list comprehensions > * View patterns > > [..] Please, where and in what chapters these 4 language features are documented? Thank you in advance for help, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Re: Unicode's greek lambda
by Donn Cave 18 Nov '08

18 Nov '08

Quoth Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>: | On Tue, 2008-11-18 at 11:51 +0000, Ross Paterson wrote: |> But it could be a reserved word synonymous with \. After all, \ can |> occur in operator symbols, but the operator \ is reserved. | | Presumably that would let you do (\ x -> ...) but not (\x -> ) since the | "\x" would run together and lexically it would be one identifier. Good, that's clearly the right way to do it anyway! Donn

1 0