Simon's email classified as spam

Dear GHC devs/users

This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder.  Gershom thinks he’s fixed it (below).  Can I trespass on your patience once more?

Just let me know if this email ends up in your inbox or spam.  Can you cc John and Gershom (but perhaps not everyone else)?  Thanks

Simon

 

| From: Gershom B [mailto:gershomb <at> gmail.com]

| Sent: 18 June 2016 18:53

| To: Simon Peyton Jones <simonpj <at> microsoft.com>; John Wiegley

| <johnw <at> newartisans.com>

| Cc: Michael Burge <michaelburge <at> pobox.com>

| Subject: Re: FW: CMM-to-SAM: Register allocation weirdness

|

| Simon — I just found two possible sources of the problem (first: the top

| level config didn’t take hold due to other errors when updating — fixed that,

| and second, it might be possible the top level config isn’t retroactively

| applied to all lists — so i added the config to the relevant lists directly).

|

| I think if you try one more time it might work (fingers crossed).

 

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Simon Peyton Jones | 18 Jun 15:01 2016
Picon
Gravatar

RE: CMM-to-ASM: Register allocation wierdness

Takenobu, and others

Thanks.  Several people have mentioned that email from me is ending up in spam.

It turns out to be a fault in the Haskell.org mailman setup, which was mis-forwarding my email.

Apparently it is fixed now.  If THIS message ends up in spam with a complaint like that below, could you let me know?

Thanks

Simon

                                                                                                                                                                                                                    

From: Takenobu Tani [mailto:takenobu.hs <at> gmail.com]
Sent: 18 June 2016 08:18
To: Simon Peyton Jones <simonpj <at> microsoft.com>
Subject: Re: CMM-to-ASM: Register allocation wierdness

 

Hi Simon,

 

I report to you about your mails.

 

Maybe, your mails don't reach to Gmail users.

I don't know why, but your mails have been distributed to "Spam" folder in Gmail.

 

Gmail displays following message:

  "Why is this message in Spam? It has a from address in microsoft.com but has failed microsoft.com's required tests for authentication."

 

 

For reference, I attach the screen of my Gmail of spam folder.

Recent your mails have been detected as spam.

Please check your mail settings.

 

Regards,

Takenobu

 

2016-06-16 21:10 GMT+09:00 Simon Peyton Jones <simonpj <at> microsoft.com>:

| All-in-all, the graph coloring allocator is in great need of some love;
| Harendra, perhaps you'd like to have a try at dusting it off and perhaps
| look into why it regresses in compiler performance? It would be great if
| we could use it by default.

I second this.   Volunteers are sorely needed.

Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

 

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Harendra Kumar | 12 Jun 20:38 2016
Picon

CMM-to-ASM: Register allocation wierdness

Hi,

I am implementing unicode normalization in Haskell. I challenged myself to match the performance with the best C/C++ implementation, the best being the ICU library. I am almost there, beating it in one of the benchmarks and within 30% for others. I am out of all application level tricks that I could think of and now need help from the compiler.

I started with a bare minimum loop and adding functionality incrementally watching where the performance trips. At one point I saw that adding just one 'if' condition reduced the performance by half. I looked at what's going on at the assembly level. Here is a github gist of the assembly instructions executed in the fast path of the loop, corresponding cmm snippets and also the full cmm corresponding to the loop:


I have annotated the assembly code with labels matching the corresponding CMM.

With the addition of another "if" condition the loop which was pretty simple till now suddenly got bloated with a lot of register reassignments. Here is a snippet of the register movements added:

# _n4se:
# swap r14 <-> r11
=> 0x408d6b: mov    %r11,0x98(%rsp)
=> 0x408d73: mov    %r14,%r11
=> 0x408d76: mov    0x98(%rsp),%r14

# reassignments
# rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx
=> 0x408d7e: mov    %rbx,0x90(%rsp)
=> 0x408d86: mov    %rcx,%rbx
=> 0x408d89: mov    %rdx,%rcx
=> 0x408d8c: mov    %rsi,%rdx
=> 0x408d8f: mov    %rdi,%rsi
=> 0x408d92: mov    %r8,%rdi
=> 0x408d95: mov    %r9,%r8
=> 0x408d98: mov    %r10,%r9
=> 0x408d9b: mov    0x90(%rsp),%r10
.
.
.
loop logic here which uses only %rax, %r10 and %r9 . 
.
.
.
# _n4s8:
# shuffle back to original assignments
=> 0x4090dc: mov    %r14,%r11
=> 0x4090df: mov    %r9,%r10
=> 0x4090e2: mov    %r8,%r9
=> 0x4090e5: mov    %rdi,%r8
=> 0x4090e8: mov    %rsi,%rdi
=> 0x4090eb: mov    %rdx,%rsi
=> 0x4090ee: mov    %rcx,%rdx
=> 0x4090f1: mov    %rbx,%rcx
=> 0x4090f4: mov    %rax,%rbx
=> 0x4090f7: mov    0x88(%rsp),%rax

=> 0x4090ff: jmpq   0x408d2a


The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. 

Maybe this is because these are reusable blocks and the movement is necessary when used in some other path?

Can this be avoided? Or at least avoided in a certain fast path somehow by hinting the compiler? Any pointers to the GHC code will be appreciated. I am not yet much familiar with the GHC code but can dig deeper pretty quickly. But before that I hope someone knowledgeable in this area can shed some light on this at a conceptual level or if at all it can be improved. I can provide more details and experiment more if needed.

Thanks,
Harendra
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Michael Burge | 11 Jun 21:12 2016
Picon

Allow extra commas in module declarations or lists?

Some languages like Perl allow you to include additional commas in your lists, so that you can freely reorder them without worrying about adding or removing commas from the last or first item:

my <at> array = (
  1,
  2,
  3,
);

Perl even allows multiple redundant commas everywhere after the first element, which is less useful but has come up on occasion:
my <at> array = (1,,,2,,,,,,,,,3,,,,,);

I propose allowing an optional single extra comma at the end in module declarations, record declarations, record constructors, and list constructors:

module Example (
  module Example,
  SomeConstructor(..),
  ) where

data SomeConstructor = SomeConstructor {
  foo :: Int,
  bar :: Int,
}

baz :: SomeConstructor -> SomeConstructor
baz x = x {
  foo = 5,
  bar = 10,
}

qux :: [ Int ]
qux = [
  1,
  2,
  3,
]

What do you think?
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Edward Z. Yang | 9 Jun 09:17 2016
Picon
Gravatar

Call for talks: Haskell Implementors Workshop 2016, Sep 24 (FIXED), Nara

(...and now with the right date in the subject line!)

                        Call for Contributions
               ACM SIGPLAN Haskell Implementors' Workshop

    http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
                Nara, Japan, 24 September, 2016

                    Co-located with ICFP 2016
               http://www.icfpconference.org/icfp2016/

Important dates
---------------
Proposal Deadline:  Monday, 8 August, 2016
Notification:       Monday, 22 August, 2016
Workshop:           Saturday, 24 September, 2016

The 8th Haskell Implementors' Workshop is to be held alongside ICFP
2016 this year in Nara. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Scope and target audience
-------------------------

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2016. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-----

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
  https://icfp-hiw16.hotcrp.com/

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
----------

  * Joachim Breitner        (Karlsruhe Institut für Technologie)
  * Duncan Coutts           (Well Typed)
  * Michael Snoyman         (FP Complete)
  * Luite Stegeman          (ghcjs)
  * Niki Vazou              (UCSD)
  * Stephanie Weirich       (University of Pennsylvania) 
  * Edward Z. Yang - chair  (Stanford University)
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Edward Z. Yang | 9 Jun 09:14 2016
Picon
Gravatar

Call for talks: Haskell Implementors Workshop 2016, Aug 24, Nara

                        Call for Contributions
               ACM SIGPLAN Haskell Implementors' Workshop

    http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
                Nara, Japan, 24 September, 2016

                    Co-located with ICFP 2016
               http://www.icfpconference.org/icfp2016/

Important dates
---------------
Proposal Deadline:  Monday, 8 August, 2016
Notification:       Monday, 22 August, 2016
Workshop:           Saturday, 24 September, 2016

The 8th Haskell Implementors' Workshop is to be held alongside ICFP
2016 this year in Nara. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Scope and target audience
-------------------------

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2016. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-----

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
  https://icfp-hiw16.hotcrp.com/

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
----------

  * Joachim Breitner        (Karlsruhe Institut für Technologie)
  * Duncan Coutts           (Well Typed)
  * Michael Snoyman         (FP Complete)
  * Luite Stegeman          (ghcjs)
  * Niki Vazou              (UCSD)
  * Stephanie Weirich       (University of Pennsylvania) 
  * Edward Z. Yang - chair  (Stanford University)
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Adam Foltzer | 3 Jun 23:33 2016
Picon
Gravatar

Feedback on -Wredundant-constraints

With 8.0.1 freshly arrived, I'm taking on the task of updating a number of our larger projects here at Galois. I made a couple of these comments briefly on a relevant Trac ticket[1], but I wanted to open this discussion to a wider audience.

We tend to use -Wall (and -Werror, in CI environments), and so I've had to make decisions about how to handle the new -Wredundant-constraints warnings. So far, I've come to think of it as two different warnings that happen to be combined:

Warning 1: a warning for constraints made redundant by superclass relationships, and
Warning 2: a warning for unused constraints

Overall I'm a fan of Warning 1. It seems very much in the spirit of other warnings such as unused imports. The only stumbling block is how it affects the 3-release compatibility plan with respect to, e.g., the AMP. Most of our code targets a 2-release window, though, so in every such case it has been fine for us to simply remove the offending constraint.

Warning 2 on the other hand is far more dubious to me. In the best case, it finds constraints that through oversight or non-local changes are truly no longer necessary in the codebase. This is nice, but the much more common case in our code is that we've made a deliberate decision to include that constraint as part of our API design.

The most painful example of this I've hit so far is in an API of related functions, where we've put the same constraint on each function even when the implementation of that particular function might not need that constraint. This is good for consistency and forward-looking compatibility (what if we need that constraint in the next version?). The warning's advice in this case makes the API harder to understand, and less abstract (the client shouldn't care or know that f needs Functor, but g doesn't, if both will always be used in a Functor context).

On another level, Warning 2 is a warning that we could have given a more general type to a definition. We quite rightly don't do this for the non-constraint parts of the type signatures, so why are we doing it for the constraints?

I'm happy that Warning 1 is now around, but Warning 2 feels much more like an opinionated lint check, and I really wish it wasn't part of -Wall.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
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

If I remove the type signature for `AddP`, the code goes through. 
Unfortunately, in my real code I need the type signature in order to 
resolve overloading.

GHC 7.10 didn't have this problem.

Is this a bug?

/ Emil
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
"{prefix}/share/doc/ghc-8.0.1/html/libraries/"
mkdir: cannot create directory `doc/aries/ghc-prim-0.5.0.0': No such file or
directory

Is there any way of knowing what the call to mkdir is relative to, and why
it's trying to create the directory there?

--
View this message in context: http://haskell.1045720.n5.nabble.com/Cannot-install-8-0-1-from-bindist-tp5836591.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
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

Gmane