Re: template haskell vs. -prof
I agree that mixing template haskell with -prof can be tricky. It's easier if you turn off dynamic linking entirely. As for multi-line string literals, I also think that an explicit syntax would be nice. Until then, I usually use: unlines [ Line 1 , Line 2 ] which ends up being pretty maintainable and easy to read. On Fri Jan 23 2015 at 6:16:46 AM Evan Laforge qdun...@gmail.com wrote: I ran into trouble compiling template haskell with -prof, and came across the ghc manual 7.9.4. Using Template Haskell with Profiling. Unfortunately I can't use its advice directly since I put profiling and non-profiling .o files into different directories. But in principle it seems it should work, I just have to get ghc to load TH from the debug build directory, which is built with -dynamic, while continuing to load from the profile build directory. But are there flags to get it to do that? I'm using -osuf .hs.o -ibuild/profile/obj. If I put :build/debug/obj on the -i line, it still seems to find the profiling one. The ghc manual advice probably gets around it by using different -osufs... I guess TH somehow ignores -osuf? Except when I compile the debug version with osuf, if finds them fine, so I don't really know how it works. Is there a way I can directly tell TH where to look? It seems awkward to rely on all these implicit and seemingly undocumented heuristics. And, this is somewhat beside the point, but shouldn't TH theoretically be able to load directly from .hs and compile to bytecode like ghci can do if it doesn't find the .o file? And, even more beside the point, the only reason I'm messing with TH is for a really simple (one line) multi-line string literal quasiquote. Surely I'm not the only person who would enjoy a -XMultiLineStringLiteral extension? The alternative seems to be a program to add or strip all of the \n\s, and when I want to edit, copy out, strip, edit, paste back in, add back. At that point maybe it's easier to just get used to all the \s... but then indentation is all a bit off due to the leading \. ___ 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: Fwd: UNPACK Existential datatype
Please take a took at that commit, UNPACK was also handled there, despite
commit message do not explicitly state this.
On Jan 23, 2015 11:49 AM, Roman Cheplyaka r...@ro-che.info wrote:
How is parsing of the *NOUNPACK* pragma relevant here?
On 23/01/15 10:45, Alexander V Vershilov wrote:
Hi.
As far as I understand it was fixed as:
commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Dec 1 17:07:48 2014 +
Fix parser for UNPACK pragmas
{-# NOUNPACK #-}
{-# NOUNPACK #-} !
were being parsed the same way. The former was wrong.
Thanks to Alan Zimmerman for pointing this out
So it will fix is in 7.10. And I can't reproduce this anymore on
ghc-HEAD.
On 20 January 2015 at 17:35, Roman Cheplyaka r...@ro-che.info wrote:
Interesting question. I managed to trace this to:
compiler/basicTypes/MkId.hs:699
isUnpackableType fam_envs ty
| Just (tc, _) - splitTyConApp_maybe ty
, Just con - tyConSingleAlgDataCon_maybe tc
, isVanillaDataCon con
= ok_con_args (unitNameSet (getName tc)) con
| otherwise
= False
where isVanillaDataCon is defined as:
dcVanilla :: Bool,
-- True = This is a vanilla Haskell 98 data constructor
-- Its type is of form
-- forall a1..an . t1 - ... tm - T a1..an
-- No existentials, no coercions, nothing.
There's no explanation why this limitation is introduced; it might be
just a conservative one.
On 20/01/15 15:08, Nicholas Clarke wrote:
I'd like to be able to use the UNPACK pragma on an existentially
quantified datatype. So as in the below example:
{-# LANGUAGE ExistentialQuantification #-}
data Foo = forall a. Show a = Foo !a
instance Show Foo where
show (Foo a) = Foo! ++ show a
data Bar =
Bar {-# UNPACK #-} !Foo
deriving (Show)
main :: IO ()
main = do
let foo = Foo Hello
bar = Bar foo
print bar
I would expect the `Foo` constructor to be unpacked into Bar, as if I
had written:
data Bar = forall a. Show a = Bar !a
However, instead I get the 'Ignoring unusable UNPACK pragma on the
first
argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
workaround to get it to do so?
___
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: Fwd: UNPACK Existential datatype
I did. The rest is whitespace; @git show -w 1d32a85@ shows only one
changed line (NOUNPACK).
On 23/01/15 10:53, Alexander V Vershilov wrote:
Please take a took at that commit, UNPACK was also handled there,
despite commit message do not explicitly state this.
On Jan 23, 2015 11:49 AM, Roman Cheplyaka r...@ro-che.info
mailto:r...@ro-che.info wrote:
How is parsing of the *NOUNPACK* pragma relevant here?
On 23/01/15 10:45, Alexander V Vershilov wrote:
Hi.
As far as I understand it was fixed as:
commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones simo...@microsoft.com
mailto:simo...@microsoft.com
Date: Mon Dec 1 17:07:48 2014 +
Fix parser for UNPACK pragmas
{-# NOUNPACK #-}
{-# NOUNPACK #-} !
were being parsed the same way. The former was wrong.
Thanks to Alan Zimmerman for pointing this out
So it will fix is in 7.10. And I can't reproduce this anymore on
ghc-HEAD.
On 20 January 2015 at 17:35, Roman Cheplyaka r...@ro-che.info
mailto:r...@ro-che.info wrote:
Interesting question. I managed to trace this to:
compiler/basicTypes/MkId.hs:699
isUnpackableType fam_envs ty
| Just (tc, _) - splitTyConApp_maybe ty
, Just con - tyConSingleAlgDataCon_maybe tc
, isVanillaDataCon con
= ok_con_args (unitNameSet (getName tc)) con
| otherwise
= False
where isVanillaDataCon is defined as:
dcVanilla :: Bool,
-- True = This is a vanilla Haskell 98 data constructor
-- Its type is of form
-- forall a1..an . t1 - ... tm - T a1..an
-- No existentials, no coercions, nothing.
There's no explanation why this limitation is introduced; it might be
just a conservative one.
On 20/01/15 15:08, Nicholas Clarke wrote:
I'd like to be able to use the UNPACK pragma on an existentially
quantified datatype. So as in the below example:
{-# LANGUAGE ExistentialQuantification #-}
data Foo = forall a. Show a = Foo !a
instance Show Foo where
show (Foo a) = Foo! ++ show a
data Bar =
Bar {-# UNPACK #-} !Foo
deriving (Show)
main :: IO ()
main = do
let foo = Foo Hello
bar = Bar foo
print bar
I would expect the `Foo` constructor to be unpacked into Bar, as
if I
had written:
data Bar = forall a. Show a = Bar !a
However, instead I get the 'Ignoring unusable UNPACK pragma on
the first
argument of ‘Bar’' warning. Is there a reason this shouldn't
work, or a
workaround to get it to do so?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
mailto: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: Fwd: UNPACK Existential datatype
Hi.
As far as I understand it was fixed as:
commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Dec 1 17:07:48 2014 +
Fix parser for UNPACK pragmas
{-# NOUNPACK #-}
{-# NOUNPACK #-} !
were being parsed the same way. The former was wrong.
Thanks to Alan Zimmerman for pointing this out
So it will fix is in 7.10. And I can't reproduce this anymore on
ghc-HEAD.
On 20 January 2015 at 17:35, Roman Cheplyaka r...@ro-che.info wrote:
Interesting question. I managed to trace this to:
compiler/basicTypes/MkId.hs:699
isUnpackableType fam_envs ty
| Just (tc, _) - splitTyConApp_maybe ty
, Just con - tyConSingleAlgDataCon_maybe tc
, isVanillaDataCon con
= ok_con_args (unitNameSet (getName tc)) con
| otherwise
= False
where isVanillaDataCon is defined as:
dcVanilla :: Bool,
-- True = This is a vanilla Haskell 98 data constructor
-- Its type is of form
-- forall a1..an . t1 - ... tm - T a1..an
-- No existentials, no coercions, nothing.
There's no explanation why this limitation is introduced; it might be
just a conservative one.
On 20/01/15 15:08, Nicholas Clarke wrote:
I'd like to be able to use the UNPACK pragma on an existentially
quantified datatype. So as in the below example:
{-# LANGUAGE ExistentialQuantification #-}
data Foo = forall a. Show a = Foo !a
instance Show Foo where
show (Foo a) = Foo! ++ show a
data Bar =
Bar {-# UNPACK #-} !Foo
deriving (Show)
main :: IO ()
main = do
let foo = Foo Hello
bar = Bar foo
print bar
I would expect the `Foo` constructor to be unpacked into Bar, as if I
had written:
data Bar = forall a. Show a = Bar !a
However, instead I get the 'Ignoring unusable UNPACK pragma on the first
argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
workaround to get it to do so?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Alexander
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: template haskell vs. -prof
On 21:23, Fri, Jan 23, 2015 Evan Laforge qdun...@gmail.com wrote: On Sat, Jan 24, 2015 at 2:38 AM, John Lato jwl...@gmail.com wrote: I agree that mixing template haskell with -prof can be tricky. It's easier if you turn off dynamic linking entirely. But that's the thing, I do turn of dynamic linking because I have to for -prof, but TH seems to require it. I mean to use a ghc that's been built without dynamic support. unlines [ Line 1 , Line 2 ] which ends up being pretty maintainable and easy to read. Yeah, I use this one too. It's ok for short things, but it can still be annoying to edit. My editor doesn't know how to do line wrapping for it. Then you can't just copy paste in and out. And tabs get messed up because you're already indented, and probably not in a tabstop multiple... though I guess I could align it so it was. And of course since there's prefix gunk, folding doesn't work inside. Yeah, those are all problematic. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: template haskell vs. -prof
On Sat, Jan 24, 2015 at 1:29 PM, John Lato jwl...@gmail.com wrote: I mean to use a ghc that's been built without dynamic support. Oh, so if the whole compiler is not dynamic then TH no longer requires .dyn_o files? Interesting. I know they've put a lot of work into this and staging is hard, so I assume there are good reasons for it :) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: template haskell vs. -prof
On Sat, Jan 24, 2015 at 2:38 AM, John Lato jwl...@gmail.com wrote: I agree that mixing template haskell with -prof can be tricky. It's easier if you turn off dynamic linking entirely. But that's the thing, I do turn of dynamic linking because I have to for -prof, but TH seems to require it. unlines [ Line 1 , Line 2 ] which ends up being pretty maintainable and easy to read. Yeah, I use this one too. It's ok for short things, but it can still be annoying to edit. My editor doesn't know how to do line wrapping for it. Then you can't just copy paste in and out. And tabs get messed up because you're already indented, and probably not in a tabstop multiple... though I guess I could align it so it was. And of course since there's prefix gunk, folding doesn't work inside. Actually, if anyone knows about a vim hack to make 'gq' handle either this style or the backslash style, it would be much appreciated... maybe I should try to create one. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: UNPACK Existential datatype
How is parsing of the *NOUNPACK* pragma relevant here?
On 23/01/15 10:45, Alexander V Vershilov wrote:
Hi.
As far as I understand it was fixed as:
commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Dec 1 17:07:48 2014 +
Fix parser for UNPACK pragmas
{-# NOUNPACK #-}
{-# NOUNPACK #-} !
were being parsed the same way. The former was wrong.
Thanks to Alan Zimmerman for pointing this out
So it will fix is in 7.10. And I can't reproduce this anymore on
ghc-HEAD.
On 20 January 2015 at 17:35, Roman Cheplyaka r...@ro-che.info wrote:
Interesting question. I managed to trace this to:
compiler/basicTypes/MkId.hs:699
isUnpackableType fam_envs ty
| Just (tc, _) - splitTyConApp_maybe ty
, Just con - tyConSingleAlgDataCon_maybe tc
, isVanillaDataCon con
= ok_con_args (unitNameSet (getName tc)) con
| otherwise
= False
where isVanillaDataCon is defined as:
dcVanilla :: Bool,
-- True = This is a vanilla Haskell 98 data constructor
-- Its type is of form
-- forall a1..an . t1 - ... tm - T a1..an
-- No existentials, no coercions, nothing.
There's no explanation why this limitation is introduced; it might be
just a conservative one.
On 20/01/15 15:08, Nicholas Clarke wrote:
I'd like to be able to use the UNPACK pragma on an existentially
quantified datatype. So as in the below example:
{-# LANGUAGE ExistentialQuantification #-}
data Foo = forall a. Show a = Foo !a
instance Show Foo where
show (Foo a) = Foo! ++ show a
data Bar =
Bar {-# UNPACK #-} !Foo
deriving (Show)
main :: IO ()
main = do
let foo = Foo Hello
bar = Bar foo
print bar
I would expect the `Foo` constructor to be unpacked into Bar, as if I
had written:
data Bar = forall a. Show a = Bar !a
However, instead I get the 'Ignoring unusable UNPACK pragma on the first
argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
workaround to get it to do so?
___
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: Fwd: UNPACK Existential datatype
Very strange, I was referring to:
git show 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Dec 1 17:07:48 2014 +
Fix parser for UNPACK pragmas
{-# NOUNPACK #-}
{-# NOUNPACK #-} !
were being parsed the same way. The former was wrong.
Thanks to Alan Zimmerman for pointing this out
diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y
index e3f82ce..c7143ae 100644
--- a/compiler/parser/Parser.y
+++ b/compiler/parser/Parser.y
@@ -1350,11 +1350,11 @@ sigtypes1 :: { (OrdList (LHsType RdrName)) }
-- Always HsForAllTys
-- Types
strict_mark :: { Located ([AddAnn],HsBang) }
-: '!'{ sL1 $1 ([],HsUserBang Nothing
True) }
-| '{-# UNPACK' '#-}' { sLL $1 $ ([mo $1,mc
$2],HsUserBang (Just True) False) }
-| '{-# NOUNPACK' '#-}' { sLL $1 $ ([mo $1,mc
$2],HsUserBang (Just False) True) }
-| '{-# UNPACK' '#-}' '!' { sLL $1 $ ([mo $1,mc
$2],HsUserBang (Just True) True) }
-| '{-# NOUNPACK' '#-}' '!' { sLL $1 $ ([mo $1,mc
$2],HsUserBang (Just False) True) }
+: '!'{ sL1 $1([],
HsUserBang Nothing True) }
+| '{-# UNPACK' '#-}' { sLL $1 $ ([mo $1,mc $2],
HsUserBang (Just True) False) }
+| '{-# NOUNPACK' '#-}' { sLL $1 $ ([mo $1,mc $2],
HsUserBang (Just False) False) }
+| '{-# UNPACK' '#-}' '!' { sLL $1 $ ([mo $1,mc $2],
HsUserBang (Just True) True) }
+| '{-# NOUNPACK' '#-}' '!' { sLL $1 $ ([mo $1,mc $2],
HsUserBang (Just False) True) }
-- Although UNPACK with no '!' is illegal, we get a
-- better error message if we parse it here
I'm not sure that is there were no other commits that that are
related to the issue. TBH, I can't see warnings for this example
program that was mentioned in this thread using GHC-HEAD,
but having either `{-# UNPACK #-} !` or `!` or `{-# UNPACK #-}`
do not change core output, regardless whether -fno-unbox-small-strict-fields
or -fno-unbox-strict-fields provided or not.
On 23 January 2015 at 11:59, Roman Cheplyaka r...@ro-che.info wrote:
I did. The rest is whitespace; @git show -w 1d32a85@ shows only one
changed line (NOUNPACK).
On 23/01/15 10:53, Alexander V Vershilov wrote:
Please take a took at that commit, UNPACK was also handled there,
despite commit message do not explicitly state this.
On Jan 23, 2015 11:49 AM, Roman Cheplyaka r...@ro-che.info
mailto:r...@ro-che.info wrote:
How is parsing of the *NOUNPACK* pragma relevant here?
On 23/01/15 10:45, Alexander V Vershilov wrote:
Hi.
As far as I understand it was fixed as:
commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones simo...@microsoft.com
mailto:simo...@microsoft.com
Date: Mon Dec 1 17:07:48 2014 +
Fix parser for UNPACK pragmas
{-# NOUNPACK #-}
{-# NOUNPACK #-} !
were being parsed the same way. The former was wrong.
Thanks to Alan Zimmerman for pointing this out
So it will fix is in 7.10. And I can't reproduce this anymore on
ghc-HEAD.
On 20 January 2015 at 17:35, Roman Cheplyaka r...@ro-che.info
mailto:r...@ro-che.info wrote:
Interesting question. I managed to trace this to:
compiler/basicTypes/MkId.hs:699
isUnpackableType fam_envs ty
| Just (tc, _) - splitTyConApp_maybe ty
, Just con - tyConSingleAlgDataCon_maybe tc
, isVanillaDataCon con
= ok_con_args (unitNameSet (getName tc)) con
| otherwise
= False
where isVanillaDataCon is defined as:
dcVanilla :: Bool,
-- True = This is a vanilla Haskell 98 data constructor
-- Its type is of form
-- forall a1..an . t1 - ... tm - T a1..an
-- No existentials, no coercions, nothing.
There's no explanation why this limitation is introduced; it might be
just a conservative one.
On 20/01/15 15:08, Nicholas Clarke wrote:
I'd like to be able to use the UNPACK pragma on an existentially
quantified datatype. So as in the below example:
{-# LANGUAGE ExistentialQuantification #-}
data Foo = forall a. Show a = Foo !a
instance Show Foo where
show (Foo a) = Foo! ++ show a
data Bar =
Bar {-# UNPACK #-} !Foo
deriving (Show)
main :: IO ()
main = do
let foo = Foo Hello
bar = Bar foo
print bar
I would expect the `Foo` constructor to be unpacked into Bar, as
if I
had written:
data Bar = forall a. Show a = Bar !a
However, instead I get the 'Ignoring unusable UNPACK pragma on
the first
argument
template haskell vs. -prof
I ran into trouble compiling template haskell with -prof, and came across the ghc manual 7.9.4. Using Template Haskell with Profiling. Unfortunately I can't use its advice directly since I put profiling and non-profiling .o files into different directories. But in principle it seems it should work, I just have to get ghc to load TH from the debug build directory, which is built with -dynamic, while continuing to load from the profile build directory. But are there flags to get it to do that? I'm using -osuf .hs.o -ibuild/profile/obj. If I put :build/debug/obj on the -i line, it still seems to find the profiling one. The ghc manual advice probably gets around it by using different -osufs... I guess TH somehow ignores -osuf? Except when I compile the debug version with osuf, if finds them fine, so I don't really know how it works. Is there a way I can directly tell TH where to look? It seems awkward to rely on all these implicit and seemingly undocumented heuristics. And, this is somewhat beside the point, but shouldn't TH theoretically be able to load directly from .hs and compile to bytecode like ghci can do if it doesn't find the .o file? And, even more beside the point, the only reason I'm messing with TH is for a really simple (one line) multi-line string literal quasiquote. Surely I'm not the only person who would enjoy a -XMultiLineStringLiteral extension? The alternative seems to be a program to add or strip all of the \n\s, and when I want to edit, copy out, strip, edit, paste back in, add back. At that point maybe it's easier to just get used to all the \s... but then indentation is all a bit off due to the leading \. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: UNPACK Existential datatype
I think this is a very reasonable suggestion. It would take some work to
implement, but nothing fundamental.
Simon
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Nicholas Clarke
Sent: 20 January 2015 13:08
To: glasgow-haskell-users@haskell.org
Subject: Fwd: UNPACK Existential datatype
I'd like to be able to use the UNPACK pragma on an existentially quantified
datatype. So as in the below example:
{-# LANGUAGE ExistentialQuantification #-}
data Foo = forall a. Show a = Foo !a
instance Show Foo where
show (Foo a) = Foo! ++ show a
data Bar =
Bar {-# UNPACK #-} !Foo
deriving (Show)
main :: IO ()
main = do
let foo = Foo Hello
bar = Bar foo
print bar
I would expect the `Foo` constructor to be unpacked into Bar, as if I had
written:
data Bar = forall a. Show a = Bar !a
However, instead I get the 'Ignoring unusable UNPACK pragma on the first
argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
workaround to get it to do so?
Cheers,
Nick
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to remove a cabal package from the local system?
Am Donnerstag, 22. Januar 2015, 11:19:37 schrieb Albert Y. C. Lai: On 2015-01-21 10:36 AM, Volker Wysk wrote: I have installed/registered a new version of a package with cabal by accident. How can I remove it again? See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact, read the whole thing. This describes what Evan is doing in his script. Bye Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
