- Glasgow-haskell-users

Re: Type checker plugins
by Adam Gundry 17 Oct '14

17 Oct '14

Thanks Simon, your branch does make it a lot more feasible to unflatten, so I'll just go ahead and implement that in my plugin for now. Eric, that's fair enough, and I don't have any concrete use cases for non-equality constraints at the moment. I'm just keen to minimize the restrictions placed on plugins, because it is much easier to recompile a plugin than make changes in GHC itself! On that note, I still wonder if it would be better to define TcPluginM as a wrapper around TcS rather than TcM. While in principle TcM should suffice, in practice GHC sometimes uses TcS for things that a plugin might want (I've run into TcSMonad.matchFam, which could easily be implemented in TcM instead). Is there any downside to defining a nice API in TcPluginM but providing an escape hatch to TcS, not just TcM? Thanks, Adam On 16/10/14 16:21, Eric Seidel wrote: > Our branch is actually based on yours Simon, are there any changes in the past week that we should pull in for people who want to experiment? > > Adam, we talked about passing other constraints to the plugins, but didn't have a concrete use-case at the time, so we just kept it as simple as possible. I don't see a reason to hide constraints if, as you say, there are plugins that may want to solve them. > > Eric > > Sent from my iPhone > >> On Oct 16, 2014, at 07:08, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: >> >> This will become easier, I think. look on wip/new-flatten-skoelms-Aug14. I'm now unflattening after solving the flat constraints. >> >> Simon >> >> | -----Original Message----- >> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- >> | bounces(a)haskell.org] On Behalf Of Adam Gundry >> | Sent: 16 October 2014 11:59 >> | To: Iavor Diatchki >> | Cc: glasgow-haskell-users(a)haskell.org >> | Subject: Re: Type checker plugins >> | >> | Hi Iavor, >> | >> | >> | On 13/10/14 21:34, Iavor Diatchki wrote: >> | > Hello, >> | > >> | > We now have an implementation of type-checker with plugin support. >> | If >> | > you are interested in trying it out: >> | > >> | > - Checkout and build the `wip/tc-plugins` branch of GHC >> | >> | >> | Thanks, this is great! I'd been working on a similar implementation, >> | but yours is much better integrated. I am trying to adapt my units of >> | measure plugin to work with this interface, and work out what else I >> | need in TcPluginM. >> | >> | One problem I've run into is transforming the flattened CFunEqCans >> | into unflattened form (so the flatten-skolems don't get in the way of >> | AG-unification). Do you know if there is an easy way to do this, or do >> | I need to rebuild the tree manually in the plugin? >> | >> | Also, I notice that you are providing only equality constraints to the >> | plugin. Is there any reason we can't make other types of constraint >> | available as well? For example, one might want to introduce a >> | typeclass with a special solution strategy (cf. Coercible, or the Has >> | class in OverloadedRecordFields). >> | >> | >> | Cheers, >> | >> | Adam >> | >> | >> | > - As an example, I've extracted my work on using an SMT solver at >> | > the type level as a separate plugin: >> | > >> | > https://github.com/yav/type-nat-solver >> | > >> | > - To see how to invoke a module that uses a plugin, have a look >> | in >> | > `examples/A.hs`. >> | > (Currently, the plugin assumes that you have `cvc4` installed >> | and >> | > available in the path). >> | > >> | > - Besides this, we don't have much documentation yet. For >> | hackers: >> | > we tried to use `tcPlugin` on >> | > `TcPlugin` in the names of all things plugin related, so you >> | could >> | > grep for this. The basic API >> | > types and functions are defined in `TcRnTypes` and `TcRnMonad`. >> | > >> | > Happy hacking, >> | > -Iavor -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 7

optimizing StgPtr allocate (Capability *cap, W_ n)
by Bulat Ziganshin 16 Oct '14

16 Oct '14

Hello Glasgow-haskell-users, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rt… if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); /// here starts new improved code: bd = cap->r.rCurrentAlloc; if (bd == NULL || bd->free + n > bd->end) { if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) { .... } if (bd->free + n <= bd->start + BLOCK_SIZE_W) bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD) goto usual_alloc; } .... } /// and here it stops usual_alloc: p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } i think it's obvious - we consolidate two if's on the crirical path into the single one plus avoid one ADD by keeping highly-useful bd->end pointer further improvements may include removing bd==NULL check by initializing bd->free=bd->end=NULL and moving entire "if" body into separate slow_allocate() procedure marked "noinline" with allocate() probably marked as forceinline: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); bd = cap->r.rCurrentAlloc; if (bd->free + n > bd->end) return slow_allocate(cap,n); p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } this change will greatly simplify optimizer's work. according to my experience current C++ compilers are weak on optimizing large functions with complex execution paths and such transformations really improve the generated code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

status of rebindable syntax for arrows
by S. Doaitse Swierstra 15 Oct '14

15 Oct '14

The GHC manual already for quite a number of version states: • Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! When using this feature we get the error: "Var/Type length mismatch: [s{tv aVL} [tv]] [] ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): tcTyVarDetails s{tv aVL} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug" So our question is whether we should really report this as a bug, and/or what we can do about this. Thanks for your help, Doaitse

3 2

The future of the haskell2010/haskell98 packages - AKA Trac #9590
by Austin Seipp 14 Oct '14

14 Oct '14

Hello developers, users, friends, I'd like you all to weigh in on something - a GHC bug report, that has happened as a result of making Applicative a superclass of Monad: https://ghc.haskell.org/trac/ghc/ticket/9590 The very condensed version is this: because haskell2010/haskell98 packages try to be fairly strictly conforming, they do not have modules like Control.Applicative. Unfortunately, due to the way these packages are structured, many things are simply re-exported from base, like `Monad`. But `Applicative` is not, and cannot be imported if you use -XHaskell2010 and the haskell2010 package. The net result here is that haskell98/haskell2010 are hopelessly broken in the current state: it's impossible to define an instance of `Monad`, because you cannot define an instance of `Applicative`, because you can't import it in the first place! This leaves us in quite a pickle. So I ask: Friends, what do you think we should do? I am particularly interested in users/developers of current Haskell2010 packages - not just code that may *be* standard Haskell - code that implies a dependency on it. There was a short discussion between me and Simon Marlow about this in the morning, and again on IRC this morning between me, Duncan, Edward K, and Herbert. Basically, I only see one of two options: - We could make GHC support both: a version of `Monad` without `Applicative`, and one with it. This creates some complication in the desugarer, where GHC takes care of `do` syntax (and thus needs to be aware of `Monad`'s definition and location). But it is, perhaps, quite doable. - We change both packages to export `Applicative` and follow the API changes in `base` accordingly. Note that #1 above is contingent on three things: 1) There is interest in this actually happening, and these separate APIs being supported. If there is not significant interest in maintaining this, it's unclear if we should go for it. 2) It's not overly monstrously complex (I don't think it necessarily will be, but it might be.) 3) You can't like `haskell2010` packages and `base` packages together in the general case, but, AFAIK, this wasn't the case before either. I'd really appreciate your thoughts. This must be sorted out for 7.10 somehow; the current situation is hopelessly busted. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 7

Dependencies missing when building ghc.
by Magicloud Magiclouds 14 Oct '14

14 Oct '14

Hi, I am with my new Ubuntu Trusty box. I have installed ghc by apt-get. Then I wanted to build ghc from git to upgrade to 7.8.3. I did following commands. I tried 'make clean', or reget the source. No luck yet. $ git clone --recursive git://git.haskell.org/ghc.git $ ./sync-all -r git://git.haskell.org remote set-url origin $ git checkout ghc-7.8.3-release $ ./sync-all get $ rm -r libraries/time # as prompted by sync-all $ ./sync-all get $ ./boot $ ./configure $ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds "inplace/bin/ghc-cabal" check libraries/haskell98 "inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install "" --with-ghc="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="/usr/bin/ranlib" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring haskell98-2.0.0.4... ghc-cabal: At least the following dependencies are missing: base ==4.8.* make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 4

Aliasing current module qualifier
by Herbert Valerio Riedel 30 Sep '14

30 Sep '14

Hello *, Here's a situation I've encountered recently, which mades me wish to be able to define a local alias (in order to avoid CPP use). Consider the following stupid module: module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null ) where length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . AnnoyinglyLongModuleName.length Now it'd be great if I could do the following instead: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglyLongModuleName as M -- <- does not work length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . M.length However, if I try to compile this, GHC complains about AnnoyinglyLongModuleName.hs:4:1: Bad interface file: AnnoyinglyLongModuleName.hi AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) while GHCi tells me: Module imports form a cycle: module ‘AnnoyinglyLongModuleName’ (AnnoyinglyLongModuleName.hs) imports itself Is there some other way (without CPP) to create a local alias for the current module-name? If not, is there a reason GHC couldn't support this special case of self-aliasing the current module name? PS: Alternatively, this could be done as a language extension but that'd require extending the Haskell grammar: module AnnoyinglyLongModuleName as M (M.length, M.null) where Cheers, hvr

7 8

Re: Permitting trailing commas for record syntax ADT declarations
by John Wiegley 29 Sep '14

29 Sep '14

>>>>> Richard Eisenberg <eir(a)cis.upenn.edu> writes: > What if we just stopped requiring commas in import/export lists? As far as I > can tell, they're not necessary for proper parsing. +1 John

5 6

__GLASGOW_HASKELL__=708?
by Greg Fitzgerald 26 Sep '14

26 Sep '14

Using GHC 7.8.3 from the latest Haskell Platform on OS X 10.9.4, the __GLASGOW_HASKELL__ preprocessor symbol is being set to 708 instead of 783. I'd guess I have some stale files lying from previous versions GHC or HP, but I can't seem to find them. Any clues? $ cat wtf.hs {-# LANGUAGE CPP #-} $ ghc-7.8.3 -v -E wtf.hs 2>&1 | grep 708 /usr/bin/gcc -E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -I /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/base-4.7.0.1/include -I /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/integer-gmp-0.5.1.0/include -I /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/include '-D__GLASGOW_HASKELL__=708' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp wtf.hs -o /var/folders/w7/_cxvr2k540163p59kwvqlzrc0000gn/T/ghc14288_0/ghc14288_1.hscpp Thanks, Greg

2 2

Re: Preliminary proposal: Monoidal categories in base and proc notation support
by John Wiegley 15 Sep '14

15 Sep '14

>>>>> Sophie Taylor <sophie(a)traumapony.org> writes: > I am working on a proposal for some additions to the base library and some > modifications to GHC in the same style as the do notation support for > Applicatives. It is still very much a work in progress, but any input/ > constructive criticism would be greatly appreciated; this is the first one of > these I've written. Hi Sophie, The work you've proposed has an almost direct overlap with Edward Kmett's recent work in his "hask" library, so I'd prefer to see the dust settle out there to determine what the nicest interface could be. In particular Ed has discovered some nice expressions involving curried bifunctors that would be a shame to miss out on. As Simon said, this really should go to the libraries mailing list, where Edward is sure to weigh in. John

1 0

Re: win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux
by Mikolaj Konarski 12 Sep '14

12 Sep '14

(cross-com^H^H^Hposting to glasgow-haskell-users(a)haskell.org) Well, sorf-of. A few extra unobvious parameters and workarounds are required in each case, but it's doable, (arguably) simpler than real cross-compilation and already exhibits problems that real cross-compilation may in some circumstances face. Wiki pages (kudos to all previous authors): http://www.haskell.org/haskellwiki/GHC_under_Wine https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64 Examples of both kinds of binaries, for a project with gtk2hs and TH dependency: https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0 Please share your success reports here or on the wiki and let's exchange ideas, file concrete tickets and propose patches to make the two processes more accessible. Some tickets are mentioned in the wikis or can be traced from there, but there may be others I'm not aware of, so let's link them where appropriate. Hope this helps somebody, Mikolaj

1 0