November 2007 - Glasgow-haskell-users

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

03 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

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 29 Nov '07

29 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

Top-level bindings for unlifted types
by Neil Mitchell 28 Nov '07

28 Nov '07

Hi, The following program: ------------------------------------------- {-# OPTIONS_GHC -fglasgow-exts #-} module Test() where import GHC.Base test = realWorld# ----------------------------------------- gives the error message: Top-level bindings for unlifted types aren't allowed: { test = realWorld# } Changing to test _ = realWorld# works fine. The question is why are these bindings disallowed? Reading the "Unboxed values as first class citizens" paper I can't see it listed as a restriction. Thanks Neil

5 6

single-stepping and infinite recursion
by Wolfgang Jeltsch 27 Nov '07

27 Nov '07

Hello, please consider the following program: main = putChar 'A' >> main I load this into GHCi, enter :step main, followed by :step and a second :step. Although I would expect to get the As in the output step by step, GHCi now hangs inside the infinite loop. Is this intentional? To me, this seems rather weird. I wanted to use GHCi’s debugger to find the reason for an infinite recursion but from my experience it looks as if this might not be possible. :-( Best wishes, Wolfgang

3 3

Profiling bugs in 6.8.1 and 6.6.1
by Daniel Fischer 26 Nov '07

26 Nov '07

Hello, first let me remark that 6.8.1 is really remarkable, compiles faster and produces faster executables than 6.6.1. However, I have a problem with profiling, the time is always reported as 0.00 secs: Sun Nov 25 22:58 2007 Time and Allocation Profiling Report (Final) p28Master +RTS -P -hb -sstderr -RTS MMDataA total time = 0.00 secs (0 ticks @ 20 ms) total alloc = 1,313,421,840 bytes (excludes profiling overheads) although it took more than 15 seconds: INIT time 0.00s ( 0.00s elapsed) MUT time 16.10s ( 16.41s elapsed) GC time 10.76s ( 11.16s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 26.86s ( 27.57s elapsed) Could that be caused by commenting out the lines ifeq "$(GhcThreaded)" "YES" SRC_HC_OPTS += -threaded endif in compiler/Makefile.ghcbin ? I did that because if I build ghc with -threaded, the times reported with :set +s in ghci are rubbish (I have a linux 2.4.20 kernel, and the threads don't support process-wide times; and no, I'm not likely to upgrade, SuSE 8.2 is the only OS that ever worked properly for me). If that's the cause, too bad, I'll have to revert to 6.4.2 for profiling :( In 6.6.1, -O2 and -prof -auto-all don't work together well, I have a programme where that combination of options results in an instant wrong output, while the combinations -prof -auto-all -O1 -prof -auto-all -O2 -prof lead to the correct output calculated in 10 to 13 seconds. If you're interested in that bug, I could send you the code, it's short enough. Thanks, Daniel

2 1

docon soft announcement
by Serge D. Mechveliani 25 Nov '07

25 Nov '07

Software Announcement. The Algebraic Domain Constructor DoCon, Version 2.11 is available at http://www.botik.ru/pub/local/Mechveliani/docon/ (Russian site), ftp.botik.ru/pub/local/Mechveliani/docon/ (same site), http://www.haskell.org/docon/distrib/ (USA site) It works under ghc-6.8.1 and 6.6.1. The difference to the previous release of 2.10 is only a couple of minor bug fixes in installation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0