Emil Axelsson | 26 May 17:27 2016
Picon
Picon
Gravatar

Pattern synonyms and GADTs in GHC 8.0.1

I have a problem where a pattern synonym doesn't provide the expected 
type refinement in GHC 8.0.1.

> {-# LANGUAGE GADTs #-}
> {-# LANGUAGE PatternSynonyms #-}
>
> data Exp a
>   where
>     Num :: (Eq a, Num a) => a -> Exp a
>     Add :: (Eq a, Num a) => Exp a -> Exp a -> Exp a
>
> pattern NumP a = Num a
>
> pattern AddP :: (Num a, Eq a) => Exp a -> Exp a -> Exp a
> pattern AddP a b = Add a b
>
> simplifyP :: Exp a -> Exp a
> simplifyP (AddP a (NumP 0)) = a
> simplifyP a                 = a

This gives the error

     • No instance for (Eq a) arising from a pattern
       Possible fix:
         add (Eq a) to the context of
           the type signature for:
             simplifyP :: Exp a -> Exp a
     • In the pattern: AddP a (NumP 0)
       In an equation for ‘simplifyP’: simplifyP (AddP a (NumP 0)) = a

(Continue reading)

Peter | 25 May 13:55 2016
Picon

Cannot install 8.0.1 from bindist

Trying to install ghc-8.0.1-x86_64-centos67-linux.tar.xz with:

  ./configure --prefix={prefix}
  make install-strip

gives me an error. The tail of the log is:

Registering ghc-8.0.1...
for f in '{prefix}/lib/ghc-8.0.1/package.conf.d'/*; do create () { touch
"$1" && chmod 644 "$1" ; } && create "$f"; done
/usr/bin/install -c -m 755 -d "{prefix}/bin"
for i in utils/hp2ps/dist/build/tmp/hp2ps; do \
		/usr/bin/install -c -m 755 -s  $i "{prefix}/bin" ;  \
	done
/usr/bin/install -c -m 755 -d "{prefix}/lib/ghc-8.0.1/bin"
for i in inplace/lib/bin/ghc-split; do \
		/usr/bin/install -c -m 755  $i "{prefix}/lib/ghc-8.0.1/bin"; \
	done
/usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1"
/usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1/html"
/usr/bin/install -c -m 644  docs/index.html
"{prefix}/share/doc/ghc-8.0.1/html"
/usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1/html/libraries"
for i in libraries/dist-haddock/*; do \
		/usr/bin/install -c -m 644  $i
"{prefix}/share/doc/ghc-8.0.1/html/libraries/"; \
	done
/usr/bin/install -c -m 644  libraries/prologue.txt
"{prefix}/share/doc/ghc-8.0.1/html/libraries/"
/usr/bin/install -c -m 755  libraries/gen_contents_index
(Continue reading)

Jeremy | 16 May 14:39 2016
Picon

TDNR without new operators or syntax changes

Previous attempts to propose TDNR [1] have met with opposition over the
accompanying proposal to change the syntax of the dot or add a new operator
for postfix application.

However, nothing about TDNR - other than certain motivating examples -
actually requires changes to the syntax of Haskell or new operators. TDNR
could be implemented as an extension which just give GHC a new way of
disambiguating function names, and nothing else. This would still have some
advantages:

 - Redundant module qualification no longer required.
 - Unqualified imports could be changed to a different module with the same
interface (a very poor-man's backpack) without any other code changes.
 - People who want TDNR with postfix function application will only need to
define a simple postfix operator.

I would therefore like to propose TNDR without any syntax/prelude changes.

[1] https://prime.haskell.org/wiki/TypeDirectedNameResolution

--
View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
Harendra Kumar | 9 May 16:23 2016
Picon

suboptimal ghc code generation in IO vs equivalent pure code case

I have a loop which runs millions of times. For some reason I have to run it in the IO monad. I noticed that when I convert the code from pure to IO monad the generated assembly code in essence is almost identical except one difference where it puts a piece of code in a separate block which is making a huge difference in performance (4-6x slower).

I want to understand what makes GHC to generate code in this way and if there is anything that can be done at source level (or ghc option)  to control that.

The pure code looks like this:

        decomposeChars :: [Char] -> [Char]

        decomposeChars [] = []
        decomposeChars [x] =
            case NFD.isDecomposable x of
                True -> decomposeChars (NFD.decomposeChar x)
                False -> [x]
        decomposeChars (x : xs) = decomposeChars [x] ++ decomposeChars xs

The equivalent IO code is this:

        decomposeStrIO :: [Char] -> IO [Char]

        decomposeStrPtr !p = decomposeStrIO
            where
                decomposeStrIO [] = return []
                decomposeStrIO [x] = do
                    res <- NFD.isDecomposable p x
                    case res of
                        True -> decomposeStrIO (NFD.decomposeChar x)
                        False -> return [x]
                decomposeStrIO (x : xs) = do
                    s1 <- decomposeStrIO [x]
                    s2 <- decomposeStrIO xs
                    return (s1 ++ s2)

The difference is in how the code corresponding to the call to the (++) operation is generated. In the pure case the (++) operation is inline in the main loop:

_cn5N:
movq $sat_sn2P_info,-48(%r12)
movq %rax,-32(%r12)
movq %rcx,-24(%r12)
movq $:_con_info,-16(%r12)
movq 16(%rbp),%rax
movq %rax,-8(%r12)
movq $GHC.Types.[]_closure+1,(%r12)
leaq -48(%r12),%rsi
leaq -14(%r12),%r14
addq $40,%rbp
jmp GHC.Base.++_info

In the IO monad version this code is placed in a separate block and a call is placed in the main loop:

the main loop call site:

_cn6A:
movq $sat_sn3w_info,-24(%r12)
movq 8(%rbp),%rax
movq %rax,-8(%r12)
movq %rbx,(%r12)
leaq -24(%r12),%rbx
addq $40,%rbp
jmp *(%rbp)

out of the line block - the code that was in the main loop in the previous case is now moved to this block (see label _cn5s below):

sat_sn3w_info:
_cn5p:
leaq -16(%rbp),%rax
cmpq %r15,%rax
jb _cn5q
_cn5r:
addq $24,%r12
cmpq 856(%r13),%r12
ja _cn5t
_cn5s:
movq $stg_upd_frame_info,-16(%rbp)
movq %rbx,-8(%rbp)
movq 16(%rbx),%rax
movq 24(%rbx),%rbx
movq $:_con_info,-16(%r12)
movq %rax,-8(%r12)
movq $GHC.Types.[]_closure+1,(%r12)
movq %rbx,%rsi
leaq -14(%r12),%r14
addq $-16,%rbp
jmp GHC.Base.++_info
_cn5t:
movq $24,904(%r13)
_cn5q:
jmp *-16(%r13)

Except this difference the rest of the assembly looks pretty similar in both the cases. The corresponding dump-simpl output for the pure case:

          False ->
            ++
              <at> Char
              (GHC.Types.: <at> Char ww_amuh (GHC.Types.[] <at> Char))
              (Data.Unicode.Internal.Normalization.decompose_$sdecompose
                 ipv_smuv ipv1_smuD);

And for the IO monad version:

                False ->
                  case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU
                  of _ [Occ=Dead] { (# ipv4_XmXv, ipv5_XmXx #) ->
                  (# ipv4_XmXv,
                     ++
                        <at> Char
                       (GHC.Types.: <at> Char sc_sn0b (GHC.Types.[] <at> Char))
                       ipv5_XmXx #)
                  };

The dump-simpl output is essentially the same except the difference due to the realworld token in the IO case. Why is the generated code different? I will appreciate if someone can throw some light on the reason or can point to the relevant ghc source to look at where this happens.

I am using ghc-7.10.3 in native code generation mode (no llvm).

Thanks,
Harendra
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Erik de Castro Lopo | 6 May 11:04 2016

RFC: Removing the `-hb` profiling option

Hi all,

After a bit of rather tedious and frustrating debugging I came to the
realisation that the code for the `-hb` profiling option is not thread
safe. See https://ghc.haskell.org/trac/ghc/ticket/12019

This gives us an opportunity to simply remove it instead of fixing it.
If there is anyone that thinks this future is really useful (ie more
useful than the other profiling modes) then I'm willing to fix it.
But if noone would miss it. I'd much rather remove it.

Thoughts?

Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
Volker Wysk | 5 May 21:19 2016
Picon

What happened to -optdep option?

Hello!

I'm using GHC 7.10.3 after an upgrade. I have the following in my Makefile:

depend_mod :: lib/abh
	ghc -M $(CFLAGS_GHC_0) -dep-makefile -optdepbuild/depend.tmp -dep-suffix "p_" 
\
	       $(foreach m, $(MOD_HS) $(PROG_HS), src/$(m).hs) \
	       $(foreach m, $(MOD_CHS) $(PROG_CHS), build/$(m).hs)
        ...

This used to work. The previous GHC version was 7.8. 

Now GHC complains:

-optdepbuild/depend.tmp: openBinaryFile: does not exist (No such file or 
directory)

This looks like the -optdep argument isn't understood. There is no mention of 
it in the new/7.10.3 user manual. I don't know any longer what this "-optget" 
argument does, and it isn't in the documentation any longer.

I googled the GHC web site. There it is mentioned that -optdep was deprecated, 
but almost all of the hits are very outdated (like ten years old).

Can soneone tell me, how I should change my Makefile..?

Greetings,
Volker Wysk
Ben Gamari | 28 Apr 11:10 2016

[ANNOUNCE] GHC 8.0.1 release candidate 4 available


Hello Haskellers,

The GHC team is happy to announce the availability of fourth release
candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and
binary distributions can be found at,

    http://downloads.haskell.org/~ghc/8.0.1-rc4/

This is the last of four candidates leading up to the 8.0.1 release,
addressing nearly all of the known issues of the previous candidates.
These include,

  * A type-checker panic triggered by use of Typeable on a
    kind-polymorphic type constructor (#11334)

  * A type-checker explosion where -XTypeInType would gobble up massive
    amounts of memory when used in a data instance (#11407)

  * A variety of other typechecker issues (#11811, #11797, #11813,
    #11814)

  * A build issue seen on OS X (#11828)

  * Template Haskell can now produce instances with
    OVERLAPP{ING,ABLE,ED} pragmas

  * Autoconf has improved version checks for libdw (#11820)

  * Typeable and hs-boot files now interact nicely (#11824)

  * The build system now checks for the broken Apple `nm` utility
    (#11823, #11744)

  * Various issues involving unexpected laziness resulting in exception
    handlers not being invoked (#11555)

  * GHC now fails more gracefully when used with an older cabal-install
    release (#11558)

  * TypeInType now has proper documentation in the users guide (#11614)

  * The story surrounding type `RuntimeRep`s (formerly known as
    `Levity`) is now far better developed, closing several doors to
    unsafe behavior that TypeInType previously opened (#11473, #11723)

  * A long-standing bug in the constant-folding rules for `mod` for the
    `Word` type has been resolved (#11702)

  * Various issues introduced by OverloadedRecordFields have been fixed
    (#11662, #11401) 

  * A regression in the typechecker resulting in the rejection of code
    in the `free` and `microlens` packages has been fixed (#11608)

  * A bug in the LLVM code generator which caused some programs to emit
    unbuildable LLVM IR has been fixed (#11649)

  * A bug where pattern synonyms defined in terms of a pattern match on
    a record would be rejected if the fields weren't written in the same order
    as they were defined has been resolved (#11633)

  * A bug in the runtime system's treatment of weak references which
    could result in segmentation faults in some cases has been fixed (#11108)

  * a variety of optimizations improving compiler performance have been
    merged

  * and many others

Mac OS X users should be aware that the recent XCode 7.3 release ships
with a broken `nm` utility which breaks the GHC build (#11744, #11823).
The build system will check for this condition and request that the tree
is configured to use the `nm-classic` utility if found. OS X users
running XCode 7.3 are encouraged to open a ticket with Apple so that
this issue may be fixed in future XCode releases.

If no major issues pop up we expect that this will be the last release
candidate before the final release, which we hope to push out in the
coming weeks. Thanks to everyone who has contributed code, testing,
builds, and bug reports thusfar!

Cheers and happy testing,

- Ben
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
AntC | 26 Apr 10:20 2016
Picon

Magic classes for Overloaded Record Fields, overlaps, FunDeps

There's an intriguing comment here wrt anonymous records:
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/
MagicClasses#Designextension:anonymousrecords
(End of the section)

"... this doesn't quite work, because the two instances overlap,
 but it is possible with a bit more trickery"

I could well understand if everybody's forgotten what was the "trickery", 
because ORF has been so long in the pipeline, but could anyone explain?

Reason for the q: I'm looking at anonymous records myself,
 including extending, shortening and joining anon records. 
And yes overlapping instances are everywhere.

Using type families isn't being too ergonomic. And I notice ORF has used FunDeps.
But for me, FunDeps in the HList style is also rather ugly.

Is there some trickery I'm missing?

Thanks
AntC
John Williams | 18 Mar 19:27 2016
Picon

idea: tool to suggest adding imports

I have an idea for a tool I'd like to implement, and I'm looking for advice on the best way to do it.

Ideally, I want to write an Emacs extension where, if I'm editing Haskell code and I try to use a symbol that's not defined or imported, it will try to automatically add an appropriate import for the symbol. If instance, if I have "import Data.Maybe (isNothing)" in my module, and I try to call "isJust", the extension would automatically change the import to "import Data.Maybe (isJust, isNothing)".

The Emacs part is easy, but the Haskell part has me kind of lost. Basically I want to figure out how to heuristically resolve a name, using an existing set of imports as hints and constraints. The main heuristic I'd like to implement is that, if some symbols are imported from a module M, consider importing additional symbols from M. A more advanced heuristic might suggest that if a symbol is exported from a module M in a visible package P, the symbol should be imported from M. Finally, if a symbol is exported by a module in the Haskell platform, I'd like to suggest adding the relevant package as a dependency in the .cabal and/or stack.yaml file, and adding an import for it in the .hs file.

Here are some implementation options I'm considering:

1. Add a ghci command to implement my heuristics directly, since ghc already understands modules, packages and import statements.
2. Load a modified version of the source file into ghci where imports like "import M (...)" are replaced with "import M", and parse the error messages about ambiguous symbols.
3. Write a separate tool that reads Haskell imports and duplicates ghc and cabal's name resolution mechanisms.
4. Write a tool that reads Haskell imports and suggests imports from a list of commonly imported symbols, ignoring which packages are actually visible.

Right now the options that look best to me are 2 and 4, because the don't require me to understand or duplicate big parts of ghc, but if modifying ghc isn't actually that hard, then maybe 1 is the way to go. Option 3 might be a good way to go if there are libraries I can use to do the hard work for me.

Any thoughts?
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Tom Sydney Kerckhove | 16 Feb 18:12 2016
Picon

[Feedback requested]: -fhelpful-import-errors

Hi,

I raised a ticket to request a new feature: -fhelpful-import-errors.

This flag should enable helpful errors if there are typo's in the
internal imports of your projects.

As suggested by `thomie`, I created a design proposal at
https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError
and am now looking for feedback.

Thank you for your time.

--

-- 
Tom Sydney Kerckhove
Evan Laforge | 15 Feb 01:32 2016
Picon

LANGUAGE ConstraintKinds not needed to use ConstraintKinds?

I recently upgraded to ghc 8 and started using stacks via
ImplicitParams.  For that I wind up using 'type Stack = (?stack ::
CallStack)' and so ContraintKinds (I see that in the future GHC will
do this by default).

So now I can have a file like:

module T where
import qualified Log as Log

f :: Log.Stack => IO ()
f = Log.warn "blah blah"

I noticed that now haskell-src-exts refuses to parse this file, saying
'MultiParamTypeClasses language extension is not enabled.'.

I assume it's a bug with haskell-src-exts in that it should require
LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want
ConstraintKinds.  Instead, it wants FlexibleContexts.  From the docs,
FlexibleContexts seems to be about the contexts in instance heads.

Is this intentional?  I'll go ahead and make a bug for
haskell-src-exts, but the ghc behaviour here seems odd as well.  What
extension should haskell-src-exts require to parse this?

Gmane