Re: What could be the possible reason of linking errors on _info and _closure?
Sorry, my mistake. I had a misunderstanding of cabal file that I did not expose enough modules. On Mon, Feb 2, 2015 at 5:27 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I am making a cabal project including a library and a executable using the library. Building the library is fine. But when linking src/main, I got undefined reference to someFunction1_info and someFunction1_closure. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What could be the possible reason of linking errors on _info and _closure?
Hi, I am making a cabal project including a library and a executable using the library. Building the library is fine. But when linking src/main, I got undefined reference to someFunction1_info and someFunction1_closure. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
On Mon, Feb 2, 2015 at 9:37 AM, Herbert Valerio Riedel h...@gnu.org wrote: Hi Mark, On 2015-01-28 at 04:31:29 +0100, Mark Lentczner wrote: I've just built a bindist under 10.10, but just normal not expressly llvm. I'll test this in a bit then post it -- but might be sometime tomorrow before it is up. How's progress on this btw? Are you also working on a GHC 7.8.4 OSX bindist by any chance? I made a bindist of RC2 (just like I did for RC1) which is here [1]. This was built on 10.9, without anything special for llvm. If anyone wants me to try something or produce a different build, please let me know. Erik [1] https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nVmJ3WElQZW81b1Uexport=download ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Restricted Template Haskell
I would like to figure out how to improve the state of TTH documentation. The GHC wiki is usually for things that are changing, and the page is written in that future style, so it makes one wonder if all things are finished or if some things remain unfinished. Some this is how it is documentation in the user guide would seem more useful now. But I am not sure if the user guide [1] is even correct because it indicates a type of `Q (TExp a)` where I would expect just `TExp a` from reading the wiki [2]. [1] https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/template-haskell.html [2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges On Mon, Feb 2, 2015 at 11:31 AM, Greg Weber g...@gregweber.info wrote: Hi Simon, I am just starting the proposal: gathering interested parties and pointers to related information. Thanks for the pointer to Typed Template Haskell. I was actually unaware of the extent to which Typed Template Haskell is restricted. I have not seen any usage of Typed Template Haskell in the wild or been able to use it myself unfortunately due to backwards compatibility needs (once the next GHC release is out libraries will start to consider dropping 7.6 support and we will see more usage, although Ubuntu still ships 7.6 by default). I will study Typed Template Haskell. Greg Weber On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones simo...@microsoft.com wrote: The new TH is already split into two parts https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal as I’m sure you know · Typed TH is for expressions only, and doesn’t have reify, nor any Q monad. · Untyped TH is the wild west Typed TH may get some of what you want? Certainly you want to acknowledge the existing split in your own design. The proposal could do with examples to illustrate what the difficulties are. What bad things happen in the Q monad? Can you give examples of reasoning that would be valid in level 1 but not in level 2. etc. More precision please! Simon *From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Greg Weber *Sent:* 30 January 2015 23:39 *To:* ghc-d...@haskell.org; GHC users *Cc:* David Terei; Maxwell Swadling *Subject:* Restricted Template Haskell Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stream fusion, concatMap, exisential seed unboxing
I think it'd help you to open a Trac ticket, give a fully-reproducible test
case, including instructions for how to reproduce, and say what isn't happening
that should happen.
What's odd is that loop_s29q looks strict in its Int arg, yet isn't unboxed.
There is a way to get the strictness analysis to run twice -flate-dmd-anal.
You could try that.
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
| Sent: 01 February 2015 12:18
| To: Glasgow-Haskell-Users
| Subject: stream fusion, concatMap, exisential seed unboxing
|
| Hi everybody,
|
| I'm playing around with concatMap in stream fusion (the vector package
| to be exact).
|
| concatMapM :: Monad m = (a-m (Stream m b)) - Stream m a - Stream m
| b concatMapM f (Stream ...) = ...
|
| I can get my concatMap to behave nicely and erase all Stream and Step
| constructors but due to the existential nature of the Stream seeds,
| they are re-boxed for the inner stream (which is kind-of annoying
| given that the seed is immediately unboxed again ;-). seq doesn't help
| here.
|
| Otherwise, fusion happens for streams and vectors, so that is ok. But
| boxing kills performance, criterion says.
|
| Do we have s.th. in place that could help here? Currently I could use
| the vector-concatMap which creates intermediate arrays, my version
| which has boxed seeds, or hermit but that is too inconvenient for non-
| ghc savy users.
|
| Viele Gruesse,
| Christian
|
|
|
| Fusing concatMapM:
|
| concatMapM f (SM.Stream ostep t _) = SM.Stream step (Left t) Unknown
|where step (Left t) = do r - ostep t
| case r of
| SM.Done - return $ SM.Done
| SM.Skipt' - return $ SM.Skip (Left
| t')
| SM.Yield a t' - do s - f a
| return $ SM.Skip
| (Right (s,t'))
| step (Right (SM.Stream istep s _,t)) = do r - istep s
|case r of
| SM.Done -
| return $ SM.Skip(Left t)
| SM.Skips' -
| return $ SM.Skip(Right (SM.Stream istep s' Unknown,t))
| SM.Yield x s' -
| return $ SM.Yield x (Right (SM.Stream istep s' Unknown,t))
| {-# INLINE [0] step #-}
| {-# INLINE [1] concatMapM #-}
|
| testConcatMapM :: Int - Int
| testConcatMapM k = seq k $ U.unId
| . SM.foldl' (+) 0
| . concatMap (\i - SM.enumFromTo 5 k)
| $ SM.enumFromTo 3 k
| {-# NOINLINE testConcatMapM #-}
|
| CORE:
|
| testConcatMapM
| testConcatMapM =
|\ k_aCA -
| let! { I# ipv_s1xv ~ _ - k_aCA } in ### inner loop
| letrec {
|$s$wfoldlM'_loop_s29q
|$s$wfoldlM'_loop_s29q =
| \ sc_s29i sc1_s29j sc2_s29k -
| ### unboxing
|let! { I# x_a1LA ~ _ - sc1_s29j } in
|case tagToEnum# (=# x_a1LA ipv_s1xv) of _ {
| False - $s$wfoldlM'_loop1_s29c sc_s29i sc2_s29k;
| True -
|$s$wfoldlM'_loop_s29q
| ### reboxing
| (+# sc_s29i x_a1LA) (I# (+# x_a1LA 1)) sc2_s29k
|};
| ### outer loop
|$s$wfoldlM'_loop1_s29c
|$s$wfoldlM'_loop1_s29c =
| \ sc_s29a sc1_s29b -
|case tagToEnum# (=# sc1_s29b ipv_s1xv) of _ {
| False - sc_s29a;
| True -
|case tagToEnum# (=# 5 ipv_s1xv) of _ {
| False - $s$wfoldlM'_loop1_s29c sc_s29a (+# sc1_s29b
| 1); ### boxed seed (I# 6)
| True - $s$wfoldlM'_loop_s29q (+# sc_s29a 5) (I# 6)
| (+# sc1_s29b 1)
|}
|}; } in
| let! { __DEFAULT ~ ww_s20G - $s$wfoldlM'_loop1_s29c 0 3 } in
| I# ww_s20G
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stream fusion, concatMap, exisential seed unboxing
Sure, no problem!
Btw. this is not a 'bug' in the usual sense. It is the (neverending)
concatMap + stream fusion story.
https://ghc.haskell.org/trac/ghc/ticket/915
I'm playing a bit with trying to get GHC to look through the existential
seed elements and have it constructor-specialize them.
Unfortunately, unbox/spec fails with more complex seeds for now. For the more
simple cases like the one below, the extra strictness pass works (cool,
thanks!). These are sometimes enough if you have just
concatMap (\i - [i .. j]) stuff.
However, if the internal stream state is, say, a pair (i,j), then one of
those is not completely unboxed. I guess that *if* we could get the
passes to continue unbox'ing and ctor-spec'ing, we could end up with a
fully fused concatMap.
I'll put a complete git repository with criterion + quickcheck modules
up (soonishly ;-).
Viele Gruesse,
Christian
* Simon Peyton Jones simo...@microsoft.com [02.02.2015 15:49]:
I think it'd help you to open a Trac ticket, give a fully-reproducible test
case, including instructions for how to reproduce, and say what isn't
happening that should happen.
What's odd is that loop_s29q looks strict in its Int arg, yet isn't unboxed.
There is a way to get the strictness analysis to run twice -flate-dmd-anal.
You could try that.
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
| Sent: 01 February 2015 12:18
| To: Glasgow-Haskell-Users
| Subject: stream fusion, concatMap, exisential seed unboxing
|
| Hi everybody,
|
| I'm playing around with concatMap in stream fusion (the vector package
| to be exact).
|
| concatMapM :: Monad m = (a-m (Stream m b)) - Stream m a - Stream m
| b concatMapM f (Stream ...) = ...
|
| I can get my concatMap to behave nicely and erase all Stream and Step
| constructors but due to the existential nature of the Stream seeds,
| they are re-boxed for the inner stream (which is kind-of annoying
| given that the seed is immediately unboxed again ;-). seq doesn't help
| here.
|
| Otherwise, fusion happens for streams and vectors, so that is ok. But
| boxing kills performance, criterion says.
|
| Do we have s.th. in place that could help here? Currently I could use
| the vector-concatMap which creates intermediate arrays, my version
| which has boxed seeds, or hermit but that is too inconvenient for non-
| ghc savy users.
|
| Viele Gruesse,
| Christian
|
|
|
| Fusing concatMapM:
|
| concatMapM f (SM.Stream ostep t _) = SM.Stream step (Left t) Unknown
|where step (Left t) = do r - ostep t
| case r of
| SM.Done - return $ SM.Done
| SM.Skipt' - return $ SM.Skip (Left
| t')
| SM.Yield a t' - do s - f a
| return $ SM.Skip
| (Right (s,t'))
| step (Right (SM.Stream istep s _,t)) = do r - istep s
|case r of
| SM.Done -
| return $ SM.Skip(Left t)
| SM.Skips' -
| return $ SM.Skip(Right (SM.Stream istep s' Unknown,t))
| SM.Yield x s' -
| return $ SM.Yield x (Right (SM.Stream istep s' Unknown,t))
| {-# INLINE [0] step #-}
| {-# INLINE [1] concatMapM #-}
|
| testConcatMapM :: Int - Int
| testConcatMapM k = seq k $ U.unId
| . SM.foldl' (+) 0
| . concatMap (\i - SM.enumFromTo 5 k)
| $ SM.enumFromTo 3 k
| {-# NOINLINE testConcatMapM #-}
|
| CORE:
|
| testConcatMapM
| testConcatMapM =
|\ k_aCA -
| let! { I# ipv_s1xv ~ _ - k_aCA } in ### inner loop
| letrec {
|$s$wfoldlM'_loop_s29q
|$s$wfoldlM'_loop_s29q =
| \ sc_s29i sc1_s29j sc2_s29k -
| ### unboxing
|let! { I# x_a1LA ~ _ - sc1_s29j } in
|case tagToEnum# (=# x_a1LA ipv_s1xv) of _ {
| False - $s$wfoldlM'_loop1_s29c sc_s29i sc2_s29k;
| True -
|$s$wfoldlM'_loop_s29q
| ### reboxing
| (+# sc_s29i x_a1LA) (I# (+# x_a1LA 1)) sc2_s29k
|};
| ### outer loop
|$s$wfoldlM'_loop1_s29c
|$s$wfoldlM'_loop1_s29c =
| \ sc_s29a sc1_s29b -
|case tagToEnum# (=# sc1_s29b ipv_s1xv) of _ {
| False - sc_s29a;
| True -
|case tagToEnum# (=# 5 ipv_s1xv) of _ {
| False - $s$wfoldlM'_loop1_s29c sc_s29a (+# sc1_s29b
| 1); ### boxed seed (I# 6)
| True - $s$wfoldlM'_loop_s29q (+# sc_s29a 5) (I# 6)
| (+# sc1_s29b 1)
|
Re: stream fusion, concatMap, exisential seed unboxing
Yes,
I'm kinda hoping that fusion-interested folks might have a comment.
Both QuickCheck and Criterion are completely optional. It depends only
on base and vector. I'm keeping vector for now, as this allows me to
observe if intermediate vectors are fused away, too.
Viele Gruesse,
Christian
* Simon Peyton Jones simo...@microsoft.com [02.02.2015 18:09]:
Ah, well, if it's really the concat/concatMap problem then I'm really not
sure how to crack it.
But there are lots of smart people on this list, so maybe someone else can.
The fewer dependencies your test case has the better. eg Don't use
criterion; this stuff is huge: you get 10G of allocation in your test run
instead of 10M. Or something.
Simon
| -Original Message-
| From: Christian Höner zu Siederdissen
| [mailto:choe...@tbi.univie.ac.at]
| Sent: 02 February 2015 16:02
| To: Simon Peyton Jones
| Cc: Glasgow-Haskell-Users
| Subject: Re: stream fusion, concatMap, exisential seed unboxing
|
| Sure, no problem!
|
| Btw. this is not a 'bug' in the usual sense. It is the (neverending)
| concatMap + stream fusion story.
| https://ghc.haskell.org/trac/ghc/ticket/915
| I'm playing a bit with trying to get GHC to look through the
| existential seed elements and have it constructor-specialize them.
|
| Unfortunately, unbox/spec fails with more complex seeds for now. For
| the more simple cases like the one below, the extra strictness pass
| works (cool, thanks!). These are sometimes enough if you have just
| concatMap (\i - [i .. j]) stuff.
|
| However, if the internal stream state is, say, a pair (i,j), then one
| of those is not completely unboxed. I guess that *if* we could get the
| passes to continue unbox'ing and ctor-spec'ing, we could end up with a
| fully fused concatMap.
|
| I'll put a complete git repository with criterion + quickcheck modules
| up (soonishly ;-).
|
| Viele Gruesse,
| Christian
|
| * Simon Peyton Jones simo...@microsoft.com [02.02.2015 15:49]:
| I think it'd help you to open a Trac ticket, give a fully-
| reproducible test case, including instructions for how to reproduce,
| and say what isn't happening that should happen.
|
| What's odd is that loop_s29q looks strict in its Int arg, yet isn't
| unboxed. There is a way to get the strictness analysis to run twice -
| flate-dmd-anal. You could try that.
|
| Simon
|
| | -Original Message-
| | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| | boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
| | Sent: 01 February 2015 12:18
| | To: Glasgow-Haskell-Users
| | Subject: stream fusion, concatMap, exisential seed unboxing
| |
| | Hi everybody,
| |
| | I'm playing around with concatMap in stream fusion (the vector
| | package to be exact).
| |
| | concatMapM :: Monad m = (a-m (Stream m b)) - Stream m a -
| | Stream m b concatMapM f (Stream ...) = ...
| |
| | I can get my concatMap to behave nicely and erase all Stream and
| | Step constructors but due to the existential nature of the Stream
| | seeds, they are re-boxed for the inner stream (which is kind-of
| | annoying given that the seed is immediately unboxed again ;-).
| seq
| | doesn't help here.
| |
| | Otherwise, fusion happens for streams and vectors, so that is ok.
| | But boxing kills performance, criterion says.
| |
| | Do we have s.th. in place that could help here? Currently I could
| | use the vector-concatMap which creates intermediate arrays, my
| | version which has boxed seeds, or hermit but that is too
| | inconvenient for non- ghc savy users.
| |
| | Viele Gruesse,
| | Christian
| |
| |
| |
| | Fusing concatMapM:
| |
| | concatMapM f (SM.Stream ostep t _) = SM.Stream step (Left t)
| Unknown
| |where step (Left t) = do r - ostep t
| | case r of
| | SM.Done - return $ SM.Done
| | SM.Skipt' - return $ SM.Skip
| (Left
| | t')
| | SM.Yield a t' - do s - f a
| | return $ SM.Skip
| | (Right (s,t'))
| | step (Right (SM.Stream istep s _,t)) = do r - istep s
| |case r of
| | SM.Done
| -
| | return $ SM.Skip(Left t)
| | SM.Skips'
| -
| | return $ SM.Skip(Right (SM.Stream istep s' Unknown,t))
| | SM.Yield x s'
| | - return $ SM.Yield x (Right (SM.Stream istep s' Unknown,t))
| | {-# INLINE [0] step #-}
| | {-# INLINE [1] concatMapM #-}
| |
| |
RE: Restricted Template Haskell
The new TH is already split into two partshttps://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal as I’m sure you know · Typed TH is for expressions only, and doesn’t have reify, nor any Q monad. · Untyped TH is the wild west Typed TH may get some of what you want? Certainly you want to acknowledge the existing split in your own design. The proposal could do with examples to illustrate what the difficulties are. What bad things happen in the Q monad? Can you give examples of reasoning that would be valid in level 1 but not in level 2. etc. More precision please! Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Greg Weber Sent: 30 January 2015 23:39 To: ghc-d...@haskell.org; GHC users Cc: David Terei; Maxwell Swadling Subject: Restricted Template Haskell Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stream fusion, concatMap, exisential seed unboxing
Ah, well, if it's really the concat/concatMap problem then I'm really not sure
how to crack it.
But there are lots of smart people on this list, so maybe someone else can.
The fewer dependencies your test case has the better. eg Don't use criterion;
this stuff is huge: you get 10G of allocation in your test run instead of 10M.
Or something.
Simon
| -Original Message-
| From: Christian Höner zu Siederdissen
| [mailto:choe...@tbi.univie.ac.at]
| Sent: 02 February 2015 16:02
| To: Simon Peyton Jones
| Cc: Glasgow-Haskell-Users
| Subject: Re: stream fusion, concatMap, exisential seed unboxing
|
| Sure, no problem!
|
| Btw. this is not a 'bug' in the usual sense. It is the (neverending)
| concatMap + stream fusion story.
| https://ghc.haskell.org/trac/ghc/ticket/915
| I'm playing a bit with trying to get GHC to look through the
| existential seed elements and have it constructor-specialize them.
|
| Unfortunately, unbox/spec fails with more complex seeds for now. For
| the more simple cases like the one below, the extra strictness pass
| works (cool, thanks!). These are sometimes enough if you have just
| concatMap (\i - [i .. j]) stuff.
|
| However, if the internal stream state is, say, a pair (i,j), then one
| of those is not completely unboxed. I guess that *if* we could get the
| passes to continue unbox'ing and ctor-spec'ing, we could end up with a
| fully fused concatMap.
|
| I'll put a complete git repository with criterion + quickcheck modules
| up (soonishly ;-).
|
| Viele Gruesse,
| Christian
|
| * Simon Peyton Jones simo...@microsoft.com [02.02.2015 15:49]:
| I think it'd help you to open a Trac ticket, give a fully-
| reproducible test case, including instructions for how to reproduce,
| and say what isn't happening that should happen.
|
| What's odd is that loop_s29q looks strict in its Int arg, yet isn't
| unboxed. There is a way to get the strictness analysis to run twice -
| flate-dmd-anal. You could try that.
|
| Simon
|
| | -Original Message-
| | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| | boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
| | Sent: 01 February 2015 12:18
| | To: Glasgow-Haskell-Users
| | Subject: stream fusion, concatMap, exisential seed unboxing
| |
| | Hi everybody,
| |
| | I'm playing around with concatMap in stream fusion (the vector
| | package to be exact).
| |
| | concatMapM :: Monad m = (a-m (Stream m b)) - Stream m a -
| | Stream m b concatMapM f (Stream ...) = ...
| |
| | I can get my concatMap to behave nicely and erase all Stream and
| | Step constructors but due to the existential nature of the Stream
| | seeds, they are re-boxed for the inner stream (which is kind-of
| | annoying given that the seed is immediately unboxed again ;-).
| seq
| | doesn't help here.
| |
| | Otherwise, fusion happens for streams and vectors, so that is ok.
| | But boxing kills performance, criterion says.
| |
| | Do we have s.th. in place that could help here? Currently I could
| | use the vector-concatMap which creates intermediate arrays, my
| | version which has boxed seeds, or hermit but that is too
| | inconvenient for non- ghc savy users.
| |
| | Viele Gruesse,
| | Christian
| |
| |
| |
| | Fusing concatMapM:
| |
| | concatMapM f (SM.Stream ostep t _) = SM.Stream step (Left t)
| Unknown
| |where step (Left t) = do r - ostep t
| | case r of
| | SM.Done - return $ SM.Done
| | SM.Skipt' - return $ SM.Skip
| (Left
| | t')
| | SM.Yield a t' - do s - f a
| | return $ SM.Skip
| | (Right (s,t'))
| | step (Right (SM.Stream istep s _,t)) = do r - istep s
| |case r of
| | SM.Done
| -
| | return $ SM.Skip(Left t)
| | SM.Skips'
| -
| | return $ SM.Skip(Right (SM.Stream istep s' Unknown,t))
| | SM.Yield x s'
| | - return $ SM.Yield x (Right (SM.Stream istep s' Unknown,t))
| | {-# INLINE [0] step #-}
| | {-# INLINE [1] concatMapM #-}
| |
| | testConcatMapM :: Int - Int
| | testConcatMapM k = seq k $ U.unId
| | . SM.foldl' (+) 0
| | . concatMap (\i - SM.enumFromTo 5 k)
| | $ SM.enumFromTo 3 k {-# NOINLINE testConcatMapM
| | #-}
| |
| | CORE:
| |
| | testConcatMapM
| | testConcatMapM =
| |\ k_aCA -
| | let! { I# ipv_s1xv ~ _ - k_aCA } in ### inner loop
| | letrec {
| |$s$wfoldlM'_loop_s29q
| |
Re: Restricted Template Haskell
Hi Simon, I am just starting the proposal: gathering interested parties and pointers to related information. Thanks for the pointer to Typed Template Haskell. I was actually unaware of the extent to which Typed Template Haskell is restricted. I have not seen any usage of Typed Template Haskell in the wild or been able to use it myself unfortunately due to backwards compatibility needs (once the next GHC release is out libraries will start to consider dropping 7.6 support and we will see more usage, although Ubuntu still ships 7.6 by default). I will study Typed Template Haskell. Greg Weber On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones simo...@microsoft.com wrote: The new TH is already split into two parts https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal as I’m sure you know · Typed TH is for expressions only, and doesn’t have reify, nor any Q monad. · Untyped TH is the wild west Typed TH may get some of what you want? Certainly you want to acknowledge the existing split in your own design. The proposal could do with examples to illustrate what the difficulties are. What bad things happen in the Q monad? Can you give examples of reasoning that would be valid in level 1 but not in level 2. etc. More precision please! Simon *From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Greg Weber *Sent:* 30 January 2015 23:39 *To:* ghc-d...@haskell.org; GHC users *Cc:* David Terei; Maxwell Swadling *Subject:* Restricted Template Haskell Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
Hi Mark, On 2015-01-28 at 04:31:29 +0100, Mark Lentczner wrote: I've just built a bindist under 10.10, but just normal not expressly llvm. I'll test this in a bit then post it -- but might be sometime tomorrow before it is up. How's progress on this btw? Are you also working on a GHC 7.8.4 OSX bindist by any chance? Cheers, hvr ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
