- Glasgow-haskell-users

ghc vs ghci: why can't ghci do everything ghc can do?
by Claus Reinke 04 Dec '07

04 Dec '07

1) is there a single place/wiki/ticket that collects all the deficiencies of ghci, compared to ghc? things like: a) which platforms have ghc, but not ghci b) which features are available in ghc, but not in ghci c) does ghci encounter bugs where ghc would succeed d) which of these deficiencies are temporary, which are likely to stay 2) given that ghci is ghc --interactive, why are there any cases of b/c above at all? wouldn't it be possible for ghci to try its stuff, but to fall back to ghc only for those modules which it can't handle from source itself (yet)? - we can do ghc --make; ghci, to get around issues - we can do ghci -fforce-recomp, to get to sources but those two are rather coarse-grained, and require too much manual tweaking to get the effect of creating a ghci session with as many modules from source as possible, and all others from object files. 3) suggestions: a) could we have a :make command in ghci that does a 'ghc --make' while reusing the information from the current session? b) could we have a --prefer-source option for ghci, so that 'ghc --make; ghci --prefer-source' will try to load all modules from source, but will fall back to the existing object files if necessary (instead of failing, as -fforce-recomp does)? c) allow selective switching between source and object files loaded into ghci (:prefer source M,N,..; :prefer object O,P,Q,..). the application i have in mind is trying to use ghci on non-trivial projects, such as darcs, or even ghc itself: - it isn't possible to load all sources into ghci - loading all object files is possible, but prevents use of ghci features such as ':m *Module', ':browse *Module', breakpoints, tags, .. - ghci -fforce-recomp fails because it applies to all modules - there is substantial setup to do before one can call ghc or ghci, so dropping out of a session and trying to figure out dependencies and flags for compiling individual modules by hand isn't practical - there is often a configurable makefile, so that one can use the same setup for calling either 'ghc --make' or 'ghc --interactive'; but, within the latter, one cannot simply switch to full :make or to selective --prefer-source, without losing the setup ideally, ghci would simply work whereever ghc works, and would provide its additional features for as many modules as it can. but in the interim, having 3a and especially 3b would help me a lot. 3c would also be nice, too, but not as urgent as 3b. i find it sad that, currently, there is this gap that doesn't allow me to make full use of ghci's features for larger projects such as darcs or ghc. is hoping for 3b realistic? claus

2 3

Leopard: ghc 6.8.1 and the case of the missing _environ
by Joel Reymont 04 Dec '07

04 Dec '07

Symptoms: You build 6.8.1 from source on Leopard (x86 in my case) and then junior:ghc-6.8.1 joelr$ ghci GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help ghc-6.8.1: /usr/local/lib/ghc-6.8.1/lib/base-3.0.0.0/HSbase-3.0.0.0.o: unknown symbol `_environ' Loading package base ... linking ... ghc-6.8.1: unable to load package `base' Problem: ghc binaries are being stripped upon installation which eliminates _environ, e.g. junior:tmp joelr$ nm x|grep environ 00002ff0 T ___hscore_environ 0004d004 D _environ junior:tmp joelr$ strip x junior:tmp joelr$ nm x|grep environ Solution: Need to make sure install-sh does _not_ use the -s option. Haven't found out where this needs to be done yet. A temporary workaround is to ask Manuel for the pre-built binaries. Thanks, Joel -- http://wagerlabs.com

3 3

RE: fundeps help
by Sittampalam, Ganesh 04 Dec '07

04 Dec '07

> I think that if you use the HEAD, much of > this will work, if you use the type-equality > notation. But you will probably encounter bugs > too. And in so doing, and reporting them, you'll > be doing us a service. I did originally intend to try all this with the HEAD, but one obstacle to this is the lack of recent linux binaries in http://www.haskell.org/ghc/dist/current/dist/ I tried building it myself, but something or another failed, and in general I think keeping up by that route would be a rather high overhead process. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

2 1

Type Families and enhanced constraints (at run-time)
by Jim Burton 04 Dec '07

04 Dec '07

Hi, I hope this is the right place to ask about working with type families...I want to make a library of Set operations that carries proofs at the type level, e.g. to make things like this possible, > insert :: Member e s' T => e -> Set s -> Set s' > union :: Union s t u => Set s -> Set t -> Set u The trouble is designing the Set datatype so it can be used in type constraints *and* in run-time functions....Something similar is of course possible with fun deps, and I knocked something up following the example of Conrad Parker's 'Instant Insanity' but, crucially, that code is 'trapped' in the type system with no populated types. I want term-level/run-time functions with enhanced constraints, such as in the example Manuel posted in haskell-cafe: > data Z > data S a > > data SNat n where > Zero :: SNat Z > Succ :: SNat n -> SNat (S n) > > zero = Zero > one = Succ zero > > type family (:+:) n m :: * > type instance Z :+: m = m > type instance (S n) :+: m = S (n :+: m) > > add :: SNat n -> SNat m -> SNat (n :+: m) > add Zero m = m > add (Succ n) m = Succ (add n m) This seems like "the best of both worlds" -- maybe it could be a general strategy for making for making these enhanced constraints at the term-level? Make a (populated) GADT and parameterise it with a phantom type (perhaps amongst other things). Make a type operator that can be used to express the constraint on the phantom types carried around by the "regular" populated type. When the type operator appears in the codomain of the function it's a compile-time check on the implementation of that function and when in the domain it checks the user at run-time. However, (SNat n) can be put very succinctly because it doesn't need to carry a value around other than the Peano number in the phantom type. What about Sets? In my case the values in the sets are just labels and could well be empty: > data A ; data B ; data C And I also need to express the cons-ness -- I don't think that needs fancy constraints so it can be done with terms, e.g., an underlying sequence such as in the Collects example. Generally I need to work out what needs to be run-time and what compile-time but I think that would follow from getting the combinations of types and terms in the Set abstraction right...could someone give me a pointer with this? Many thanks, Jim

3 6

GHC porting to FreeBSD-amd64 progress report
by wb＠arb-phys.uni-dortmund.de 03 Dec '07

03 Dec '07

In my effort to produce a working FreeBSD-amd64 compiler I made some progress. Now I have a working stage1/ghc-inplace (which is a 32bit executable producing 64bit code). But the compilation of rts fails in file Apply.cmm with the following message: == gmake all -r; in /.amd_mnt/vestein/host/usr/home/wb/ghc-6.8.1/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -H16m -O -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Apply.cmm -o Apply.o In file included from Apply.cmm:13:0: /.amd_mnt/vestein/host/usr/home/wb/ghc-6.8.1/includes/Cmm.h:333:2: error: #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false gmake[1]: *** [Apply.o] Error 1 gmake: *** [stage1] Error 1 This is, of course, because the derived constants SIZEOF_mp_limb_t is wrong. Is there a way to get to a working system from this intermediate stage? I tried to replace the real 32bit ghc in /usr/local/bin/ghc with a ghc-inplace, but this didn't work. Probably I only need to get the correct derived constants in the header files and remake the files depending on them. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key

3 4

win32&ghc: using more than 2gb of memory
by Bulat Ziganshin 03 Dec '07

03 Dec '07

Hello is it possible to use more than 2gb of memory for win32 ghc-compiled programs? does anyone checked this? i've found that the following switch should be added to cmdline: ghc ... -optl --large-address-aware but can't check compiled executable if this question was never considered, here is some possible problems which may arise: http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

cabal for ghc 6.8.2, package upgrade warnings, please?
by Claus Reinke 30 Nov '07

30 Nov '07

assuming that ghc 6.8.2 is not too far away, is there any chance of cabal becoming a bit friendlier wrt old .cabal and Setup files, before that release? you've heard me say before that i'd have preferred a backwards compatibility module, but if that isn't possible, couldn't cabal at least detect that a .cabal file is probably outdated (==not obviously up to date), and issue a warning with a helpful url? something like: $ runhaskell Setup configure *** warning: this .cabal/Setup file might be out of date; *** if you run into issues, please contact the *** package maintainer, and have a look at *** http://haskell.org/haskellwiki/Upgrading_packages .. (either it works or you get errors here, but you already know something is not quite right, and what to do about it) btw, i knew that page existed, but had quite a bit of trouble finding it. shouldn't there be prominent links to it from cabal and hackage home pages? as in: concerning recent cabal updates (look here first if you have trouble with old .cabal packages). in the longer term, that could become the start of a cabal/hackage faq section.. claus

1 0

ghci changes in 6.8 that are not improvements
by Alex Jacobson 30 Nov '07

30 Nov '07

1. just using : at the prompt caused a reload. Now you have to type :r. 2. reload now reloads all modules rather than just the modules that changed (faster but not as fast as not reloading them at all). -Alex-

4 6

ENC: Call for Papers - SBLP 2008 (12th BRAZILIAN SYMPOSIUM ON PROGRAMMING LANGUAGES)
by Heron 30 Nov '07

30 Nov '07

12th BRAZILIAN SYMPOSIUM ON PROGRAMMING LANGUAGES <http://www.lia.ufc.br/sblp2008> http://www.lia.ufc.br/sblp2008 Fortaleza, Ceara, Brazil August 27-29, 2008 CALL FOR PAPERS AND TUTORIALS The 12th Brazilian Symposium on Programming Languages, SBLP 2008, will be held in Fortaleza, Ceara, Brazil, on August 27-29, 2008. SBLP provides a venue for researchers and practitioners interested in the fundamental principles and innovations in the design and implementation of programming languages and systems. SBLP 2008 invites authors to contribute with Technical Papers and Tutorial Proposals related (but not limited) to: * Programming language design and implementation * Formal semantics of programming languages * Theoretical foundations of programming languages * Design and implementation of programming language environments * Object-oriented programming languages * Functional programming * Aspect-oriented programming languages * Scripting languages * Domain-specific languages * Programming languages for mobile, web and network computing * New programming models * Program transformations * Program analysis and verification * Compilation and interpretation techniques Contributions can be written in Portuguese or English. Papers should have at most 14 pages. All accepted papers will be published in the conference proceedings. Selected papers will appear in a Special Issue of the Journal of Universal Computer Science (J.UCS). Only papers written in English are eligible to be published in JUCS. Papers should be presented in the language of submission. Tutorial submissions must be in the form of an extended abstract with at most 10 pages. The final version of accepted tutorials should contain at most 30 pages. This final version will be distributed to attendees. An abstract of the tutorial (1-2 pages) will be included in the conference proceedings. Detailed submission guidelines are available at <http://www.lia.ufc.br/sblp2008> http://www.lia.ufc.br/sblp2008. IMPORTANT DATES Paper abstract submission (15 lines): March 28, 2008 Full paper submission: April 4, 2008 Notification of acceptance: June 6, 2008 Final papers due: June 30, 2008 GENERAL CHAIR Francisco Heron de Carvalho Junior, UFC PROGRAMME CHAIRS Marco Tulio Valente, PUC Minas Peter Mosses, Swansea University PROGRAMME COMMITTEE Alberto Pardo, Univ. de La Republica Alex Garcia, IME Alfio Martini, PUC-RS Alvaro Freitas Moreira, UFRGS Andre Rauber Du Bois, UCPel Andre Santos, UFPE Carlos Camarao, UFMG Christiano Braga, Univ. Comp. de Madrid David Naumann, Stevens Tech Eric Tanter, Univ. of Chile Francisco Heron de Carvalho Junior, UFC Isabel Cafezeiro, UFF Johan Jeuring, Utrecht Univ. Joao Saraiva, Univ. do Minho Jose Guimaraes, UFSCAR Jose E. Labra Gayo, Univ. of Oviedo Jose Luiz Fiadeiro, Univ. of Leicester Lucilia Figueiredo, UFOP Luis Soares Barbosa, Univ. do Minho Luis Carlos Meneses, UPE Marcelo A. Maia, UFU Mariza A. S. Bigonha, UFMG Martin A. Musicante, UFRN Nabor Mendonca,UNIFOR Nick Benton, Microsoft Research Noemi Rodriguez, PUC-Rio Paulo Borba, UFPE Rafael Dueire Lins, UFPE Renato Cerqueira, PUC-Rio Ricardo Massa Lima, UPE Roberto S. Bigonha, UFMG Roberto Ierusalimschy, PUC-Rio Rodolfo Jardim de Azevedo, UNICAMP Sandro Rigo, UNICAMP Sergio de Mello Schneider, UFU Sergio Soares, UPE Sergiu Dascalu, Univ. of Nevada Simon Thompson, Univ. of Kent Varmo Vene, Univ. de Tartu Vitor Santos Costa, UFRJ Vladimir Di Iorio, UFV ORGANIZATION Brazilian Computer Society and Federal University of Ceara

1 0

GHC's CPP and Cabal's unlit
by Alistair Bayley 29 Nov '07

29 Nov '07

I'm doing some testing with GHC 6.6.1 and Cabal 1.3, and I'm trying to figure out what happens with CPP and Cabal's unlit. I start with file Test.lhs: > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" and run command: ghc -E -x hs -cpp Test.lhs -o Test2.lhs which gives me Test2.lhs: {-# LINE 1 "Test.lhs" #-} # 1 "Test.lhs" # 1 "<built-in>" # 1 "<command line>" # 1 "Test.lhs" > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" So I'm wondering: where does the {-# LINE #-} comment come from, and also the # 1 lines? AFAICT the # 1 lines are ignored by GHC; I can compile Test2.lhs without errors. Is there anything in GHC's docs about this? More puzzling is that the files that Cabal runs through ghc's CPP don't get the # n lines, so we end up with something like this: {-# LINE 1 "Test.lhs" #-} > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" which is not a valid .lhs file, because we have a code line next to a comment. I also note in Cabal the haddock command runs CPP before unlit. GHC does it the other way around i.e. run unlit first then CPP, and I'm wondering if Cabal shouldn't do the same thing? Thanks, Alistair

2 2