From voldermort at hotmail.com Tue Mar 4 08:15:38 2014 From: voldermort at hotmail.com (harry) Date: Tue, 4 Mar 2014 00:15:38 -0800 (PST) Subject: Stripping the bindist? Message-ID: <1393920938577-5745023.post@n5.nabble.com> Should the binary distribution be stripped? Not a huge deal, but I'm saving a fair amount of space by stripping http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-x86_64-unknown-linux-rhel65.tar.bz2 after installing it. -- View this message in context: http://haskell.1045720.n5.nabble.com/Stripping-the-bindist-tp5745023.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Tue Mar 4 09:13:39 2014 From: voldermort at hotmail.com (harry) Date: Tue, 4 Mar 2014 01:13:39 -0800 (PST) Subject: Problem with gold linker and 7.8.1rc2 Message-ID: <1393924419253-5745027.post@n5.nabble.com> If I use the gold linker with 7.8.1rc2 (RHEL bindist), anything using network in build-depends - even if it's not used in the code - fails to build with: libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to 'sem_unlink' libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to 'sem_open' libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to 'sem_wait' libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to 'sem_getvalue' libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to 'sem_close' libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to 'sem_post' libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to 'sem_trywait' (I only have shared libraries on this machine.) -- View this message in context: http://haskell.1045720.n5.nabble.com/Problem-with-gold-linker-and-7-8-1rc2-tp5745027.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From mail at joachim-breitner.de Tue Mar 4 15:29:12 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 04 Mar 2014 16:29:12 +0100 Subject: RC2 build failures on Debian: mips In-Reply-To: <1391693762.2555.9.camel@kirk> References: <1391693762.2555.9.camel@kirk> Message-ID: <1393946952.2433.10.camel@kirk> Hi, building RC2 right now, and the failures have changed. Reporting as the come in: Am Donnerstag, den 06.02.2014, 13:36 +0000 schrieb Joachim Breitner: > mips (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=mips&ver=7.8.20140130-1&stamp=1391631539) > mipsel (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=mipsel&ver=7.8.20140130-1&stamp=1391660280) > In file included from rts/sm/Evac.c:21:0: > rts/sm/GCTDecl.h:139:2: error: #error Cannot find a way to declare the thread-local gc variable! > #error Cannot find a way to declare the thread-local gc variable! > ^ > make[2]: *** [rts/dist/build/.depend-v-p-dyn-l-debug-thr-thr_debug-thr_l-thr_p-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn-thr_debug_p.c_asm] Error 1 > make[2]: *** Waiting for unfinished jobs.... > echo "compiler_stage2_depfile_haskell_EXISTS = YES" >> compiler/stage2/build/.depend-v-p-dyn.haskell.tmp > for dir in compiler/stage2/build/./ compiler/stage2/build/CodeGen/ compiler/stage2/build/CodeGen/Platform/ compiler/stage2/build/Hoopl/ compiler/stage2/build/Llvm/ compiler/stage2/build/LlvmCodeGen/ compiler/stage2/build/PPC/ compiler/stage2/build/RegAlloc/ compiler/stage2/build/RegAlloc/Graph/ compiler/stage2/build/RegAlloc/Linear/ compiler/stage2/build/RegAlloc/Linear/PPC/ compiler/stage2/build/RegAlloc/Linear/SPARC/ compiler/stage2/build/RegAlloc/Linear/X86/ compiler/stage2/build/RegAlloc/Linear/X86_64/ compiler/stage2/build/SPARC/ compiler/stage2/build/SPARC/CodeGen/ compiler/stage2/build/Vectorise/ compiler/stage2/build/Vectorise/Builtins/ compiler/stage2/build/Vectorise/Generic/ compiler/stage2/build/Vectorise/Monad/ compiler/stage2/build/Vectorise/Type/ compiler/stage2/build/Vectorise/Utils/ compiler/stage2/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done > grep -v ' : [a-zA-Z]:/' compiler/stage2/build/.depend-v-p-dyn.haskell.tmp > compiler/stage2/build/.depend-v-p-dyn.haskell.tmp2 > sed '/hs$/ p ; /hs$/ s/o /hi /g ; /hs$/ s/:/ : %hi: %o / ; /hs$/ s/^/$(eval $(call hi-rule,/ ; /hs$/ s/$/))/ ; /hs-boot$/ p ; /hs-boot$/ s/o-boot /hi-boot /g ; /hs-boot$/ s/:/ : %hi-boot: %o-boot / ; /hs-boot$/ s/^/$(eval $(call hi-rule,/ ; /hs-boot$/ s/$/))/' compiler/stage2/build/.depend-v-p-dyn.haskell.tmp2 > compiler/stage2/build/.depend-v-p-dyn.haskell > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/?PKGBUILDDIR?' > make: *** [build-stamp] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > Is now: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=mipsel&ver=7.8.20140228-1&stamp=1393940600 "rm" -f rts/dist/build/libHSrts.a echo rts/dist/build/Adjustor.o rts/dist/build/Arena.o rts/dist/build/Capability.o rts/dist/build/CheckUnload.o rts/dist/build/ClosureFlags.o rts/dist/build/Disassembler.o rts/dist/build/FileLock.o rts/dist/build/Globals.o rts/dist/build/Hash.o rts/dist/build/Hpc.o rts/dist/build/HsFFI.o rts/dist/build/Inlines.o rts/dist/build/Interpreter.o rts/dist/build/LdvProfile.o rts/dist/build/Linker.o rts/dist/build/Messages.o rts/dist/build/OldARMAtomic.o rts/dist/build/Papi.o rts/dist/build/Printer.o rts/dist/build/ProfHeap.o rts/dist/build/Profiling.o rts/dist/build/Proftimer.o rts/dist/build/RaiseAsync.o rts/dist/build/RetainerProfile.o rts/dist/build/RetainerSet.o rts/dist/build/RtsAPI.o rts/dist/build/RtsDllMain.o rts/dist/build/RtsFlags.o rts/dist/build/RtsMain.o rts/dist/build/RtsMessages.o rts/dist/build/RtsStartup.o rts/dist/build/RtsUtils.o rts/dist/build/STM.o rts/dist/build/Schedule.o rts/dist/build/Sparks.o rts/dist/build/Stable.o rts/dist/build/Stats.o rts/dist/build/StgCRun.o rts/dist/build/StgPrimFloat.o rts/dist/build/Task.o rts/dist/build/ThreadLabels.o rts/dist/build/ThreadPaused.o rts/dist/build/Threads.o rts/dist/build/Ticky.o rts/dist/build/Timer.o rts/dist/build/Trace.o rts/dist/build/WSDeque.o rts/dist/build/Weak.o rts/dist/build/hooks/FlagDefaults.o rts/dist/build/hooks/MallocFail.o rts/dist/build/hooks/OnExit.o rts/dist/build/hooks/OutOfHeap.o rts/dist/build/hooks/StackOverflow.o rts/dist/build/sm/BlockAlloc.o rts/dist/build/sm/Compact.o rts/dist/build/sm/Evac.o rts/dist/build/sm/GC.o rts/dist/build/sm/GCAux.o rts/dist/build/sm/GCUtils.o rts/dist/build/sm/MBlock.o rts/dist/build/sm/MarkWeak.o rts/dist/build/sm/Sanity.o rts/dist/build/sm/Scav.o rts/dist/build/sm/Storage.o rts/dist/build/sm/Sweep.o rts/dist/build/eventlog/EventLog.o rts/dist/build/posix/GetEnv.o rts/dist/build/posix/GetTime.o rts/dist/build/posix/Itimer.o rts/dist/build/posix/OSMem.o rts/dist/build/posix/OSThreads.o rts/dist/build/posix/Select.o rts/dist/build/posix/Signals.o rts/dist/build/posix/TTY.o rts/dist/build/Apply.o rts/dist/build/Exception.o rts/dist/build/HeapStackCheck.o rts/dist/build/PrimOps.o rts/dist/build/StgMiscClosures.o rts/dist/build/StgStartup.o rts/dist/build/StgStdThunks.o rts/dist/build/Updates.o rts/dist/build/AutoApply.o | "xargs" "/usr/bin/ar" q rts/dist/build/libHSrts.a /usr/bin/ar: creating rts/dist/build/libHSrts.a "rm" -f rts/dist/build/libHSrts_p.a echo rts/dist/build/Adjustor.p_o rts/dist/build/Arena.p_o rts/dist/build/Capability.p_o rts/dist/build/CheckUnload.p_o rts/dist/build/ClosureFlags.p_o rts/dist/build/Disassembler.p_o rts/dist/build/FileLock.p_o rts/dist/build/Globals.p_o rts/dist/build/Hash.p_o rts/dist/build/Hpc.p_o rts/dist/build/HsFFI.p_o rts/dist/build/Inlines.p_o rts/dist/build/Interpreter.p_o rts/dist/build/LdvProfile.p_o rts/dist/build/Linker.p_o rts/dist/build/Messages.p_o rts/dist/build/OldARMAtomic.p_o rts/dist/build/Papi.p_o rts/dist/build/Printer.p_o rts/dist/build/ProfHeap.p_o rts/dist/build/Profiling.p_o rts/dist/build/Proftimer.p_o rts/dist/build/RaiseAsync.p_o rts/dist/build/RetainerProfile.p_o rts/dist/build/RetainerSet.p_o rts/dist/build/RtsAPI.p_o rts/dist/build/RtsDllMain.p_o rts/dist/build/RtsFlags.p_o rts/dist/build/RtsMain.p_o rts/dist/build/RtsMessages.p_o rts/dist/build/RtsStartup.p_o rts/dist/build/RtsUtils.p_o rts/dist/build/STM.p_o rts/dist/build/Schedule.p_o rts/dist/build/Sparks.p_o rts/dist/build/Stable.p_o rts/dist/build/Stats.p_o rts/dist/build/StgCRun.p_o rts/dist/build/StgPrimFloat.p_o rts/dist/build/Task.p_o rts/dist/build/ThreadLabels.p_o rts/dist/build/ThreadPaused.p_o rts/dist/build/Threads.p_o rts/dist/build/Ticky.p_o rts/dist/build/Timer.p_o rts/dist/build/Trace.p_o rts/dist/build/WSDeque.p_o rts/dist/build/Weak.p_o rts/dist/build/hooks/FlagDefaults.p_o rts/dist/build/hooks/MallocFail.p_o rts/dist/build/hooks/OnExit.p_o rts/dist/build/hooks/OutOfHeap.p_o rts/dist/build/hooks/StackOverflow.p_o rts/dist/build/sm/BlockAlloc.p_o rts/dist/build/sm/Compact.p_o rts/dist/build/sm/Evac.p_o rts/dist/build/sm/GC.p_o rts/dist/build/sm/GCAux.p_o rts/dist/build/sm/GCUtils.p_o rts/dist/build/sm/MBlock.p_o rts/dist/build/sm/MarkWeak.p_o rts/dist/build/sm/Sanity.p_o rts/dist/build/sm/Scav.p_o rts/dist/build/sm/Storage.p_o rts/dist/build/sm/Sweep.p_o rts/dist/build/eventlog/EventLog.p_o rts/dist/build/posix/GetEnv.p_o rts/dist/build/posix/GetTime.p_o rts/dist/build/posix/Itimer.p_o rts/dist/build/posix/OSMem.p_o rts/dist/build/posix/OSThreads.p_o rts/dist/build/posix/Select.p_o rts/dist/build/posix/Signals.p_o rts/dist/build/posix/TTY.p_o rts/dist/build/Apply.p_o rts/dist/build/Exception.p_o rts/dist/build/HeapStackCheck.p_o rts/dist/build/PrimOps.p_o rts/dist/build/StgMiscClosures.p_o rts/dist/build/StgStartup.p_o rts/dist/build/StgStdThunks.p_o rts/dist/build/Updates.p_o rts/dist/build/AutoApply.p_o | "xargs" "/usr/bin/ar" q rts/dist/build/libHSrts_p.a /usr/bin/ar: creating rts/dist/build/libHSrts_p.a "rm" -f rts/dist/build/libHSrts-ghc7.8.0.20140228.so "inplace/bin/ghc-stage1" -package-name rts -shared -dynamic -dynload deploy -no-auto-link-packages `cat rts/dist/libs.depend` rts/dist/build/Adjustor.dyn_o rts/dist/build/Arena.dyn_o rts/dist/build/Capability.dyn_o rts/dist/build/CheckUnload.dyn_o rts/dist/build/ClosureFlags.dyn_o rts/dist/build/Disassembler.dyn_o rts/dist/build/FileLock.dyn_o rts/dist/build/Globals.dyn_o rts/dist/build/Hash.dyn_o rts/dist/build/Hpc.dyn_o rts/dist/build/HsFFI.dyn_o rts/dist/build/Inlines.dyn_o rts/dist/build/Interpreter.dyn_o rts/dist/build/LdvProfile.dyn_o rts/dist/build/Linker.dyn_o rts/dist/build/Messages.dyn_o rts/dist/build/OldARMAtomic.dyn_o rts/dist/build/Papi.dyn_o rts/dist/build/Printer.dyn_o rts/dist/build/ProfHeap.dyn_o rts/dist/build/Profiling.dyn_o rts/dist/build/Proftimer.dyn_o rts/dist/build/RaiseAsync.dyn_o rts/dist/build/RetainerProfile.dyn_o rts/dist/build/RetainerSet.dyn_o rts/dist/build/RtsAPI.dyn_o rts/dist/build/RtsDllMain.dyn_o rts/dist/build/RtsFlags.dyn_o rts/dist/build/RtsMain.dyn_o rts/dist/build/RtsMessages.dyn_o rts/dist/build/RtsStartup.dyn_o rts/dist/build/RtsUtils.dyn_o rts/dist/build/STM.dyn_o rts/dist/build/Schedule.dyn_o rts/dist/build/Sparks.dyn_o rts/dist/build/Stable.dyn_o rts/dist/build/Stats.dyn_o rts/dist/build/StgCRun.dyn_o rts/dist/build/StgPrimFloat.dyn_o rts/dist/build/Task.dyn_o rts/dist/build/ThreadLabels.dyn_o rts/dist/build/ThreadPaused.dyn_o rts/dist/build/Threads.dyn_o rts/dist/build/Ticky.dyn_o rts/dist/build/Timer.dyn_o rts/dist/build/Trace.dyn_o rts/dist/build/WSDeque.dyn_o rts/dist/build/Weak.dyn_o rts/dist/build/hooks/FlagDefaults.dyn_o rts/dist/build/hooks/MallocFail.dyn_o rts/dist/build/hooks/OnExit.dyn_o rts/dist/build/hooks/OutOfHeap.dyn_o rts/dist/build/hooks/StackOverflow.dyn_o rts/dist/build/sm/BlockAlloc.dyn_o rts/dist/build/sm/Compact.dyn_o rts/dist/build/sm/Evac.dyn_o rts/dist/build/sm/GC.dyn_o rts/dist/build/sm/GCAux.dyn_o rts/dist/build/sm/GCUtils.dyn_o rts/dist/build/sm/MBlock.dyn_o rts/dist/build/sm/MarkWeak.dyn_o rts/dist/build/sm/Sanity.dyn_o rts/dist/build/sm/Scav.dyn_o rts/dist/build/sm/Storage.dyn_o rts/dist/build/sm/Sweep.dyn_o rts/dist/build/eventlog/EventLog.dyn_o rts/dist/build/posix/GetEnv.dyn_o rts/dist/build/posix/GetTime.dyn_o rts/dist/build/posix/Itimer.dyn_o rts/dist/build/posix/OSMem.dyn_o rts/dist/build/posix/OSThreads.dyn_o rts/dist/build/posix/Select.dyn_o rts/dist/build/posix/Signals.dyn_o rts/dist/build/posix/TTY.dyn_o rts/dist/build/Apply.dyn_o rts/dist/build/Exception.dyn_o rts/dist/build/HeapStackCheck.dyn_o rts/dist/build/PrimOps.dyn_o rts/dist/build/StgMiscClosures.dyn_o rts/dist/build/StgStartup.dyn_o rts/dist/build/StgStdThunks.dyn_o rts/dist/build/Updates.dyn_o rts/dist/build/AutoApply.dyn_o -o rts/dist/build/libHSrts-ghc7.8.0.20140228.so /usr/bin/ld: rts/dist/build/Adjustor.dyn_o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC rts/dist/build/Adjustor.dyn_o: error adding symbols: Bad value collect2: error: ld returned 1 exit status make[2]: *** [rts/dist/build/libHSrts-ghc7.8.0.20140228.so] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [all] Error 2 make[1]: Leaving directory `/?PKGBUILDDIR?' make: *** [build-stamp] Error 2 Does anyone feel responsible for exotic architectures? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From nikita at karetnikov.org Tue Mar 4 19:36:09 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Tue, 04 Mar 2014 23:36:09 +0400 Subject: RC2 build failures on Debian: mips In-Reply-To: <1393946952.2433.10.camel@kirk> (Joachim Breitner's message of "Tue, 04 Mar 2014 16:29:12 +0100") References: <1391693762.2555.9.camel@kirk> <1393946952.2433.10.camel@kirk> Message-ID: <878usppxhy.fsf@karetnikov.org> > rts/dist/build/Adjustor.dyn_o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > make[2]: *** [rts/dist/build/libHSrts-ghc7.8.0.20140228.so] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/?PKGBUILDDIR?' > make: *** [build-stamp] Error 2 I got the same error on my mips64el machine. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From mail at joachim-breitner.de Wed Mar 5 21:54:42 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 05 Mar 2014 22:54:42 +0100 Subject: RC2 build failures on Debian: sparc Message-ID: <1394056482.6318.3.camel@kirk> Hi, sparc fails differently than in RC1, and very plainly with a segmentation fault in dll-split (which happens to be the first program to be run that is compiled with stage1): https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140228-1&stamp=1393975264 Any ideas? Anyone feeling responsible? It would be shame to loose a lot of architectures in 7.8 compared to 7.6, but I?m not a porter and don?t know much about these part of the compiler, so I have to rely on your support in fixing these problems, preferably before 7.8.1. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From mle+hs at mega-nerd.com Wed Mar 5 22:47:15 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Thu, 6 Mar 2014 09:47:15 +1100 Subject: RC2 build failures on Debian: sparc In-Reply-To: <1394056482.6318.3.camel@kirk> References: <1394056482.6318.3.camel@kirk> Message-ID: <20140306094715.fd6037fb07525f79aca4350b@mega-nerd.com> Joachim Breitner wrote: > sparc fails differently than in RC1, and very plainly with a > segmentation fault in dll-split (which happens to be the first program > to be run that is compiled with stage1): > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140228-1&stamp=1393975264 > > Any ideas? Anyone feeling responsible? > > It would be shame to loose a lot of architectures in 7.8 compared to > 7.6, but I?m not a porter and don?t know much about these part of the > compiler, so I have to rely on your support in fixing these problems, > preferably before 7.8.1. I've seen this on powerpc64 as well, but I first ran into this well before 7.8.1. See: https://ghc.haskell.org/trac/ghc/ticket/8024 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From fmaste at gmail.com Fri Mar 7 15:47:38 2014 From: fmaste at gmail.com (Federico Mastellone) Date: Fri, 7 Mar 2014 12:47:38 -0300 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 Message-ID: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> Hi, On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 Doing: cabal configure --enable-library-coverage cabal build Fails with: > ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) But without the coverage flag it?s OK. I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and was able to strip it to this: https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage Don?t know if this is a cabal or ghc problem and I don?t know how to continue. Thanks! My ghc ?info: [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.0.20140228") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Mar 7 16:10:41 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 7 Mar 2014 11:10:41 -0500 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> Message-ID: try using real GCC i have these directions https://gist.github.com/cartazio/7131371 On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: > Hi, > > On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 > > Doing: > cabal configure --enable-library-coverage > cabal build > > Fails with: > > ld: illegal text reloc in > '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to > '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for > architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > But without the coverage flag it?s OK. > > I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and > was able to strip it to this: > https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage > > Don?t know if this is a cabal or ghc problem and I don?t know how to > continue. > > Thanks! > > My ghc ?info: > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -m64 -fno-stack-protector") > ,("C compiler link flags"," -m64") > ,("ld command","/usr/bin/ld") > ,("ld flags"," -arch x86_64") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","NO") > ,("ld supports filelist","YES") > ,("ld is GNU ld","NO") > ,("ar command","/usr/bin/ar") > ,("ar flags","clqs") > ,("ar supports at file","NO") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSDarwin") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","True") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.0.20140228") > ,("Booter version","7.6.3") > ,("Stage","2") > ,("Build platform","x86_64-apple-darwin") > ,("Host platform","x86_64-apple-darwin") > ,("Target platform","x86_64-apple-darwin") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn > thr_dyn thr_debug_dyn l_dyn thr_l_dyn") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","YES") > ,("Leading underscore","YES") > ,("Debug on","False") > ] > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmaste at gmail.com Fri Mar 7 19:01:06 2014 From: fmaste at gmail.com (Federico Mastellone) Date: Fri, 7 Mar 2014 16:01:06 -0300 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> Message-ID: <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> It?s the same error with and without the clang-xcode5-wrapper that is named as an alternative solution On Mar 7, 2014, at 13:10, Carter Schonwald wrote: > try using real GCC > > i have these directions https://gist.github.com/cartazio/7131371 > > > On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: > Hi, > > On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 > > Doing: > cabal configure --enable-library-coverage > cabal build > > > > Fails with: >> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see invocation) > > But without the coverage flag it?s OK. > > I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and was able to strip it to this: > https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage > > Don?t know if this is a cabal or ghc problem and I don?t know how to continue. > > Thanks! > > My ghc ?info: > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -m64 -fno-stack-protector") > ,("C compiler link flags"," -m64") > ,("ld command","/usr/bin/ld") > ,("ld flags"," -arch x86_64") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","NO") > ,("ld supports filelist","YES") > ,("ld is GNU ld","NO") > ,("ar command","/usr/bin/ar") > ,("ar flags","clqs") > ,("ar supports at file","NO") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSDarwin") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","True") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.0.20140228") > ,("Booter version","7.6.3") > ,("Stage","2") > ,("Build platform","x86_64-apple-darwin") > ,("Host platform","x86_64-apple-darwin") > ,("Target platform","x86_64-apple-darwin") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","YES") > ,("Leading underscore","YES") > ,("Debug on","False") > ] > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Fri Mar 7 19:36:53 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Fri, 07 Mar 2014 14:36:53 -0500 Subject: GHC 7.8 on ARM Message-ID: <87eh2dn6lm.fsf@gmail.com> I've been accumulating some notes concerning the current status of GHC on ARM here[1]. To quote the tl;dr, GHC 7.8 should run well on ARM with the LLVM code generator and dynamic linking. The process of building GHC itself might be a bit hairy due to linker terribleness. After this, however, you?ll have fully-featured GHC installation supporting all of the modern amenities including GHCi and Template Haskell. Cheers, - Ben [1] http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From carter.schonwald at gmail.com Fri Mar 7 19:58:55 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 7 Mar 2014 14:58:55 -0500 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> Message-ID: No. Try real GCC. Follow my linked directions. Xcode GCC is fake. It's clang. Follow my directions please. On Friday, March 7, 2014, Federico Mastellone wrote: > It?s the same error with and without the clang-xcode5-wrapper that is > named as an alternative solution > > On Mar 7, 2014, at 13:10, Carter Schonwald > wrote: > > try using real GCC > > i have these directions https://gist.github.com/cartazio/7131371 > > > On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: > > Hi, > > On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 > > Doing: > cabal configure --enable-library-coverage > cabal build > > Fails with: > > ld: illegal text reloc in > '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to > '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for > architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > But without the coverage flag it?s OK. > > I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and > was able to strip it to this: > https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage > > Don?t know if this is a cabal or ghc problem and I don?t know how to > continue. > > Thanks! > > My ghc ?info: > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -m64 -fno-stack-protector") > ,("C compiler link flags"," -m64") > ,("ld command","/usr/bin/ld") > ,("ld flags"," -arch x86_64") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","NO") > ,("ld supports filelist","YES") > ,("ld is GNU ld","NO") > ,("ar command","/usr/bin/ar") > ,("ar flags","clqs") > ,("ar supports at file","NO") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSDarwin") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","True") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.0.20140228") > ,("Booter version","7.6.3") > ,("Stage","2") > ,("Build platform","x86_64-apple-darwin") > ,("Host platform","x86_64-apple-darwin") > ,("Target platform","x86_64-apple-darwin") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn > thr_dyn thr_debug_dyn l_dyn thr_l_dyn") > ,("Support dynamic-too","YES") > ,("Support parallel --make", > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmaste at gmail.com Sun Mar 9 14:15:23 2014 From: fmaste at gmail.com (Federico Mastellone) Date: Sun, 9 Mar 2014 11:15:23 -0300 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> Message-ID: <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> Downloaded gcc-4.9 binary from http://hpc.sourceforge.net and tested again with both 7.6.3 and 7.8-rc2 Fails with the same error with 7.8-rc2 and does not fail with 7.6.3 ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 collect2: error: ld returned 1 exit status On Mar 7, 2014, at 16:58, Carter Schonwald wrote: > No. Try real GCC. Follow my linked directions. Xcode GCC is fake. It's clang. Follow my directions please. > > On Friday, March 7, 2014, Federico Mastellone wrote: > It?s the same error with and without the clang-xcode5-wrapper that is named as an alternative solution > > On Mar 7, 2014, at 13:10, Carter Schonwald wrote: > >> try using real GCC >> >> i have these directions https://gist.github.com/cartazio/7131371 >> >> >> On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: >> Hi, >> >> On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 >> >> Doing: >> cabal configure --enable-library-coverage >> cabal build >> >> >> >> >> Fails with: >>> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >> >> But without the coverage flag it?s OK. >> >> I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and was able to strip it to this: >> https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage >> >> Don?t know if this is a cabal or ghc problem and I don?t know how to continue. >> >> Thanks! >> >> My ghc ?info: >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","/usr/bin/gcc") >> ,("C compiler flags"," -m64 -fno-stack-protector") >> ,("C compiler link flags"," -m64") >> ,("ld command","/usr/bin/ld") >> ,("ld flags"," -arch x86_64") >> ,("ld supports compact unwind","YES") >> ,("ld supports build-id","NO") >> ,("ld supports filelist","YES") >> ,("ld is GNU ld","NO") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","clqs") >> ,("ar supports at file","NO") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("libtool command","libtool") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSDarwin") >> ,("target arch","ArchX86_64") >> ,("target word size","8") >> ,("target has GNU nonexec stack","False") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","True") >> ,("Unregisterised","NO") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.8.0.20140228") >> ,("Booter version","7.6.3") >> ,("Stage","2") >> ,("Build platform","x86_64-apple-darwin") >> ,("Host platform","x86_64-apple-darwin") >> ,("Target platform","x86_64-apple-darwin") >> ,("Have interpreter","YES") >> ,("Object splitting supported","YES") >> ,("Have native code generator","YES") >> ,("Support SMP","YES") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") >> ,("Support dynamic-too","YES") >> ,("Support parallel --make", -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Mar 9 14:41:02 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 9 Mar 2014 10:41:02 -0400 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> Message-ID: Ok. What cabal package? Have you filed a bug report on ghc trac? On Sunday, March 9, 2014, Federico Mastellone wrote: > Downloaded gcc-4.9 binary from http://hpc.sourceforge.net and tested > again with both 7.6.3 and 7.8-rc2 > > Fails with the same error with 7.8-rc2 and does not fail with 7.6.3 > > ld: illegal text reloc > in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' > to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for > architecture x86_64 > collect2: error: ld returned 1 exit status > > On Mar 7, 2014, at 16:58, Carter Schonwald > wrote: > > No. Try real GCC. Follow my linked directions. Xcode GCC is fake. It's > clang. Follow my directions please. > > On Friday, March 7, 2014, Federico Mastellone wrote: > > It?s the same error with and without the clang-xcode5-wrapper that is > named as an alternative solution > > On Mar 7, 2014, at 13:10, Carter Schonwald > wrote: > > try using real GCC > > i have these directions https://gist.github.com/cartazio/7131371 > > > On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: > > Hi, > > On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 > > Doing: > cabal configure --enable-library-coverage > cabal build > > Fails with: > > ld: illegal text reloc in > '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to > '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for > architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > But without the coverage flag it?s OK. > > I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and > was able to strip it to this: > https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage > > Don?t know if this is a cabal or ghc problem and I don?t know how to > continue. > > Thanks! > > My ghc ?info: > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -m64 -fno-stack-protector") > ,("C compiler link flags"," -m64") > ,("ld command","/usr/bin/ld") > ,("ld flags"," -arch x86_64") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","NO") > ,("ld supports filelist","YES") > ,("ld is GNU ld","NO") > ,("ar command","/usr/bin/ar") > ,("ar flags","clqs") > ,("ar supports at file","NO") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSDarwin") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","True") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.0.20140228") > ,("Booter version","7.6.3") > ,("Stage","2") > ,("Build platform","x86_64-apple-darwin") > ,("Hos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmaste at gmail.com Sun Mar 9 16:32:05 2014 From: fmaste at gmail.com (Federico Mastellone) Date: Sun, 9 Mar 2014 13:32:05 -0300 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> Message-ID: <9DEDA4A9-3E58-4FA4-9DDF-43B4E9EFABA5@gmail.com> With a package of mine that I reduced it to just two modules, the one on the link below. I did not file a bug, I wanted to ask here first. I'll do it now > On 09/03/2014, at 11:41, Carter Schonwald wrote: > > Ok. What cabal package? Have you filed a bug report on ghc trac? > >> On Sunday, March 9, 2014, Federico Mastellone wrote: >> Downloaded gcc-4.9 binary from http://hpc.sourceforge.net and tested again with both 7.6.3 and 7.8-rc2 >> >> Fails with the same error with 7.8-rc2 and does not fail with 7.6.3 >> >> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >> collect2: error: ld returned 1 exit status >> >>> On Mar 7, 2014, at 16:58, Carter Schonwald wrote: >>> >>> No. Try real GCC. Follow my linked directions. Xcode GCC is fake. It's clang. Follow my directions please. >>> >>> On Friday, March 7, 2014, Federico Mastellone wrote: >>> It?s the same error with and without the clang-xcode5-wrapper that is named as an alternative solution >>> >>>> On Mar 7, 2014, at 13:10, Carter Schonwald wrote: >>>> >>>> try using real GCC >>>> >>>> i have these directions https://gist.github.com/cartazio/7131371 >>>> >>>> >>>> On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: >>>> Hi, >>>> >>>> On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 >>>> >>>> Doing: >>>> cabal configure --enable-library-coverage >>>> cabal build >>>> >>>> >>>> >>>> >>>> >>>> Fails with: >>>>> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>>> >>>> But without the coverage flag it?s OK. >>>> >>>> I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and was able to strip it to this: >>>> https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage >>>> >>>> Don?t know if this is a cabal or ghc problem and I don?t know how to continue. >>>> >>>> Thanks! >>>> >>>> My ghc ?info: >>>> [("Project name","The Glorious Glasgow Haskell Compilation System") >>>> ,("GCC extra via C opts"," -fwrapv") >>>> ,("C compiler command","/usr/bin/gcc") >>>> ,("C compiler flags"," -m64 -fno-stack-protector") >>>> ,("C compiler link flags"," -m64") >>>> ,("ld command","/usr/bin/ld") >>>> ,("ld flags"," -arch x86_64") >>>> ,("ld supports compact unwind","YES") >>>> ,("ld supports build-id","NO") >>>> ,("ld supports filelist","YES") >>>> ,("ld is GNU ld","NO") >>>> ,("ar command","/usr/bin/ar") >>>> ,("ar flags","clqs") >>>> ,("ar supports at file","NO") >>>> ,("touch command","touch") >>>> ,("dllwrap command","/bin/false") >>>> ,("windres command","/bin/false") >>>> ,("libtool command","libtool") >>>> ,("perl command","/usr/bin/perl") >>>> ,("target os","OSDarwin") >>>> ,("target arch","ArchX86_64") >>>> ,("target word size","8") >>>> ,("target has GNU nonexec stack","False") >>>> ,("target has .ident directive","True") >>>> ,("target has subsections via symbols","True") >>>> ,("Unregisterised","NO") >>>> ,("LLVM llc command","llc") >>>> ,("LLVM opt command","opt") >>>> ,("Project version","7.8.0.20140228") >>>> ,("Booter version","7.6.3") >>>> ,("Stage","2") >>>> ,("Build platform","x86_64-apple-darwin") >>>> ,("Hos -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Mar 9 20:26:01 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 9 Mar 2014 16:26:01 -0400 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: <9DEDA4A9-3E58-4FA4-9DDF-43B4E9EFABA5@gmail.com> References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> <9DEDA4A9-3E58-4FA4-9DDF-43B4E9EFABA5@gmail.com> Message-ID: great! Thanks for taking the time to shrink the bug, look forward to helping on the ticket On Sun, Mar 9, 2014 at 12:32 PM, Federico Mastellone wrote: > With a package of mine that I reduced it to just two modules, the one on > the link below. > I did not file a bug, I wanted to ask here first. I'll do it now > > On 09/03/2014, at 11:41, Carter Schonwald > wrote: > > Ok. What cabal package? Have you filed a bug report on ghc trac? > > On Sunday, March 9, 2014, Federico Mastellone wrote: > >> Downloaded gcc-4.9 binary from http://hpc.sourceforge.net and tested >> again with both 7.6.3 and 7.8-rc2 >> >> Fails with the same error with 7.8-rc2 and does not fail with 7.6.3 >> >> ld: illegal text reloc >> in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' >> to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for >> architecture x86_64 >> collect2: error: ld returned 1 exit status >> >> On Mar 7, 2014, at 16:58, Carter Schonwald >> wrote: >> >> No. Try real GCC. Follow my linked directions. Xcode GCC is fake. >> It's clang. Follow my directions please. >> >> On Friday, March 7, 2014, Federico Mastellone wrote: >> >> It?s the same error with and without the clang-xcode5-wrapper that is >> named as an alternative solution >> >> On Mar 7, 2014, at 13:10, Carter Schonwald >> wrote: >> >> try using real GCC >> >> i have these directions https://gist.github.com/cartazio/7131371 >> >> >> On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: >> >> Hi, >> >> On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 >> >> Doing: >> cabal configure --enable-library-coverage >> cabal build >> >> Fails with: >> >> ld: illegal text reloc in >> '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to >> '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for >> architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> >> But without the coverage flag it?s OK. >> >> I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and >> was able to strip it to this: >> https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage >> >> Don?t know if this is a cabal or ghc problem and I don?t know how to >> continue. >> >> Thanks! >> >> My ghc ?info: >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","/usr/bin/gcc") >> ,("C compiler flags"," -m64 -fno-stack-protector") >> ,("C compiler link flags"," -m64") >> ,("ld command","/usr/bin/ld") >> ,("ld flags"," -arch x86_64") >> ,("ld supports compact unwind","YES") >> ,("ld supports build-id","NO") >> ,("ld supports filelist","YES") >> ,("ld is GNU ld","NO") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","clqs") >> ,("ar supports at file","NO") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("libtool command","libtool") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSDarwin") >> ,("target arch","ArchX86_64") >> ,("target word size","8") >> ,("target has GNU nonexec stack","False") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","True") >> ,("Unregisterised","NO") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.8.0.20140228") >> ,("Booter version","7.6.3") >> ,("Stage","2") >> ,("Build platform","x86_64-apple-darwin") >> ,("Hos >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmaste at gmail.com Mon Mar 10 16:04:07 2014 From: fmaste at gmail.com (Federico Mastellone) Date: Mon, 10 Mar 2014 13:04:07 -0300 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> <9DEDA4A9-3E58-4FA4-9DDF-43B4E9EFABA5@gmail.com> Message-ID: <708BAEA0-C09A-43AE-BFB0-0DE2C7DD8B5C@gmail.com> Found the problem, I did not have the modules that were used but not exposed enumerated under "other-modules? on cabal's library definition. This builds OK on 7.6.3 even with a correct code coverage report, but fails to build with the linking error under 7.8-rc2. When I add the ?other-modules? it works on both. On Mar 9, 2014, at 17:26, Carter Schonwald wrote: > great! > Thanks for taking the time to shrink the bug, look forward to helping on the ticket > > > On Sun, Mar 9, 2014 at 12:32 PM, Federico Mastellone wrote: > With a package of mine that I reduced it to just two modules, the one on the link below. > I did not file a bug, I wanted to ask here first. I'll do it now > > On 09/03/2014, at 11:41, Carter Schonwald wrote: > >> Ok. What cabal package? Have you filed a bug report on ghc trac? >> >> On Sunday, March 9, 2014, Federico Mastellone wrote: >> Downloaded gcc-4.9 binary from http://hpc.sourceforge.net and tested again with both 7.6.3 and 7.8-rc2 >> >> Fails with the same error with 7.8-rc2 and does not fail with 7.6.3 >> >> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >> collect2: error: ld returned 1 exit status >> >> On Mar 7, 2014, at 16:58, Carter Schonwald wrote: >> >>> No. Try real GCC. Follow my linked directions. Xcode GCC is fake. It's clang. Follow my directions please. >>> >>> On Friday, March 7, 2014, Federico Mastellone wrote: >>> It?s the same error with and without the clang-xcode5-wrapper that is named as an alternative solution >>> >>> On Mar 7, 2014, at 13:10, Carter Schonwald wrote: >>> >>>> try using real GCC >>>> >>>> i have these directions https://gist.github.com/cartazio/7131371 >>>> >>>> >>>> On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: >>>> Hi, >>>> >>>> On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 >>>> >>>> Doing: >>>> cabal configure --enable-library-coverage >>>> cabal build >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Fails with: >>>>> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>>> >>>> But without the coverage flag it?s OK. >>>> >>>> I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and was able to strip it to this: >>>> https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage >>>> >>>> Don?t know if this is a cabal or ghc problem and I don?t know how to continue. >>>> >>>> Thanks! >>>> >>>> My ghc ?info: >>>> [("Project name","The Glorious Glasgow Haskell Compilation System") >>>> ,("GCC extra via C opts"," -fwrapv") >>>> ,("C compiler command","/usr/bin/gcc") >>>> ,("C compiler flags"," -m64 -fno-stack-protector") >>>> ,("C compiler link flags"," -m64") >>>> ,("ld command","/usr/bin/ld") >>>> ,("ld flags"," -arch x86_64") >>>> ,("ld supports compact unwind","YES") >>>> ,("ld supports build-id","NO") >>>> ,("ld supports filelist","YES") >>>> ,("ld is GNU ld","NO") >>>> ,("ar command","/usr/bin/ar") >>>> ,("ar flags","clqs") >>>> ,("ar supports at file","NO") >>>> ,("touch command","touch") >>>> ,("dllwrap command","/bin/false") >>>> ,("windres command","/bin/false") >>>> ,("libtool command","libtool") >>>> ,("perl command","/usr/bin/perl") >>>> ,("target os","OSDarwin") >>>> ,("target arch","ArchX86_64") >>>> ,("target word size","8") >>>> ,("target has GNU nonexec stack","False") >>>> ,("target has .ident directive","True") >>>> ,("target has subsections via symbols","True") >>>> ,("Unregisterised","NO") >>>> ,("LLVM llc command","llc") >>>> ,("LLVM opt command","opt") >>>> ,("Project version","7.8.0.20140228") >>>> ,("Booter version","7.6.3") >>>> ,("Stage","2") >>>> ,("Build platform","x86_64-apple-darwin") >>>> ,("Hos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 10 17:41:25 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 10 Mar 2014 13:41:25 -0400 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: <708BAEA0-C09A-43AE-BFB0-0DE2C7DD8B5C@gmail.com> References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> <9DEDA4A9-3E58-4FA4-9DDF-43B4E9EFABA5@gmail.com> <708BAEA0-C09A-43AE-BFB0-0DE2C7DD8B5C@gmail.com> Message-ID: So, was the issue cabal not catching the linker error? On Mon, Mar 10, 2014 at 12:04 PM, Federico Mastellone wrote: > Found the problem, > > I did not have the modules that were used but not exposed enumerated under > "other-modules? on cabal's library definition. This builds OK on 7.6.3 even > with a correct code coverage report, but fails to build with the linking > error under 7.8-rc2. When I add the ?other-modules? it works on both. > > > On Mar 9, 2014, at 17:26, Carter Schonwald > wrote: > > great! > Thanks for taking the time to shrink the bug, look forward to helping on > the ticket > > > On Sun, Mar 9, 2014 at 12:32 PM, Federico Mastellone wrote: > >> With a package of mine that I reduced it to just two modules, the one on >> the link below. >> I did not file a bug, I wanted to ask here first. I'll do it now >> >> On 09/03/2014, at 11:41, Carter Schonwald >> wrote: >> >> Ok. What cabal package? Have you filed a bug report on ghc trac? >> >> On Sunday, March 9, 2014, Federico Mastellone wrote: >> >>> Downloaded gcc-4.9 binary from http://hpc.sourceforge.net and tested >>> again with both 7.6.3 and 7.8-rc2 >>> >>> Fails with the same error with 7.8-rc2 and does not fail with 7.6.3 >>> >>> ld: illegal text reloc >>> in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' >>> to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for >>> architecture x86_64 >>> collect2: error: ld returned 1 exit status >>> >>> On Mar 7, 2014, at 16:58, Carter Schonwald >>> wrote: >>> >>> No. Try real GCC. Follow my linked directions. Xcode GCC is fake. >>> It's clang. Follow my directions please. >>> >>> On Friday, March 7, 2014, Federico Mastellone wrote: >>> >>> It?s the same error with and without the clang-xcode5-wrapper that is >>> named as an alternative solution >>> >>> On Mar 7, 2014, at 13:10, Carter Schonwald >>> wrote: >>> >>> try using real GCC >>> >>> i have these directions https://gist.github.com/cartazio/7131371 >>> >>> >>> On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: >>> >>> Hi, >>> >>> On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 >>> >>> Doing: >>> cabal configure --enable-library-coverage >>> cabal build >>> >>> Fails with: >>> >>> ld: illegal text reloc in >>> '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to >>> '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for >>> architecture x86_64 >>> clang: error: linker command failed with exit code 1 (use -v to see >>> invocation) >>> >>> >>> But without the coverage flag it?s OK. >>> >>> I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and >>> was able to strip it to this: >>> https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage >>> >>> Don?t know if this is a cabal or ghc problem and I don?t know how to >>> continue. >>> >>> Thanks! >>> >>> My ghc ?info: >>> [("Project name","The Glorious Glasgow Haskell Compilation System") >>> ,("GCC extra via C opts"," -fwrapv") >>> ,("C compiler command","/usr/bin/gcc") >>> ,("C compiler flags"," -m64 -fno-stack-protector") >>> ,("C compiler link flags"," -m64") >>> ,("ld command","/usr/bin/ld") >>> ,("ld flags"," -arch x86_64") >>> ,("ld supports compact unwind","YES") >>> ,("ld supports build-id","NO") >>> ,("ld supports filelist","YES") >>> ,("ld is GNU ld","NO") >>> ,("ar command","/usr/bin/ar") >>> ,("ar flags","clqs") >>> ,("ar supports at file","NO") >>> ,("touch command","touch") >>> ,("dllwrap command","/bin/false") >>> ,("windres command","/bin/false") >>> ,("libtool command","libtool") >>> ,("perl command","/usr/bin/perl") >>> ,("target os","OSDarwin") >>> ,("target arch","ArchX86_64") >>> ,("target word size","8") >>> ,("target has GNU nonexec stack","False") >>> ,("target has .ident directive","True") >>> ,("target has subsections via symbols","True") >>> ,("Unregisterised","NO") >>> ,("LLVM llc command","llc") >>> ,("LLVM opt command","opt") >>> ,("Project version","7.8.0.20140228") >>> ,("Booter version","7.6.3") >>> ,("Stage","2") >>> ,("Build platform","x86_64-apple-darwin") >>> ,("Hos >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Mar 11 22:11:25 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 11 Mar 2014 23:11:25 +0100 Subject: can't load .so/.DLL - undefined symbol Message-ID: <531F8A0D.8060508@henning-thielemann.de> I am trying to understand the following linker message. I have started GHCi, loaded a program and try to run it: Main> main ... Loading package poll-0.0 ... linking ... done. Loading package alsa-seq-0.6.0.3 ... can't load .so/.DLL for: /var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so (/var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so: undefined symbol: alsazmseqzm0zi6zi0zi3_SystemziPosixziPoll_zdfStorableFd_closure) I assume that GHCi wants to say the following: The instance Storable Fd defined in module System.Posix.Poll cannot be found in the shared object file of the alsa-seq package. That's certainly true because that module is in the package 'poll' and not in 'alsa-seq'. But 'alsa-seq' imports 'poll'. What might be the problem? It's a rather big example that fails here, whereas the small examples in alsa-seq package work. Thus I first like to know what the message really means, before investigating further. I installed many packages at once with cabal-install using a single build directory, like: $ cabal install --builddir=/tmp/dist --with-ghc=ghc7.8.0.20140228 poll alsa-seq pkg1 pkg2 pkg3 ... ? Can this cause problems? From marlowsd at gmail.com Wed Mar 12 08:36:03 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 12 Mar 2014 08:36:03 +0000 Subject: RC2 build failures on Debian: sparc In-Reply-To: <1394056482.6318.3.camel@kirk> References: <1394056482.6318.3.camel@kirk> Message-ID: <53201C73.6020304@gmail.com> These look suspicious: /tmp/ghc29241_0/ghc29241_2.hc: In function 'stg_ap_pppv_ret': /tmp/ghc29241_0/ghc29241_2.hc:2868:30: warning: function called through a non-compatible type [enabled by default] /tmp/ghc29241_0/ghc29241_2.hc:2868:30: note: if this code is reached, the program will abort If this is a general problem with unregisterised via-C compilation then we can probably fix it. Could you open a ticket (or point me to the existing ticket if there is one)? Cheers, Simon On 05/03/2014 21:54, Joachim Breitner wrote: > Hi, > > sparc fails differently than in RC1, and very plainly with a > segmentation fault in dll-split (which happens to be the first program > to be run that is compiled with stage1): > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140228-1&stamp=1393975264 > > Any ideas? Anyone feeling responsible? > > It would be shame to loose a lot of architectures in 7.8 compared to > 7.6, but I?m not a porter and don?t know much about these part of the > compiler, so I have to rely on your support in fixing these problems, > preferably before 7.8.1. > > Greetings, > Joachim > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From mail at joachim-breitner.de Wed Mar 12 08:56:36 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 12 Mar 2014 09:56:36 +0100 Subject: RC2 build failures on Debian: sparc In-Reply-To: <53201C73.6020304@gmail.com> References: <1394056482.6318.3.camel@kirk> <53201C73.6020304@gmail.com> Message-ID: <1394614596.2439.4.camel@kirk> Hi, I only found https://ghc.haskell.org/trac/ghc/ticket/4872, so I created a new one at https://ghc.haskell.org/trac/ghc/ticket/8877 Thanks for having a look. Greetings, Joachim Am Mittwoch, den 12.03.2014, 08:36 +0000 schrieb Simon Marlow: > These look suspicious: > > /tmp/ghc29241_0/ghc29241_2.hc: In function 'stg_ap_pppv_ret': > > /tmp/ghc29241_0/ghc29241_2.hc:2868:30: > warning: function called through a non-compatible type [enabled by > default] > > /tmp/ghc29241_0/ghc29241_2.hc:2868:30: > note: if this code is reached, the program will abort > > If this is a general problem with unregisterised via-C compilation then > we can probably fix it. Could you open a ticket (or point me to the > existing ticket if there is one)? > > Cheers, > Simon > > On 05/03/2014 21:54, Joachim Breitner wrote: > > Hi, > > > > sparc fails differently than in RC1, and very plainly with a > > segmentation fault in dll-split (which happens to be the first program > > to be run that is compiled with stage1): > > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140228-1&stamp=1393975264 > > > > Any ideas? Anyone feeling responsible? > > > > It would be shame to loose a lot of architectures in 7.8 compared to > > 7.6, but I?m not a porter and don?t know much about these part of the > > compiler, so I have to rely on your support in fixing these problems, > > preferably before 7.8.1. > > > > Greetings, > > Joachim > > > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed Mar 12 08:59:00 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 12 Mar 2014 09:59:00 +0100 Subject: RC2 build failure on Debian: armel Message-ID: <1394614740.2439.7.camel@kirk> Hi, armel still fails like in RC1: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140228-1&stamp=1394495564 "inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock ... /?PKGBUILDDIR?/compiler/stage2/build/libHSghc-7.8.0.20140228.a(genSym.o): In function `genSym': genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock' genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock' Any ideas? Anyone feeling responsible? Thanks, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From lemming at henning-thielemann.de Fri Mar 14 16:57:23 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 14 Mar 2014 17:57:23 +0100 Subject: GHC-7.8 warning on rules that may not fire Message-ID: <532334F3.2050000@henning-thielemann.de> With GHC-7.8 I get lots of warnings like src/Foo/Bar.hs:215:6: Warning: Rule "foo" may never fire because ?bar? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?bar? So far I thought that rewrite RULES always have precedence to INLINE. Has this changed? I hesitate to follow the advice of adding phase numbers in bracket because I consider these phase numbers a quite fragile and non-modular solution (like precedence numbers for infix operators). I have found: https://ghc.haskell.org/trac/ghc/wiki/Plugins/Phases Is this still considered for future developments? From simonpj at microsoft.com Fri Mar 14 17:05:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 14 Mar 2014 17:05:35 +0000 Subject: GHC-7.8 warning on rules that may not fire In-Reply-To: <532334F3.2050000@henning-thielemann.de> References: <532334F3.2050000@henning-thielemann.de> Message-ID: <59543203684B2244980D7E4057D5FBC1487EE904@DB3EX14MBXC306.europe.corp.microsoft.com> You may think they are fragile, but not as fragile as saying nothing and hoping for the best, which is *super*-fragile. You can't rely on rules to take priority, because the rule only fires if it matches, and it may only match if some other inlining has taken place. (We tried that originally.) I don't have any plans to change this, but of course am always open to well-worked out design proposals. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Henning Thielemann | Sent: 14 March 2014 16:57 | To: GHC Users List | Subject: GHC-7.8 warning on rules that may not fire | | With GHC-7.8 I get lots of warnings like | | src/Foo/Bar.hs:215:6: Warning: | Rule "foo" may never fire | because ?bar? might inline first | Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?bar? | | So far I thought that rewrite RULES always have precedence to INLINE. | Has this changed? I hesitate to follow the advice of adding phase | numbers in bracket because I consider these phase numbers a quite | fragile and non-modular solution (like precedence numbers for infix | operators). | | I have found: | https://ghc.haskell.org/trac/ghc/wiki/Plugins/Phases | | Is this still considered for future developments? | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From lemming at henning-thielemann.de Fri Mar 14 17:26:56 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 14 Mar 2014 18:26:56 +0100 Subject: GHC-7.8 warning on rules that may not fire In-Reply-To: <59543203684B2244980D7E4057D5FBC1487EE904@DB3EX14MBXC306.europe.corp.microsoft.com> References: <532334F3.2050000@henning-thielemann.de> <59543203684B2244980D7E4057D5FBC1487EE904@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <53233BE0.2010506@henning-thielemann.de> Am 14.03.2014 18:05, schrieb Simon Peyton Jones: > You may think they are fragile, but not as fragile as saying nothing and hoping for the best, which is *super*-fragile. You can't rely on rules to take priority, because the rule only fires if it matches, and it may only match if some other inlining has taken place. (We tried that originally.) Ok, how shall I choose "n" in "INLINE[n]"? Is there a meaning of the phase numbers? I guess it is important to adhere to some conventions in order to work together with other libraries. If I understand correctly I can alter the number of phases with the -fsimplifier-phases option - how can I choose phase numbers for INLINE that are universally reasonable? From fmaste at gmail.com Fri Mar 14 18:48:56 2014 From: fmaste at gmail.com (Federico Mastellone) Date: Fri, 14 Mar 2014 15:48:56 -0300 Subject: Problem with cabal's --enable-library-coverage on 7.8.1rc2 In-Reply-To: References: <8DB2FD31-8912-4C6C-86BA-798439567497@gmail.com> <8E37C2CF-608B-43C3-8E4A-9C2548DF3D4B@gmail.com> <858D249D-0275-4486-A0A3-E2CC30070A65@gmail.com> <9DEDA4A9-3E58-4FA4-9DDF-43B4E9EFABA5@gmail.com> <708BAEA0-C09A-43AE-BFB0-0DE2C7DD8B5C@gmail.com> Message-ID: <155492A7-530A-47C9-A498-768E9D9CD000@gmail.com> I don?t know the cause of the error, I commented on this related cabal issue I found: https://github.com/haskell/cabal/issues/1700 On Mar 10, 2014, at 14:41, Carter Schonwald wrote: > So, was the issue cabal not catching the linker error? > > > On Mon, Mar 10, 2014 at 12:04 PM, Federico Mastellone wrote: > Found the problem, > > I did not have the modules that were used but not exposed enumerated under "other-modules? on cabal's library definition. This builds OK on 7.6.3 even with a correct code coverage report, but fails to build with the linking error under 7.8-rc2. When I add the ?other-modules? it works on both. > > > On Mar 9, 2014, at 17:26, Carter Schonwald wrote: > >> great! >> Thanks for taking the time to shrink the bug, look forward to helping on the ticket >> >> >> On Sun, Mar 9, 2014 at 12:32 PM, Federico Mastellone wrote: >> With a package of mine that I reduced it to just two modules, the one on the link below. >> I did not file a bug, I wanted to ask here first. I'll do it now >> >> On 09/03/2014, at 11:41, Carter Schonwald wrote: >> >>> Ok. What cabal package? Have you filed a bug report on ghc trac? >>> >>> On Sunday, March 9, 2014, Federico Mastellone wrote: >>> Downloaded gcc-4.9 binary from http://hpc.sourceforge.net and tested again with both 7.6.3 and 7.8-rc2 >>> >>> Fails with the same error with 7.8-rc2 and does not fail with 7.6.3 >>> >>> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >>> collect2: error: ld returned 1 exit status >>> >>> On Mar 7, 2014, at 16:58, Carter Schonwald wrote: >>> >>>> No. Try real GCC. Follow my linked directions. Xcode GCC is fake. It's clang. Follow my directions please. >>>> >>>> On Friday, March 7, 2014, Federico Mastellone wrote: >>>> It?s the same error with and without the clang-xcode5-wrapper that is named as an alternative solution >>>> >>>> On Mar 7, 2014, at 13:10, Carter Schonwald wrote: >>>> >>>>> try using real GCC >>>>> >>>>> i have these directions https://gist.github.com/cartazio/7131371 >>>>> >>>>> >>>>> On Fri, Mar 7, 2014 at 10:47 AM, Federico Mastellone wrote: >>>>> Hi, >>>>> >>>>> On Mac OS X 10.9.2 with ghc 7.8.0.20140228 and cabal 1.18.0.3 >>>>> >>>>> Doing: >>>>> cabal configure --enable-library-coverage >>>>> cabal build >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Fails with: >>>>>> ld: illegal text reloc in '_enablezmlibraryzmcoveragezm0zi0zi1_Library_sendMsg2_info' to '__hpc_tickboxes_enablezmlibraryzmcoveragezm0zi0zi1_Util_hpc' for architecture x86_64 >>>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>>>> >>>>> But without the coverage flag it?s OK. >>>>> >>>>> I found it when switching from 7.6.3 to 7.8.1RC2 on a project I have and was able to strip it to this: >>>>> https://github.com/fmaste/ghc-7.8.0.20140228-enable-library-coverage >>>>> >>>>> Don?t know if this is a cabal or ghc problem and I don?t know how to continue. >>>>> >>>>> Thanks! >>>>> >>>>> My ghc ?info: >>>>> [("Project name","The Glorious Glasgow Haskell Compilation System") >>>>> ,("GCC extra via C opts"," -fwrapv") >>>>> ,("C compiler command","/usr/bin/gcc") >>>>> ,("C compiler flags"," -m64 -fno-stack-protector") >>>>> ,("C compiler link flags"," -m64") >>>>> ,("ld command","/usr/bin/ld") >>>>> ,("ld flags"," -arch x86_64") >>>>> ,("ld supports compact unwind","YES") >>>>> ,("ld supports build-id","NO") >>>>> ,("ld supports filelist","YES") >>>>> ,("ld is GNU ld","NO") >>>>> ,("ar command","/usr/bin/ar") >>>>> ,("ar flags","clqs") >>>>> ,("ar supports at file","NO") >>>>> ,("touch command","touch") >>>>> ,("dllwrap command","/bin/false") >>>>> ,("windres command","/bin/false") >>>>> ,("libtool command","libtool") >>>>> ,("perl command","/usr/bin/perl") >>>>> ,("target os","OSDarwin") >>>>> ,("target arch","ArchX86_64") >>>>> ,("target word size","8") >>>>> ,("target has GNU nonexec stack","False") >>>>> ,("target has .ident directive","True") >>>>> ,("target has subsections via symbols","True") >>>>> ,("Unregisterised","NO") >>>>> ,("LLVM llc command","llc") >>>>> ,("LLVM opt command","opt") >>>>> ,("Project version","7.8.0.20140228") >>>>> ,("Booter version","7.6.3") >>>>> ,("Stage","2") >>>>> ,("Build platform","x86_64-apple-darwin") >>>>> ,("Hos >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Mar 14 20:05:41 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 14 Mar 2014 21:05:41 +0100 Subject: RC2 build failure on Debian: armhf Message-ID: <1394827541.28530.1.camel@kirk> Hi, armhf still fails like in RC1: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20140228-1&stamp=1394723755 [..] 0% ( 0 / 5) in 'WwLib' 0% ( 0 / 2) in 'DmdAnal' 0% ( 0 / 2) in 'WorkWrap' compiler/typecheck/TcSplice.lhs-boot:29:1: TcSplice.tcTopSpliceExpr is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:37:1: TcSplice.runMetaE is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:38:1: TcSplice.runMetaP is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:39:1: TcSplice.runMetaT is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:40:1: TcSplice.runMetaD is exported by the hs-boot file, but not exported by the module 67% ( 2 / 3) in 'CmmPipeline' 0% ( 0 / 3) in 'StgCmmHpc' 0% ( 0 / 13) in 'PrelInfo' 0% ( 0 / 4) in 'StgCmmCon' 0% ( 0 / 2) in 'StgCmmExpr' 0% ( 0 / 6) in 'StgCmmBind' 0% ( 0 / 2) in 'CmmParse' 0% ( 0 / 2) in 'StgCmm' 5% ( 9 /175) in 'TcRnMonad' make[2]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 Any ideas? Anyone feeling responsible? Thanks, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From choener at tbi.univie.ac.at Fri Mar 14 21:46:31 2014 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Fri, 14 Mar 2014 22:46:31 +0100 Subject: splicing varPs in quasi-quote brackets Message-ID: <20140314214631.GA4966@workstation> Hello everybody, I wrote me this nice function 'buildRns' which splices in $(varP w) nice and recursively. Unfortunately, this only seems to work in the 7.8 branch, not in 7.6.3. Is this indeed new, or am I missing something obvious? The message is: ADP/Fusion/TH.hs:106:86: Parse error in pattern: $(varP w) The code works wonderfully in 7.8. It not only compiles, but also produces working code in applications. I have no problem waiting until 7.8 is stable, but being backwards compatible to 7.6 would be nice. Many thanks, Christian buildRns f xs [] = appE ([| return . SM.singleton |]) (foldl (\g z -> appE g (varE z)) (return f) xs) buildRns f xs (VarP v : ys) = buildRns f (xs++[v]) ys buildRns f xs (TupP [_,VarP v] : ys) = do w <- newName "w" [| $(varE v) >>= return . SM.concatMapM (\ $(varP w) -> $(buildRns f (xs++[w]) ys)) |] -->>>>> ^^^^^^^^^ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From vogt.adam at gmail.com Sat Mar 15 04:12:52 2014 From: vogt.adam at gmail.com (adam vogt) Date: Sat, 15 Mar 2014 00:12:52 -0400 Subject: splicing varPs in quasi-quote brackets In-Reply-To: <20140314214631.GA4966@workstation> References: <20140314214631.GA4966@workstation> Message-ID: Hello Christian, It seems new to me that $( ) is allowed in patterns. I would have used lamE in something like: [| $(varE v) >>= return . SM.concatMapM $(lamE [varP v] (buildRns f (xs++[w]) ys))) |] Regards, Adam From fuuzetsu at fuuzetsu.co.uk Sat Mar 15 10:24:05 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 15 Mar 2014 10:24:05 +0000 Subject: RC2 build failure on Debian: armhf In-Reply-To: <1394827541.28530.1.camel@kirk> References: <1394827541.28530.1.camel@kirk> Message-ID: <53242A45.3020606@fuuzetsu.co.uk> On 14/03/14 20:05, Joachim Breitner wrote: > Hi, > > armhf still fails like in RC1: > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20140228-1&stamp=1394723755 > [..] > 0% ( 0 / 5) in 'WwLib' > 0% ( 0 / 2) in 'DmdAnal' > 0% ( 0 / 2) in 'WorkWrap' > > compiler/typecheck/TcSplice.lhs-boot:29:1: > TcSplice.tcTopSpliceExpr is exported by the hs-boot file, but not exported by the module > > compiler/typecheck/TcSplice.lhs-boot:37:1: > TcSplice.runMetaE is exported by the hs-boot file, but not exported by the module > > compiler/typecheck/TcSplice.lhs-boot:38:1: > TcSplice.runMetaP is exported by the hs-boot file, but not exported by the module > > compiler/typecheck/TcSplice.lhs-boot:39:1: > TcSplice.runMetaT is exported by the hs-boot file, but not exported by the module > > compiler/typecheck/TcSplice.lhs-boot:40:1: > TcSplice.runMetaD is exported by the hs-boot file, but not exported by the module > 67% ( 2 / 3) in 'CmmPipeline' > 0% ( 0 / 3) in 'StgCmmHpc' > 0% ( 0 / 13) in 'PrelInfo' > 0% ( 0 / 4) in 'StgCmmCon' > 0% ( 0 / 2) in 'StgCmmExpr' > 0% ( 0 / 6) in 'StgCmmBind' > 0% ( 0 / 2) in 'CmmParse' > 0% ( 0 / 2) in 'StgCmm' > 5% ( 9 /175) in 'TcRnMonad' > make[2]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 > > > Any ideas? Anyone feeling responsible? > > Thanks, > Joachim > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Does building without docs work? Does building HEAD with docs work? I don't have an ARM machine to try and while it looks like Haddock messing up, I'm somewhat sceptical that's where the problem is. -- Mateusz K. From choener at tbi.univie.ac.at Sat Mar 15 14:08:26 2014 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Sat, 15 Mar 2014 15:08:26 +0100 Subject: splicing varPs in quasi-quote brackets In-Reply-To: References: <20140314214631.GA4966@workstation> Message-ID: <20140315140826.GA17778@workstation> Thanks Adam, It indeed does work with a lambda, should've thought about it. So, it seems splices in patterns are new in 7.8 (hadn't seen it in the notes). Gruss, Christian * adam vogt [15.03.2014 05:12]: > Hello Christian, > > It seems new to me that $( ) is allowed in patterns. I would have used > lamE in something like: > > [| $(varE v) >>= return . SM.concatMapM $(lamE [varP v] (buildRns f > (xs++[w]) ys))) |] > > Regards, > Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mainland at apeiron.net Sat Mar 15 14:44:31 2014 From: mainland at apeiron.net (Geoffrey Mainland) Date: Sat, 15 Mar 2014 10:44:31 -0400 Subject: splicing varPs in quasi-quote brackets In-Reply-To: <20140315140826.GA17778@workstation> References: <20140314214631.GA4966@workstation> <20140315140826.GA17778@workstation> Message-ID: <5324674F.4090903@apeiron.net> Yes, pattern splices are indeed new in 7.8. See: https://www.cs.drexel.edu/~mainland/2013/05/31/type-safe-runtime-code-generation-with-typed-template-haskell/ Cheers, Geoff On 03/15/2014 10:08 AM, Christian H?ner zu Siederdissen wrote: > Thanks Adam, > > It indeed does work with a lambda, should've thought about it. So, it > seems splices in patterns are new in 7.8 (hadn't seen it in the notes). > > Gruss, > Christian > > * adam vogt [15.03.2014 05:12]: >> Hello Christian, >> >> It seems new to me that $( ) is allowed in patterns. I would have used >> lamE in something like: >> >> [| $(varE v) >>= return . SM.concatMapM $(lamE [varP v] (buildRns f >> (xs++[w]) ys))) |] >> >> Regards, >> Adam From lemming at henning-thielemann.de Sat Mar 15 16:47:56 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 15 Mar 2014 17:47:56 +0100 Subject: importing (<=) from GHC.TypeLits Message-ID: <5324843C.9010602@henning-thielemann.de> I want to import Nat and type-level (<=) from GHC.TypeLits: import GHC.TypeLits (Nat, (<=)) "Nat" is found this way, but (<=) is not: Module ?GHC.TypeLits? does not export ?(<=)? What is the trick? The doc only shows the anonymous import: http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/promotion.html From vogt.adam at gmail.com Sat Mar 15 17:13:51 2014 From: vogt.adam at gmail.com (adam vogt) Date: Sat, 15 Mar 2014 13:13:51 -0400 Subject: importing (<=) from GHC.TypeLits In-Reply-To: <5324843C.9010602@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> Message-ID: http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/syntax-extns.html#explicit-namespaces is the trick On Sat, Mar 15, 2014 at 12:47 PM, Henning Thielemann wrote: > I want to import Nat and type-level (<=) from GHC.TypeLits: > > import GHC.TypeLits (Nat, (<=)) > > "Nat" is found this way, but (<=) is not: > > Module ?GHC.TypeLits? does not export ?(<=)? > > What is the trick? > > The doc only shows the anonymous import: > > http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/promotion.html > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From lemming at henning-thielemann.de Sat Mar 15 17:26:23 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 15 Mar 2014 18:26:23 +0100 Subject: converting type-level natural numbers to data-level In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> Message-ID: <53248D3F.3080707@henning-thielemann.de> Am 15.03.2014 18:13, schrieb adam vogt: > http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/syntax-extns.html#explicit-namespaces > is the trick Great, this works! Now I run into the next problem: How can I convert a type-level natural number into a data-level number? The Trac-Wiki mentions singletons: https://ghc.haskell.org/trac/ghc/wiki/TypeNats/Basics and the base package of GHC-7.6 exports the Sing class: http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC-TypeLits.html but it seems to have gone in GHC-7.8. :-( From hesselink at gmail.com Sat Mar 15 18:17:57 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Sat, 15 Mar 2014 19:17:57 +0100 Subject: converting type-level natural numbers to data-level In-Reply-To: <53248D3F.3080707@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> Message-ID: I think most of the singletons stuff has been moved to the 'singletons' package [0]. Erik [0] http://hackage.haskell.org/package/singletons On Sat, Mar 15, 2014 at 6:26 PM, Henning Thielemann wrote: > Am 15.03.2014 18:13, schrieb adam vogt: >> >> >> http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/syntax-extns.html#explicit-namespaces >> is the trick > > > Great, this works! > > Now I run into the next problem: How can I convert a type-level natural > number into a data-level number? The Trac-Wiki mentions singletons: > https://ghc.haskell.org/trac/ghc/wiki/TypeNats/Basics > and the base package of GHC-7.6 exports the Sing class: > http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC-TypeLits.html > but it seems to have gone in GHC-7.8. :-( > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From lemming at henning-thielemann.de Sat Mar 15 20:48:58 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 15 Mar 2014 21:48:58 +0100 Subject: converting data-level natural numbers to type-level In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> Message-ID: <5324BCBA.9090804@henning-thielemann.de> Am 15.03.2014 19:17, schrieb Erik Hesselink: > I think most of the singletons stuff has been moved to the > 'singletons' package [0]. Yes, that's it. It means that all Nat related functionality in 'singletons' can be implemented using GHC.TypeLits - interesting. Using the library I succeeded to convert type-level Nats to data-level Integer. Now I need the other way round. I want to implement: withVector :: [a] -> (forall n. (KnownNat n) => Vector n a -> b) -> b I want to have the (KnownNat n) constraint, since I want to call 'sing' within the continuation and this requires (KnownNat n). I guess, in order to implement withVector I need toSing, but this one does not give me a (KnownNat n). :-( Thus I have two questions: What is the meaning of KnownNat and how can I implement "withVector"? From christiaan.baaij at gmail.com Sun Mar 16 09:21:34 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Sun, 16 Mar 2014 10:21:34 +0100 Subject: converting data-level natural numbers to type-level In-Reply-To: <5324BCBA.9090804@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> Message-ID: To answer your second question using GADT-style vectors: {-# LANGUAGE RankNTypes #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators#-} {-# LANGUAGE ScopedTypeVariables #-} module WithVector where import Data.Maybe import Data.Proxy import GHC.TypeLits import Unsafe.Coerce data Vector :: Nat -> * -> * where Nil :: Vector 0 a (:>) :: a -> Vector n a -> Vector (n + 1) a infixr 5 :> data SNat :: Nat -> * where SZero :: SNat 0 SSucc :: SNat n -> SNat (n + 1) snat :: forall proxy n . KnownNat n => proxy n -> SNat n snat = snat' . natVal where snat' :: Integer -> SNat m snat' 0 = unsafeCoerce SZero snat' n = unsafeCoerce (SSucc (snat' (n-1))) vreplicate :: SNat n -> a -> Vector n a vreplicate SZero _ = Nil vreplicate (SSucc n) a = a :> vreplicate n a asVector :: KnownNat n => proxy n -> [a] -> Vector n a asVector s as = asVector' as (vreplicate (snat s) undefined) where asVector' :: [a] -> Vector m b -> Vector m a asVector' _ Nil = Nil asVector' [] (_ :> _ ) = error "static/dynamic mismatch" asVector' (x:xs) (_ :> vs) = x :> asVector' xs vs withVector :: forall a b . [a] -> (forall n . KnownNat n => Vector n a -> b) -> b withVector xs f = case sn of SomeNat s -> f (asVector s xs) where sn = fromMaybe (error "static/dynamic mismatch") (someNatVal (toInteger (length xs))) vlength :: forall n a . KnownNat n => Vector n a -> Integer vlength _ = natVal (Proxy :: Proxy n) On Sat, Mar 15, 2014 at 9:48 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > Am 15.03.2014 19:17, schrieb Erik Hesselink: > > I think most of the singletons stuff has been moved to the >> 'singletons' package [0]. >> > > Yes, that's it. It means that all Nat related functionality in > 'singletons' can be implemented using GHC.TypeLits - interesting. > > Using the library I succeeded to convert type-level Nats to data-level > Integer. Now I need the other way round. I want to implement: > > withVector :: > [a] -> > (forall n. (KnownNat n) => Vector n a -> b) -> > b > > I want to have the (KnownNat n) constraint, since I want to call 'sing' > within the continuation and this requires (KnownNat n). I guess, in order > to implement withVector I need toSing, but this one does not give me a > (KnownNat n). :-( > > Thus I have two questions: What is the meaning of KnownNat and how can I > implement "withVector"? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Mar 16 10:29:20 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Mar 2014 11:29:20 +0100 Subject: type-level induction on Nat In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> Message-ID: <53257D00.3010709@henning-thielemann.de> Am 16.03.2014 09:40, schrieb Christiaan Baaij: > To answer the second question (under the assumption that you want > phantom-type style Vectors and not GADT-style): That works, someNatVal was the missing piece. Now the natural next question is how to perform type-level induction on Nat. This page mentions the Nat1 type, a unary representation of natural numbers: https://ghc.haskell.org/trac/ghc/wiki/TypeNats/MatchingOnNats Since the unary natural number kind so ubiquituous in examples, is there a recommended module to import it from, which also contains the injectivity magic of FromNat1? I cannot see it in: http://hackage.haskell.org/package/base-4.7.0.0/candidate/docs/GHC-TypeLits.html although it seems to have been there: http://co-dan.github.io/base-docs/src/GHC-TypeLits.html From lemming at henning-thielemann.de Sun Mar 16 10:50:51 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Mar 2014 11:50:51 +0100 Subject: type-level induction on Nat In-Reply-To: <53257D00.3010709@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53257D00.3010709@henning-thielemann.de> Message-ID: <5325820B.4060807@henning-thielemann.de> Am 16.03.2014 11:29, schrieb Henning Thielemann: > Since the unary natural number kind so ubiquituous in examples, is there > a recommended module to import it from, which also contains the > injectivity magic of FromNat1? I cannot see it in: > > http://hackage.haskell.org/package/base-4.7.0.0/candidate/docs/GHC-TypeLits.html > > > although it seems to have been there: > http://co-dan.github.io/base-docs/src/GHC-TypeLits.html Nat1 was removed here: https://github.com/ghc/packages-base/commit/5eaba365ff2354d3231f049866964d25f245ede2 but commit message does not tell where it was moved. :-( Obviously it was not moved to "singletons". From lemming at henning-thielemann.de Sun Mar 16 12:44:31 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Mar 2014 13:44:31 +0100 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> Message-ID: <53259CAF.3070702@henning-thielemann.de> Am 16.03.2014 09:40, schrieb Christiaan Baaij: > To answer the second question (under the assumption that you want > phantom-type style Vectors and not GADT-style): Now I like to define non-empty vectors. The phantom parameter for the length shall refer to the actual vector length, not to length-1, for consistency between possibly empty and non-empty vectors. I have modified your code as follows: {-# LANGUAGE Rank2Types #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} module PositiveNat where import Data.Proxy (Proxy(Proxy)) import GHC.TypeLits (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal, type (<=), type (+)) data Vector (n :: Nat) a = Vector a [a] withVector :: forall a b. a -> [a] -> (forall n . (KnownNat n, 1<=n) => Vector n a -> b) -> b withVector x xs f = case someNatVal $ toInteger $ length xs of Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m+1) a) vecLen :: forall n . KnownNat n => Vector n Integer -> Integer vecLen _ = natVal (Proxy :: Proxy n) -- > withVector vecLen [1,2,3,4] -- 4 GHC-7.8 complains with: PositiveNat.hs:23:40: Could not deduce ((1 GHC.TypeLits.<=? (n + 1)) ~ 'True) from the context (KnownNat n) bound by a pattern with constructor SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> SomeNat, in a case alternative at PositiveNat.hs:23:13-34 In the expression: f (Vector x xs :: Vector (m + 1) a) In a case alternative: Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) In the expression: case someNatVal $ toInteger $ length xs of { Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) } How can I convince GHC that n+1 is always at least 1? When I remove the (1<=n) constraint, I still get: PositiveNat.hs:23:40: Could not deduce (KnownNat (n + 1)) arising from a use of ?f? from the context (KnownNat n) bound by a pattern with constructor SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> SomeNat, in a case alternative at PositiveNat.hs:23:13-34 In the expression: f (Vector x xs :: Vector (m + 1) a) In a case alternative: Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) In the expression: case someNatVal (toInteger (length xs)) of { Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) } That is, I also have to convince GHC, that if (KnownNat n) then (n+1) is also KnownNat. How to do that? From merijn at inconsistent.nl Sun Mar 16 12:56:34 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sun, 16 Mar 2014 13:56:34 +0100 Subject: PROPOSAL: Literate haskell and module file names Message-ID: Ola! I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. Pros: - Tool authors can more easily determine non-haskell content of literate haskell files - Currently valid module names will not break - Report doesn't specify behaviour, so GHC can do whatever it likes Cons: - Someone has to implement it - ?? Discussion: 4 weeks Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mail at joachim-breitner.de Sun Mar 16 13:13:15 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 16 Mar 2014 14:13:15 +0100 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: <1394975595.2415.12.camel@kirk> Hi, Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten: > Cons: GHC would have to either maintain a possibly long of variants to look for ([".hs", ".lhs", ".rst.lhs", ".md.lhs", ".svg.lhs", ".docx.lhs"]), or look for "Foo.*.lhs". I?d find the latter acceptable, but it should be noted. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From carter.schonwald at gmail.com Sun Mar 16 13:31:53 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 16 Mar 2014 09:31:53 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: <1394975595.2415.12.camel@kirk> References: <1394975595.2415.12.camel@kirk> Message-ID: I'd rather there be some textual finger print in the module itself that be be used to signal the literate format. But if there's a Case to be made in open to it I guess. On Sunday, March 16, 2014, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten: > > Cons: > > GHC would have to either maintain a possibly long of variants to look > for ([".hs", ".lhs", ".rst.lhs", ".md.lhs", ".svg.lhs", ".docx.lhs"]), > or look for "Foo.*.lhs". > > I?d find the latter acceptable, but it should be noted. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? > http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: > 0x4743206C > Debian Developer: nomeata at debian.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Mar 16 13:35:44 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 16 Mar 2014 09:35:44 -0400 Subject: positive type-level naturals In-Reply-To: <53259CAF.3070702@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: You can't with type lits. The solver can only decide concrete values :"""( You'll have to use a concrete peano Nats type instead. I've been toying with the idea that the type lits syntax should be just that, a type level analogue of from integer that you can give to user land types, but I'm not going to suggest that till 7.8 is fully released. On Sunday, March 16, 2014, Henning Thielemann wrote: > Am 16.03.2014 09:40, schrieb Christiaan Baaij: > > To answer the second question (under the assumption that you want >> phantom-type style Vectors and not GADT-style): >> > > Now I like to define non-empty vectors. The phantom parameter for the > length shall refer to the actual vector length, not to length-1, for > consistency between possibly empty and non-empty vectors. > > I have modified your code as follows: > > {-# LANGUAGE Rank2Types #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE TypeFamilies #-} > module PositiveNat where > > import Data.Proxy (Proxy(Proxy)) > import GHC.TypeLits > (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal, > type (<=), type (+)) > > data Vector (n :: Nat) a = Vector a [a] > > withVector :: > forall a b. > a -> [a] -> > (forall n . (KnownNat n, 1<=n) => Vector n a -> b) -> b > withVector x xs f = > case someNatVal $ toInteger $ length xs of > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m+1) a) > > vecLen :: forall n . KnownNat n => Vector n Integer -> Integer > vecLen _ = natVal (Proxy :: Proxy n) > > -- > withVector vecLen [1,2,3,4] > -- 4 > > > GHC-7.8 complains with: > > PositiveNat.hs:23:40: > Could not deduce ((1 GHC.TypeLits.<=? (n + 1)) ~ 'True) > from the context (KnownNat n) > bound by a pattern with constructor > SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> > SomeNat, > in a case alternative > at PositiveNat.hs:23:13-34 > In the expression: f (Vector x xs :: Vector (m + 1) a) > In a case alternative: > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) > In the expression: > case someNatVal $ toInteger $ length xs of { > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) } > > > How can I convince GHC that n+1 is always at least 1? > > > When I remove the (1<=n) constraint, I still get: > > PositiveNat.hs:23:40: > Could not deduce (KnownNat (n + 1)) arising from a use of ?f? > from the context (KnownNat n) > bound by a pattern with constructor > SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> > SomeNat, > in a case alternative > at PositiveNat.hs:23:13-34 > In the expression: f (Vector x xs :: Vector (m + 1) a) > In a case alternative: > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) > In the expression: > case someNatVal (toInteger (length xs)) of { > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) } > > That is, I also have to convince GHC, that if (KnownNat n) then (n+1) is > also KnownNat. How to do that? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Sun Mar 16 13:37:59 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sun, 16 Mar 2014 14:37:59 +0100 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: <1394975595.2415.12.camel@kirk> References: <1394975595.2415.12.camel@kirk> Message-ID: My personal approach would have been to make ghc accept "Foo.*.lhs", maintaining a list of potential file format seems arduous and error prone. Cheers, Merijn On Mar 16, 2014, at 14:13 , Joachim Breitner wrote: > Hi, > > Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten: >> Cons: > > GHC would have to either maintain a possibly long of variants to look > for ([".hs", ".lhs", ".rst.lhs", ".md.lhs", ".svg.lhs", ".docx.lhs"]), > or look for "Foo.*.lhs". > > I?d find the latter acceptable, but it should be noted. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From carter.schonwald at gmail.com Sun Mar 16 13:52:09 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 16 Mar 2014 09:52:09 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: <1394975595.2415.12.camel@kirk> Message-ID: Idk, this behavior of doing Data.Vector.lhs seems pretty awesome. I actually might start doing that. That ghc allows that seems pretty darn awesome. And handy too On Sunday, March 16, 2014, Merijn Verstraaten wrote: > My personal approach would have been to make ghc accept "Foo.*.lhs", > maintaining a list of potential file format seems arduous and error prone. > > Cheers, > Merijn > > On Mar 16, 2014, at 14:13 , Joachim Breitner wrote: > > Hi, > > > > Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten: > >> Cons: > > > > GHC would have to either maintain a possibly long of variants to look > > for ([".hs", ".lhs", ".rst.lhs", ".md.lhs", ".svg.lhs", ".docx.lhs"]), > > or look for "Foo.*.lhs". > > > > I?d find the latter acceptable, but it should be noted. > > > > Greetings, > > Joachim > > > > -- > > Joachim ?nomeata? Breitner > > mail at joachim-breitner.de ? > http://www.joachim-breitner.de/ > > Jabber: nomeata at joachim-breitner.de ? GPG-Key: > 0x4743206C > > Debian Developer: nomeata at debian.org > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Mar 16 14:28:54 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Mar 2014 15:28:54 +0100 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: <5325B526.2060602@henning-thielemann.de> Am 16.03.2014 13:48, schrieb Dan Frumin: > This is just a wild guess, but is there a possibility that (1+n) will > produce less complaints than (n+1)? unfortunately no From lemming at henning-thielemann.de Sun Mar 16 14:37:51 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Mar 2014 15:37:51 +0100 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: <5325B73F.4020603@henning-thielemann.de> Am 16.03.2014 14:35, schrieb Carter Schonwald: > You can't with type lits. The solver can only decide concrete values :"""( I hoped that with type-level natural numbers all my dreams would become true. :-) I'd be also happy if I could manually provide the proof for 1<=n+1 and more complicated statements like n+n=2*n and n>0 && m>0 => n*m>0. > You'll have to use a concrete peano Nats type instead. That is, I may as well stay with the existing type-level number packages? > I've been toying with the idea that the type lits syntax should be just > that, a type level analogue of from integer that you can give to user > land types, but I'm not going to suggest that till 7.8 is fully released. Seems reasonable. By the way, is the GHC Nat kind defined by data promotion or is it a special kind with an efficient internal representation? From carter.schonwald at gmail.com Sun Mar 16 14:56:18 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 16 Mar 2014 10:56:18 -0400 Subject: positive type-level naturals In-Reply-To: <5325B73F.4020603@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <5325B73F.4020603@henning-thielemann.de> Message-ID: its a special Thing that just uses Integer internally, but because it doenst provide a PEANO api, we can't do computations on it :'( On Sun, Mar 16, 2014 at 10:37 AM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > Am 16.03.2014 14:35, schrieb Carter Schonwald: > > > You can't with type lits. The solver can only decide concrete values :"""( >> > > I hoped that with type-level natural numbers all my dreams would become > true. :-) > > I'd be also happy if I could manually provide the proof for 1<=n+1 and > more complicated statements like n+n=2*n and n>0 && m>0 => n*m>0. > > > You'll have to use a concrete peano Nats type instead. >> > > That is, I may as well stay with the existing type-level number packages? > > > I've been toying with the idea that the type lits syntax should be just >> that, a type level analogue of from integer that you can give to user >> land types, but I'm not going to suggest that till 7.8 is fully released. >> > > Seems reasonable. By the way, is the GHC Nat kind defined by data > promotion or is it a special kind with an efficient internal representation? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Sun Mar 16 15:06:10 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Sun, 16 Mar 2014 16:06:10 +0100 Subject: positive type-level naturals In-Reply-To: <53259CAF.3070702@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: Iavor is working on a branch that allows the constraint solver to call an external solver: https://github.com/ghc/ghc/tree/decision-procedure Currently, it: a) only supports CVC4 (an SMT solver), and b) is slightly out of of line with HEAD. I think the above branch will be able to solve things like: 1 <= n + 1 ~ True I myself worked on a patch that can only work with equalities: https://gist.github.com/christiaanb/8396614 It allows you to solve both more and less constraints than Iavor's CVC4 approach: More: It can deal with non-constant multiplications, and also with exponentials Less: It cannot deal with inequalities On Sun, Mar 16, 2014 at 1:44 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > Am 16.03.2014 09:40, schrieb Christiaan Baaij: > > To answer the second question (under the assumption that you want >> phantom-type style Vectors and not GADT-style): >> > > Now I like to define non-empty vectors. The phantom parameter for the > length shall refer to the actual vector length, not to length-1, for > consistency between possibly empty and non-empty vectors. > > I have modified your code as follows: > > {-# LANGUAGE Rank2Types #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE TypeFamilies #-} > module PositiveNat where > > import Data.Proxy (Proxy(Proxy)) > import GHC.TypeLits > (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal, > type (<=), type (+)) > > data Vector (n :: Nat) a = Vector a [a] > > withVector :: > forall a b. > a -> [a] -> > (forall n . (KnownNat n, 1<=n) => Vector n a -> b) -> b > withVector x xs f = > case someNatVal $ toInteger $ length xs of > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m+1) a) > > vecLen :: forall n . KnownNat n => Vector n Integer -> Integer > vecLen _ = natVal (Proxy :: Proxy n) > > -- > withVector vecLen [1,2,3,4] > -- 4 > > > GHC-7.8 complains with: > > PositiveNat.hs:23:40: > Could not deduce ((1 GHC.TypeLits.<=? (n + 1)) ~ 'True) > from the context (KnownNat n) > bound by a pattern with constructor > SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> > SomeNat, > in a case alternative > at PositiveNat.hs:23:13-34 > In the expression: f (Vector x xs :: Vector (m + 1) a) > In a case alternative: > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) > In the expression: > case someNatVal $ toInteger $ length xs of { > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) } > > > How can I convince GHC that n+1 is always at least 1? > > > When I remove the (1<=n) constraint, I still get: > > PositiveNat.hs:23:40: > Could not deduce (KnownNat (n + 1)) arising from a use of 'f' > from the context (KnownNat n) > bound by a pattern with constructor > SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> > SomeNat, > in a case alternative > at PositiveNat.hs:23:13-34 > In the expression: f (Vector x xs :: Vector (m + 1) a) > In a case alternative: > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) > In the expression: > case someNatVal (toInteger (length xs)) of { > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) } > > That is, I also have to convince GHC, that if (KnownNat n) then (n+1) is > also KnownNat. How to do that? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Sun Mar 16 15:26:40 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun, 16 Mar 2014 15:26:40 +0000 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: <1394975595.2415.12.camel@kirk> Message-ID: <5325C2B0.2080603@earth.li> The behaviour could be invoked only for lower-case parts, but that may prove problematic on case-insensitive filesystems like Windows. On 16/03/2014 13:52, Carter Schonwald wrote: > Idk, this behavior of doing Data.Vector.lhs seems pretty awesome. I > actually might start doing that. That ghc allows that seems pretty darn > awesome. And handy too > > On Sunday, March 16, 2014, Merijn Verstraaten > wrote: > > My personal approach would have been to make ghc accept "Foo.*.lhs", > maintaining a list of potential file format seems arduous and error > prone. > > Cheers, > Merijn > > On Mar 16, 2014, at 14:13 , Joachim Breitner wrote: > > Hi, > > > > Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten: > >> Cons: > > > > GHC would have to either maintain a possibly long of variants to look > > for ([".hs", ".lhs", ".rst.lhs", ".md.lhs", ".svg.lhs", ".docx.lhs"]), > > or look for "Foo.*.lhs". > > > > I?d find the latter acceptable, but it should be noted. > > > > Greetings, > > Joachim > > > > -- > > Joachim ?nomeata? Breitner > > mail at joachim-breitner.de ? > http://www.joachim-breitner.de/ > > Jabber: nomeata at joachim-breitner.de ? GPG-Key: > 0x4743206C > > Debian Developer: nomeata at debian.org > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From ekmett at gmail.com Sun Mar 16 15:41:12 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 16 Mar 2014 11:41:12 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: One problem with Foo.*.hs or even Foo.md.hs mapping to the module name Foois that as I recall JHC will look for Data.Vector in Data.Vector.hs as well as Data/Vector.hs This means that on a case insensitive file system Foo.MD.hs matches both conventions. Do I want to block an change to GHC because of an incompatible change in another compiler? Not sure, but I at least want to raise the issue so it can be discussed. Another small issue is that this means you need to actually scan the directory rather than look for particular file names, but off my head really I don't expect directories to be full enough for that to be a performance problem. -Edward On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten wrote: > Ola! > > I didn't know what the most appropriate venue for this proposal was so I > crossposted to haskell-prime and glasgow-haskell-users, if this isn't the > right venue I welcome advice where to take this proposal. > > Currently the report does not specify the mapping between filenames and > module names (this is an issue in itself, it essentially makes writing > haskell code that's interoperable between compilers impossible, as you > can't know what directory layout each compiler expects). I believe that a > minimal specification *should* go into the report (hence, haskell-prime). > However, this is a separate issue from this proposal, so please start a new > thread rather than sidetracking this one :) > > The report only mentions that "by convention" .hs extensions imply normal > haskell and .lhs literate haskell (Section 10.4). In the absence of > guidance from the report GHC's convention of mapping module Foo.Bar.Baz to > Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that > exists. In general this standard is nice enough, but the mapping of > literate haskell is a bit inconvenient, it leaves it completelyl ambiguous > what the non-haskell content of said file is, which is annoying for tool > authors. > > Pandoc has adopted the policy of checking for further file extensions for > literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs > gets interpreted as being reStructured Text with literate haskell and > .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps > filenames like this to the module names Foo.rst and Foo.md, breaking > anything that wants to import the module Foo. > > I would like to propose allowing an optional extra extension in the pandoc > style for literate haskell files, mapping Foo.rst.lhs to module name Foo. > This is a backwards compatible change as there is no way for Foo.rst.lhs to > be a valid module in the current GHC convention. Foo.rst.lhs would map to > module name "Foo.rst" but module name "Foo.rst" maps to filename > "Foo/rst.hs" which is not a valid haskell module anyway as the rst is > lowercase and module names have to start with an uppercase letter. > > Pros: > - Tool authors can more easily determine non-haskell content of literate > haskell files > - Currently valid module names will not break > - Report doesn't specify behaviour, so GHC can do whatever it likes > > Cons: > - Someone has to implement it > - ?? > > Discussion: 4 weeks > > Cheers, > Merijn > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Sun Mar 16 16:23:33 2014 From: greg at gregweber.info (Greg Weber) Date: Sun, 16 Mar 2014 09:23:33 -0700 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: Can we get a little more information on what pandoc is doing? Is there a documentation link? In part am wondering if it is possible to have a Foo.hs.md file that pandoc compiles down to Foo.hs with or without help from GHC. On Sun, Mar 16, 2014 at 5:56 AM, Merijn Verstraaten wrote: > Ola! > > I didn't know what the most appropriate venue for this proposal was so I > crossposted to haskell-prime and glasgow-haskell-users, if this isn't the > right venue I welcome advice where to take this proposal. > > Currently the report does not specify the mapping between filenames and > module names (this is an issue in itself, it essentially makes writing > haskell code that's interoperable between compilers impossible, as you > can't know what directory layout each compiler expects). I believe that a > minimal specification *should* go into the report (hence, haskell-prime). > However, this is a separate issue from this proposal, so please start a new > thread rather than sidetracking this one :) > > The report only mentions that "by convention" .hs extensions imply normal > haskell and .lhs literate haskell (Section 10.4). In the absence of > guidance from the report GHC's convention of mapping module Foo.Bar.Baz to > Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that > exists. In general this standard is nice enough, but the mapping of > literate haskell is a bit inconvenient, it leaves it completelyl ambiguous > what the non-haskell content of said file is, which is annoying for tool > authors. > > Pandoc has adopted the policy of checking for further file extensions for > literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs > gets interpreted as being reStructured Text with literate haskell and > .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps > filenames like this to the module names Foo.rst and Foo.md, breaking > anything that wants to import the module Foo. > > I would like to propose allowing an optional extra extension in the pandoc > style for literate haskell files, mapping Foo.rst.lhs to module name Foo. > This is a backwards compatible change as there is no way for Foo.rst.lhs to > be a valid module in the current GHC convention. Foo.rst.lhs would map to > module name "Foo.rst" but module name "Foo.rst" maps to filename > "Foo/rst.hs" which is not a valid haskell module anyway as the rst is > lowercase and module names have to start with an uppercase letter. > > Pros: > - Tool authors can more easily determine non-haskell content of literate > haskell files > - Currently valid module names will not break > - Report doesn't specify behaviour, so GHC can do whatever it likes > > Cons: > - Someone has to implement it > - ?? > > Discussion: 4 weeks > > Cheers, > Merijn > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabian.bergmark at gmail.com Sun Mar 16 16:57:16 2014 From: fabian.bergmark at gmail.com (Fabian Bergmark) Date: Sun, 16 Mar 2014 17:57:16 +0100 Subject: Safe Haskell trust Message-ID: Im using the Hint library in a project where users are able to upload and run code. As I don't want them to do any IO, I run the interpreter with -XSafe. However, some packages (in my case aeson) are needed and I therefore tried marking them as trusted with ghc-pkg trust aeson. This seems to have no effect however and the interpreter fails with: Data.Aeson: Can't be safely imported! The module itself isn't safe Is there any way to get XSafe-like guarantees with the ability of allowing certain packages? From merijn at inconsistent.nl Sun Mar 16 17:14:12 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sun, 16 Mar 2014 18:14:12 +0100 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: I agree that this could collide, see my beginning remark that I believe that the report should provide a minimal specification how to map modules to filenames and vice versa. Anyhoo, I'm not married to this specific suggestion. Carter suggested "Foo+rst.lhs" on IRC, other options would be "Foo.rst+lhs" or "Foo.lhs+rst", I don't particularly care what as long as we pick something. Patching tools to support whatever solution we pick should be trivial. Cheers, Merijn On Mar 16, 2014, at 16:41 , Edward Kmett wrote: > One problem with Foo.*.hs or even Foo.md.hs mapping to the module name Foo is that as I recall JHC will look for Data.Vector in Data.Vector.hs as well as Data/Vector.hs > > This means that on a case insensitive file system Foo.MD.hs matches both conventions. > > Do I want to block an change to GHC because of an incompatible change in another compiler? Not sure, but I at least want to raise the issue so it can be discussed. > > Another small issue is that this means you need to actually scan the directory rather than look for particular file names, but off my head really I don't expect directories to be full enough for that to be a performance problem. > > -Edward > > > > On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten wrote: > Ola! > > I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. > > Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) > > The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. > > Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. > > I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. > > Pros: > - Tool authors can more easily determine non-haskell content of literate haskell files > - Currently valid module names will not break > - Report doesn't specify behaviour, so GHC can do whatever it likes > > Cons: > - Someone has to implement it > - ?? > > Discussion: 4 weeks > > Cheers, > Merijn > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ekmett at gmail.com Sun Mar 16 17:34:30 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 16 Mar 2014 13:34:30 -0400 Subject: Safe Haskell trust In-Reply-To: References: Message-ID: Not directly. You can, however, make a Trustworthy module that re-exports the (parts of) the Unsafe ones you want to allow yourself to use. -Edward On Sun, Mar 16, 2014 at 12:57 PM, Fabian Bergmark wrote: > Im using the Hint library in a project where users are able to upload > and run code. As I don't want them to do any IO, I run the interpreter > with -XSafe. However, some packages (in my case aeson) are needed and > I therefore tried marking them as trusted with ghc-pkg trust aeson. > This seems to have no effect however and the interpreter fails with: > > Data.Aeson: Can't be safely imported! The module itself isn't safe > > Is there any way to get XSafe-like guarantees with the ability of > allowing certain packages? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Mar 16 19:02:41 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 16 Mar 2014 15:02:41 -0400 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: respectfully, The current typeLits story for nats is kinda a fuster cluck to put it politely . We have type lits but we cant use them (well, we can't compute on them, which is the same thing). For the past 2 years, every ghc release cycle, I first discover, then have to communicate to everyone else "you can't compute on type lits". Heres what I'd like to happen for 7.10, and i'm happy to help / pester this along 1) Typelits as it currently exists in GHC actually conflates "syntactic support" for Nats with having primacy as the "nat" type for ghc. I think we should seriously consider moving in a direction akin to how Agda provides syntactic/ computational support for efficient / 2) the current typelits supplied Nat is kinda crippled because we can't do userland reasoning / compute on it, I consider this a bug! I'm still waiting (2 years later) for a solver we can actually include in ghc or even a user land solver! i think (1) and some part of (2) should happen for 7.10. What design work / subtleties might block it? On Sun, Mar 16, 2014 at 11:06 AM, Christiaan Baaij < christiaan.baaij at gmail.com> wrote: > Iavor is working on a branch that allows the constraint solver to call an > external solver: https://github.com/ghc/ghc/tree/decision-procedure > Currently, it: a) only supports CVC4 (an SMT solver), and b) is slightly > out of of line with HEAD. > I think the above branch will be able to solve things like: 1 <= n + 1 ~ > True > > I myself worked on a patch that can only work with equalities: > https://gist.github.com/christiaanb/8396614 > It allows you to solve both more and less constraints than Iavor's CVC4 > approach: > More: It can deal with non-constant multiplications, and also with > exponentials > Less: It cannot deal with inequalities > > > > On Sun, Mar 16, 2014 at 1:44 PM, Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> Am 16.03.2014 09:40, schrieb Christiaan Baaij: >> >> To answer the second question (under the assumption that you want >>> phantom-type style Vectors and not GADT-style): >>> >> >> Now I like to define non-empty vectors. The phantom parameter for the >> length shall refer to the actual vector length, not to length-1, for >> consistency between possibly empty and non-empty vectors. >> >> I have modified your code as follows: >> >> {-# LANGUAGE Rank2Types #-} >> {-# LANGUAGE DataKinds #-} >> {-# LANGUAGE KindSignatures #-} >> {-# LANGUAGE ScopedTypeVariables #-} >> {-# LANGUAGE TypeOperators #-} >> {-# LANGUAGE TypeFamilies #-} >> module PositiveNat where >> >> import Data.Proxy (Proxy(Proxy)) >> import GHC.TypeLits >> (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal, >> type (<=), type (+)) >> >> data Vector (n :: Nat) a = Vector a [a] >> >> withVector :: >> forall a b. >> a -> [a] -> >> (forall n . (KnownNat n, 1<=n) => Vector n a -> b) -> b >> withVector x xs f = >> case someNatVal $ toInteger $ length xs of >> Nothing -> error "static/dynamic mismatch" >> Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m+1) a) >> >> vecLen :: forall n . KnownNat n => Vector n Integer -> Integer >> vecLen _ = natVal (Proxy :: Proxy n) >> >> -- > withVector vecLen [1,2,3,4] >> -- 4 >> >> >> GHC-7.8 complains with: >> >> PositiveNat.hs:23:40: >> Could not deduce ((1 GHC.TypeLits.<=? (n + 1)) ~ 'True) >> from the context (KnownNat n) >> bound by a pattern with constructor >> SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> >> SomeNat, >> in a case alternative >> at PositiveNat.hs:23:13-34 >> In the expression: f (Vector x xs :: Vector (m + 1) a) >> In a case alternative: >> Just (SomeNat (_ :: Proxy m)) >> -> f (Vector x xs :: Vector (m + 1) a) >> In the expression: >> case someNatVal $ toInteger $ length xs of { >> Nothing -> error "static/dynamic mismatch" >> Just (SomeNat (_ :: Proxy m)) >> -> f (Vector x xs :: Vector (m + 1) a) } >> >> >> How can I convince GHC that n+1 is always at least 1? >> >> >> When I remove the (1<=n) constraint, I still get: >> >> PositiveNat.hs:23:40: >> Could not deduce (KnownNat (n + 1)) arising from a use of ?f? >> from the context (KnownNat n) >> bound by a pattern with constructor >> SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> >> SomeNat, >> in a case alternative >> at PositiveNat.hs:23:13-34 >> In the expression: f (Vector x xs :: Vector (m + 1) a) >> In a case alternative: >> Just (SomeNat (_ :: Proxy m)) >> -> f (Vector x xs :: Vector (m + 1) a) >> In the expression: >> case someNatVal (toInteger (length xs)) of { >> Nothing -> error "static/dynamic mismatch" >> Just (SomeNat (_ :: Proxy m)) >> -> f (Vector x xs :: Vector (m + 1) a) } >> >> That is, I also have to convince GHC, that if (KnownNat n) then (n+1) is >> also KnownNat. How to do that? >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Mar 16 20:52:19 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Mar 2014 21:52:19 +0100 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: <53260F03.8020806@henning-thielemann.de> Am 16.03.2014 20:02, schrieb Carter Schonwald: > respectfully, > The current typeLits story for nats is kinda a fuster cluck to put it > politely . We have type lits but we cant use them (well, we can't > compute on them, which is the same thing). > > For the past 2 years, every ghc release cycle, I first discover, then > have to communicate to everyone else "you can't compute on type lits". A minimal invasive solution would be to provide a kind for unary type level numbers and type functions that convert between Unary and Nat. From ekmett at gmail.com Mon Mar 17 13:08:01 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 17 Mar 2014 09:08:01 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: Foo+rst.lhs does nicely dodge the collision with jhc. How does ghc do the search now? By trying each alternative in turn? On Sun, Mar 16, 2014 at 1:14 PM, Merijn Verstraaten wrote: > I agree that this could collide, see my beginning remark that I believe > that the report should provide a minimal specification how to map modules > to filenames and vice versa. > > Anyhoo, I'm not married to this specific suggestion. Carter suggested > "Foo+rst.lhs" on IRC, other options would be "Foo.rst+lhs" or > "Foo.lhs+rst", I don't particularly care what as long as we pick something. > Patching tools to support whatever solution we pick should be trivial. > > Cheers, > Merijn > > On Mar 16, 2014, at 16:41 , Edward Kmett wrote: > > One problem with Foo.*.hs or even Foo.md.hs mapping to the module name Foois that as I recall JHC will look for > Data.Vector in Data.Vector.hs as well as Data/Vector.hs > > This means that on a case insensitive file system Foo.MD.hs matches both > conventions. > > Do I want to block an change to GHC because of an incompatible change in > another compiler? Not sure, but I at least want to raise the issue so it > can be discussed. > > Another small issue is that this means you need to actually scan the > directory rather than look for particular file names, but off my head > really I don't expect directories to be full enough for that to be a > performance problem. > > -Edward > > > > On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten < > merijn at inconsistent.nl> wrote: > >> Ola! >> >> I didn't know what the most appropriate venue for this proposal was so I >> crossposted to haskell-prime and glasgow-haskell-users, if this isn't the >> right venue I welcome advice where to take this proposal. >> >> Currently the report does not specify the mapping between filenames and >> module names (this is an issue in itself, it essentially makes writing >> haskell code that's interoperable between compilers impossible, as you >> can't know what directory layout each compiler expects). I believe that a >> minimal specification *should* go into the report (hence, haskell-prime). >> However, this is a separate issue from this proposal, so please start a new >> thread rather than sidetracking this one :) >> >> The report only mentions that "by convention" .hs extensions imply normal >> haskell and .lhs literate haskell (Section 10.4). In the absence of >> guidance from the report GHC's convention of mapping module Foo.Bar.Baz to >> Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that >> exists. In general this standard is nice enough, but the mapping of >> literate haskell is a bit inconvenient, it leaves it completelyl ambiguous >> what the non-haskell content of said file is, which is annoying for tool >> authors. >> >> Pandoc has adopted the policy of checking for further file extensions for >> literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs >> gets interpreted as being reStructured Text with literate haskell and >> .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps >> filenames like this to the module names Foo.rst and Foo.md, breaking >> anything that wants to import the module Foo. >> >> I would like to propose allowing an optional extra extension in the >> pandoc style for literate haskell files, mapping Foo.rst.lhs to module name >> Foo. This is a backwards compatible change as there is no way for >> Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs >> would map to module name "Foo.rst" but module name "Foo.rst" maps to >> filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst >> is lowercase and module names have to start with an uppercase letter. >> >> Pros: >> - Tool authors can more easily determine non-haskell content of literate >> haskell files >> - Currently valid module names will not break >> - Report doesn't specify behaviour, so GHC can do whatever it likes >> >> Cons: >> - Someone has to implement it >> - ?? >> >> Discussion: 4 weeks >> >> Cheers, >> Merijn >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabian.bergmark at gmail.com Mon Mar 17 13:10:09 2014 From: fabian.bergmark at gmail.com (Fabian Bergmark) Date: Mon, 17 Mar 2014 14:10:09 +0100 Subject: Safe Haskell trust In-Reply-To: References: Message-ID: I downloaded aeson and modified Data.Aeson to be trustworthy and I can now use it with Hint and XSafe. I however stumbled upon some strange behavior. I use loadModules to import some modules from the same package, and then use setImports with a list of user provided modules. Some explanation about their difference would be appreciated, as the documentation is rather short. The modules loaded with loadModules seems to be checked, ie. can't import unsafe modules, but those imported with setImports are not, ie. the user can import unsafe modules. Have I misunderstood the documentation or is this a flaw in Hint? 2014-03-16 18:34 GMT+01:00 Edward Kmett : > Not directly. You can, however, make a Trustworthy module that re-exports > the (parts of) the Unsafe ones you want to allow yourself to use. > > -Edward > > > On Sun, Mar 16, 2014 at 12:57 PM, Fabian Bergmark > wrote: >> >> Im using the Hint library in a project where users are able to upload >> and run code. As I don't want them to do any IO, I run the interpreter >> with -XSafe. However, some packages (in my case aeson) are needed and >> I therefore tried marking them as trusted with ghc-pkg trust aeson. >> This seems to have no effect however and the interpreter fails with: >> >> Data.Aeson: Can't be safely imported! The module itself isn't safe >> >> Is there any way to get XSafe-like guarantees with the ability of >> allowing certain packages? >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From allbery.b at gmail.com Mon Mar 17 13:22:10 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 17 Mar 2014 09:22:10 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett wrote: > Foo+rst.lhs does nicely dodge the collision with jhc. > Is this legal on Windows? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Mar 17 13:35:32 2014 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 17 Mar 2014 14:35:32 +0100 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: 2014-03-17 14:22 GMT+01:00 Brandon Allbery : > On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett wrote: >> >> Foo+rst.lhs does nicely dodge the collision with jhc. > > > Is this legal on Windows? According to http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx it is, although I can't test this at the moment. From metaniklas at gmail.com Mon Mar 17 13:48:59 2014 From: metaniklas at gmail.com (Niklas Larsson) Date: Mon, 17 Mar 2014 14:48:59 +0100 Subject: SV: PROPOSAL: Literate haskell and module file names Message-ID: <5326fd75.89aa980a.514a.0f71@mx.google.com> I tested and it works on Windows. Niklas ----- Ursprungligt meddelande ----- Fr?n: "Brandon Allbery" Skickat: ?2014-?03-?17 14:22 Till: "Edward Kmett" Kopia: "glasgow-haskell-users at haskell.org" ; "haskell-prime at haskell.org Prime" ?mne: Re: PROPOSAL: Literate haskell and module file names On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett wrote: Foo+rst.lhs does nicely dodge the collision with jhc. Is this legal on Windows? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Mar 17 09:22:01 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 17 Mar 2014 09:22:01 +0000 Subject: can't load .so/.DLL - undefined symbol In-Reply-To: <531F8A0D.8060508@henning-thielemann.de> References: <531F8A0D.8060508@henning-thielemann.de> Message-ID: <5326BEB9.5010802@gmail.com> On 11/03/2014 22:11, Henning Thielemann wrote: > I am trying to understand the following linker message. I have started > GHCi, loaded a program and try to run it: > > Main> main > ... > Loading package poll-0.0 ... linking ... done. > Loading package alsa-seq-0.6.0.3 ... can't load .so/.DLL for: > /var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so > (/var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so: > undefined symbol: > alsazmseqzm0zi6zi0zi3_SystemziPosixziPoll_zdfStorableFd_closure) > > > I assume that GHCi wants to say the following: The instance Storable Fd > defined in module System.Posix.Poll cannot be found in the shared object > file of the alsa-seq package. That's certainly true because that module > is in the package 'poll' and not in 'alsa-seq'. But 'alsa-seq' imports > 'poll'. What might be the problem? It seems to have the idea that System.Posix.Poll is part of the alsa-seq package. Perhaps you have a copy of that module on the search path somewhere, or inside the alsa-seq package? Cheers, Simon > It's a rather big example that fails here, whereas the small examples in > alsa-seq package work. Thus I first like to know what the message really > means, before investigating further. I installed many packages at once > with cabal-install using a single build directory, like: > > $ cabal install --builddir=/tmp/dist --with-ghc=ghc7.8.0.20140228 poll > alsa-seq pkg1 pkg2 pkg3 ... > > ? Can this cause problems? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From lemming at henning-thielemann.de Mon Mar 17 14:33:50 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 17 Mar 2014 15:33:50 +0100 Subject: can't load .so/.DLL - undefined symbol In-Reply-To: <5326BEB9.5010802@gmail.com> References: <531F8A0D.8060508@henning-thielemann.de> <5326BEB9.5010802@gmail.com> Message-ID: <532707CE.5090909@henning-thielemann.de> Am 17.03.2014 10:22, schrieb Simon Marlow: > On 11/03/2014 22:11, Henning Thielemann wrote: >> I am trying to understand the following linker message. I have started >> GHCi, loaded a program and try to run it: >> >> Main> main >> ... >> Loading package poll-0.0 ... linking ... done. >> Loading package alsa-seq-0.6.0.3 ... can't load .so/.DLL for: >> /var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so >> >> (/var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so: >> >> undefined symbol: >> alsazmseqzm0zi6zi0zi3_SystemziPosixziPoll_zdfStorableFd_closure) >> >> >> I assume that GHCi wants to say the following: The instance Storable Fd >> defined in module System.Posix.Poll cannot be found in the shared object >> file of the alsa-seq package. That's certainly true because that module >> is in the package 'poll' and not in 'alsa-seq'. But 'alsa-seq' imports >> 'poll'. What might be the problem? > > It seems to have the idea that System.Posix.Poll is part of the alsa-seq > package. Perhaps you have a copy of that module on the search path > somewhere, or inside the alsa-seq package? This would confirm how I understood the linker message. Then I guess that compiling all packages at once in a single build dir with cabal was the problem. The command line was like: $ cabal install --builddir=/tmp/dist --with-ghc=ghc7.8.0.20140228 poll alsa-seq pkg1 pkg2 pkg3 ... After compiling the packages separately the problem has gone. From dgorin at dc.uba.ar Mon Mar 17 15:08:57 2014 From: dgorin at dc.uba.ar (=?windows-1252?Q?Daniel_Gor=EDn?=) Date: Mon, 17 Mar 2014 16:08:57 +0100 Subject: Safe Haskell trust In-Reply-To: References: Message-ID: Hi Fabian, In general, the behavior you get from hint should be more or less the same one you would observe in ghci, the mapping being roughly: loadModules ~~~> :load setImports ~~~~> :module In ghci, if you have a package installed (and is not hidden in your session), then I believe you can use :module to put any of its public modules in scope with (Safe or otherwise), am I right? If so, that should explain what you are observing? Daniel On 17 Mar 2014, at 14:10, Fabian Bergmark wrote: > I downloaded aeson and modified Data.Aeson to be trustworthy and I can > now use it with Hint and XSafe. I however stumbled upon some strange > behavior. I use loadModules to import some modules from the same > package, and then use setImports with a list of user provided modules. > Some explanation about their difference would be appreciated, as the > documentation is rather short. The modules loaded with loadModules > seems to be checked, ie. can't import unsafe modules, but those > imported with setImports are not, ie. the user can import unsafe > modules. > > Have I misunderstood the documentation or is this a flaw in Hint? > > 2014-03-16 18:34 GMT+01:00 Edward Kmett : >> Not directly. You can, however, make a Trustworthy module that re-exports >> the (parts of) the Unsafe ones you want to allow yourself to use. >> >> -Edward >> >> >> On Sun, Mar 16, 2014 at 12:57 PM, Fabian Bergmark >> wrote: >>> >>> Im using the Hint library in a project where users are able to upload >>> and run code. As I don't want them to do any IO, I run the interpreter >>> with -XSafe. However, some packages (in my case aeson) are needed and >>> I therefore tried marking them as trusted with ghc-pkg trust aeson. >>> This seems to have no effect however and the interpreter fails with: >>> >>> Data.Aeson: Can't be safely imported! The module itself isn't safe >>> >>> Is there any way to get XSafe-like guarantees with the ability of >>> allowing certain packages? >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Mon Mar 17 16:22:27 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 17 Mar 2014 16:22:27 +0000 Subject: GHC-7.8 warning on rules that may not fire In-Reply-To: <53233BE0.2010506@henning-thielemann.de> References: <532334F3.2050000@henning-thielemann.de> <59543203684B2244980D7E4057D5FBC1487EE904@DB3EX14MBXC306.europe.corp.microsoft.com> <53233BE0.2010506@henning-thielemann.de> Message-ID: <59543203684B2244980D7E4057D5FBC1488045CC@DB3EX14MBXC308.europe.corp.microsoft.com> The simplifier runs with phase 2, then 1 then 0 (multiple times). Generally you want to make sure that something does not inline before its RULE can fire. There are quite a few examples in the base package, if you grep for RULE Simon | -----Original Message----- | From: Henning Thielemann [mailto:lemming at henning-thielemann.de] | Sent: 14 March 2014 17:27 | To: Simon Peyton Jones; GHC Users List | Subject: Re: GHC-7.8 warning on rules that may not fire | | Am 14.03.2014 18:05, schrieb Simon Peyton Jones: | | > You may think they are fragile, but not as fragile as saying nothing | > and hoping for the best, which is *super*-fragile. You can't rely on | > rules to take priority, because the rule only fires if it matches, and | > it may only match if some other inlining has taken place. (We tried | > that originally.) | | Ok, how shall I choose "n" in "INLINE[n]"? Is there a meaning of the | phase numbers? I guess it is important to adhere to some conventions in | order to work together with other libraries. | | If I understand correctly I can alter the number of phases with the - | fsimplifier-phases option - how can I choose phase numbers for INLINE | that are universally reasonable? From simonpj at microsoft.com Mon Mar 17 16:31:16 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 17 Mar 2014 16:31:16 +0000 Subject: splicing varPs in quasi-quote brackets In-Reply-To: <5324674F.4090903@apeiron.net> References: <20140314214631.GA4966@workstation> <20140315140826.GA17778@workstation> <5324674F.4090903@apeiron.net> Message-ID: <59543203684B2244980D7E4057D5FBC1488046E3@DB3EX14MBXC308.europe.corp.microsoft.com> Geoffrey This major new feature of Template Haskell is barely reflected in the user manual at all, except a cryptic reference to "a typed expression splice". Might it be possible to add a summary; such as the very fact that there are now two pretty separate parts of TH: the untyped part and the typed part. Plus some links to your blog posts, the TH blog post that described the change? Are there any other relevant links? Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Geoffrey Mainland | Sent: 15 March 2014 14:45 | To: glasgow-haskell-users at haskell.org | Subject: Re: splicing varPs in quasi-quote brackets | | Yes, pattern splices are indeed new in 7.8. See: | | https://www.cs.drexel.edu/~mainland/2013/05/31/type-safe-runtime-code- | generation-with-typed-template-haskell/ | | Cheers, | Geoff | | On 03/15/2014 10:08 AM, Christian H?ner zu Siederdissen wrote: | > Thanks Adam, | > | > It indeed does work with a lambda, should've thought about it. So, it | > seems splices in patterns are new in 7.8 (hadn't seen it in the | notes). | > | > Gruss, | > Christian | > | > * adam vogt [15.03.2014 05:12]: | >> Hello Christian, | >> | >> It seems new to me that $( ) is allowed in patterns. I would have | >> used lamE in something like: | >> | >> [| $(varE v) >>= return . SM.concatMapM $(lamE [varP v] (buildRns f | >> (xs++[w]) ys))) |] | >> | >> Regards, | >> Adam | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From eir at cis.upenn.edu Mon Mar 17 18:05:43 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 17 Mar 2014 14:05:43 -0400 Subject: positive type-level naturals In-Reply-To: <53260F03.8020806@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <53260F03.8020806@henning-thielemann.de> Message-ID: <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> So much to respond to! First, a little relevant context: Iavor Diatchki is the primary implementor of the type-lits stuff; I am not. But, he and I are playing in the same playground, so to speak, so we confer a fair amount and I may have some helpful perspective on all of this. Henning asks: > How can I convince GHC that n+1 is always at least 1? You can ramrod facts like this down GHC's throat when necessary. For example, the following works: > foo :: (1 <= n + 1) => Proxy n -> () > foo _ = () > > lt :: Proxy n -> (1 <=? n + 1) :~: True > lt _ = unsafeCoerce Refl > > bar :: forall (n :: Nat). Proxy n -> () > bar p = gcastWith (lt p) (foo p) In case you're unfamiliar with them, here are some helpful definitions from Data.Type.Equality, used above: > data a :~: b where > Refl :: a :~: a > gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r Also helpful when doing things like this is this definition, from Edward Kmett's `constraints` package: > data Dict c where > Dict :: c => Dict c An `unsafeCoerce Dict` can be used to satisfy any arbitrary constraint. Of course, it is often possible to use an inductive proof (er, recursive function) to produce Refl or Dict without resorting to unsafeCoerce. But, as the TypeLits Nat isn't inductive, we're forced to use drastic measures here. Carter says: > I've been toying with the idea that the type lits syntax should be just that, a type level analogue of from integer that you can give to user land types, but I'm not going to suggest that till 7.8 is fully released. I like this idea. Christiaan says: > Iavor is working on a branch that allows the constraint solver to call an external solver: https://github.com/ghc/ghc/tree/decision-procedure Yes, though I don't know how active this branch is currently. There are whispers afoot of going in the direction of strapping an SMT solver into GHC, though much work remains to be done before this happens. My sense is that an SMT solver will be necessary before TypeLits really becomes fluently useful. I'm confident this will happen eventually, but it may be over a year out, still. It's even possible that I will be the one to do it, but it's not on my short-to-do-list. Christiaan says: > I myself worked on a patch that can only work with equalities: https://gist.github.com/christiaanb/8396614 Cool! Have you conferred with Iavor about this? Carter says: > The current typeLits story for nats is kinda a fuster cluck to put it politely . We have type lits but we cant use them (well, we can't compute on them, which is the same thing). I disagree on both counts here. TypeLits is a work in progress, as are many parts of GHC. That's one of the beautiful things about Haskell/GHC! Is there more progress to be made? Absolutely. But, without the work that's already been done, I'm not sure we would be as convinced as we are (still not 100%, to be sure, but getting there) that we need an SMT solver. We have to build on previous work, and to do that, we have to write potentially incomplete features. And, I've been able to use TypeLits most of the way toward implementing my `units` library (a way of type-checking with respect to units-of-measure). The only feature that they couldn't support was automatic unit conversions. Carter says: > I'm still waiting (2 years later) for a solver we can actually include in ghc or even a user land solver! I've done some thinking about user-land solvers and am quite interested in seeing it done. My chief thrust right now is about dependent types in Haskell, not this, but Iavor's "decision-procedure" branch lays a lot of the groundwork down for integrating perhaps multiple solvers in with GHC. Henning says: > A minimal invasive solution would be to provide a kind for unary type level numbers and type functions that convert between Unary and Nat. This definition is quite straightforward and works beautifully: > data Nat1 = Zero | Succ Nat1 > type family U n where > U 0 = Zero > U n = Succ (U (n-1)) Iavor made sure that subtraction worked specifically in this case because it was so useful. I hope this is helpful! Richard On Mar 16, 2014, at 4:52 PM, Henning Thielemann wrote: > Am 16.03.2014 20:02, schrieb Carter Schonwald: >> respectfully, >> The current typeLits story for nats is kinda a fuster cluck to put it >> politely . We have type lits but we cant use them (well, we can't >> compute on them, which is the same thing). >> >> For the past 2 years, every ghc release cycle, I first discover, then >> have to communicate to everyone else "you can't compute on type lits". > > A minimal invasive solution would be to provide a kind for unary type level numbers and type functions that convert between Unary and Nat. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From carter.schonwald at gmail.com Mon Mar 17 18:52:38 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 17 Mar 2014 14:52:38 -0400 Subject: positive type-level naturals In-Reply-To: <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <53260F03.8020806@henning-thielemann.de> <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> Message-ID: (aside, pardon my earlier tone, been a bit overloaded the past few weeks, that crossed over to the list) OOO that works? I guess that gives a decent way of using TypeLits as a concrete input syntax for Peano numbers. Thanks for pointing that out I think i'm gonna go drop 7.6 support on some code i'm working on if this works :) On Mon, Mar 17, 2014 at 2:05 PM, Richard Eisenberg wrote: > So much to respond to! > > First, a little relevant context: Iavor Diatchki is the primary > implementor of the type-lits stuff; I am not. But, he and I are playing in > the same playground, so to speak, so we confer a fair amount and I may have > some helpful perspective on all of this. > > Henning asks: > > How can I convince GHC that n+1 is always at least 1? > > You can ramrod facts like this down GHC's throat when necessary. For > example, the following works: > > > foo :: (1 <= n + 1) => Proxy n -> () > > foo _ = () > > > > lt :: Proxy n -> (1 <=? n + 1) :~: True > > lt _ = unsafeCoerce Refl > > > > bar :: forall (n :: Nat). Proxy n -> () > > bar p = gcastWith (lt p) (foo p) > > > In case you're unfamiliar with them, here are some helpful definitions > from Data.Type.Equality, used above: > > > data a :~: b where > > Refl :: a :~: a > > gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r > > Also helpful when doing things like this is this definition, from Edward > Kmett's `constraints` package: > > > data Dict c where > > Dict :: c => Dict c > > An `unsafeCoerce Dict` can be used to satisfy any arbitrary constraint. > > Of course, it is often possible to use an inductive proof (er, recursive > function) to produce Refl or Dict without resorting to unsafeCoerce. But, > as the TypeLits Nat isn't inductive, we're forced to use drastic measures > here. > > Carter says: > > I've been toying with the idea that the type lits syntax should be just > that, a type level analogue of from integer that you can give to user land > types, but I'm not going to suggest that till 7.8 is fully released. > > > I like this idea. > > Christiaan says: > > Iavor is working on a branch that allows the constraint solver to call > an external solver: https://github.com/ghc/ghc/tree/decision-procedure > > > Yes, though I don't know how active this branch is currently. There are > whispers afoot of going in the direction of strapping an SMT solver into > GHC, though much work remains to be done before this happens. My sense is > that an SMT solver will be necessary before TypeLits really becomes > fluently useful. I'm confident this will happen eventually, but it may be > over a year out, still. It's even possible that I will be the one to do it, > but it's not on my short-to-do-list. > > Christiaan says: > > I myself worked on a patch that can only work with equalities: > https://gist.github.com/christiaanb/8396614 > > > Cool! Have you conferred with Iavor about this? > > Carter says: > > The current typeLits story for nats is kinda a fuster cluck to put it > politely . We have type lits but we cant use them (well, we can't compute > on them, which is the same thing). > > I disagree on both counts here. TypeLits is a work in progress, as are > many parts of GHC. That's one of the beautiful things about Haskell/GHC! Is > there more progress to be made? Absolutely. But, without the work that's > already been done, I'm not sure we would be as convinced as we are (still > not 100%, to be sure, but getting there) that we need an SMT solver. We > have to build on previous work, and to do that, we have to write > potentially incomplete features. And, I've been able to use TypeLits most > of the way toward implementing my `units` library (a way of type-checking > with respect to units-of-measure). The only feature that they couldn't > support was automatic unit conversions. > > Carter says: > > I'm still waiting (2 years later) for a solver we can actually include > in ghc or even a user land solver! > > > I've done some thinking about user-land solvers and am quite interested in > seeing it done. My chief thrust right now is about dependent types in > Haskell, not this, but Iavor's "decision-procedure" branch lays a lot of > the groundwork down for integrating perhaps multiple solvers in with GHC. > > Henning says: > > A minimal invasive solution would be to provide a kind for unary type > level numbers and type functions that convert between Unary and Nat. > > > This definition is quite straightforward and works beautifully: > > > data Nat1 = Zero | Succ Nat1 > > type family U n where > > U 0 = Zero > > U n = Succ (U (n-1)) > > Iavor made sure that subtraction worked specifically in this case because > it was so useful. > > I hope this is helpful! > Richard > > On Mar 16, 2014, at 4:52 PM, Henning Thielemann < > lemming at henning-thielemann.de> wrote: > > > Am 16.03.2014 20:02, schrieb Carter Schonwald: > >> respectfully, > >> The current typeLits story for nats is kinda a fuster cluck to put it > >> politely . We have type lits but we cant use them (well, we can't > >> compute on them, which is the same thing). > >> > >> For the past 2 years, every ghc release cycle, I first discover, then > >> have to communicate to everyone else "you can't compute on type lits". > > > > A minimal invasive solution would be to provide a kind for unary type > level numbers and type functions that convert between Unary and Nat. > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 17 18:14:45 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 17 Mar 2014 14:14:45 -0400 Subject: type-level induction on Nat In-Reply-To: <53257D00.3010709@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53257D00.3010709@henning-thielemann.de> Message-ID: <5F5D9438-6891-4273-852F-7634AC7163D0@cis.upenn.edu> On Mar 16, 2014, at 6:29 AM, Henning Thielemann wrote: > > Since the unary natural number kind so ubiquituous in examples, is there a recommended module to import it from, which also contains the injectivity magic of FromNat1? I cannot see it in: > No. After some debate (on the libraries list, perhaps?), we decided to remove this from `base`, and I don't know of another library that has taken it on. If it were possible just to define a *kind* Nat1 with *type-level* conversions to and from Nat, we would have kept it in. But, we had to define a *type* Nat1 as well, and it only seemed sensible to have all the class instances, etc., to use this type in terms. This led to a fair amount of code, none of which was tightly coupled to code in `base`. There is a data-nat library, but it doesn't have the conversions to/from Nat built in. Richard From eir at cis.upenn.edu Mon Mar 17 18:19:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 17 Mar 2014 14:19:36 -0400 Subject: converting data-level natural numbers to type-level In-Reply-To: <5324BCBA.9090804@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> Message-ID: On Mar 15, 2014, at 4:48 PM, Henning Thielemann wrote: > What is the meaning of KnownNat? It is a Nat whose value is known at runtime. I'll confess to suggesting the name? I think I was hoping there would be more debate and a better idea at the time, but it just stuck. I see that there is no good way to extract a KnownNat constraint from a singleton Nat. This is an oversight, and I'll be releasing a new version of singletons in the next week with this oversight fixed. If you have other things you want from singletons, now is a good time to ask! Thanks, Richard From carter.schonwald at gmail.com Mon Mar 17 20:01:40 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 17 Mar 2014 16:01:40 -0400 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <53260F03.8020806@henning-thielemann.de> <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> Message-ID: I had to enable undecidable instances, but I'm very very very happy with the U trick, no TH or other things needed. Thanks :) On Mon, Mar 17, 2014 at 2:52 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > (aside, pardon my earlier tone, been a bit overloaded the past few weeks, > that crossed over to the list) > > OOO > that works? > I guess that gives a decent way of using TypeLits as a concrete input > syntax for Peano numbers. Thanks for pointing that out > > I think i'm gonna go drop 7.6 support on some code i'm working on if this > works :) > > > > > > On Mon, Mar 17, 2014 at 2:05 PM, Richard Eisenberg wrote: > >> So much to respond to! >> >> First, a little relevant context: Iavor Diatchki is the primary >> implementor of the type-lits stuff; I am not. But, he and I are playing in >> the same playground, so to speak, so we confer a fair amount and I may have >> some helpful perspective on all of this. >> >> Henning asks: >> > How can I convince GHC that n+1 is always at least 1? >> >> You can ramrod facts like this down GHC's throat when necessary. For >> example, the following works: >> >> > foo :: (1 <= n + 1) => Proxy n -> () >> > foo _ = () >> > >> > lt :: Proxy n -> (1 <=? n + 1) :~: True >> > lt _ = unsafeCoerce Refl >> > >> > bar :: forall (n :: Nat). Proxy n -> () >> > bar p = gcastWith (lt p) (foo p) >> >> >> In case you're unfamiliar with them, here are some helpful definitions >> from Data.Type.Equality, used above: >> >> > data a :~: b where >> > Refl :: a :~: a >> > gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r >> >> Also helpful when doing things like this is this definition, from Edward >> Kmett's `constraints` package: >> >> > data Dict c where >> > Dict :: c => Dict c >> >> An `unsafeCoerce Dict` can be used to satisfy any arbitrary constraint. >> >> Of course, it is often possible to use an inductive proof (er, recursive >> function) to produce Refl or Dict without resorting to unsafeCoerce. But, >> as the TypeLits Nat isn't inductive, we're forced to use drastic measures >> here. >> >> Carter says: >> > I've been toying with the idea that the type lits syntax should be just >> that, a type level analogue of from integer that you can give to user land >> types, but I'm not going to suggest that till 7.8 is fully released. >> >> >> I like this idea. >> >> Christiaan says: >> > Iavor is working on a branch that allows the constraint solver to call >> an external solver: https://github.com/ghc/ghc/tree/decision-procedure >> >> >> Yes, though I don't know how active this branch is currently. There are >> whispers afoot of going in the direction of strapping an SMT solver into >> GHC, though much work remains to be done before this happens. My sense is >> that an SMT solver will be necessary before TypeLits really becomes >> fluently useful. I'm confident this will happen eventually, but it may be >> over a year out, still. It's even possible that I will be the one to do it, >> but it's not on my short-to-do-list. >> >> Christiaan says: >> > I myself worked on a patch that can only work with equalities: >> https://gist.github.com/christiaanb/8396614 >> >> >> Cool! Have you conferred with Iavor about this? >> >> Carter says: >> > The current typeLits story for nats is kinda a fuster cluck to put it >> politely . We have type lits but we cant use them (well, we can't compute >> on them, which is the same thing). >> >> I disagree on both counts here. TypeLits is a work in progress, as are >> many parts of GHC. That's one of the beautiful things about Haskell/GHC! Is >> there more progress to be made? Absolutely. But, without the work that's >> already been done, I'm not sure we would be as convinced as we are (still >> not 100%, to be sure, but getting there) that we need an SMT solver. We >> have to build on previous work, and to do that, we have to write >> potentially incomplete features. And, I've been able to use TypeLits most >> of the way toward implementing my `units` library (a way of type-checking >> with respect to units-of-measure). The only feature that they couldn't >> support was automatic unit conversions. >> >> Carter says: >> > I'm still waiting (2 years later) for a solver we can actually include >> in ghc or even a user land solver! >> >> >> I've done some thinking about user-land solvers and am quite interested >> in seeing it done. My chief thrust right now is about dependent types in >> Haskell, not this, but Iavor's "decision-procedure" branch lays a lot of >> the groundwork down for integrating perhaps multiple solvers in with GHC. >> >> Henning says: >> > A minimal invasive solution would be to provide a kind for unary type >> level numbers and type functions that convert between Unary and Nat. >> >> >> This definition is quite straightforward and works beautifully: >> >> > data Nat1 = Zero | Succ Nat1 >> > type family U n where >> > U 0 = Zero >> > U n = Succ (U (n-1)) >> >> Iavor made sure that subtraction worked specifically in this case because >> it was so useful. >> >> I hope this is helpful! >> Richard >> >> On Mar 16, 2014, at 4:52 PM, Henning Thielemann < >> lemming at henning-thielemann.de> wrote: >> >> > Am 16.03.2014 20:02, schrieb Carter Schonwald: >> >> respectfully, >> >> The current typeLits story for nats is kinda a fuster cluck to put it >> >> politely . We have type lits but we cant use them (well, we can't >> >> compute on them, which is the same thing). >> >> >> >> For the past 2 years, every ghc release cycle, I first discover, then >> >> have to communicate to everyone else "you can't compute on type lits". >> > >> > A minimal invasive solution would be to provide a kind for unary type >> level numbers and type functions that convert between Unary and Nat. >> > >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users at haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Mar 18 13:33:02 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 18 Mar 2014 09:33:02 -0400 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <53260F03.8020806@henning-thielemann.de> <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> Message-ID: Yes, I suppose you would need UndecidableInstances. There's no way for GHC's (already rather weak) termination checker to know that by saying (n-1) a bunch, you're bound to reach 0. I'm glad it's working for you. When I discovered this application for closed type families, I was rather pleased, myself! Richard On Mar 17, 2014, at 4:01 PM, Carter Schonwald wrote: > I had to enable undecidable instances, but I'm very very very happy with the U trick, no TH or other things needed. Thanks :) > > > On Mon, Mar 17, 2014 at 2:52 PM, Carter Schonwald wrote: > (aside, pardon my earlier tone, been a bit overloaded the past few weeks, that crossed over to the list) > > OOO > that works? > I guess that gives a decent way of using TypeLits as a concrete input syntax for Peano numbers. Thanks for pointing that out > > I think i'm gonna go drop 7.6 support on some code i'm working on if this works :) > > > > > > On Mon, Mar 17, 2014 at 2:05 PM, Richard Eisenberg wrote: > So much to respond to! > > First, a little relevant context: Iavor Diatchki is the primary implementor of the type-lits stuff; I am not. But, he and I are playing in the same playground, so to speak, so we confer a fair amount and I may have some helpful perspective on all of this. > > Henning asks: > > How can I convince GHC that n+1 is always at least 1? > > You can ramrod facts like this down GHC's throat when necessary. For example, the following works: > > > foo :: (1 <= n + 1) => Proxy n -> () > > foo _ = () > > > > lt :: Proxy n -> (1 <=? n + 1) :~: True > > lt _ = unsafeCoerce Refl > > > > bar :: forall (n :: Nat). Proxy n -> () > > bar p = gcastWith (lt p) (foo p) > > > In case you're unfamiliar with them, here are some helpful definitions from Data.Type.Equality, used above: > > > data a :~: b where > > Refl :: a :~: a > > gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r > > Also helpful when doing things like this is this definition, from Edward Kmett's `constraints` package: > > > data Dict c where > > Dict :: c => Dict c > > An `unsafeCoerce Dict` can be used to satisfy any arbitrary constraint. > > Of course, it is often possible to use an inductive proof (er, recursive function) to produce Refl or Dict without resorting to unsafeCoerce. But, as the TypeLits Nat isn't inductive, we're forced to use drastic measures here. > > Carter says: > > I've been toying with the idea that the type lits syntax should be just that, a type level analogue of from integer that you can give to user land types, but I'm not going to suggest that till 7.8 is fully released. > > > I like this idea. > > Christiaan says: > > Iavor is working on a branch that allows the constraint solver to call an external solver: https://github.com/ghc/ghc/tree/decision-procedure > > > Yes, though I don't know how active this branch is currently. There are whispers afoot of going in the direction of strapping an SMT solver into GHC, though much work remains to be done before this happens. My sense is that an SMT solver will be necessary before TypeLits really becomes fluently useful. I'm confident this will happen eventually, but it may be over a year out, still. It's even possible that I will be the one to do it, but it's not on my short-to-do-list. > > Christiaan says: > > I myself worked on a patch that can only work with equalities: https://gist.github.com/christiaanb/8396614 > > > Cool! Have you conferred with Iavor about this? > > Carter says: > > The current typeLits story for nats is kinda a fuster cluck to put it politely . We have type lits but we cant use them (well, we can't compute on them, which is the same thing). > > I disagree on both counts here. TypeLits is a work in progress, as are many parts of GHC. That's one of the beautiful things about Haskell/GHC! Is there more progress to be made? Absolutely. But, without the work that's already been done, I'm not sure we would be as convinced as we are (still not 100%, to be sure, but getting there) that we need an SMT solver. We have to build on previous work, and to do that, we have to write potentially incomplete features. And, I've been able to use TypeLits most of the way toward implementing my `units` library (a way of type-checking with respect to units-of-measure). The only feature that they couldn't support was automatic unit conversions. > > Carter says: > > I'm still waiting (2 years later) for a solver we can actually include in ghc or even a user land solver! > > > I've done some thinking about user-land solvers and am quite interested in seeing it done. My chief thrust right now is about dependent types in Haskell, not this, but Iavor's "decision-procedure" branch lays a lot of the groundwork down for integrating perhaps multiple solvers in with GHC. > > Henning says: > > A minimal invasive solution would be to provide a kind for unary type level numbers and type functions that convert between Unary and Nat. > > > This definition is quite straightforward and works beautifully: > > > data Nat1 = Zero | Succ Nat1 > > type family U n where > > U 0 = Zero > > U n = Succ (U (n-1)) > > Iavor made sure that subtraction worked specifically in this case because it was so useful. > > I hope this is helpful! > Richard > > On Mar 16, 2014, at 4:52 PM, Henning Thielemann wrote: > > > Am 16.03.2014 20:02, schrieb Carter Schonwald: > >> respectfully, > >> The current typeLits story for nats is kinda a fuster cluck to put it > >> politely . We have type lits but we cant use them (well, we can't > >> compute on them, which is the same thing). > >> > >> For the past 2 years, every ghc release cycle, I first discover, then > >> have to communicate to everyone else "you can't compute on type lits". > > > > A minimal invasive solution would be to provide a kind for unary type level numbers and type functions that convert between Unary and Nat. > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Tue Mar 18 15:17:36 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue, 18 Mar 2014 16:17:36 +0100 Subject: Mac CPP problem with ghc-clang-wrapper Message-ID: <53286390.1010906@dfki.de> Hi, under mavericks using the ghc-clang-wrapper (ghc-7.6) or using ghc-7.8.20140130 I can no longer install the HaXml package. The source line: putStrLn $ "part of HaXml-"++show MAJOR.MINOR seems to put spaces around the decimal point between MAJOR and MINOR and fails as shown below. Is this already a known problem? Cheers Christian [14 of 42] Compiling Text.XML.HaXml.Wrappers ( src/Text/XML/HaXml/Wrappers.hs, dist/build/Text/XML/HaXml/Wrappers.o ) src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match type ?[Char]? with ?b0 -> c0? Expected type: b0 -> c0 Actual type: String Possible cause: ?show? is applied to too many arguments In the first argument of ?(.)?, namely ?show 1? In the second argument of ?(++)?, namely ?show 1 . 24? src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match expected type ?[Char]? with actual type ?a0 -> c0? In the second argument of ?(++)?, namely ?show 1 . 24? In the second argument of ?($)?, namely ?"part of HaXml-" ++ show 1 . 24? In a stmt of a 'do' block: putStrLn $ "part of HaXml-" ++ show 1 . 24 Failed to install HaXml-1.24 From malcolm.wallace at me.com Tue Mar 18 15:26:21 2014 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Tue, 18 Mar 2014 15:26:21 +0000 Subject: Mac CPP problem with ghc-clang-wrapper In-Reply-To: <53286390.1010906@dfki.de> References: <53286390.1010906@dfki.de> Message-ID: <1EF69434-7EFB-4ED9-83E4-00540CF03939@me.com> Yes, this is a known problem. I intend to put out a fresh version of HaXml soon to fix it. Regards, Malcolm On 18 Mar 2014, at 15:17, Christian Maeder wrote: > Hi, > > under mavericks using the ghc-clang-wrapper (ghc-7.6) or using ghc-7.8.20140130 I can no longer install the HaXml package. > > The source line: > putStrLn $ "part of HaXml-"++show MAJOR.MINOR > > seems to put spaces around the decimal point between MAJOR and MINOR and fails as shown below. > > Is this already a known problem? > > Cheers Christian > > [14 of 42] Compiling Text.XML.HaXml.Wrappers ( src/Text/XML/HaXml/Wrappers.hs, dist/build/Text/XML/HaXml/Wrappers.o ) > > src/Text/XML/HaXml/Wrappers.hs:34:36: > Couldn't match type ?[Char]? with ?b0 -> c0? > Expected type: b0 -> c0 > Actual type: String > Possible cause: ?show? is applied to too many arguments > In the first argument of ?(.)?, namely ?show 1? > In the second argument of ?(++)?, namely ?show 1 . 24? > > src/Text/XML/HaXml/Wrappers.hs:34:36: > Couldn't match expected type ?[Char]? with actual type ?a0 -> c0? > In the second argument of ?(++)?, namely ?show 1 . 24? > In the second argument of ?($)?, namely > ?"part of HaXml-" ++ show 1 . 24? > In a stmt of a 'do' block: > putStrLn $ "part of HaXml-" ++ show 1 . 24 > Failed to install HaXml-1.24 > > From carter.schonwald at gmail.com Tue Mar 18 16:02:30 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 18 Mar 2014 12:02:30 -0400 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <53260F03.8020806@henning-thielemann.de> <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> Message-ID: Would it be correct to think of closed type families as being more like a closed, ordered collection of unification queries against the constraint solver, that happens to act like pattern matching? Does that mean that one possible but potentially ill advised generalization be some sort of way to add pattern guards? I imagine it'd kinda work like instance heads for type classes. I'm not suggesting this mind you, merely thing to understand how to think about the crazy amount of power :) that said, for fake 7.6 support i'm going to have to via CPP export the following opentype family :) type family U (n:: LitNat) :: Nat -- can't induct, hence crippled type instance U n = Z On Tue, Mar 18, 2014 at 9:33 AM, Richard Eisenberg wrote: > Yes, I suppose you would need UndecidableInstances. There's no way for > GHC's (already rather weak) termination checker to know that by saying > (n-1) a bunch, you're bound to reach 0. > > I'm glad it's working for you. When I discovered this application for > closed type families, I was rather pleased, myself! > > Richard > > On Mar 17, 2014, at 4:01 PM, Carter Schonwald wrote: > > I had to enable undecidable instances, but I'm very very very happy with > the U trick, no TH or other things needed. Thanks :) > > > On Mon, Mar 17, 2014 at 2:52 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> (aside, pardon my earlier tone, been a bit overloaded the past few weeks, >> that crossed over to the list) >> >> OOO >> that works? >> I guess that gives a decent way of using TypeLits as a concrete input >> syntax for Peano numbers. Thanks for pointing that out >> >> I think i'm gonna go drop 7.6 support on some code i'm working on if this >> works :) >> >> >> >> >> >> On Mon, Mar 17, 2014 at 2:05 PM, Richard Eisenberg wrote: >> >>> So much to respond to! >>> >>> First, a little relevant context: Iavor Diatchki is the primary >>> implementor of the type-lits stuff; I am not. But, he and I are playing in >>> the same playground, so to speak, so we confer a fair amount and I may have >>> some helpful perspective on all of this. >>> >>> Henning asks: >>> > How can I convince GHC that n+1 is always at least 1? >>> >>> You can ramrod facts like this down GHC's throat when necessary. For >>> example, the following works: >>> >>> > foo :: (1 <= n + 1) => Proxy n -> () >>> > foo _ = () >>> > >>> > lt :: Proxy n -> (1 <=? n + 1) :~: True >>> > lt _ = unsafeCoerce Refl >>> > >>> > bar :: forall (n :: Nat). Proxy n -> () >>> > bar p = gcastWith (lt p) (foo p) >>> >>> >>> In case you're unfamiliar with them, here are some helpful definitions >>> from Data.Type.Equality, used above: >>> >>> > data a :~: b where >>> > Refl :: a :~: a >>> > gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r >>> >>> Also helpful when doing things like this is this definition, from Edward >>> Kmett's `constraints` package: >>> >>> > data Dict c where >>> > Dict :: c => Dict c >>> >>> An `unsafeCoerce Dict` can be used to satisfy any arbitrary constraint. >>> >>> Of course, it is often possible to use an inductive proof (er, recursive >>> function) to produce Refl or Dict without resorting to unsafeCoerce. But, >>> as the TypeLits Nat isn't inductive, we're forced to use drastic measures >>> here. >>> >>> Carter says: >>> > I've been toying with the idea that the type lits syntax should be >>> just that, a type level analogue of from integer that you can give to user >>> land types, but I'm not going to suggest that till 7.8 is fully released. >>> >>> >>> I like this idea. >>> >>> Christiaan says: >>> > Iavor is working on a branch that allows the constraint solver to call >>> an external solver: https://github.com/ghc/ghc/tree/decision-procedure >>> >>> >>> Yes, though I don't know how active this branch is currently. There are >>> whispers afoot of going in the direction of strapping an SMT solver into >>> GHC, though much work remains to be done before this happens. My sense is >>> that an SMT solver will be necessary before TypeLits really becomes >>> fluently useful. I'm confident this will happen eventually, but it may be >>> over a year out, still. It's even possible that I will be the one to do it, >>> but it's not on my short-to-do-list. >>> >>> Christiaan says: >>> > I myself worked on a patch that can only work with equalities: >>> https://gist.github.com/christiaanb/8396614 >>> >>> >>> Cool! Have you conferred with Iavor about this? >>> >>> Carter says: >>> > The current typeLits story for nats is kinda a fuster cluck to put it >>> politely . We have type lits but we cant use them (well, we can't compute >>> on them, which is the same thing). >>> >>> I disagree on both counts here. TypeLits is a work in progress, as are >>> many parts of GHC. That's one of the beautiful things about Haskell/GHC! Is >>> there more progress to be made? Absolutely. But, without the work that's >>> already been done, I'm not sure we would be as convinced as we are (still >>> not 100%, to be sure, but getting there) that we need an SMT solver. We >>> have to build on previous work, and to do that, we have to write >>> potentially incomplete features. And, I've been able to use TypeLits most >>> of the way toward implementing my `units` library (a way of type-checking >>> with respect to units-of-measure). The only feature that they couldn't >>> support was automatic unit conversions. >>> >>> Carter says: >>> > I'm still waiting (2 years later) for a solver we can actually include >>> in ghc or even a user land solver! >>> >>> >>> I've done some thinking about user-land solvers and am quite interested >>> in seeing it done. My chief thrust right now is about dependent types in >>> Haskell, not this, but Iavor's "decision-procedure" branch lays a lot of >>> the groundwork down for integrating perhaps multiple solvers in with GHC. >>> >>> Henning says: >>> > A minimal invasive solution would be to provide a kind for unary type >>> level numbers and type functions that convert between Unary and Nat. >>> >>> >>> This definition is quite straightforward and works beautifully: >>> >>> > data Nat1 = Zero | Succ Nat1 >>> > type family U n where >>> > U 0 = Zero >>> > U n = Succ (U (n-1)) >>> >>> Iavor made sure that subtraction worked specifically in this case >>> because it was so useful. >>> >>> I hope this is helpful! >>> Richard >>> >>> On Mar 16, 2014, at 4:52 PM, Henning Thielemann < >>> lemming at henning-thielemann.de> wrote: >>> >>> > Am 16.03.2014 20:02, schrieb Carter Schonwald: >>> >> respectfully, >>> >> The current typeLits story for nats is kinda a fuster cluck to put it >>> >> politely . We have type lits but we cant use them (well, we can't >>> >> compute on them, which is the same thing). >>> >> >>> >> For the past 2 years, every ghc release cycle, I first discover, then >>> >> have to communicate to everyone else "you can't compute on type lits". >>> > >>> > A minimal invasive solution would be to provide a kind for unary type >>> level numbers and type functions that convert between Unary and Nat. >>> > >>> > _______________________________________________ >>> > Glasgow-haskell-users mailing list >>> > Glasgow-haskell-users at haskell.org >>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Mar 18 16:25:56 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 18 Mar 2014 12:25:56 -0400 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <53260F03.8020806@henning-thielemann.de> <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> Message-ID: <7EC37D8E-3C4E-4F81-9D69-F925CCB741C2@cis.upenn.edu> I wouldn't call them unification queries against the constraint solver, because that implies a little more intelligence than is really there. They are unification queries, I suppose, against the fully-simplified (i.e., with as many type family simplifications as possible) arguments. Pattern guards do not seem possible here, as unification (and *only* unification, nothing more complicated -- we couldn't handle it) plays a very central role to the mechanism. The theory is complicated enough as it is, and trying to add some form of guard (other than perhaps inequality guards, which play nicely with unification) would surely blow whatever small slice is left of the complexity budget. Richard On Mar 18, 2014, at 12:02 PM, Carter Schonwald wrote: > Would it be correct to think of closed type families as being more like a closed, ordered collection of unification queries against the constraint solver, that happens to act like pattern matching? Does that mean that one possible but potentially ill advised generalization be some sort of way to add pattern guards? I imagine it'd kinda work like instance heads for type classes. I'm not suggesting this mind you, merely thing to understand how to think about the crazy amount of power :) > > that said, for fake 7.6 support i'm going to have to via CPP export the following opentype family :) > > type family U (n:: LitNat) :: Nat > -- can't induct, hence crippled > type instance U n = Z > > > > > On Tue, Mar 18, 2014 at 9:33 AM, Richard Eisenberg wrote: > Yes, I suppose you would need UndecidableInstances. There's no way for GHC's (already rather weak) termination checker to know that by saying (n-1) a bunch, you're bound to reach 0. > > I'm glad it's working for you. When I discovered this application for closed type families, I was rather pleased, myself! > > Richard > > On Mar 17, 2014, at 4:01 PM, Carter Schonwald wrote: > >> I had to enable undecidable instances, but I'm very very very happy with the U trick, no TH or other things needed. Thanks :) >> >> >> On Mon, Mar 17, 2014 at 2:52 PM, Carter Schonwald wrote: >> (aside, pardon my earlier tone, been a bit overloaded the past few weeks, that crossed over to the list) >> >> OOO >> that works? >> I guess that gives a decent way of using TypeLits as a concrete input syntax for Peano numbers. Thanks for pointing that out >> >> I think i'm gonna go drop 7.6 support on some code i'm working on if this works :) >> >> >> >> >> >> On Mon, Mar 17, 2014 at 2:05 PM, Richard Eisenberg wrote: >> So much to respond to! >> >> First, a little relevant context: Iavor Diatchki is the primary implementor of the type-lits stuff; I am not. But, he and I are playing in the same playground, so to speak, so we confer a fair amount and I may have some helpful perspective on all of this. >> >> Henning asks: >> > How can I convince GHC that n+1 is always at least 1? >> >> You can ramrod facts like this down GHC's throat when necessary. For example, the following works: >> >> > foo :: (1 <= n + 1) => Proxy n -> () >> > foo _ = () >> > >> > lt :: Proxy n -> (1 <=? n + 1) :~: True >> > lt _ = unsafeCoerce Refl >> > >> > bar :: forall (n :: Nat). Proxy n -> () >> > bar p = gcastWith (lt p) (foo p) >> >> >> In case you're unfamiliar with them, here are some helpful definitions from Data.Type.Equality, used above: >> >> > data a :~: b where >> > Refl :: a :~: a >> > gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r >> >> Also helpful when doing things like this is this definition, from Edward Kmett's `constraints` package: >> >> > data Dict c where >> > Dict :: c => Dict c >> >> An `unsafeCoerce Dict` can be used to satisfy any arbitrary constraint. >> >> Of course, it is often possible to use an inductive proof (er, recursive function) to produce Refl or Dict without resorting to unsafeCoerce. But, as the TypeLits Nat isn't inductive, we're forced to use drastic measures here. >> >> Carter says: >> > I've been toying with the idea that the type lits syntax should be just that, a type level analogue of from integer that you can give to user land types, but I'm not going to suggest that till 7.8 is fully released. >> >> >> I like this idea. >> >> Christiaan says: >> > Iavor is working on a branch that allows the constraint solver to call an external solver: https://github.com/ghc/ghc/tree/decision-procedure >> >> >> Yes, though I don't know how active this branch is currently. There are whispers afoot of going in the direction of strapping an SMT solver into GHC, though much work remains to be done before this happens. My sense is that an SMT solver will be necessary before TypeLits really becomes fluently useful. I'm confident this will happen eventually, but it may be over a year out, still. It's even possible that I will be the one to do it, but it's not on my short-to-do-list. >> >> Christiaan says: >> > I myself worked on a patch that can only work with equalities: https://gist.github.com/christiaanb/8396614 >> >> >> Cool! Have you conferred with Iavor about this? >> >> Carter says: >> > The current typeLits story for nats is kinda a fuster cluck to put it politely . We have type lits but we cant use them (well, we can't compute on them, which is the same thing). >> >> I disagree on both counts here. TypeLits is a work in progress, as are many parts of GHC. That's one of the beautiful things about Haskell/GHC! Is there more progress to be made? Absolutely. But, without the work that's already been done, I'm not sure we would be as convinced as we are (still not 100%, to be sure, but getting there) that we need an SMT solver. We have to build on previous work, and to do that, we have to write potentially incomplete features. And, I've been able to use TypeLits most of the way toward implementing my `units` library (a way of type-checking with respect to units-of-measure). The only feature that they couldn't support was automatic unit conversions. >> >> Carter says: >> > I'm still waiting (2 years later) for a solver we can actually include in ghc or even a user land solver! >> >> >> I've done some thinking about user-land solvers and am quite interested in seeing it done. My chief thrust right now is about dependent types in Haskell, not this, but Iavor's "decision-procedure" branch lays a lot of the groundwork down for integrating perhaps multiple solvers in with GHC. >> >> Henning says: >> > A minimal invasive solution would be to provide a kind for unary type level numbers and type functions that convert between Unary and Nat. >> >> >> This definition is quite straightforward and works beautifully: >> >> > data Nat1 = Zero | Succ Nat1 >> > type family U n where >> > U 0 = Zero >> > U n = Succ (U (n-1)) >> >> Iavor made sure that subtraction worked specifically in this case because it was so useful. >> >> I hope this is helpful! >> Richard >> >> On Mar 16, 2014, at 4:52 PM, Henning Thielemann wrote: >> >> > Am 16.03.2014 20:02, schrieb Carter Schonwald: >> >> respectfully, >> >> The current typeLits story for nats is kinda a fuster cluck to put it >> >> politely . We have type lits but we cant use them (well, we can't >> >> compute on them, which is the same thing). >> >> >> >> For the past 2 years, every ghc release cycle, I first discover, then >> >> have to communicate to everyone else "you can't compute on type lits". >> > >> > A minimal invasive solution would be to provide a kind for unary type level numbers and type functions that convert between Unary and Nat. >> > >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users at haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Mar 18 16:32:53 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 18 Mar 2014 12:32:53 -0400 Subject: positive type-level naturals In-Reply-To: <7EC37D8E-3C4E-4F81-9D69-F925CCB741C2@cis.upenn.edu> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> <53260F03.8020806@henning-thielemann.de> <0C5BDFC6-7363-41D4-98E1-DDC9E43DE6B0@cis.upenn.edu> <7EC37D8E-3C4E-4F81-9D69-F925CCB741C2@cis.upenn.edu> Message-ID: hrm, good point, that helps me understand this better, Thanks! On Tue, Mar 18, 2014 at 12:25 PM, Richard Eisenberg wrote: > I wouldn't call them unification queries against the constraint solver, > because that implies a little more intelligence than is really there. They > are unification queries, I suppose, against the fully-simplified (i.e., > with as many type family simplifications as possible) arguments. > > Pattern guards do not seem possible here, as unification (and *only* > unification, nothing more complicated -- we couldn't handle it) plays a > very central role to the mechanism. The theory is complicated enough as it > is, and trying to add some form of guard (other than perhaps inequality > guards, which play nicely with unification) would surely blow whatever > small slice is left of the complexity budget. > > Richard > > On Mar 18, 2014, at 12:02 PM, Carter Schonwald wrote: > > Would it be correct to think of closed type families as being more like a > closed, ordered collection of unification queries against the constraint > solver, that happens to act like pattern matching? Does that mean that one > possible but potentially ill advised generalization be some sort of way to > add pattern guards? I imagine it'd kinda work like instance heads for type > classes. I'm not suggesting this mind you, merely thing to understand how > to think about the crazy amount of power :) > > that said, for fake 7.6 support i'm going to have to via CPP export the > following opentype family :) > > type family U (n:: LitNat) :: Nat > -- can't induct, hence crippled > type instance U n = Z > > > > > On Tue, Mar 18, 2014 at 9:33 AM, Richard Eisenberg wrote: > >> Yes, I suppose you would need UndecidableInstances. There's no way for >> GHC's (already rather weak) termination checker to know that by saying >> (n-1) a bunch, you're bound to reach 0. >> >> I'm glad it's working for you. When I discovered this application for >> closed type families, I was rather pleased, myself! >> >> Richard >> >> On Mar 17, 2014, at 4:01 PM, Carter Schonwald wrote: >> >> I had to enable undecidable instances, but I'm very very very happy with >> the U trick, no TH or other things needed. Thanks :) >> >> >> On Mon, Mar 17, 2014 at 2:52 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> (aside, pardon my earlier tone, been a bit overloaded the past few >>> weeks, that crossed over to the list) >>> >>> OOO >>> that works? >>> I guess that gives a decent way of using TypeLits as a concrete input >>> syntax for Peano numbers. Thanks for pointing that out >>> >>> I think i'm gonna go drop 7.6 support on some code i'm working on if >>> this works :) >>> >>> >>> >>> >>> >>> On Mon, Mar 17, 2014 at 2:05 PM, Richard Eisenberg wrote: >>> >>>> So much to respond to! >>>> >>>> First, a little relevant context: Iavor Diatchki is the primary >>>> implementor of the type-lits stuff; I am not. But, he and I are playing in >>>> the same playground, so to speak, so we confer a fair amount and I may have >>>> some helpful perspective on all of this. >>>> >>>> Henning asks: >>>> > How can I convince GHC that n+1 is always at least 1? >>>> >>>> You can ramrod facts like this down GHC's throat when necessary. For >>>> example, the following works: >>>> >>>> > foo :: (1 <= n + 1) => Proxy n -> () >>>> > foo _ = () >>>> > >>>> > lt :: Proxy n -> (1 <=? n + 1) :~: True >>>> > lt _ = unsafeCoerce Refl >>>> > >>>> > bar :: forall (n :: Nat). Proxy n -> () >>>> > bar p = gcastWith (lt p) (foo p) >>>> >>>> >>>> In case you're unfamiliar with them, here are some helpful definitions >>>> from Data.Type.Equality, used above: >>>> >>>> > data a :~: b where >>>> > Refl :: a :~: a >>>> > gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r >>>> >>>> Also helpful when doing things like this is this definition, from >>>> Edward Kmett's `constraints` package: >>>> >>>> > data Dict c where >>>> > Dict :: c => Dict c >>>> >>>> An `unsafeCoerce Dict` can be used to satisfy any arbitrary constraint. >>>> >>>> Of course, it is often possible to use an inductive proof (er, >>>> recursive function) to produce Refl or Dict without resorting to >>>> unsafeCoerce. But, as the TypeLits Nat isn't inductive, we're forced to use >>>> drastic measures here. >>>> >>>> Carter says: >>>> > I've been toying with the idea that the type lits syntax should be >>>> just that, a type level analogue of from integer that you can give to user >>>> land types, but I'm not going to suggest that till 7.8 is fully released. >>>> >>>> >>>> I like this idea. >>>> >>>> Christiaan says: >>>> > Iavor is working on a branch that allows the constraint solver to >>>> call an external solver: >>>> https://github.com/ghc/ghc/tree/decision-procedure >>>> >>>> >>>> Yes, though I don't know how active this branch is currently. There are >>>> whispers afoot of going in the direction of strapping an SMT solver into >>>> GHC, though much work remains to be done before this happens. My sense is >>>> that an SMT solver will be necessary before TypeLits really becomes >>>> fluently useful. I'm confident this will happen eventually, but it may be >>>> over a year out, still. It's even possible that I will be the one to do it, >>>> but it's not on my short-to-do-list. >>>> >>>> Christiaan says: >>>> > I myself worked on a patch that can only work with equalities: >>>> https://gist.github.com/christiaanb/8396614 >>>> >>>> >>>> Cool! Have you conferred with Iavor about this? >>>> >>>> Carter says: >>>> > The current typeLits story for nats is kinda a fuster cluck to put it >>>> politely . We have type lits but we cant use them (well, we can't compute >>>> on them, which is the same thing). >>>> >>>> I disagree on both counts here. TypeLits is a work in progress, as are >>>> many parts of GHC. That's one of the beautiful things about Haskell/GHC! Is >>>> there more progress to be made? Absolutely. But, without the work that's >>>> already been done, I'm not sure we would be as convinced as we are (still >>>> not 100%, to be sure, but getting there) that we need an SMT solver. We >>>> have to build on previous work, and to do that, we have to write >>>> potentially incomplete features. And, I've been able to use TypeLits most >>>> of the way toward implementing my `units` library (a way of type-checking >>>> with respect to units-of-measure). The only feature that they couldn't >>>> support was automatic unit conversions. >>>> >>>> Carter says: >>>> > I'm still waiting (2 years later) for a solver we can actually >>>> include in ghc or even a user land solver! >>>> >>>> >>>> I've done some thinking about user-land solvers and am quite interested >>>> in seeing it done. My chief thrust right now is about dependent types in >>>> Haskell, not this, but Iavor's "decision-procedure" branch lays a lot of >>>> the groundwork down for integrating perhaps multiple solvers in with GHC. >>>> >>>> Henning says: >>>> > A minimal invasive solution would be to provide a kind for unary type >>>> level numbers and type functions that convert between Unary and Nat. >>>> >>>> >>>> This definition is quite straightforward and works beautifully: >>>> >>>> > data Nat1 = Zero | Succ Nat1 >>>> > type family U n where >>>> > U 0 = Zero >>>> > U n = Succ (U (n-1)) >>>> >>>> Iavor made sure that subtraction worked specifically in this case >>>> because it was so useful. >>>> >>>> I hope this is helpful! >>>> Richard >>>> >>>> On Mar 16, 2014, at 4:52 PM, Henning Thielemann < >>>> lemming at henning-thielemann.de> wrote: >>>> >>>> > Am 16.03.2014 20:02, schrieb Carter Schonwald: >>>> >> respectfully, >>>> >> The current typeLits story for nats is kinda a fuster cluck to put it >>>> >> politely . We have type lits but we cant use them (well, we can't >>>> >> compute on them, which is the same thing). >>>> >> >>>> >> For the past 2 years, every ghc release cycle, I first discover, then >>>> >> have to communicate to everyone else "you can't compute on type >>>> lits". >>>> > >>>> > A minimal invasive solution would be to provide a kind for unary type >>>> level numbers and type functions that convert between Unary and Nat. >>>> > >>>> > _______________________________________________ >>>> > Glasgow-haskell-users mailing list >>>> > Glasgow-haskell-users at haskell.org >>>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Wed Mar 19 05:33:29 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Wed, 19 Mar 2014 01:33:29 -0400 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: On Sun, Mar 16, 2014 at 11:06 AM, Christiaan Baaij wrote: > Iavor is working on a branch that allows the constraint solver to call an > external solver: https://github.com/ghc/ghc/tree/decision-procedure > Currently, it: a) only supports CVC4 (an SMT solver), and b) is slightly out > of of line with HEAD. > I think the above branch will be able to solve things like: 1 <= n + 1 ~ > True I don't know much about CVC4, but I do know that Presberger arithmetic is decidable-- which means all the addition-based inequalities can be proven automatically. With that in hand, the only things users or other solvers would have to worry about is multiplying two variables together (multiplying a variable by a constant is included in PA) and similar things (like exponentiation). It shouldn't be too hard to copy over the PA solver used in Coq, though I have no idea how hard it'd be to actually hook the solver up to GHC. The other thing to look at is Agda's (semi)ring solver which, iirc, has the same pros and cons as your patch: variable multiplications but no inequalities. Given the undecidability of Peano arithmetic, the only real way forward will require the ability for users to generate proofs manually-- which is still sorely lacking. Or course, we'd like to have solvers to automate away as much of this as possible, but it's known that we can't automate all of it away. -- Live well, ~wren From iavor.diatchki at gmail.com Wed Mar 19 21:27:49 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 19 Mar 2014 14:27:49 -0700 Subject: positive type-level naturals In-Reply-To: <53259CAF.3070702@henning-thielemann.de> References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: Hi Henning, I see two separate issues that show in what you describe, so it might be useful to discuss them separately: 1. The first issue is figuring out that `n + 1` is always at least 1. As others have mentioned, GHC currently only does proofs "by evaluation", which is why it gets stuck here. We are working on connecting more sophisticated decision procedures with GHC's type checker, and they seem to work fairly well for these kinds of problems. 2. The second one is about: `KnownNat (n + 1)`, and should this be implied by `KnownNat n`, which is more of a design choice. The current thinking is that `KnownNat n` asserts that `n` is a concrete number (i.e., a literal). So having a `KnownNat` constraint is like having an extra integer parameter, which is always evaluated, and never a thunk. Now, `(n + 1)` is not a literal, which is why `KnowNat (n + 1)` is not solved. I think that it would be entirely possible to add more rules for solving `KnownNat` constraints but there are trade offs. For example, consider the following two types: f1 :: KnownNat (a + b) => ... f2 :: (KnownNat a, KnownNat b) => ... The first function will take a single integer parameter, while the second one will take two, and then add them, which seems like more work. Of course, one might hope that in some cases GHC will optimize this away, so maybe this is not much of an issue. Then, there is the issue about situations like this: f3 :: (a + b ~ c, x + y ~ c, KnownNat c) => ... If we apply the same thinking, we could replace `KnownNat c` with either `(KnowNat a, KnownNat b)` or with `(KnownNat x, KnownNat y)` and it is not clear what is the right choice. Similarly, it is not clear if `KnowNat (a * b)`, should be replaced by `(KnownNat a, KnownNat b)`: what if `a` was 0, then we shouldn't need the `KnowNat b` constraint at all. It is also possible to compromise: maybe we should simplify things like `KnownNat (x + 1)` and `KnownNat (x * 2)`, because these do not increase the number of constraints, and there is never the possibility of ambiguity? This might be an interesting direction to explore... A general comment: the function `withVec` is fairly tricky because it introduces vectors whose length is not known statically. This tends to require much more advanced tools because one has to do real mathematical reasoning about abstract values. Of course, sometimes there is no way around this, but on occasion one can avoid it. For example, in the expression `withVec 1 [2,3,4]` we know exactly the length of the vectors involved, so there is no reason to resort to using fancy reasoning. The problem is that Haskell's list notation does not tell us the length of the list literal. One could imagine writing a little quasi-quoter that will allow us to write things like `[vec| 1, 2, 3, 4]`, which would generate the correctly sized vector. Then you can append and manipulate these as usual and GHC will be able to check the types because it only has to work with concrete numbers. This is not a great program verification technique, but it certainly beats having to do it manually :-) I hope this helps, -Iavor On Sun, Mar 16, 2014 at 5:44 AM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > Am 16.03.2014 09:40, schrieb Christiaan Baaij: > > To answer the second question (under the assumption that you want >> phantom-type style Vectors and not GADT-style): >> > > Now I like to define non-empty vectors. The phantom parameter for the > length shall refer to the actual vector length, not to length-1, for > consistency between possibly empty and non-empty vectors. > > I have modified your code as follows: > > {-# LANGUAGE Rank2Types #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE TypeFamilies #-} > module PositiveNat where > > import Data.Proxy (Proxy(Proxy)) > import GHC.TypeLits > (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal, > type (<=), type (+)) > > data Vector (n :: Nat) a = Vector a [a] > > withVector :: > forall a b. > a -> [a] -> > (forall n . (KnownNat n, 1<=n) => Vector n a -> b) -> b > withVector x xs f = > case someNatVal $ toInteger $ length xs of > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m+1) a) > > vecLen :: forall n . KnownNat n => Vector n Integer -> Integer > vecLen _ = natVal (Proxy :: Proxy n) > > -- > withVector vecLen [1,2,3,4] > -- 4 > > > GHC-7.8 complains with: > > PositiveNat.hs:23:40: > Could not deduce ((1 GHC.TypeLits.<=? (n + 1)) ~ 'True) > from the context (KnownNat n) > bound by a pattern with constructor > SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> > SomeNat, > in a case alternative > at PositiveNat.hs:23:13-34 > In the expression: f (Vector x xs :: Vector (m + 1) a) > In a case alternative: > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) > In the expression: > case someNatVal $ toInteger $ length xs of { > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) } > > > How can I convince GHC that n+1 is always at least 1? > > > When I remove the (1<=n) constraint, I still get: > > PositiveNat.hs:23:40: > Could not deduce (KnownNat (n + 1)) arising from a use of ?f? > from the context (KnownNat n) > bound by a pattern with constructor > SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> > SomeNat, > in a case alternative > at PositiveNat.hs:23:13-34 > In the expression: f (Vector x xs :: Vector (m + 1) a) > In a case alternative: > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) > In the expression: > case someNatVal (toInteger (length xs)) of { > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) > -> f (Vector x xs :: Vector (m + 1) a) } > > That is, I also have to convince GHC, that if (KnownNat n) then (n+1) is > also KnownNat. How to do that? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Mar 19 22:40:53 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 19 Mar 2014 23:40:53 +0100 Subject: positive type-level naturals In-Reply-To: References: <5324843C.9010602@henning-thielemann.de> <53248D3F.3080707@henning-thielemann.de> <5324BCBA.9090804@henning-thielemann.de> <53259CAF.3070702@henning-thielemann.de> Message-ID: <532A1CF5.5080106@henning-thielemann.de> Hi Iavor, Am 19.03.2014 22:27, schrieb Iavor Diatchki: > I see two separate issues that show in what you describe, so it might be > useful to discuss them separately: Thank you and Richard Eisenberg for the detailed explanations. For now, I have just fooled GHC by unsafeCoerceing dictionaries as suggested by Richard. > A general comment: the function `withVec` is fairly tricky because it > introduces vectors whose length is not known statically. This tends to > require much more advanced tools because one has to do real mathematical > reasoning about abstract values. Of course, sometimes there is no way > around this, but on occasion one can avoid it. For example, in the > expression `withVec 1 [2,3,4]` we know exactly the length of the vectors > involved, so there is no reason to resort to using fancy reasoning. The > problem is that Haskell's list notation does not tell us the length of > the list literal. One could imagine writing a little quasi-quoter that > will allow us to write things like `[vec| 1, 2, 3, 4]`, which would > generate the correctly sized vector. Then you can append and manipulate > these as usual and GHC will be able to check the types because it only > has to work with concrete numbers. This is not a great program > verification technique, but it certainly beats having to do it manually :-) For this problem I have a simple solution. I think that the infix list syntax is underrated. If you are used to write 1:2:3:4:[], then you have no problem writing: x = 1:.2:.3:.4:.End with data OneMore f a = a :. f a data End a = End Then x has type (OneMore (OneMore (OneMore (OneMore End))) a) and GHC can easily derive the static list length from it. From marlowsd at gmail.com Wed Mar 26 08:29:10 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 26 Mar 2014 08:29:10 +0000 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: <53328FD6.8050700@gmail.com> On 17/03/2014 13:08, Edward Kmett wrote: > Foo+rst.lhs does nicely dodge the collision with jhc. > > How does ghc do the search now? By trying each alternative in turn? Yes - see compiler/main/Finder.hs Cheers, Simon > > > > > On Sun, Mar 16, 2014 at 1:14 PM, Merijn Verstraaten > > wrote: > > I agree that this could collide, see my beginning remark that I > believe that the report should provide a minimal specification how > to map modules to filenames and vice versa. > > Anyhoo, I'm not married to this specific suggestion. Carter > suggested "Foo+rst.lhs" on IRC, other options would be "Foo.rst+lhs" > or "Foo.lhs+rst", I don't particularly care what as long as we pick > something. Patching tools to support whatever solution we pick > should be trivial. > > Cheers, > Merijn > > On Mar 16, 2014, at 16:41 , Edward Kmett wrote: >> One problem with Foo.*.hs or even Foo.md.hs mapping to the module >> name Foo is that as I recall JHC will look for Data.Vector in >> Data.Vector.hs as well as Data/Vector.hs >> >> This means that on a case insensitive file system >> Foo.MD.hs matches both conventions. >> >> Do I want to block an change to GHC because of an incompatible >> change in another compiler? Not sure, but I at least want to raise >> the issue so it can be discussed. >> >> Another small issue is that this means you need to actually scan >> the directory rather than look for particular file names, but off >> my head really I don't expect directories to be full enough for >> that to be a performance problem. >> >> -Edward >> >> >> >> On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten >> > wrote: >> >> Ola! >> >> I didn't know what the most appropriate venue for this >> proposal was so I crossposted to haskell-prime and >> glasgow-haskell-users, if this isn't the right venue I welcome >> advice where to take this proposal. >> >> Currently the report does not specify the mapping between >> filenames and module names (this is an issue in itself, it >> essentially makes writing haskell code that's interoperable >> between compilers impossible, as you can't know what directory >> layout each compiler expects). I believe that a minimal >> specification *should* go into the report (hence, >> haskell-prime). However, this is a separate issue from this >> proposal, so please start a new thread rather than >> sidetracking this one :) >> >> The report only mentions that "by convention" .hs extensions >> imply normal haskell and .lhs literate haskell (Section 10.4). >> In the absence of guidance from the report GHC's convention of >> mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or >> Foo/Bar/Baz.lhs seems the only sort of standard that exists. >> In general this standard is nice enough, but the mapping of >> literate haskell is a bit inconvenient, it leaves it >> completelyl ambiguous what the non-haskell content of said >> file is, which is annoying for tool authors. >> >> Pandoc has adopted the policy of checking for further file >> extensions for literate haskell source, e.g. Foo.rst.lhs and >> Foo.md.lhs. Here .rst.lhs gets interpreted as being >> reStructured Text with literate haskell and .md.lhs is >> Markdown with literate haskell. Unfortunately GHC currently >> maps filenames like this to the module names Foo.rst and >> Foo.md, breaking anything that wants to import the module Foo. >> >> I would like to propose allowing an optional extra extension >> in the pandoc style for literate haskell files, mapping >> Foo.rst.lhs to module name Foo. This is a backwards compatible >> change as there is no way for Foo.rst.lhs to be a valid module >> in the current GHC convention. Foo.rst.lhs would map to module >> name "Foo.rst" but module name "Foo.rst" maps to filename >> "Foo/rst.hs" which is not a valid haskell module anyway as the >> rst is lowercase and module names have to start with an >> uppercase letter. >> >> Pros: >> - Tool authors can more easily determine non-haskell content >> of literate haskell files >> - Currently valid module names will not break >> - Report doesn't specify behaviour, so GHC can do whatever it >> likes >> >> Cons: >> - Someone has to implement it >> - ?? >> >> Discussion: 4 weeks >> >> Cheers, >> Merijn >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From christiaan.baaij at gmail.com Wed Mar 26 16:40:31 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 26 Mar 2014 17:40:31 +0100 Subject: GHC API: getting the unfolding of a "strange" Id Message-ID: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> Dear list, I'm using the GHC API to get Core Expressions from haskell interface (.hi) files, and have encountered a strange kind of 'Id' for which I can't seem to get the unfolding: The properties of this 'Id' are the following: - varName: $fNumFixed2 - IdDetails: VannillaId - Pretty print of IdInfo.inlinePragInfo: [Always] - IdInfo.unfoldingInfo: NoUnfolding The source file which gives rise to this 'Id' is: https://github.com/christiaanb/clash-prelude/blob/master/src/CLaSH/Sized/Fixed.hs As you can see, the file is compiled with: -fexpose-all-unfoldings The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function, so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'. Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would expect to have a usable 'Unfolding' in general. How can GHC inline the body of this 'Id' if it has no unfolding? Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the $fNumFixed2 'Id' is no longer included in the interface file. At positions where "$fNumFixed2" was originally used, a equality constraint can eventually be found: Using -O: (CLaSH.Sized.Fixed.$fNumFixed2 @(GHC.TypeLits.+ 4 4) Using -O0 -fno-omit-interface-pragmas: (GHC.Types.Eq# @GHC.Types.Bool @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4)) @GHC.Types.True _CO_) So my question is, what kind of "strange" 'Id' is this $fNumFixed2? And how can I get the Core expression for this 'Id' from the interface file? And if I can't get it from the interface file, is there a straightforward way to generate it from the 'Id'? Cheers, Christiaan From christiaan.baaij at gmail.com Wed Mar 26 21:58:18 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 26 Mar 2014 22:58:18 +0100 Subject: GHC API: getting the unfolding of a "strange" Id In-Reply-To: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> References: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> Message-ID: After some more analysis, I found out the following two details: The output of 'ghc -show-iface': be3312a893800a4aa077856449084da7 $fNumFixed2 :: forall (n::GHC.TypeLits.Nat). (GHC.TypeLits.<=) 1 n {- Strictness: b -} $fNumFixed2 is only included in the interface file because of -fexpose-all-unfoldings. And appearently, the inlinePragInfo is by default set to AlwaysInline when an Id is included in the interface file. Additionally, the Id seems to be introduced by the strictness analysis, as compiling with -fno-strictness makes the Id go away. So I guess I should rephrase my question abit: Why does the strictness analysis phase introduce binders for which no unfoldings are generated in the interface file? Even when -fexpose-all-unfoldings is set. -- Christiaan On Wed, Mar 26, 2014 at 5:40 PM, Christiaan Baaij < christiaan.baaij at gmail.com> wrote: > Dear list, > > I'm using the GHC API to get Core Expressions from haskell interface (.hi) > files, and have encountered a strange kind of 'Id' for which I can't seem > to get the unfolding: > > The properties of this 'Id' are the following: > - varName: $fNumFixed2 > - IdDetails: VannillaId > - Pretty print of IdInfo.inlinePragInfo: [Always] > - IdInfo.unfoldingInfo: NoUnfolding > > The source file which gives rise to this 'Id' is: > https://github.com/christiaanb/clash-prelude/blob/master/src/CLaSH/Sized/Fixed.hs > As you can see, the file is compiled with: -fexpose-all-unfoldings > > The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function, > so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'. > Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would > expect to have a usable 'Unfolding' in general. > How can GHC inline the body of this 'Id' if it has no unfolding? > > Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the > $fNumFixed2 'Id' is no longer included in the interface file. > At positions where "$fNumFixed2" was originally used, a equality > constraint can eventually be found: > > Using -O: > (CLaSH.Sized.Fixed.$fNumFixed2 > @(GHC.TypeLits.+ 4 4) > > Using -O0 -fno-omit-interface-pragmas: > (GHC.Types.Eq# > @GHC.Types.Bool > @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4)) > @GHC.Types.True > _CO_) > > So my question is, what kind of "strange" 'Id' is this $fNumFixed2? > And how can I get the Core expression for this 'Id' from the interface > file? > And if I can't get it from the interface file, is there a straightforward > way to generate it from the 'Id'? > > Cheers, > > Christiaan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Mar 28 09:08:52 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 28 Mar 2014 09:08:52 +0000 Subject: GHC API: getting the unfolding of a "strange" Id In-Reply-To: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> References: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0C6176@DB3PRD3001MB020.064d.mgd.msft.net> >From what you say, in a subsequent message, about the strictness being "b", that means the strictness analyser has decided that $fNumFixed2 is bottom (i.e. diverges). So there's no point in exposing the unfolding, because (one way or another) it's an infinite loop, so there's no point in optimising it. It's unusual to have a bottom dictionary; you must be using undecidable instances or something. ("Scrap your boilerplate with class" describes why recursive dictionaries are good.) Bur apparently you have. It's arguable that with -fexpose-all-unfoldings we should expose even bottom values. If you have a reason for wanting that, it'd be an easy change to make, I think. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Christiaan Baaij | Sent: 26 March 2014 16:41 | To: glasgow-haskell-users | Subject: GHC API: getting the unfolding of a "strange" Id | | Dear list, | | I'm using the GHC API to get Core Expressions from haskell interface | (.hi) files, and have encountered a strange kind of 'Id' for which I | can't seem to get the unfolding: | | The properties of this 'Id' are the following: | - varName: $fNumFixed2 | - IdDetails: VannillaId | - Pretty print of IdInfo.inlinePragInfo: [Always] | - IdInfo.unfoldingInfo: NoUnfolding | | The source file which gives rise to this 'Id' is: | https://github.com/christiaanb/clash- | prelude/blob/master/src/CLaSH/Sized/Fixed.hs | As you can see, the file is compiled with: -fexpose-all-unfoldings | | The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function, | so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'. | Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would | expect to have a usable 'Unfolding' in general. | How can GHC inline the body of this 'Id' if it has no unfolding? | | Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the | $fNumFixed2 'Id' is no longer included in the interface file. | At positions where "$fNumFixed2" was originally used, a equality | constraint can eventually be found: | | Using -O: | (CLaSH.Sized.Fixed.$fNumFixed2 | @(GHC.TypeLits.+ 4 4) | | Using -O0 -fno-omit-interface-pragmas: | (GHC.Types.Eq# | @GHC.Types.Bool | @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4)) | @GHC.Types.True | _CO_) | | So my question is, what kind of "strange" 'Id' is this $fNumFixed2? | And how can I get the Core expression for this 'Id' from the interface | file? | And if I can't get it from the interface file, is there a straightforward | way to generate it from the 'Id'? | | Cheers, | | Christiaan | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From christiaan.baaij at gmail.com Fri Mar 28 09:49:26 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Fri, 28 Mar 2014 10:49:26 +0100 Subject: GHC API: getting the unfolding of a "strange" Id In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0C6176@DB3PRD3001MB020.064d.mgd.msft.net> References: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0C6176@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <214060E8-ABC4-4C8B-B6CC-91B0C0A304F4@gmail.com> Hello Simon, Thank you for your reply, I am indeed using undecidable instances. The type of the "offending" dictionary is: forall (n::GHC.TypeLits.Nat). (GHC.TypeLits.<=) 1 n Indeed, part of the context for my 'Num' instance is: 1 <= n Where GHC.TypeLits defines: type x <= y = (x <=? y) ~ True I don't really get why this GHC.TypeLits constraint is a bottom dictionary... Is it because all Coercions/Constraints are bottom? Is there perhaps a set of flags I can use so that I can see the Core term corresponding to CLaSH.Sized.Fixed.$fNumFixed2 during compilation? As for exposing bottom values with -fexpose-all-unfoldings, my use-case is specific, but not too specific I guess. What I do is use whole-program transformation to convert Core to the hardware description language VHDL. As such, any identifier without an unfolding must be considered a black box, for which the compiler must have builtin knowledge. I understand that primitive operators defined in GHC.Prim, such as '+#', don't have an unfolding. And indeed, for those operators I can generate equivalently behaving VHDL. But it becomes annoying when any user code can give rise to potential identifiers with no unfolding. I think that any of the Haskell->Javascript projects that start from Core would have the same issues. Hence my believe that my use-case is not too specific. Also, the flag is called -fexpose-all-unfoldings, not -fexpose-all-unfoldings-except-bottom-values ;-) -- Christiaan On Mar 28, 2014, at 10:08 AM, Simon Peyton Jones wrote: > From what you say, in a subsequent message, about the strictness being "b", that means the strictness analyser has decided that $fNumFixed2 is bottom (i.e. diverges). So there's no point in exposing the unfolding, because (one way or another) it's an infinite loop, so there's no point in optimising it. > > It's unusual to have a bottom dictionary; you must be using undecidable instances or something. ("Scrap your boilerplate with class" describes why recursive dictionaries are good.) Bur apparently you have. > > It's arguable that with -fexpose-all-unfoldings we should expose even bottom values. If you have a reason for wanting that, it'd be an easy change to make, I think. > > Simon > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of Christiaan Baaij > | Sent: 26 March 2014 16:41 > | To: glasgow-haskell-users > | Subject: GHC API: getting the unfolding of a "strange" Id > | > | Dear list, > | > | I'm using the GHC API to get Core Expressions from haskell interface > | (.hi) files, and have encountered a strange kind of 'Id' for which I > | can't seem to get the unfolding: > | > | The properties of this 'Id' are the following: > | - varName: $fNumFixed2 > | - IdDetails: VannillaId > | - Pretty print of IdInfo.inlinePragInfo: [Always] > | - IdInfo.unfoldingInfo: NoUnfolding > | > | The source file which gives rise to this 'Id' is: > | https://github.com/christiaanb/clash- > | prelude/blob/master/src/CLaSH/Sized/Fixed.hs > | As you can see, the file is compiled with: -fexpose-all-unfoldings > | > | The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function, > | so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'. > | Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would > | expect to have a usable 'Unfolding' in general. > | How can GHC inline the body of this 'Id' if it has no unfolding? > | > | Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the > | $fNumFixed2 'Id' is no longer included in the interface file. > | At positions where "$fNumFixed2" was originally used, a equality > | constraint can eventually be found: > | > | Using -O: > | (CLaSH.Sized.Fixed.$fNumFixed2 > | @(GHC.TypeLits.+ 4 4) > | > | Using -O0 -fno-omit-interface-pragmas: > | (GHC.Types.Eq# > | @GHC.Types.Bool > | @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4)) > | @GHC.Types.True > | _CO_) > | > | So my question is, what kind of "strange" 'Id' is this $fNumFixed2? > | And how can I get the Core expression for this 'Id' from the interface > | file? > | And if I can't get it from the interface file, is there a straightforward > | way to generate it from the 'Id'? > | > | Cheers, > | > | Christiaan > | > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From christiaan.baaij at gmail.com Fri Mar 28 09:57:29 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Fri, 28 Mar 2014 10:57:29 +0100 Subject: GHC API: getting the unfolding of a "strange" Id In-Reply-To: <214060E8-ABC4-4C8B-B6CC-91B0C0A304F4@gmail.com> References: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0C6176@DB3PRD3001MB020.064d.mgd.msft.net> <214060E8-ABC4-4C8B-B6CC-91B0C0A304F4@gmail.com> Message-ID: <299206C2-6350-4B07-87C5-2FF3608E88A8@gmail.com> > I don't really get why this GHC.TypeLits constraint is a bottom dictionary... > Is it because all Coercions/Constraints are bottom? > Is there perhaps a set of flags I can use so that I can see the Core term corresponding to CLaSH.Sized.Fixed.$fNumFixed2 during compilation? I guess I straight away answer my own question, sorry for the noise: CLaSH.Sized.Fixed.$fNumFixed2 :: forall (n_a5SH :: GHC.TypeLits.Nat). 1 GHC.TypeLits.<= n_a5SH [GblId, Str=DmdType b] CLaSH.Sized.Fixed.$fNumFixed2 = \ (@ (n_a5SH :: GHC.TypeLits.Nat)) -> Control.Exception.Base.absentError @ (1 GHC.TypeLits.<= n_a5SH) "ww_s9JT{v} [lid] 1 base:GHC.TypeLits.<={tc r1W} n{tv a5SH} [tv]"# I must say... I have never seen, in any of my programs, the error that Control.Exception.Base.absentError is supposed to give: absentError s = error ("Oops! Entered absent arg " ++ unpackCStringUtf8# s) -- Christiaan From dsf at seereason.com Sat Mar 29 17:31:59 2014 From: dsf at seereason.com (David Fox) Date: Sat, 29 Mar 2014 10:31:59 -0700 Subject: Module that causes GHC-7.8 to exhaust memory when -O2 is on Message-ID: The repository at http://src.seereason.com/o2bug contains a package that causes GHC-7.8.1 (rc2?) to exhaust 16GB of RAM and die when the -O2 flag is turned on. I haven't been able to simplify it very much, almost any change to JSON.Render causes it to start working properly. I did get it to fail using only packages available in hackage. Just thought I should let folks know about this issue. Let me know if it fails to fail. Maybe someone who can log in could put this in trac. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Sat Mar 29 19:23:23 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 29 Mar 2014 19:23:23 +0000 Subject: Module that causes GHC-7.8 to exhaust memory when -O2 is on In-Reply-To: References: Message-ID: <53371DAB.9070008@fuuzetsu.co.uk> On 29/03/14 17:31, David Fox wrote: > The repository at http://src.seereason.com/o2bug contains a package that > causes GHC-7.8.1 (rc2?) to exhaust 16GB of RAM and die when the -O2 flag is > turned on. I haven't been able to simplify it very much, almost any change > to JSON.Render causes it to start working properly. I did get it to fail > using only packages available in hackage. Just thought I should let folks > know about this issue. Let me know if it fails to fail. > > Maybe someone who can log in could put this in trac. > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > You can log in to Trac with username ?guest? and password ?guest? I believe. -- Mateusz K. From dsf at seereason.com Sun Mar 30 14:42:11 2014 From: dsf at seereason.com (David Fox) Date: Sun, 30 Mar 2014 07:42:11 -0700 Subject: Module that causes GHC-7.8 to exhaust memory when -O2 is on In-Reply-To: <53371DAB.9070008@fuuzetsu.co.uk> References: <53371DAB.9070008@fuuzetsu.co.uk> Message-ID: On Sat, Mar 29, 2014 at 12:23 PM, Mateusz Kowalczyk wrote: > On 29/03/14 17:31, David Fox wrote: > > The repository at http://src.seereason.com/o2bug contains a package that > > causes GHC-7.8.1 (rc2?) to exhaust 16GB of RAM and die when the -O2 flag > is > > turned on. I haven't been able to simplify it very much, almost any > change > > to JSON.Render causes it to start working properly. I did get it to fail > > using only packages available in hackage. Just thought I should let > folks > > know about this issue. Let me know if it fails to fail. > > > > Maybe someone who can log in could put this in trac. > > > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > You can log in to Trac with username 'guest' and password 'guest' I > believe. > Thanks, I've created https://ghc.haskell.org/trac/ghc/ticket/8941. -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Mar 31 07:30:22 2014 From: voldermort at hotmail.com (harry) Date: Mon, 31 Mar 2014 00:30:22 -0700 (PDT) Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: <1396251022697-5746681.post@n5.nabble.com> Mikhail Glushenkov-2 wrote > Austin promised to provide us with build bots for 3/4 of the tier 1 > platforms. I assume that he is busy with preparing with the 7.8 > release now. How often is cabal-install released? Requiring a dedicated buildbot seems like an overkill just for publishing binaries. I wouldn't mind doing Windows and Linux manually. -- View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742543p5746681.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Mon Mar 31 07:36:10 2014 From: voldermort at hotmail.com (harry) Date: Mon, 31 Mar 2014 00:36:10 -0700 (PDT) Subject: Haskell Weekly News Message-ID: <1396251370106-5746682.post@n5.nabble.com> There hasn't been a HWN since mid-December. I've emailed the editor with no response, and there doesn't seem to have been any (public) online activity from him since. I hope he's OK, but either way, it seems that HWN needs a new editor. Any volunteers? -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Weekly-News-tp5746682.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Mon Mar 31 12:27:00 2014 From: voldermort at hotmail.com (harry) Date: Mon, 31 Mar 2014 05:27:00 -0700 (PDT) Subject: Haskell Support on Windows Message-ID: <1396268819897-5746711.post@n5.nabble.com> I've been getting the impression that a lot of the stickier GHC bugs are Windows specific, while very few GHC hackers actually use Windows, other than to ensure that GHC works on it. Windows is already somewhat of a second-class citizen in Hackage, where platform-sensitive packages tend to only work out-of-the box on Linux. Perhaps it should be "demoted" to second-tier GHC support as well, at least to the extent that Windows bugs won't hold up a release? (I write this as a Windows user who also manages some Linux servers. I agree that Windows support is important, but it seems to be unreasonably "taking" far more than it "gives".) -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Support-on-Windows-tp5746711.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From metaniklas at gmail.com Mon Mar 31 12:57:14 2014 From: metaniklas at gmail.com (Niklas Larsson) Date: Mon, 31 Mar 2014 14:57:14 +0200 Subject: SV: Haskell Support on Windows Message-ID: <53396665.4476700a.4d69.0a09@mx.google.com> Seems to me that a less pessimistic solution would be to set up a windows buildbot. Niklas ----- Ursprungligt meddelande ----- Fr?n: "harry" Skickat: ?2014-?03-?31 14:27 Till: "glasgow-haskell-users at haskell.org" ?mne: Haskell Support on Windows I've been getting the impression that a lot of the stickier GHC bugs are Windows specific, while very few GHC hackers actually use Windows, other than to ensure that GHC works on it. Windows is already somewhat of a second-class citizen in Hackage, where platform-sensitive packages tend to only work out-of-the box on Linux. Perhaps it should be "demoted" to second-tier GHC support as well, at least to the extent that Windows bugs won't hold up a release? (I write this as a Windows user who also manages some Linux servers. I agree that Windows support is important, but it seems to be unreasonably "taking" far more than it "gives".) -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Support-on-Windows-tp5746711.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Mar 31 13:28:07 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 31 Mar 2014 15:28:07 +0200 Subject: Haskell Support on Windows In-Reply-To: <53396665.4476700a.4d69.0a09@mx.google.com> References: <53396665.4476700a.4d69.0a09@mx.google.com> Message-ID: On Mon, Mar 31, 2014 at 2:57 PM, Niklas Larsson wrote: > Seems to me that a less pessimistic solution would be to set up a > windows buildbot. > +1 I believe there's at least one investment bank that uses Haskell on Windows. Perhaps they could set one up. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Mar 31 15:41:10 2014 From: voldermort at hotmail.com (harry) Date: Mon, 31 Mar 2014 08:41:10 -0700 (PDT) Subject: SV: Haskell Support on Windows In-Reply-To: <53396665.4476700a.4d69.0a09@mx.google.com> References: <53396665.4476700a.4d69.0a09@mx.google.com> Message-ID: <1396280470105-5746728.post@n5.nabble.com> Niklas Larsson wrote > Seems to me that a less pessimistic solution would be to set up a windows > buildbot. We need a meatbot who can fix Windows issues in GHC. What's the current state with buildbots? Wondering around the wiki led me to http://darcs.haskell.org/ghcBuilder/builders/, which suggests that nothing's happened since August, and there are a lot of broken bots. -- View this message in context: http://haskell.1045720.n5.nabble.com/SV-Haskell-Support-on-Windows-tp5746713p5746728.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.